The framing most companies get wrong
There's a pattern I keep seeing in how companies talk about adopting AI. They treat it like upgradi...
For further actions, you may consider blocking this person and/or reporting abuse
Great article. I think there is a fifth shift that does not get mentioned much: the team's implicit memory.
Before, the "why it is built this way" lived in the head of the dev who wrote the code. With AI, that "why" often disappears: the code is there, it compiles, but nobody can explain it during a 3am incident.
This is not just a review problem. It is a knowledge capture problem. The orgs I see doing well are investing in the layer above the code: explicit decisions, versioned context, a log of choices. Not to slow AI down, but so generation speed does not destroy traceability.
AI does not replace the org. It forces you to externalize what the org used to keep in people's heads. That might be the real redesign.
I really like "the team's implicit memory" and "knowledge capture problem." Well said.
I've found AI to be incredibly helpful in surfacing common, hidden, and missing knowledge.
But capturing that knowledge is the problem. How many times do we want agents to research an issue that's already been documented? That's a waste of tokens.
I might nitpick the concept of "above the code". That's probably a "code smell" of pre-AI concepts.
I wager that "all" organizational knowledge belongs "with" the code, as @cyclopt_dimitrisk noted in a reply.
That knowledge should optimized for efficient Agent usage while also being Human readable.
For me, that's the real constraint...
Fair nitpick on "above" vs "with" the code. I think you're right: if the knowledge doesn't travel with the repo (ideally with the PR), agents will keep hitting the same questions and humans won't find it either.
The real issue isn't "document more." It's making capture light enough that it happens at decision time, not in a cleanup sprint nobody schedules.
And yes on token waste: re-researching something already settled is exactly what happens when knowledge isn't in the right place, or the right format.
The implicit memory angle is real but I'd frame it as a consequence of the accountability gap rather than a separate fifth shift. When accountability is clear, the "why" gets captured almost automatically because someone owns the decision and has to be able to defend it later. When accountability is blurry, the "why" evaporates because nobody felt responsible for documenting a choice they didn't fully make themselves. The code compiles, it ships, and the reasoning never existed in anyone's head to begin with because the AI made the call and the human just approved it. Fix the ownership structure and a lot of the knowledge capture follows on its own. That said, your point about externalizing what used to live in people's heads is the right destination. What works for us is keeping ADRs in the repo itself, not in a wiki nobody opens, but as files that travel with the code. Context, decision, rejected alternatives, and why. Five minutes per decision and it's the difference between "why is it built this way" having an answer at 3am or being a dead end.
Absolutely, and not just ADRs!
This framing is incredibly accurate. The bottleneck didn't disappear; it just shifted from generation to validation.
On the review process breaking down, this is exactly what I’m seeing everywhere. When an AI tool empowers a developer to generate five pull requests in a single day, but a senior engineer still needs 45 minutes to properly audit each one for security and architectural context, the math simply doesn't work.
Even working solo and pushing dozens of commits a week on my own architecture, I’ve had to radically force myself to slow down. The AI can write the code in seconds, but if I don't artificially throttle my own output to ensure I actually understand the underlying choices it made, I end up with technical debt that takes days to untangle.
To answer your question: most places seem to be treating it like a faster keyboard rather than a new team member. The tools changed overnight, but the definition of 'Done' is still stuck in 2022
Agreed, and add only that specs and requirements are another bottleneck.
You can't validate what you haven't spec'd.
That's marrying manual process to AI flows waste resources. If you can't spec and validate fast enough, it doesn't really matter how fast AI can code.
That's were successful organization will redesign their processes. That's probably easier in smaller, newer orgs. Established ones have invested in people and processes they will find difficult to discard.
The math you laid out is the clearest version of this problem I've seen. Five PRs a day at 45 minutes each is nearly four hours of senior review time per developer per day. Scale that to a team of eight and you need a full-time reviewer who does nothing else. Nobody budgets for that because nobody reframed AI adoption as "we need more review capacity" rather than "we need fewer engineers."
Your point about throttling your own output is the part most people won't admit to. The tool can go faster but you can't absorb faster, and the gap between generation speed and comprehension speed is where the debt accumulates. The fact that you caught that working solo is telling because on a team it's even harder to spot since the debt gets distributed across multiple people's PRs and nobody sees the full picture.
"Faster keyboard rather than a new team member" is a good way to put it. The teams treating it as a new team member are the ones updating their definition of done.
This is an under-rated line of thinking. I think many organizations will struggle to let go of old processes and will waste time and resources on marrying processes instead of reimagining them.
Companies that can harness that speed will "box out" ones who can't.
The "marrying processes instead of reimagining them" distinction is sharp. That's exactly what happens in practice. Teams bolt AI onto existing workflows and call it transformation, but all they've done is make the old process run faster without asking whether the old process was the right one. The boxing out point is real too, because the speed advantage isn't in generation, everyone has that now. The advantage is in how fast the org can absorb and ship what gets generated. The companies that redesign around that will just operate at a different clock speed than the ones still running AI output through a process designed for manual work.
Great insights. I'm currently learning AI and found this article very helpful.
Thank you very much. I am glad I helped.