AI killed the code review. What happens to knowledge sharing?

As long as software engineering is done in teams, we need a way for people to know how things work, why certain decisions were made and where the boundaries are. That need doesn’t go away when AI writes the code. If anything, it gets more critical.

Code reviews were how most teams handled this. When someone reviewed your PR, they didn’t just check for bugs; they absorbed context. They learned why certain decisions were made. That’s tribal knowledge. At The Hangar, a community of DevEx leaders, we discussed code reviews a lot. According to Adrienne Braganza Tacke, author of ‘Looks Good to Me: Constructive Code Reviews’, the most important function of code review is actually record-keeping: chronicling how the codebase changed and why, not just catching bugs.

That conversation now feels like a different era. The entire software development lifecycle, as we know it, is not only accelerating, but collapsing and being redefined. I recently said that we should kill the code review. AI generates code faster than humans can review it. PRs pile up or get rubber-stamped. That approval gate no longer matches how we do software engineering now.

But if AI is now generating most of the code and there is no way a human could ever read all of it, how do we share knowledge?

Decisions over diffs

My proposal for solving the code review bottleneck was to move the human checkpoint upstream, to reviewing intent, reviewing the contract that code should fulfill: specs, plans, constraints and acceptance criteria. The same applies to the knowledge-sharing part of the review process.

If the team reviews intent and acceptance criteria before code is generated, the knowledge sharing happens naturally as part of planning. You’re not trying to reverse-engineer decisions from a 500-line diff. You’re aligning on a handful of key choices before anything gets built. The reviewer reads 10 lines of decisions, not 500 lines of code.

Whether that takes the form of a lightweight spec, a set of acceptance criteria, or even bullet points extracted from the prompt conversation, the principle is the same: make decisions visible and reviewable. That’s where the knowledge lives.

When a developer works with Cursor or Claude Code, they make decisions constantly: architectural choices, behavior tradeoffs and scope calls. Those decisions live in the prompt conversation, in the back-and-forth with the agent. When the PR is submitted, that context is gone. The code is there. The reasoning behind it is not.

The idea of formalizing intent before implementation is not new. Behavior-Driven Development, Test-Driven Development and Design-by-Contract approaches all tried to define behavior in structured, human-readable specs before writing code. BDD in particular asks teams to describe what the system should do in natural language, as scenarios that even the non-technical stakeholders can read and verify, before any code is written.

These approaches were often perceived as overhead. Writing formal behavior descriptions and contracts demanded discipline and time. Under delivery pressure, teams frequently skipped them. AI makes them more practical, not less. AI can help generate structured acceptance criteria, behavioral specs, or even contract-like descriptions. It can also help enforce them.

AI software engineering isn’t a solo sport

Every now and then we hear about engineers out there running agent orchestrators that produce 100,000 lines of code a day, like Steve Yegge and his Gas Town. Some say this is the future of software development, solo developers with swarms of agents, but I disagree. Building software, even with agents, is not a solo sport.

If that one person gets hit by a bus, can someone else drive the project? Do they understand all the decisions that were made? No. In an enterprise, you need redundancy. Multiple stakeholders, teams and collaboration.

The knowledge-sharing function doesn’t become less important as AI adoption grows. It becomes more important, because the gap between what the system does and what any individual understands about it is widening faster than ever. No one wants to have their senior engineers become bottlenecks because they’re the only ones that know how they got their solutions from AI.

When AI is involved in every part of the process, the social contract of collaboration is changing. There’s authorship ambiguity — someone reviewing code that a colleague submitted doesn’t know how much effort they put into understanding the nuances of that code. The reviewer then might use AI to help them understand that code and post comments and the author may use AI to address those comments without investing time in reading and understanding them.

In a pre-AI team, a junior PR generates:

• 4–8 comments from a senior on idiomatic patterns.
• A back-and-forth on edge cases.
• An implicit “here’s how I’d think about this” lesson.
• A senior who now knows that part of the code exists.

In an AI-heavy team, that same change is:

• Generated by AI, lightly edited.
• Reviewed by AI, lightly approved.
• Merged with zero humans having formed a mental model of it.

New kind of debt: Cognitive debt

I recently spoke to professor and researcher Margaret-Anne Storey, who has coined a term for that: cognitive debt. She first noticed it with a group of her students who were building with AI and moving fast. At some point they told her that they couldn’t make changes in the product anymore. The professor suspected they had tech debt, messy code, but found out that the students had accrued a new kind of debt.

They had lost track of what features they were trying to build and why. They didn’t know who knew what on the team. And on one of the teams, it was one person who knew all the code and understood it because they were supervising the AI that generated it, and the rest of the team was unable to do that. And the person who had generated the code didn’t really understand what was generated either.

That’s the risk when teams start building fast with AI, dropping code reviews because they realistically cannot review thousands of lines of AI-generated code, but doing nothing to replace the knowledge-sharing function.

Anthropic’s study showed how over-reliance on AI coding assistants has downsides in code comprehension. Their study with 52 engineers found that AI assistance produced no statistically significant speedup on the task but scored 17% lower on a comprehension quiz afterward. The biggest drops were in debugging, with smaller declines in conceptual understanding and code reading. The takeaway is clear: passively delegating to AI (“just make it work”) impairs learning far more than using it to ask questions and understand the code.

Even a workflow of triggering an adversarial agent after you’re done coding with your primary agent that asks questions like: Why did you do it this way? What behavior do you expect? What tradeoffs did you consider, could go a long way toward reducing cognitive debt. It forces the developer to articulate understanding before the code moves forward.

Make knowledge sharing intentional

That judgment and those decisions — that is the main thing we as humans are providing in an AI-first world. You could even go so far as to say that most of the code written is boilerplate. The main decisions we’re making are architectural decisions, behavior decisions and technical decisions. These are the things we need to provide as input for the AI systems and every change requires clarity on those decisions.

A lot of the knowledge sharing that happened through code reviews was incidental. Engineers absorbed context because they had to look at the code to approve it. As we phase out reviews, being able to review these decisions becomes more important.

Eventually, engineers are still accountable for the changes they’ve created. All these decisions have to be tracked, and somebody has to be able to audit them to ask why certain decisions were made. That becomes your source of truth. That’s how I think team collaboration and knowledge sharing evolve, even though I said that we should kill the code review.

The productivity gains are real and worth taking. But every org optimizing purely for PR throughput is running an experiment on its own engineering culture. In five years, the orgs that win won’t be the ones that shipped the most AI code. They’ll be the ones whose engineers still understand what got shipped.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?