The volume of AI-generated code has broken code review. Engineers are reviewing 500-line diffs they didn’t write, generated by models they don’t fully control, at a pace that makes careful reading impossible.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 save the knowledge-sharing job code review had always had?“If code review shifts left, knowledge sharing also has to shift left.”Code review has always been where knowledge moves through the team, where junior engineers watch how senior engineers think, where architectural decisions are challenged, mental models of the codebase are formed, and where shared ownership takes shape. If code review shifts left, knowledge sharing also has to shift left.Code review as a teaching toolIn my podcast conversation with Vanitha Kumar, Market Technology Director at ThoughtWorks, she accidentally came to this realization.Vanitha built an agent designed to catch anti-patterns and explain them to a developer who didn’t fit her team’s archetype. Knowing that archetype, she would instruct it to review code against the practices in their reference document, identify where the team was deviating, and explain why the deviation would be detrimental. She built it as a teaching agent more than a code review agent, though it gradually evolved into one.It then occurred to me that this shouldn’t be caught late, after the commit. Code review, whether done by a human or an agent, has to happen much earlier, and it need not even be a review. It can be rubber ducking or a teaching moment.A new kind of debt: cognitive debtMost of the conversation about replacing code review focuses on catching bugs and standards checking. Most of that work can be automated by LLM-based adversarial review, automated verification, and deterministic checks. But if we solve standards-checking completely and do nothing about knowledge sharing, we have only fixed the easier job.In a pre-AI team, a junior’s PR generates four to eight comments from a senior on idiomatic patterns, a back-and-forth on edge cases, and an implicit “here’s how I’d think about this” lesson. In an AI-heavy team, that same change is generated by AI, lightly edited, reviewed by AI, lightly approved, and merged with zero humans having formed a mental model of it.Margaret-Anne Storey has a useful name for what happens when that collaboration disappears: cognitive debt. Technical debt lives in the code. Cognitive debt lives in people. It builds up when the team stops understanding the system they’re building, and no dashboard is going to tell you it’s happening.“Technical debt lives in the code. Cognitive debt lives in people.”She first noticed it with a group of students who were building with AI and moving fast. At some point, they told her they couldn’t make changes to the product anymore. She suspected tech debt, messy code. But the students had lost track of what features they were trying to build and why. They didn’t know who knew what on the team. On one of the teams, it was one person who understood the code because they were supervising the AI that generated it, and the rest of the team couldn’t. The person who had generated the code didn’t really understand what was generated either.One can argue that if we have AI to answer all the questions about the code, there shouldn’t be a cognitive debt. We can offload the code understanding to it. Even though LLMs are great at explaining how a feature or behavior works, we lose the “what” and “why.” Why were the changes created this way? What assumptions were made when implementing a feature? What are the side effects or behavior of a capability, and how would this fit into the product’s roadmap? Why does this feature need to exist? All of this is cognitive debt; it’s not wired into the code, and this is where we need the mental models.Intent-driven verification keeps knowledge sharing aliveThe solution for the code review bottleneck was to move the human checkpoint upstream, to reviewing intent, reviewing the contract that code should fulfill: plans, constraints, and acceptance criteria. The same applies to the knowledge-sharing part of the review process.Intent-driven verification means capturing the decisions an engineer makes during their session with an agent, the architectural choices, behavior tradeoffs, and scope calls, and writing them down as acceptance criteria before submitting the change. A brief description of scope, a list of acceptance criteria, and a note on what is explicitly out of scope. The decisions are already there in the prompts. With Aviator Verify, engineers capture them rather than losing them when the session ends.The reviewer’s job changes. Instead of reading a 600-line diff and asking, “Does this look right?” they read a handful of acceptance criteria and ask, “Are we solving the right problem with the right constraints?” They don’t need to read every line of code. They need to understand the intent behind it, what changed, and more importantly, why. That’s a fundamentally better use of a senior engineer’s time.“Reviewers reading acceptance criteria are reading the decisions behind the implementation, not the implementation itself.”This is important for the author as much as the reviewer. As an engineer, you need a mental model of your code to do effective back-and-forth with agents and question their suggestions. If you don’t understand what’s being built at the behavior level, you can’t catch when the agent goes sideways. Capturing and reviewing intent and behavior, both as an author and as a reviewer, is what builds and maintains that mental model. And it’s where the knowledge-sharing function of review survives. Reviewers reading acceptance criteria are reading the decisions behind the implementation, not the implementation itself.We have always said that no single person on a team should hold all the knowledge and that work shouldn’t stall if someone wins the lottery. Few teams truly worked toward that. We were often content with one person holding all the context. Now that AI writes most of the code, we don’t have a choice. The productivity gains are real and worth taking. But without a deliberate process for maintaining mental models of what’s being built and why, teams will ship faster and understand less, until the speed itself becomes the problem.The post AI broke code review. What about knowledge sharing? appeared first on The New Stack.