it's funny - nervous funny, not haha funny - that you think drawing a real issue like this out into the open would focus an organization on solving it.

Agents pretty good at describing how a particular feature works. It's not as dire as you make it seem.

> you can ask the agent to give you an overview of the architecture and then dive into whatever part you want to explore more.

This is actually a cool use that's being explored more and more. I first saw it in the wiki thing from the devin people, and now google released one as well.

Humans are just better at communicating about their process. They will spend hours talking over architectural decisions, implementation issues, writing technical details in commit messages and issue notes, and in this way they not only debug their decisions but socialize knowledge of both the code and the reasons it came to be that way. Communication and collaboration are the real adaptive skills of our species. To the extent AI can aid in those, it will be useful. To the extent it goes off and does everything in a silo, it will ultimately be ignored - much like many developers who attempt this.

I do think the primary strengths of genai are more in comprehension and troubleshooting than generating code - so far. These activities play into the collaboration and communication narrative. I would not trust an AI to clean up cruft or refactor a codebase unsupervised. Even if it did an excellent job, who would really know?

Sure, you can ask the agents to "identify and remove cruft" but I never have any confidence that they actually do that reliably. Sometimes it works. Mostly they just burn tokens, in my experience.

> And it's not like any of your criticisms don't apply to human teams.

Every time the limitations of AI are discussed, we see this unfair standard applied: ideal AI output is compared to the worst human output. We get it, people suck, and sometimes the AI is better.

At least the ways that humans screw up are predictable to me. And I rarely find myself in a gaslighting session with my coworkers where I repeatedly have to tell them that they're doing it wrong, only to be met with "oh my, you're so right!" and watch them re-write the same flawed code over and over again.

Because what we need is not lazy people - we need lazy people with AI? How is this even a justification?

The increasing levels of abstraction work only as long as the abstractions are deterministic (with some limited exceptions - i.e. branch prediction/preloading at CPU level, etc). You can still get into issues with leaky abstractions, but generally they are quite rare in established high->low level language transformations.

This is more akin to manager-level view of the code (who need developers to go and look at the "deterministic" instructions); the abstraction is a lot lot more leaky than high->low level languages.

In the 00s I saw so many C codebases with hand-rolled linked lists where dynamically resized arrays would be more appropriate, "should be big enough" static allocations with no real idea of how to determine that size, etc. Hardly anyone seemed to have a practical understanding of hashes. When you use a higher level language, you get steered towards the practical, fundamental data structures more or less automatically.

even JS doesn't churn as fast as the models powering vibe coding, and that cut & paste node app is still deterministic, compared to what happens when the next version of the model looks at AI-generated code from two years ago...