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.

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.

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.

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.

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.

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.