Stop perfecting the ticket

A product manager spends an afternoon on a ticket in Linear. An agent builds exactly what it says, the tests pass, and it still isn’t what anyone meant.

That’s becoming the normal failure. The code itself can get better: Chris Evans reports that his team ships three times as much code as a year ago, while the share of changes causing incidents fell 41%. The harder problem is building what the team meant. Sean Goedecke routinely finds massive errors in AI-written code:

These are not bugs — the code typically does what the AI wanted it to do — so much as they’re problems of alignment.

In his example, a small change ballooned into a three-thousand-line diff. The agent had built machinery to “fix” a race condition that was harmless by design.

The software development lifecycle still puts most of the thinking up front, in the ticket. I think that balance should flip. Write rough, high-level tickets, let the agent build, then do most of the refinement on the change, together with the people who care about the outcome.

The ticket is a guess

Planning was front-loaded because building used to be slow and expensive. A wrong build meant weeks of wasted engineering, so the product manager tried to settle every question up front.

That was always a guess. Kent Beck points out that writing the whole spec first assumes you’ll learn nothing during implementation.

Meeting the written spec isn’t the same as being right, either. METR had maintainers of scikit-learn, Sphinx and pytest review agent-written fixes that passed SWE-bench’s tests. They judged that roughly half would not have been merged. Some had code quality problems, some broke other code, and some didn’t solve the problem. The agents never got to respond to feedback, as a human contributor would.

Agents make the guess more expensive. A human engineer notices when the ticket stops matching reality and comes back with questions. An agent keeps going. As Amelia Wattenberger puts it:

A stale spec misleads agents that don’t know any better. They’ll execute a plan that no longer matches reality, confidently, and they won’t flag that anything is wrong.

Her answer is to have agents keep the spec up to date. I’d take her opening line further: “The only documentation you can 100% trust is the code itself.” If that’s true, the place to settle what we meant is the change, not a better-maintained ticket.

Judge the change together

A ticket describes what you hope will happen. A change shows what did happen, and everyone can have an opinion about it.

Edwin Morris, a designer at Jane Street, now builds prototypes instead of writing specs:

Instead of laboring over spec docs, building Figma mockups, writing proposals, and reviewing the implementation with devs, I find myself building prototype features that just do the exact thing I have in mind.

The benefit, he says, is that others “can just use it.”

Taylor Otwell has gone further. He turned off GitHub issues on most Laravel packages and asks people to describe the problem to a coding agent and open a pull request instead. Even if the code isn’t great, he says, it can be iterated on. The conversation now starts on the change.

When the code is mostly sound, the hard question in review isn’t “is this correct?” but “is this what we meant?” Engineers can’t answer that alone.

So tickets should get rougher. Instead of slicing a feature into small engineering tasks, write one ticket for a customer outcome, like “customers can cancel their own subscription”. The agent builds the whole thing. The refinement that used to happen in the ticket happens at review, where the product manager, the designer and whoever knows the customer can see what was actually built.

A rough ticket gives the agent more room to wander, like Goedecke’s three-thousand-line fix. But his task was already precise: thread one extra value through existing code. A tighter ticket wouldn’t have stopped it. Reading the change did.

Not everyone agrees. Cockroach Labs makes its agents write a plan before any code, and calls plan review “the highest value review in the system”, even though plans are rejected less than 10% of the time. There, another agent reviews the plan. A quick check like that is cheap and worth keeping. But the people who know what the customer meant learn far more from what was built than from a plan.

That doesn’t mean everyone reviews everything. Most changes don’t need a product manager. Bring non-engineers in where getting the outcome wrong is most costly, and have them review the outcome, not the diff.

The missing infrastructure

There’s a catch: review is already overloaded. A study of 718 firms found that after firms adopted coding agents, the average time to review a pull request rose 49%, and the share where reviewers asked for changes nearly doubled. Adding more people without changing how review works makes that worse.

PostHog shows the first step. Its StampHog agent approves roughly 1 in 3 pull requests in its main repo on its own, and sends anything touching auth, secrets, billing or public APIs to an expert. Most teams aren’t there yet. Spotify’s coding agent gets about 1,000 pull requests merged every 10 days, and the engineers behind it call review “the new bottleneck”. Which pull requests to auto-merge is, in their words, “a hard question, and it’s not fully answered.”

Reviewing as a team needs three things most teams don’t have yet:

• Accurate risk metrics, so people only look at the changes that need them.
• Routing to the right people, across product, design and engineering, not just whoever owns the code.
• An interface that explains the change quickly, so they can contribute without reading the diff.

We’re building those pieces at Distill. Spend less time writing the ticket, and more time judging the change together.