Gardening, Not Writing
📖 Read the full version with charts and embedded sources on AgentConn →
GitHub's Octoverse 2026 report dropped a number that should change how every engineering team plans their sprints: over 40% of pull requests in September 2026 were agent-started, up from 17% in March. That is 110 million agent-drafted PRs in a single month, with a 90% merge rate within two weeks. The code generation problem, for practical purposes, is solved. The bottleneck has moved.
The same week, Theo Browne published a video titled "Coding Isn't About Code Anymore" and framed the shift with a metaphor that stuck: engineers are becoming gardeners. You don't grow the plants yourself anymore. You design the garden, maintain the soil, prune what comes up wrong, and pull the weeds before they spread. His team at T3 Code went from 2 merged PRs a day to as many as 400 — with three engineers — by restructuring their entire workflow around tending agent output instead of producing code.
And Simon Willison, one of the most prolific open-source developers alive, spent the same day hiding his AI-written PR descriptions behind collapsible <details><summary> blocks. Not because the descriptions were wrong — they were accurate and thorough. Because they felt like slop: useful information buried in so much thoroughness that nobody wanted to read it. He now writes a short, human-curated paragraph on top and collapses the agent-generated essay underneath.
The argument isn't about whether AI can write code. It clearly can. The argument is about taste.
The Scale of the Shift
The Octoverse numbers are worth sitting with. In the 12 months ending September 30, 2026, GitHub recorded 34.3 billion commits and 17.9 billion pushes across public and private repositories. Agent-started PRs grew from 17% to over 40% in just seven months. These aren't toy projects or hobby repos — the growth spans enterprise teams and open-source infrastructure alike.
The merge rate is the number that leadership loves to cite: 90% of agent-involved PRs merged within two weeks, versus about 86% for human-only PRs. But that number hides more than it reveals. Semgrep's analysis found that AI-authored PRs took 20% longer from first human review to merge, even after controlling for PR size. And CodeRabbit's study of 470 PRs found 10.83 issues per AI-coauthored PR versus 6.45 per human-only PR. The PRs get merged — but the review work is harder, not easier.
As GitHub itself acknowledged: review is where developers now shape what comes back. The GitHub blog's guide to reviewing agent PRs puts it directly: more than one in five code reviews on GitHub now involve an agent, with 10x growth in AI-assisted code review in under a year.
What "Gardening" Actually Means
Theo's gardening metaphor isn't just vibes. He walked through the specific operational changes that made T3 Code's throughput possible:
1. Delete the dead weight. He deleted 250,000 lines of low-value unit tests in a single PR — zero regressions. Those tests weren't catching bugs; they were slowing agents down. Agents stall on the same friction that slowed human engineers, only worse — they lack the context to route around it. Clearing the path is gardening.
2. CI as the steering wheel. Instead of reviewing every line an agent writes, his team invested in CI checks that steer agent behavior. If the linter, type checker, and integration tests pass, the agent's PR is probably fine. If they don't, the agent re-runs. The human's job shifted from reading code to designing the checks that shape it.
3. Cap the review loops. T3 Code caps agent-to-agent review loops. An agent writes, another agent reviews, and if the back-and-forth exceeds a threshold, a human steps in. This prevents infinite recursion without requiring humans to review every change.
4. Turn off agent memory. Counterintuitively, Theo turned off agent memory entirely. Every task starts fresh. This prevents context pollution and makes each agent run reproducible — the same input produces the same output. It is the software equivalent of annual plants instead of perennials: you don't carry last season's baggage.
This maps to a broader pattern we've been tracking at AgentConn. The 10x PRs, 1x Reviewers bottleneck is real, and the teams breaking through it aren't finding faster reviewers — they're building better gardens.
Theo's Throughput Recipe — Delete dead tests. Invest in CI over manual review. Cap agent-to-agent loops. Turn off agent memory. The goal is a codebase where agents can work with minimal friction and CI catches what matters. The engineer's job is maintaining that environment — not reading every line of output.
The Decision Fatigue Problem
The cognitive cost of this shift is higher than most teams acknowledge. Stack Overflow's analysis named the hidden tax: decision fatigue.
When you write code yourself, you understand why every line exists. When an agent writes it, you face a different cognitive task: reconstructing the reasoning that was never written down. Stack Overflow reported that 80% of AI-generated content is edited before finalization, and the context needed to evaluate agent code is greater than for human code because no one authored the original reasoning.
Addy Osmani, engineering lead on the Google Chrome team, published "Agentic Code Review" in June and made the distinction precise: reviewers aren't validating correctness — they're judging necessity. Does this change need to exist? Is it the right abstraction? Does it fit the system's direction? These are design questions, not bug-finding questions. And they are exactly the questions that resist automation.
A CMU study analyzing 38,709 documents — 7,630 web articles and 31,079 Reddit threads — on code review in the AI era found that practitioner opinions are genuinely split. Some see AI-assisted review as the solution; others see it as the cause. The study's most striking finding: the observed trends shift direction under defensible analysis choices. The same data supports both "review is the bottleneck" and "review is working fine" depending on how you measure.
The practitioner discourse on Hacker News captures this tension. A 365-point thread on "AI coding agents generate more code, but not more software" drew 314 comments, with one engineer noting that AI-generated tests were a contributing factor in every defect severe enough for a formal root cause analysis they handled this year.
This is what comprehension debt looks like at scale. The code works. The tests pass. But nobody on the team can explain why a particular abstraction was chosen, because the entity that chose it doesn't remember.
The Taste Argument
Willison's <details><summary> technique is a small hack with a large philosophical implication. When he writes a one-paragraph summary and collapses the agent's 500-word description underneath, he's making a claim: the human's job is editorial judgment, not information production.
His earlier stance was stronger. In July 2026, Kenton Varda — creator of Protocol Buffers and Cap'n Proto — declared a moratorium on AI-written change descriptions for his team. The complaint: agent descriptions restate what the code already shows while omitting the higher-level framing a reviewer actually needs. Willison agreed, then softened. By November, his position was pragmatic: agent descriptions are useful reference material, but they need a human frame. The summary is the promise that someone with taste read this and decided it matters.
View on Simon Willison's Blog →
This tracks with what we've seen in the verify, don't review paradigm. The old code review question was "is this correct?" The new question is "should this exist, and does it match what I intended?" The shift from verification to curation is what makes gardening the right metaphor — a gardener doesn't check whether each flower is a valid flower. They check whether it's in the right place.
The Willison Pattern — Write a 2-3 sentence human summary at the top of every agent-generated PR. Wrap the full agent description in a collapsed details/summary block labeled with the model name and effort level. The summary signals that a human with context vetted the change. The collapsed detail is available for deep dives without cluttering the review queue.
Education Catches Up
Stanford rewrote its CS146S course — "The Modern Software Developer" — for Fall 2026, and the changes reveal what the academy thinks the new engineering discipline looks like. C.C. Gong reported that 85% of the Fall 2025 material was thrown out. The replacement curriculum covers:
- Agent skills and context engineering — writing the prompts, constraints, and AGENTS.md files that shape agent behavior
- MCP portals — connecting agents to external tools and data sources
- Agentic code review — the new review discipline for agent output
- Security in an agent-first world — when agents write most of the code, the attack surface changes
- Software factories — designing the production line, not just the product
This is a curriculum designed for gardeners, not writers. The assignments include building an MCP server from scratch, running agents from a design document, and security-scanning your own code. Writing code from scratch is no longer the central skill — it's the baseline that everything else builds on.
What the New Workflow Looks Like
If you accept the gardening frame, a senior engineer's day in late 2026 looks something like this:
Morning: Specification (30%)
Write or refine the prompts, constraints, and skill files that agents will execute. Review AGENTS.md and CLAUDE.md for accuracy. Define what "done" looks like for each task — not in code, but in outcomes. This is the planting season. Boris Cherny captures the sentiment of how deeply agents are integrated into the review loop itself.
Midday: Triage (40%)
Walk the review queue. Sort agent PRs by risk: which ones touch critical paths? Which are routine? Tools like Haystack are emerging specifically for this — surfacing the PRs that actually need human attention and letting the rest flow through CI. The four horsemen of agentic coding pattern helps categorize the failure modes.
Afternoon: System Gardening (30%)
This is the new work. Remove dead code that confuses agents. Simplify module boundaries. Delete tests that test implementation details rather than behavior. Update CI pipelines to catch the patterns agents get wrong. Write better error messages, because agents read them too. Think of it as loop engineering — designing the feedback loops that make agents more effective over time.
⚠️ The Deskilling Risk — If junior engineers never write code from scratch, they may never develop the judgment needed to evaluate agent output. Gardening requires knowing what a healthy plant looks like — and that knowledge comes from growing things yourself. Teams that skip the apprenticeship phase risk creating reviewers who can't review.
The Contrarian Corner: Gardening Might Be Premature
The gardening metaphor is seductive, but it may be premature for most teams. Theo's T3 Code is an outlier — a small, elite team with deep infrastructure investment. For the median engineering org:
The overhead is real. Prompt engineering, AGENTS.md maintenance, CI customization for agent patterns, and review queue management all take time. At typical agent adoption levels (not 400 PRs/day, more like 10-20), the gardening overhead may exceed just writing the code yourself.
Quality metrics don't support the narrative. Semgrep's data shows agent-authored PRs taking 20% longer to review. CodeRabbit finds ~68% more issues per AI-coauthored PR. The "fast code, tired developers" pattern from The Principled Engineer is real: speed at the generation layer is creating exhaustion at the review layer.
The merge rate is misleading. A 90% two-week merge rate doesn't mean 90% quality. It means 90% of agent PRs didn't get rejected within two weeks. That is a process metric, not a quality metric. The MSR '26 paper finding that reviewers express more positive emotions toward AI-generated code than human code suggests that the quality bar may actually be dropping — not because agents are good, but because review fatigue makes humans less critical.
Meanwhile, Google's response is to invest in automated review infrastructure. Their Sashiko project for agentic AI code review of the Linux kernel drew 111 points and 48 comments on HN — a signal that even at kernel-level complexity, the industry sees automated review as inevitable.
The honest assessment: gardening is the correct long-term trajectory, but most teams aren't there yet. They're in the awkward middle — too much agent output to ignore, not enough infrastructure to manage it well.
What To Do This Week
If you're an engineering lead reading this, here are three moves that don't require a full workflow restructuring:
1. Audit your review queue. How many PRs in the last week were agent-generated? What was the actual review time per PR? Most teams don't have this data, and you can't garden what you can't measure.
2. Adopt the Willison pattern. Require a human-written summary on every agent PR. Collapse the agent's description. This is a 5-minute process change that immediately improves signal-to-noise in your review queue.
3. Delete one thing. Find a test suite, a config file, or a module boundary that slows agents down and remove it. Theo deleted 250,000 lines. You can start with 250. The point isn't the volume — it's the practice of optimizing for agent productivity, not just human productivity.
The engineer's job didn't disappear. It changed. The question isn't whether you'll become a gardener — the Octoverse data says the garden is already growing. The question is whether you'll tend it deliberately or let the weeds take over.
For the data behind the review bottleneck, see our companion piece: 10x PRs, 1x Reviewers: The Code-Quality Bottleneck. For the emerging review paradigm, see Verify, Don't Review.
Originally published at AgentConn
