Somebody Has to Press Merge
On an August episode of Tom Johnson’s I’d Rather Be Writing podcast, Sarah Deaton, the only technical writer on Claude Code at Anthropic, mentions a goal she set during a company shutdown week: get her open pull requests from over two hundred to under a hundred. She merged or closed a hundred-something pull requests in one day.
It’s a passing detail in a longer conversation about how her docs get made now. She tells Tom the proposed changes arrive at “maybe ten to twenty PRs a day, from stakeholders, from the triaging bots.” She describes persona bots that walk through the docs every week as, say, a Windows user or an IT admin, and a daily release PR that “churns for like two hours” stitching together changelog entries and a diff (the record of exactly what changed in the code, between versions).
A pull request, if you haven’t lived in GitHub, is a proposed change parked in a backlog until someone with the authority to accept it signs off. Accepting it is called merging. And on those docs, by her own account, one person does that: “I’m still ultimately the one pushing merge on everything.” This is also my reality at Conductor.
The Cheap Part
In my last post about AI and the job, I described building a pipeline that reads the style guide, watches Jira for what shipped, drafts the change, and opens a GitHub PR for a human to review. It’s worth looking into that last part. The pipelines I build all end there, with a pull request waiting on me for review.
Mintlify’s State of Knowledge report, published in September, puts numbers on how fast the drafting end has grown. Between February and August, users told Mintlify’s agent to update documentation nearly 367,000 times. By the end of that window, 95% of those requests were fully automated, kicked off by webhooks and cron jobs. In other words, an event in some other system (a ticket closed, a release tagged) or a timer told the agent to go write something. No person decided that particular doc needed changing. More than 61% of the resulting pull requests were merged.
And only 9% of the 329 people Mintlify surveyed let agents publish without review.
Let’s put those thoughts side by side: Drafting got cheap. Deciding whether a draft is a correct reflection of reality didn’t.
What a Steer Costs
What Deaton walks Tom through isn’t just proofreading.
She explains that she does her reviews with Claude, inside GitHub, so that “every comment I make of ‘I didn’t like this’ can then feed back into a skill,” which is a reusable set of instructions the agent loads the next time it does that kind of work. Every PR gets checked against a pitfalls doc: a running list of the mistakes the agents keep making. And the question she’s asking isn’t only whether the sentence is right. It’s whether the change makes “these four other pages invalid.”
She also measures it. She counts the number of steers each docs PR needs, meaning how many times she has to redirect the agent before the change is right, and works to drive that number down by improving the skills. And she traces every false claim that lands in the docs back to where it came from, tracking the time from an incorrect claim being introduced to its correction.
Those are two numbers a writer can walk into a manager’s office with. In August, agents made 257 million requests to Mintlify-hosted docs, against 131 million human page loads. A page view tells you less about whether your docs are working every month that ratio grows. Mintlify’s report quotes Deaton putting the stakes plainly: “The same page that misled one developer now misleads an unknowable number of agents, which then propagate that misunderstanding to downstream users.”
Time-to-correction measures exactly that: how long a wrong answer was out there being repeated.
The Rubber Stamp
By her description, Claude Code’s docs have one reviewer, but it’s a reviewer who built the system around the review. Most teams adopting agents don’t have that.
Cherryleaf’s survey of technical communicators in June caught the other version. Several respondents said AI makes it easier for other people to generate documentation drafts, but those drafts still need expert review. One described the risk of writers becoming overwhelmed by low-quality pull requests from colleagues using AI. Seventy-six percent of the 109 respondents said they’d had no formal training in using AI for technical writing.
Picture a writer in that position with a queue of two hundred and a manager who reads the merge rate as a productivity number. The fastest way to clear a queue is to approve it. Nobody would be counting how many false claims went in with it, because nobody asked for that number.
That 61% merge rate is also a 39% rejection rate. Somebody decided those changes weren’t good enough to ship. That decision is a huge part of the job now.
If you’re the one buying the agent, this is the line item to look for. Counting merged PRs counts the cheap half. The expensive half is a person with the context to know what’s true about your product, the authority to close a PR instead of shrugging and merging changes regardless, and the time to build something like the skills and pitfall lists that make the next hundred PRs need fewer steers. Without them, you’ve automated the production of confident, unchecked claims about your own product.
The Part You Keep
In August I argued that “writer” names the smallest part of this work, and that the title might be the hardest thing to give up for many career technical writers. I still think that’s right. But it left a question hanging: if you give up the drafting, what exactly are you keeping?
This is it: knowing that a change to the authentication article quietly breaks four others articles. Knowing which engineer to ask when a claim smells wrong. Knowing the difference between a sentence that’s accurate and a sentence that only sounds accurate. That was always the core of the craft. It just used to be buried under the drafting, and now the drafting has been lifted off it.
The writers who come through this well won’t be the ones who review fastest. They’ll be the ones who can tell you, with a number, how long a wrong answer stayed live on their watch, and what they built so it doesn’t happen twice.
Somebody has to press merge. It should be someone who knows—and understands—what they’re approving.