AI
AI-generated code threatens knowledge sharing in teams, experts warn
As artificial intelligence takes over code authoring, teams risk losing the collaborative learning that once happened during code review—and building what researchers call "cognitive debt."
The New Stack
The sheer volume of AI-generated code is collapsing the traditional code review process. Engineers now face massive diffs—sometimes 500 lines or more—that they didn't write and can't feasibly review carefully. But the real problem goes deeper than the bottleneck: teams are losing a critical learning mechanism.
Code review historically served as the team's knowledge transmission belt. Junior developers watched how senior engineers reasoned about problems, architectural decisions got challenged in real time, and shared understanding of the codebase developed organically. With AI generating most new code, that educational function is evaporating.
Shifting knowledge-sharing upstream#
The answer isn't just better tooling to handle review volume. According to conversations with technologists like Vanitha Kumar, Market Technology Director at ThoughtWorks, the solution requires reimagining when knowledge transfer happens.
Kumar built an AI agent that catches anti-patterns and explains them to developers who didn't align with the team's practices—essentially a teaching agent disguised as a code reviewer. This work, she realized, shouldn't happen after code is committed. Instead, knowledge-sharing needs to move left in the development cycle, happening during initial planning and implementation discussions rather than in retrospective review.
The rise of cognitive debt#
A deeper threat lurks beneath the review bottleneck. Researcher Margaret-Anne Storey has introduced the concept of cognitive debt—knowledge that lives in people rather than code. Unlike technical debt (which accumulates in messy code), cognitive debt builds silently when teams stop understanding the systems they're building.
Storey observed this firsthand with student teams leveraging AI heavily. Despite moving quickly and shipping features, the teams eventually couldn't modify their own products. Not because the code was tangled, but because they'd lost track of what they were building and why. In some cases, only the person managing the AI knew how features worked, creating invisible single points of failure.
LLMs can explain how code works, but they can't preserve the assumptions, trade-offs, and intent baked into decisions. Why was this built this way? What behavior trade-offs were accepted? Which features remain out of scope? These context-dependent answers won't appear in code alone—they need to live in human minds across the team.
