Real question here, as I'm struggling with this and I'm not finding a lot of evidence to support my inclination (that you are correct).Why would this person be more skilled? And more importantly, what does it mean to be "skilled" in the era of AI?
I'm trying to be open-minded to both sides, but I have senior engineers on my team with a fleet of agents, shipping code they don't fully understand, and... everything is fine. Stuff still breaks, we fix it. Clients ask "How does XYZ work?" and we say, "Not sure, let us get back to you." And they're totally fine with that answer.
Everything within me screams that this is wrong and we should have intimate familiarity with the system, but I cannot find any evidence that the path of "running a team" instead of "building engineering skill" is not going to work out fine in the long-run. (Yes, my comparison between "team" and "engineering skill" is a bit rough but I'm not interested in the semantics.)
All the evidence that I'm seeing in my own business, with senior engineers meeting clients' needs with autonomous agentic teams is that it's all fine, and while there are gaps, it's actually okay. Clients are happy. Software works 80-90% of the team exactly as it should. Bugs are fixed quickly. We ship more in 3 months than we previously could've shipped in a year. I'm baffled and frankly not as advanced as my devs (I still ask questions one by one to my agent, like a Real Caveman!)
It makes me wildly uncomfortable so I'm trying to wrestle with this. I want your statement to be true, but I just don't see evidence of that.
8/20/2026
at
3:38:49 PM
> Software works 80-90% of the team exactly as it should.Either you work in a non-standard field, or your standards for software are way too low.
What software gets to fail 80% of the time? If your ecommerce checkout software fails 1 in 5 times, you don't have an ecommerce business at all, you are dead in the water. If your airline booking software fails for 1 in 5 customers, you are out of business.
99.99% reliability still means 1 in 10000 customers are experiencing an error, which at scale can mean thousands to millions per day. That's completely unacceptable for any software I've ever been involved with writing.
by miyoji
8/20/2026
at
3:53:10 PM
I think you might be taking that number a bit too literally. What I mean is, it works enough that no one is complaining. But, all software has bugs. Some are logic/syntax bugs, and some are intent. "It should do this, but actually does that."The sum of ALL of these classes of bugs is such that our clients haven't complained about the software being particularly faulty. It's impossible to tell if it's more or less buggy than it would've been written entirely by hand, but I suspect it's less buggy than it would be if written by hand.
by adamtaylor_13
8/20/2026
at
8:27:28 PM
I'm with you on this. It feels like it should matter, but everything is pointing to "it doesn't matter as much as you guys say that it matters". I had the same experience at work. I thought we would have way more bugs and problems, yet all I see is the same as ever, but faster. It's eye-opening, honestly
by tuesdaynight
8/21/2026
at
9:40:28 AM
We are seeing the same. We are moving significantly faster and ship more complex stuff, and there are still bugs as they were in the before times, but nothing catastrophic, no gremlins in the machine. Our main worry is about process and communication, not the actual coding really.
by danielbln
8/20/2026
at
9:52:06 PM
I think the biggest issue with LLM generated code is that it's happy to just keep plugging away making a bigger and bigger rat's nest.I spend a lot of time reviewing code and the LLM code works for what the implementer wanted and from the outside things function the way people expected, but inside the code is becoming more and more knotted and incomprehensible.
Now maybe you could point claude at it and say "make the code easy for people to understand too" and no one is bothering to do that. Maybe it's a skill issue and the people around me should be prompting better or revising better.
The only thing I know is that I'm seeing it happen. Code quality is going down, comprehension is not just missing because people didn't author the code, it's getting worse because even when they go to read the code it's become too complex and weird. So now they have to rely on LLMs to tell them what the code they are responsible for is doing and how.
The thing that remains to be seen is if comprehensibility will matter. I can't look at the assembly the compiler outputs and comprehend it and it doesn't bother me. LLM advocates argue the same will become true for code, it won't matter if you understand the code because it only matters that the LLM can comprehend it and keep making it do the things you want.
I'm less inclined to believe that being able to reason about your codebase and make changes to it is something I really want to put into a bunch of hyperscaler company hands. Enshittification tells me that this honey moon of affordable intelligence will reach an end at some point and a lot of companies are going to clamp down on more expensive tokens and a lot of engineers are going to find that they have both let their code comprehension skills atrophy and aren't permitted to take every little question and change to the LLM because it's too costly.
They will crack open the codebase, every changeset with a full comprehensive page of LLM-speak explaining how it addresses the problem, every changeset in isolation reasonable enough, and an end state that is something only an LLM can love.
by ihumanable