{"slug": "ai-can-write-more-code-than-teams-can-review", "title": "AI can write more code than teams can review", "summary": "Coding agents now generate code faster than teams can review it, creating an explainability gap that shifts the bottleneck from writing changes to understanding them, according to Harjot Gill. Gill argues that review interfaces must move from file-level diffs to higher-level abstractions that trace intent through system behavior, as demonstrated by a TanStack/cli pull request where 45 files were reorganized into six review paths. Without a shared mental model, reviewers are left with a thin approve-or-reject choice, unable to improve design or challenge assumptions.", "body_md": "Harjot Gill\n\nJuly 21, 2026\n\n8 min read\n\nJuly 21, 2026\n\n8 min read\n\nCut code review time & bugs by 50%\n\nMost installed AI app on GitHub and GitLab\n\nFree 14-day trial\n\nGetStarted in2 clicks.\n\nCoding agents have changed what is scarce in software.\n\nProducing a plausible change is getting faster. But a team needs more than evidence that the code runs. It needs enough understanding to decide whether the change belongs, how it reshapes the system, and what should happen next.\n\nThat mismatch is the explainability gap. Agent output can expand through more capable models, more context, and more parallel work. Human comprehension does not scale the same way. The bottleneck moves from writing the change to building enough understanding to direct it. When people can no longer explain a change, they stop shaping it and start accepting it.\n\nMost review interfaces start with files, lines, and comments. That evidence is essential. It is also a poor place to begin when one system change crosses routes, providers, templates, tests, and configuration.\n\nReview needs a higher level of abstraction. It does not need a summary that asks for blind trust. It needs a path from intent to system behavior to code, with every claim traceable back to the diff.\n\nA reviewer is not there to count changed files or act as a final checksum. The job is to answer a different set of questions:\n\nTests, static analysis, and agents can check more of the implementation. That does not remove the need for human judgment. It raises the level where judgment matters. A team must still decide whether a boundary is sound, whether a tradeoff is worth it, and whether the change creates a system they want to keep building.\n\nWithout a working model of the change, a reviewer is left with a thin choice: approve or reject. They cannot improve the design, challenge an assumption, or connect the change to the next decision. Comprehension lets the team direct the work.\n\nThe scarce work is a shared mental model. If every reviewer has to reconstruct one from a file tree, review capacity cannot keep pace with generation capacity. If each person reconstructs a different one, the team cannot reason about the change together. The interface becomes part of the bottleneck.\n\nA repository path works like a GPS coordinate. It tells you where code lives. It does not always tell you why several files changed together or which file makes the next one intelligible.\n\nThe repository is organized around implementation. Review is organized around decisions. One system behavior can cross a route, provider, configuration file, template, and test without respecting the folders that hold them.\n\nThe answer is not to replace the diff. The diff remains the exact evidence. The missing layer is a useful route through that evidence.\n\n[TanStack/cli pull request #490](https://github.com/TanStack/cli/pull/490) is a useful example because it is broad without being exotic. The change touched 45 files across authentication, environment handling, templates, package configuration, and tests.\n\nIn a file view, the reviewer starts with 45 coordinates. In Change Stack, the same code becomes six paths through related system behavior. Nothing about the underlying change is hidden or rewritten. Only the starting point changes.\n\nBoth views are accurate. One answers **where did the code change?** The other proposes **which parts should be evaluated together?**\n\nThe six paths are not an authoritative interpretation of the pull request. They are a review map: a proposal about which code ranges belong in the same thought. A useful map lowers the cost of orientation. A trustworthy one also lets the reviewer challenge the grouping.\n\nOne path in the TanStack change connected ten files into a single sign-in flow. No one file contained the behavior the reviewer needed to judge. The behavior existed between the route, provider, callback, configuration, and tests.\n\nThe diagram does not replace the code. It gives the reviewer a model to test against it. Instead of spending the first pass discovering that a flow exists, the reviewer can spend it checking whether the flow is correct, complete, and safe.\n\nThat model also gives the team a common object to challenge. The author, reviewer, and maintainer can discuss the same proposed flow instead of carrying three private interpretations of the diff.\n\nThat is the useful change in altitude: from repository structure to system behavior.\n\nAbstraction is cheap if it only produces a polished summary. The hard requirement is traceability.\n\nIn this review, the path runs from the pull request to a change layer, from the layer to a system flow, and from that flow back to semantic entities, files, and lines. The reviewer can zoom out to ask whether the behavior makes sense, then zoom in to test the claim against the implementation.\n\nEach level answers a different question. Intent explains why the change exists. System behavior shows how parts interact. A layer sets a review boundary. A semantic entity names the function, route, or type involved. The file and line provide the exact evidence.\n\nRemove the upper levels and the reviewer must reconstruct the system from coordinates. Remove the lower levels and the reviewer is asked to trust a story they cannot verify.\n\nAgentic development will not become governable through larger diffs or longer summaries. Both leave the reviewer doing the same reconstruction work. A summary is one-way. A useful model can be inspected, corrected, and discussed.\n\nThe review interface has to become a stack. Intent explains why the change exists. System behavior shows how parts interact. A change layer defines what belongs in one review path. Semantic entities, files, and lines provide the exact evidence.\n\nNo representation is sufficient alone. The value comes from moving between them without losing the chain of evidence.\n\nThe goal is not to read less code. It is to spend code-reading time testing a coherent model instead of constructing one from scratch. It keeps human judgment attached to the design, not only to the final approval. Machines can organize the change and expose the paths. Humans decide whether the model is accurate, the boundary is sound, and the direction is worth taking.\n\nThe diff remains the ground truth. The stack gives the team a way to think with it.\n\n[Inspect the merged pull request on GitHub](https://github.com/TanStack/cli/pull/490) · [Open the same pull request in Change Stack](https://app.coderabbit.ai/change-stack/TanStack/cli/pull/490)", "url": "https://wpnews.pro/news/ai-can-write-more-code-than-teams-can-review", "canonical_source": "https://coderabbit.ai/blog/ai-can-write-more-code-than-teams-can-review", "published_at": "2026-07-21 00:00:00+00:00", "updated_at": "2026-07-22 17:26:22.354895+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-tools"], "entities": ["Harjot Gill", "TanStack", "GitHub", "GitLab"], "alternates": {"html": "https://wpnews.pro/news/ai-can-write-more-code-than-teams-can-review", "markdown": "https://wpnews.pro/news/ai-can-write-more-code-than-teams-can-review.md", "text": "https://wpnews.pro/news/ai-can-write-more-code-than-teams-can-review.txt", "jsonld": "https://wpnews.pro/news/ai-can-write-more-code-than-teams-can-review.jsonld"}}