Software works because someone is accountable for it. Pair Programming, Test Driven Development, and now Agentic coding all to one degree or another damage the network of trust.
- Pair Programming (There is no one person accountable for the change.)
- Test Driven Development (The test pass, so my software is good)
- Agentic Coding (My prompt was good, so my software is good)
AI is great for software development... As long as you review and understand each change it makes. Because YOU are going to be held accountable for what the software does.
> Software works because someone is accountable for it.
When software works, it's because there were layers of measures to ensure quality. In order to set up and maintain those measures, you need to establish accountability for quality, not for individual changes.
In fact, given that making mistakes is perfectly human, I would argue that insisting on accountability for individual changes is counterproductive. Since I'm a grumpy old fart, I'll illustrate what I mean with a story ;)
At one of the places I've worked, there was this workplace survey they would do twice a year, one of those anonymous surveys where they give you a bunch of statements and have you select options ranging from "strongly disagree" to "strongly agree". One of the questions that has stuck with me was "on my team, it feels safe to make mistakes".
For the first couple of years or so, I didn't really grok the deeper meaning of that question. I simply interpreted it as "my team is forgiving of minor fuck-ups" and didn't think more about it. I'm not sure what made it click, but one day I realized that it's not just about not working under a martinet. It's about minimizing the chances of a mistake causing problems and maximizing the ease of recovery from such problems if they do occur.
Being able to point a finger at me or one of my teammates and say "this is the person that screwed up" is not what makes software work.
yeah I get the same vibes from the book "psychology of computer programming", and one of the things that I liked in this book (and for the most part, missed in actual employment) was the confidence you get when you can run your code by other folks, you know, code review type things. I was also quite surprised by the bandwidth that pair programming brought to the table, two pairs of eyes on a screen with conversations is quite the different experience than one siloed guy off in a cubicle.
Mistakes are a cost of doing business with engineering, even the kinda sorta engineering programming looks like. An environment that helps to prevent mistakes from making it through testing and review should be the focus, but I guess there is value in identifying an individual as being especially mistake prone.
How does opensource software work when nobody is accountable when I run software from GitHub?
This is the exact mentality behind corporate software and why nobody gets fired for using IBM, Oracle, Azure...
Accountability is a poor proxy for quality because there are so many ways to frame an incident never those responsible really get accountable.
Software works because developers care about the product. If something goes wrong the entire team is accountable, so they work together on something as one.
Yes, you look at stars, issues and activity to infer trust, but there is no accountability, the licenses are clear about that that software is distributed as is
I started thinking about agentic programming from a totally different perspective.
Personal accountability in software development is actually hard, and less useful than it seems. What good is it if you discover a 12 y.o. vulnerability and can blame a specific person? (Like the recent one in PHP?) You may learn the name of that programmer who made the mistake, but it does not really tell you anything about that person, unless their overall record is terrible, and you are not entitled to any damages anyway.
In closed source, this is even worse. So a certain Windows function sucks. Now what. You never learn any other provenience than "Microsoft did it". Tough luck even getting support, and you certainly don't get your license fee back. This sort of accountability is worse than useless.
The only exception I see is knowledge within a specific development team. We usually know what sort of errors our colleagues are prone to, and we may be able to work around their personal weak spots.
Agentic coding done well has a dimension of trust that human coding cannot achieve. I can tell my agents to aim for 100 per cent test coverage without overburdening them or running out of budget and time. I can ask other agents and other models to review code written by the first agents, and then again. Every layer of such review adds some credibility to the result, and its mechanistic character ensures certain level of repeatability. Sure, it can happen that all involved mechanisms share the same weakness and let a particular bug through. But it is similar to several sieves over one another lining up perfectly to let something through, and that is quite rare.
If I had to choose, I would trust code designed, implemented and reviewed by three different SOTA models over code designed, implemented and reviewed by three median programmers today. Three elite programmers would have been a different story, but that would also be expensive like hell, and much like you don't eat most of your dinners in a Michelin restaurant, you have to economize with your code development in a similar way.
For me programming is about reducing complexity, in one way or another. By reducing needless CPU cycles or RAM, or by reducing the complexity of the code when I read it, making it "more logical", which is of course in tension with what would be the absolute most optimal (e.g. perfectly optimized assembly for everything). You make low-level things to turn into higher-level functions to do even higher level things with, and how joyful that is to navigate and use has a lot, if not everything, to do with how things are named.
LLM are great at creating code, obviously, but what is your (or anyone's) experience with them making code "better" in that way? Finding patterns in messy things and making it more "tidy", renaming things to be less verbose yet still descriptive, or even more descriptive, that sort of thing? Where you can "apply" agents to a codebase and have it come out more accessible to LLM and humans, because it's better code and less of it, if you will. I know rewriting things is more enticing and often more practically useful, but are there efforts/experiment in that direction? With actual code I can look at, comparing before and after?
I agree it would be nice to see some more formal experiments in this space but you can very easily experiment with this yourself. I had Claude rewrite a C++ simulation code to better adhere to the C++ core guidelines and it did a good enough job. Hard to quantify how good it did...
It's not about blaming a person, it's having a person or organization that has reputation to lose or gain and resources to fix it. Responsible AI coding usage increases both velocity and quality, but it's very easy to have issues become the responsibility of nobody.
This comment makes me despair. Pair Programming and TDD, as well as other aspects of Extreme Programming, were explicitly introduced as practices that put the human, with needs and feelings, at the center of the software development process. Your analogy is wildly off base, so much so that I suspect a trolling attempt (if that's the case, well played)
They have a HN history going back nearly a decade (pre-LLM) with comments mostly not looking like trolling to me. My first guess would be that they've just been exposed to a bad implementation of Pair Programming and TDD (or even a "good" implementation in an environment where it's not a good fit), and that's where they developed those opinions.
TDD especially has a lot of critics. Some of that's justified. Some of it is just a difference in thought methodologies (e.g., a fraction of developers "think" through a problem by writing code, and the "tests" mandated by TDD physically can't meaningfully appear till after some implementation has happened). If a rando developer thinks negatively of it, that's not news to me. If they haven't tried it much and misattribute the exact cause of those negative opinions to be able to form a nice story-centric through-line, that's also not surprising. I'd be much more inclined to believe they're a developer who you disagree with than a deliberate troll. Who knows.
I don't get this comment, you say it breaks trust because it's unknown who is accountable, and then you say you (the author) is accountable. So where is the trust broken?
Also your examples are wrong, regardless of pair programming or TDD, there is always a single committer, who is to be held accountable. How you achieve that commit in the past, copy-pasting from stackoverflow, or some auto-expand snippet automation from the IDE - so any tooling - does not matter. Agentic development is also such a tool, thus does not change trust.
The agent runner, or committer, a single human, is to be held accountable. That responsibility is - and always was - the most important role of a programmer.
> Agentic Coding (My prompt was good, so my software is good)
You are far, far behind where the industry currently is, and where the puck is moving with statements like that. Check out how pstack (from poteto) handles this, and look at what Spawn (game company) is doing as a couple off the top of my head examples.
100%. It's the accountability that I find most compelling.
My AI assisted software has far FEWER bugs than when I hand-coded everything.
Why? I use it to improve and augment my judgement, rather than replace it. Critical analysis, rapid PoC spikes, more tests, more documentation. Half the tests may be superfluous, and the documentation might be overly verbose...but there are more good tests, and the documentation is at least PRESENT and consistent.
I think it definitely breaks the "locus" of knowedlge acquisition. You know this dev worked on this component and can tell you about it.
That's not true anymore. All handoffs are "hard won" and everyone gets silo'd.
This stuff is supercharging my development because I'm unaccountable and I choose the level of technical intricacy based on what I expect to do with any piece. All the user facing stuff is not going to matter. Whoever comes after me will have docs, tests and code, but will need to remake the world in which the assumptions are made.
I am wondering if a combination of broader/deeper observability attach and synthetic user monitoring can help offset some of this. This may just displace and not mitigate the trust issue, but it seems like a valid product direction for the harness layer given falling token costs.
> Software works because someone is accountable for it.
Good joke.
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
But what have we built on top of software so far? My first thought is that we have made new communities. But most of them are of much poorer quality than what we had in person.
I hope we start to rebuild in person connections again with this technology.
Well it has certainly transformed bureaucratic operations. And I don't mean that in a bad way; superior bureaucracy and logistics was a key to the British Empire.
Software allows us to push computation (intelligence) into our environment.
Telecommunications did that, not really software. Twitter started out as an SMS compatible service remember.
I do think there's something there though: I've spent the last 2 days building an app I've always wanted to build for myself with my computer in the corner running Claude and Claude Remote. Prototypes land on my phone and I don't even look at it for more then a few minutes before doing something else.
It's software, actually useful software, which doesn't take 100s of hours to build.
So I didn't even really spend two days on it: I mostly didn't look at all. I'll spend more time setting the result up on my home server.
Like all automations it's not 100% perfect, and they all require a human to monitor them.
Turning over a problem to a LLM as solved means we won't be able to do the task anymore. Because we will never learn how. We will not know that the LLM has made a mistake, and will be unable to fix it ourselves.
Right now we can correct the LLM, as the years go on we will become unable to do so.
Most people who drive a car have no idea how an engine works. I know and agree it's a scary future, but I wonder if it's really _essential_ to understand things on a deeper level.
Most people are quite capable of understanding higher-order ideas without fully grasping the underlying details too.
Maybe less than we might hope. Not only is the knowledge distributed over the hundreds of people involved in designing a car, there may be conventions/habits of design and manufacture whose purpose has become hazy but are nevertheless important, or details of a design iterated upon whose original motivation is less understood.
Software works because someone is accountable for it. Pair Programming, Test Driven Development, and now Agentic coding all to one degree or another damage the network of trust.
- Pair Programming (There is no one person accountable for the change.) - Test Driven Development (The test pass, so my software is good) - Agentic Coding (My prompt was good, so my software is good)
AI is great for software development... As long as you review and understand each change it makes. Because YOU are going to be held accountable for what the software does.