The Agent Principal-Agent Problem

David Crawshaw (exe.dev co-founder, ex-Tailscale, ex-Google) argues that the standard review-then-commit code review process — born at Apache, corporatized at Google, popularized via the GitHub PR — was load-bearing infrastructure for low-trust collaboration, and agents have broken it.

The original process worked because the reviewer could cheaply infer effort from reading the contribution. Time spent thinking shows up in the diff. That signal is what made it acceptable to ask reviewers to spend serious effort responding. Agents collapse this signal entirely. A "contributor" who types two sentences of bug-report-quality prompt and pokes at the result for five minutes can generate a substantial PR that costs the reviewer hours.

This is a textbook principal-agent problem: the reviewer (principal) can't observe the contributor's (agent's) effort, but the cost of mis-aligned effort falls on the reviewer. In OSS this manifests as "slop PRs." In companies it shows up as review queues where the reviewer would have been more productive prompting the agent themselves.

The naive fix — insert agents into the existing workflow as "the human reviews the agent's output, then sends it for review" — doubles total review while increasing total change volume. The math doesn't work. Reviewer bandwidth was already the bottleneck before agents existed.

What does work, in Crawshaw's experience at exe.dev (team of nine):

1. A human instructs a machine to make a change.
2. The human reviews and iterates with comments until they approve it.
3. They push to production and deploy.

The reviewer-of-the-team has been removed from the loop. The human driving the agent is on the hook for the deployment. Principal-agent collapses because the principal is the agent. They invest heavily in integration tests, e2e tests, and agent-driven safety/perf/usability analysis to compensate — machinery that traditionally appears only at much larger scale, but is much cheaper to build with agents.

Why this doesn't transplant to BigCo:

• You have to trust colleagues to start architecture conversations before they make sweeping changes
• No one at BigCo trusts that
• And no one at BigCo wants to deploy without a code review to "smear the blame around"

Crawshaw's historical pointer is Microsoft in the 1990s — large, but organized as many independent teams with QA-driven sync rather than mandated review-before-commit. "Cowboy" by post-2005 Google standards, but it produced Win32 and a lot of long-lived software. He notes that little is written about that period and asks for first-hand accounts.

The conclusion is bracingly direct: until someone develops processes that scale agent-driven work in low-trust environments, small high-trust teams have a force multiplier big teams don't have. Ship while you can.

Connections: skill-atrophy-supervision-paradox is the same problem from the supervisor side; i-dont-want-your-prs is the OSS-specific reframe (replace PRs with prompts); no-silver-bullet-llms is the productivity-gain skepticism; agentic-coding-fatigue is the human-cost side.

The follow-up from the same company: claude-is-not-a-compiler (Josh Bleecher Snyder, July 2026) is a worked instance of the machinery Crawshaw describes abstractly here. It shows what "the human driving the agent is on the hook" looks like on a real production system — a distributed DNS server built by concurrent agent loops, verified through differential-spec-analysis and shadow-mode rollout rather than review, with a scar-tissue guidance document as the durable artifact. Step 2's "reviews and iterates until they approve it" turns out, in practice, not to mean reading the code.

Cross-references: crawshaw-blog, exe-dev-blog, claude-is-not-a-compiler, vibe-engineering, skill-atrophy-supervision-paradox, i-dont-want-your-prs, agentic-coding-fatigue, no-silver-bullet-llms, contributor-poker.