The framing most companies get wrong
There's a pattern I keep seeing in how companies talk about adopting AI. They treat it like upgrading a tool. Swap in the new thing, keep everything else the same, move faster.
That framing misses what actually happens.
What changes when AI enters a workflow
Once AI starts generating code, drafting decisions, or automating steps that humans used to own, four things shift simultaneously.
Decision speed changes. AI produces output in seconds. But the review, approval, and validation structures around that output were designed for human-speed delivery. You now have a team that can generate a week's worth of code in a day, running into a review process that was built to handle a week's worth of code in a week. Something has to give, and usually what gives is review quality.
Accountability gets blurry. When a human writes code, you know who made every decision. When AI generates code and a human approves it, accountability lives in a grey zone. Who owns the architectural choice the AI made? Who's responsible when a generated function introduces a security vulnerability? Most orgs haven't answered these questions explicitly, so they get answered implicitly by whoever is on call when something breaks.
Escalation paths break. Traditional escalation assumes a human-made decision that can be explained and traced. AI-generated output often can't be traced the same way. "Why was it built this way?" gets answered with "that's what the AI produced, and it looked right." That's not an escalation path. That's a dead end.
Operational expectations shift faster than operations do. Leadership sees the speed of generation and expects the speed of delivery to match. But delivery includes review, testing, integration, deployment, and monitoring. None of those got faster just because the first step did. The expectation gap creates pressure that compresses everything downstream.
Why this creates tension
The tension isn't about the technology. The technology works. The tension is that AI evolves faster than the organizational structures around it.
Teams adopt AI tools in weeks. Changing how decisions get made, who's accountable for what, how reviews work, and what "done" means takes months. In that gap, you get teams generating more output than their processes can absorb, accountability questions that nobody has answered, and escalation paths that quietly stopped working.
Most of the AI adoption failures I've watched weren't technical failures. They were alignment failures. The tool changed. The org didn't.
The alignment problem nobody talks about
The challenge for most companies is no longer access to AI. Everyone has access. The challenge is alignment.
Aligning the speed of AI output with the capacity of the review process.
Aligning accountability structures to account for AI-generated decisions.
Aligning operational expectations with the reality that generation is only one step in a much longer delivery chain.
The teams that get this right don't just adopt AI tools. They redesign how work flows through the organization to account for what those tools actually change. That's not a software upgrade. That's an organizational redesign.
Has your company actually changed its processes since adopting AI tools, or did the tools change and everything else stayed the same?
Top comments (6)
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.
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.
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.
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
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.