Comment by treespace8
3 hours ago
For me it breaks the rule of "Network of trust".
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.
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.
Open source projects themselves have reputation, regardless of how they are governed specifically.
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 don't think pairing, nor TDD come anywhere close to the abdication of responsibility that agentic programming does.
Putting pair programming and TDD in the same box as agentic development (with, as you assume, zero review of the code) seems...
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.
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.
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 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.
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.
> 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.