Generated by Codex with GPT-5.5

The Pragmatic Engineer surfaced this piece in Gergely Orosz’s June 23, 2026 essay, Slow down to speed up: so much has changed in 6 months’ time. Based on his Craft Conference keynote and reporting across AI labs, large technology companies, startups, and traditional enterprises, the article argues that software development has crossed an important threshold: coding agents can now generate changes faster than many teams can review, understand, and safely absorb them.

That is why “slow down” is not an argument against AI. It is a warning that maximizing code output can reduce the rate at which a team delivers reliable value. When generation becomes cheap, judgment, coordination, verification, and operational ownership become the scarce resources.

The throughput numbers hide the real bottleneck

Orosz points to several indicators of a rapid shift since late 2025. Linear reports that teams using agents now open roughly five times as many pull requests as they did two years ago. Cursor says its users produce about 2.5 times as much code as 18 months ago, while the average pull request has tripled in size. Cursor’s data also shows a sharp increase in changes accepted without human review after more capable models arrived in early 2026.

These figures should not be mistaken for clean measures of productivity. Vendor data is self-selected, lines of code are not business outcomes, and more pull requests can mean either faster delivery or more work pushed downstream. But the direction is clear: the supply of plausible code is expanding much faster than human attention.

The result is a queueing problem. An engineer can run several agents at once and produce more proposed changes, but reviewers, test systems, release processes, and on-call teams do not automatically gain the same capacity. Larger pull requests make review harder just as their volume rises. If teams respond by weakening review, they preserve apparent velocity by borrowing against future debugging, security, reliability, and maintenance work.

AI-native teams are redesigning the workflow

The most revealing examples are not individual developers asking a chatbot for code. They are organizations rebuilding development around agents.

At Anthropic, Claude Code creator Boris Cherny has described running about five agents in parallel and shipping 20 to 30 pull requests per day. Prototypes have displaced many product requirement documents, and Claude reportedly generates most of the company’s code. This changes an engineer’s job from typing an implementation to defining the problem, steering multiple attempts, and deciding which result is worth keeping.

OpenAI’s Codex team uses a similar model. An internal mobile app can turn bug reports into one-shot fixes, developers routinely run multiple agents, and code changes go through tiered review: lower-risk work may receive AI review, while more consequential changes require human review. Orosz highlights “taste” as a core skill in this environment—the ability to recognize a good design, reject a superficially convincing one, and preserve coherence across many generated changes.

Uber shows what this shift requires at enterprise scale. It has built an internal gateway, agent builder, background coding agents, a code inbox, risk profiles, AI-assisted review, and tools for large migrations. The important feature is not simply that Uber uses agents. Its infrastructure tries to rank changes by risk and direct scarce human attention toward the parts that matter. That is a more serious response than adding an AI assistant to an existing workflow and expecting the rest of the delivery system to cope.

Adoption is also broader than frontier labs and Silicon Valley startups. The article cites 18,000 Cisco developers using Codex for migrations, refactoring, and code review in February, while JPMorgan Chase has built a multi-agent framework for data annotation. AI-assisted development is becoming normal across company types; the differentiator is increasingly how well an organization governs the resulting work.

Output without scrutiny is negative leverage

The article opens with Meta’s account-takeover incident, in which an AI support system could change the email address on an account without adequate authorization. Orosz reports that AI-generated and AI-reviewed code, reduced security staffing, and engineers reassigned from integrity work contributed to the conditions around the failure.

The episode illustrates the central risk. AI does not merely accelerate good engineering practice. It accelerates whatever system surrounds it. Strong specifications, tests, review boundaries, observability, and ownership can turn generated code into leverage. Weak controls can let a plausible but unsafe change move from request to production before anyone has formed a complete mental model of it.

AI-only review is especially vulnerable to correlated error. A reviewer using similar models, context, and assumptions may confidently approve the same mistake the generating agent made. Human review is not automatically superior, but removing it from high-impact changes eliminates an independent source of skepticism and accountability.

Slowing down means controlling the work, not rejecting the tool

The practical implication is to measure the whole delivery system rather than celebrate generation volume. Teams need to ask whether lead time, incident rate, rollback frequency, customer outcomes, and maintenance burden improve—not whether token use, pull requests, or generated lines go up.

They also need explicit risk boundaries. Routine, reversible changes can tolerate more automation. Authentication, permissions, data handling, migrations, billing, and infrastructure deserve independent human scrutiny and stronger validation. Risk-based queues, like Uber’s approach, are more sustainable than treating every generated diff as equally urgent.

Finally, teams should limit generated work in progress. Running more agents is useful only when the organization can evaluate and integrate their output. Smaller changes, clear ownership, disciplined tests, staged releases, and time to remove weak code may feel slower than merging everything an agent proposes. In practice, they protect the scarce judgment that keeps rapid generation from becoming rapid entropy.

The essay’s lasting point is that software engineering is no longer constrained primarily by how fast code can be written. The constraint is deciding what should exist, proving that it behaves correctly, and maintaining it after release. AI agents raise the ceiling on implementation speed, but teams capture that advantage only when they strengthen the human and technical systems around the code.