Appearance
The bottleneck moved
For most of software history, writing code was the expensive part. A feature took hours or days: requirements, codebase exploration, design, implementation, tests, debugging, then a pull request. Coding agents blew that equation apart. Claude Code, Codex, Cursor, Copilot, and similar tools can now produce a working diff in minutes.
The problem nobody predicted: the same agents that compress generation leave review untouched. A PR I reviewed recently touched 27 files and contained 1,800 lines. The agent produced it in roughly ten minutes. Reading it, checking security implications, and verifying behavior took me more than an hour. The constraint didn't disappear. It moved.
The numbers behind the shift: one agent PR can touch 27 files and 1,800 lines, generated in minutes, while review still takes an hour. GitHub reported that an ensemble of specialized review agents raised the rate of high-severity comment resolution by 47%. The AGENTS.md feature request in the Claude Code repo sat at 5,200+ upvotes, four times the next-highest request, before it shipped in September 2026. More than 60,000 open source projects now ship an AGENTS.md file.
You can see the shift in volume metrics. The review-bottleneck discussions that have been circling the community use a stylized before/after: 10 PRs per week and 2 bugs before agents, 35 PRs per week and 11 bugs after. PR velocity triples, bugs more than quintuple, and understanding collapses. Generating more code is not automatically increasing productivity. Sometimes it's generating future work faster.
GitHub is already responding. Copilot Code Review expanded to run builds, tests, and targeted checks as part of its analysis, and GitHub experimented with an ensemble of specialized review agents. The reported result: a 47% increase in the rate at which developers addressed high-severity review comments. Practically, that's the difference between a review process that catches critical issues and one that generates noise. AI isn't just writing code anymore. It's being drafted to review the code AI wrote.
Reviewing code at machine speed
When diffs get that large, line-by-line review stops working. I changed how I approach agent PRs. Instead of reading the diff first, I ask five questions in order:
- What changed at the level of the system, not the diff?
- Why did each file change? Every file in the diff should have a reason to exist.
- What assumptions did the agent make? This is where bugs hide.
- What happens when something fails? Agents are great at the happy path. Production lives in the unhappy paths.
- Could a human maintain this without the agent? If the answer is no, don't merge it yet.
The first question is the one most teams skip. For API changes, I now diff the generated openapi.json between the base branch and the PR head before touching the implementation. If the contract doesn't match the requirement, there's no point reviewing the 1,800 lines underneath. It turns "does this look right?" into a concrete check against the spec.
The failure mode shows up one step later. A team can review 1,800 lines carefully and still break production because nobody checked the new environment variable or the migration order. Review catches logic bugs. It doesn't catch the deploy step, and that gap is quieter and usually more expensive. Verification has to cover the deployment path, not just the diff.
Using AI to review AI-generated code isn't automatically dangerous. A second agent can hunt for missing tests, race conditions, and broken edge cases while tooling runs static analysis, type checks, and integration tests. The real danger: verification can be perfectly correct and validate the wrong thing. If the requirement was misunderstood, implementation, tests, and AI review all agree with each other while the feature stays wrong. Passing tests prove the code matches the agent's interpretation of the requirement. They don't prove the interpretation matches reality.
The load-bearing move is separating review from verification. They're different jobs, and only one of them scales. Review is a human reading a diff and forming a belief; that's bounded by attention, and agents have already outrun it. Verification asks whether what the diff does is permitted, and that doesn't have to be done by reading. In the systems where I've seen this work, anything that moves money or touches auth flows through one narrow interface, reviewed as if it were the only code in the repo. A 2,000-line agent diff that doesn't touch it gets a cheap look. A 20-line change that does gets the full treatment.
Quick Take: The teams that treat review surface area, not PR count, as their scarce resource are the ones that survive agent adoption without drowning in AI technical debt.
AGENTS.md finally becomes the standard
September 2026 finally brought the fix. After thirteen months of requests, Claude Code added support for AGENTS.md. From version 2.1.277, if a project has no CLAUDE.md, Claude Code checks for and reads AGENTS.md. Teams can configure the behavior under /config, Project instructions: CLAUDE.md only, fallback to AGENTS.md, or both loaded together.
Why this matters: AGENTS.md is the closest thing the agent world has to a README for agents. It tells the coding agent how the project builds, which tests to run, and what conventions to follow. OpenAI introduced it with Codex in August 2025 and donated it to the Linux Foundation's Agentic AI Foundation in December, where Anthropic sits as a platinum member alongside its MCP protocol donation. Codex, Cursor, Copilot, Gemini CLI, and Devin all read it before Claude Code did. The feature request in the Claude Code repo sat at 5,200+ upvotes and 300+ comments, four times the next-highest request. Now, if your repo has an AGENTS.md, every major agent on the market reads it.
| Tool | Instruction files it reads | AGENTS.md support |
|---|---|---|
| OpenAI Codex | AGENTS.md | Native, created the format |
| Cursor | AGENTS.md | Native |
| GitHub Copilot | AGENTS.md | Native |
| Gemini CLI | AGENTS.md | Native |
| Devin | AGENTS.md | Native |
| Claude Code | CLAUDE.md, AGENTS.md | Since 2.1.277, fallback or combined |
Before this landed, teams ran on duct tape. I kept a soft link from CLAUDE.md to AGENTS.md for months. Others put an @AGENTS.md import line at the top of CLAUDE.md, or hooked a startup script that printed AGENTS.md into every new session. Each hack worked until someone's environment didn't run the hook, and then the agent followed stale rules and produced code matching no convention in the repo. Shopify CEO Tobi Lütke threatened to ban Claude Code internally until it read AGENTS.md and called the dual-file burden a "complexity tax." In a monorepo, instruction files cascade down the directory tree. Maintaining two in sync is exactly the work nobody wants to do twice.
Community reaction to the update was relief more than celebration. The AGENTS.md issue had become a running joke, and when it finally landed the response was mostly "finally." One engineer I work with put the frustration bluntly: AI writes our code now, and we were spending our time solving instruction-file compatibility for the AI. The remaining decision is which rules are cross-tool consensus, put them in AGENTS.md, and which are Claude-specific, keep them in CLAUDE.md. That split is now a deliberate choice instead of a tax.
The other half of the announcement matters more than the compatibility fix. AGENTS.md support is Claude Code's first built-in mod, a plugin mechanism for modifying the harness itself, and Anthropic shipped the source in the official repo. Community analysis of the mod hooks started within hours. The same month, DeepSeek open-sourced its Harness with the slogan "everything is a plugin," a Cordis-based framework that treats models, tools, sessions, sandboxes, and even the UI as swappable components. It passed 229,000 GitHub stars and can even schedule Claude Code or Codex as sub-agents. One approach modifies a finished product, the other starts from a pile of parts. Both say the same thing: the agent harness is infrastructure you configure, not a black box you accept.
The same week showed how far apart product strategies still are. Kimi shipped a separate desktop Code client rather than folding it into Kimi Work, while Claude and ChatGPT merged chat, work, and code surfaces into single entry points. Tools consolidating their standards while fragmenting their interfaces: that tension is the current state of the agent market.
From story points to prototypes
The bottleneck is reshaping process, not just tooling. The strongest case came from a developer declaring Scrum finally dead and crediting coding agents. The argument: the Agile Manifesto failed not because its principles were wrong, but because principles don't scale by memo. Organizations convert principles into practices, and Scrum is that conversion. Story points, sprint planning, burndown charts: legible, auditable, certifiable, and requiring no judgment. The things the Manifesto actually valued, judgment, trust, continuous reflection, can't be checklisted.
Agents change the math. A domain expert who never wrote production code can sit with a coding agent and build the thing they want. The prototype becomes the requirement, and a working prototype beats any ticket ever written. A spec describes; a prototype demonstrates. When the handoff chain collapses from idea, epic, refinement, story, acceptance criteria, estimate, sprint, demo, "that's not what I meant," down to "here's the thing I want," the backlog loses its reason to exist.
The caveats matter. Prototypes are validated intent, not products, and engineering's job shifts from figuring out what they meant to making it real, safe, scalable, and correct. Agents are amplifiers, not correctors. Teams bolting agents onto Scrum, asking for agent-produced story-point estimates, running AI-assisted standups, will amplify their dysfunction faster. Estimating agent velocity is superstition with a Fibonacci sequence attached. The new failure mode isn't shipping slowly. It's shipping the wrong, unsafe thing faster.
When the stack itself gets re-evaluated
The same cost shift is rewriting technology choices. Shopify announced it's moving its mobile apps from React Native back to native Swift and Kotlin, and its stated reason is AI. In 2020, React Native was the right call: two native codebases meant twice the work. Shopify had been using LLMs in development since 2021, and by late 2025 it re-examined that assumption. If an agent can port features between iOS and Android, and shared specs, tests, and review gates keep the two ends aligned, then the duplication cost that justified cross-platform frameworks starts to disappear.
The evidence is concrete. Shop went from proof of concept to a fully rewritten native release in 12 weeks. The flagship Shopify App, with more than 300 pages plus home-screen widgets, an Apple Watch app, and Siri Shortcuts, is mid-migration with a native release expected later in 2026. Notably, they didn't migrate incrementally. They rebuilt from scratch, treating the React Native app as a reference implementation, precisely because the old code carried historical constraints they didn't want to inherit.
They also failed first, which is the instructive part. Handing the entire React Native codebase to an LLM and asking for a native rewrite in one pass produced a pile of unmaintainable, unreleasable code, even when the model was given complete spec and task files. The working system, Helix, breaks the rewrite into small nodes with hard gates: behavioral tests pass, visual comparison against the running original, two adversarial code reviews, and human confirmation. Feedback from each gate feeds the next node. And they hit the same wall everyone hits: model inference is fast, but verification through a mobile simulator takes minutes per cycle. Their fix was architectural. Business logic fully decoupled from UI and running headless in the desktop environment, so agents inspect application state and navigate in milliseconds, booting the simulator only when UI verification is genuinely needed.
Shopify's open source projects are being handed off rather than abandoned:
| Project | Fate |
|---|---|
| React Native Skia | Sponsored until end of 2026, then forked and continued under a new name |
| FlashList | About 2 million downloads per week, maintained until a new long-term maintainer is found |
| Restyle | Archived at end of 2026, community fork welcome |
So is React Native dead? No. It didn't get worse. What changed is the cost of the alternative. Cross-platform still buys you one toolchain and one hiring pool. But for large teams with agent infrastructure, the tradeoff has inverted. Shopify is one data point, a big one. Watch whether it becomes a pattern.
Common pitfalls
After watching teams adopt agents over the past year, these are the mistakes I see repeatedly.
Reviewing agent PRs line by line when the diff is 27 files and 1,800 lines. Human attention loses. Diff the contract first, openapi.json, protobufs, type definitions, between base branch and PR head. Then check env vars and migration order. Then read exactly the parts that touch auth, payments, and data. A 20-line auth change deserves more attention than 500 lines of UI.
Treating AI review as the final authority. Verification can be perfectly correct and validate the wrong thing. If the requirement is misunderstood, implementation, tests, and AI review all agree with each other. Keep a human responsible for intent, invariants, and whether the behavior matches the product contract.
Maintaining parallel instruction files that drift. Two tools reading two files means one forgotten update and the agent follows stale rules. Put cross-tool consensus in AGENTS.md, keep model-specific preferences in CLAUDE.md, and let the 2.1.277 fallback handle the rest.
Asking an agent to rewrite a whole system in one pass. Shopify tried it and got unreleasable code. Break the work into small nodes, each with automated verification and a human gate. The first pass is never the deliverable.
Measuring PR velocity while review surface expands. Ten PRs a week, two bugs, people understand the changes. Then 35 PRs, 11 bugs, nobody understands half. Track how much surface a human must read to trust a change, and design so dangerous changes have fewer places to hide.
One thing to remember
Coding agents solved the scarcity that shaped software engineering for forty years: human typing throughput. The scarcity that replaces it, verified understanding, is harder to measure and easier to skip. Every workflow change in this article, contract-first review, shared agent instructions, prototypes over tickets, stack re-evaluation, is a response to the same shift. The hard part of software is no longer writing code. It's knowing which code deserves to reach production.
The bottom line
If you're on a team where agents generate most PRs, adopt contract-first review now. Diff the API spec and migration order before touching the implementation, and give heavy human review only to changes that touch auth, payments, or data. That's how you keep review time flat while agent output grows.
If you're running a multi-tool team across Codex, Cursor, and Claude Code, standardize on AGENTS.md as the shared rulebook and keep CLAUDE.md for what's actually Claude-specific. The 2.1.277 fallback makes this workable, and the complexity tax of syncing parallel files is no longer worth paying.
If you chose a cross-platform framework to avoid duplicated native work, redo the cost math with agents in the picture. Shopify rewrote Shop natively in 12 weeks with AI assistance and is migrating its 300-page flagship app. Expect more large teams to follow within the next 12 to 18 months, because the duplication cost that justified the frameworks is being rewritten.