Nobody Understands the Product Anymore, and That's the Real AI Risk
Two scenes, both increasingly common:
A bug shows up. It’s not obvious. You go to the team for an explanation, and there isn’t one. The developer who “built” the feature doesn’t fully understand what they built. The team lead doesn’t know what features their own team is actually shipping, because they, too, just handed requirements to a model and got a task breakdown back.
You ask a simple question. You get back a hundred lines of AI-generated copy-paste in response, and no time to actually read it.
Neither of these is a hypothetical. They’re what happens when “understanding the product” quietly stops being a requirement of the job.
The Shift Nobody Voted On
It used to work like this: to build a feature, a developer had to understand the product: what it did, why, and how the pieces fit together. That understanding was the actual bottleneck, and also the actual value a developer brought.
Increasingly, it works differently: requirements go to an AI, the AI hands back a set of pre-broken-down tasks, code gets written, and it ships. The understanding step, the part that used to be unavoidable, has become optional. And when a step becomes optional, it starts quietly disappearing.
Where It Actually Breaks
The failure isn’t hypothetical or distant. It shows up in ordinary week-to-week work:
- The unexplainable bug. Nobody on the team can walk through why it happened, because nobody fully holds a model of how that part of the system works. The code exists; the understanding of the code doesn’t.
- The team lead who’s also lost the thread. This one is more uncomfortable than it sounds. It’s not just individual contributors outsourcing understanding. Team leads are doing it too, relaying requirements to a model and receiving a task list back, without necessarily holding the “why” themselves.
Two Takes From the Room
When this gets raised, the reactions split roughly two ways.
Take one: this is fine, actually. It’s just a role change. Developers now have the time freed up from writing code by hand to spend on understanding “the model” and “the product” instead. In this view, there are no more purely human developers in the old sense. Everyone is effectively a team lead now, managing an AI collaborator rather than typing every line themselves. The job didn’t disappear; it moved up a level.
Take two, harder-edged: if nobody can explain what was built, that’s not really an AI problem. It’s an accountability problem. “Ask Claude” isn’t a substitute for a human who’s accountable for a decision. If a team genuinely has no person who can explain what they shipped and why, the issue isn’t the tooling. It’s that responsibility got diffused past the point where anyone actually owns it, and that’s a staffing and process failure, not something AI did to the team.
Both takes can be true at once, which is what makes this uncomfortable rather than simple. The role is changing, and some of what looks like “the new normal” is actually a gap opening up that nobody’s decided to own yet.
The Uncomfortable Question
Is this a temporary growing pain (the awkward phase every team goes through while figuring out how to work with AI collaborators) or a permanent redefinition of what “being a developer” even means?
And more practically: what would it actually take to keep understanding from quietly evaporating? Candidates worth testing:
- Review norms that require the reviewer (human) to be able to explain the change, not just approve it
- Explicit ownership rules: someone’s name is accountable for a feature, independent of who or what wrote the code
- Documentation requirements that capture why a decision was made, not just what the code does
None of these are exotic. They’re the same disciplines good engineering teams have always needed. The difference is that AI-assisted development makes it possible to skip them entirely and still ship. That means, for the first time, skipping them is no longer self-correcting. The code still works. The bugs still get “fixed.” And the understanding just isn’t there when you need it.
Where does your team draw the line? Has anyone actually written down a rule for this, or is everyone just finding out the hard way?