The teams winning with AI aren't typing faster. They rebuilt everything around it.

AI has made the actual writing of code fast, in some cases nearly instant. What it hasn’t sped up is the human work on either side of that typing: deciding what to build (direction) and confirming what got built is correct (verification). Take typing off the table and the bottleneck doesn’t disappear, it just moves to those two steps, and direction goes first, since everything downstream inherits it. Our companion piece makes that argument in full. Here, we get practical: the habits that keep direction sharp and verification honest when an agent can out-type your whole team.

The 20,000-Line PR Problem

The slow step used to be typing. Now it’s trusting: pull requests are bigger, arrive faster, and reviewers can’t keep up.

We felt this shift directly. At Arsenal, we’re the embedded product team for our partner startups, shipping across multiple codebases where review velocity isn’t optional. Before AI, a PR that size was rare almost by default: a person can only type and think through so much code in one sitting, so pull requests naturally landed somewhere in the 200 to 400 line range, which is also about where unaided human review reliably holds up. AI removed that natural ceiling. As we integrated it into our workflow, traditional ticket structures couldn’t keep pace with the volume of generated code, and PRs that used to run a few hundred lines started arriving at 20,000. AI doesn’t just speed up coding, it makes scope creep the default, because nothing about generating code imposes the discipline that typing it by hand used to enforce for free.

That’s a problem, not a milestone. Review quality falls off well before 20,000 lines: reviewers start skimming instead of reading, context gets lost across a diff that size, and the things that actually matter, a misread requirement, a subtly wrong flow, an edge case nobody tested, hide behind volume instead of complexity. Bigger, faster PRs don’t just strain reviewers, they erode the thing review exists to protect: confidence that what shipped is what was intended. We’re still in the adjustment phase to that shift. The rest of this post is the structure we built to force those PRs back down to something a human can actually hold in their head, and what’s still left to check even after they are.

The One Step We Don’t Automate

Solving PR size is a structural fix, but it assumes the PR should exist in the first place. Before a feature ever gets chunked into reviewable pieces, someone has to decide it’s worth building and describe it precisely enough to build correctly, and neither of those calls gets automated. The first is whether the feature is worth building at all. The second, and the one that gets less attention, is exactly what you’re asking for.

There’s a wide range between handing an agent a fully thought-out spec and handing it a vague idea and letting it fill in the rest. In traditional development, that gap used to close itself: building a feature took long enough that a developer had time to think through the what and the how as they went, and there was room to stop and ask a clarifying question mid-build when something was unclear. AI coding removes both. It moves fast enough that there’s rarely a natural pause to ask, and it will fill in whatever you left unspecified without hesitation, just not necessarily the way you meant. Under-specifying used to cost you time. Now it costs you a wrong feature, built at full speed, that looks finished. The more velocity you have, the more precisely you need to know what you’re asking for before you ask for it.

feature-planner will take whatever ticket you hand it and turn it into a sharp, well-scoped plan, which solves the second problem, not the first. AI amplifies the input, it doesn’t question it. It rarely notices a bad bet, and it never asks whether you should be building this at all.

The odds make that expensive. In controlled experiments, most well-built ideas don’t move the metric they target. At Microsoft, only about a third did; the rest did nothing or made things worse. Cheap generation doesn’t improve those odds. It just lets you lose faster, and the faster the loop runs, the more it costs to point it at the wrong thing.

So the gate before feature-planner is human, and it stays human: is this worth a teammate’s review time, a slice of the roadmap, a permanent place in the codebase, and have you specified what you actually want closely enough for a plan to be evaluated against it? Answer both first. Everything below assumes you already have. The method makes a good, precisely specified bet cheap to execute; it can’t make a bad or vague one good.

What AI Review Can’t See

Direction decides what should get built. Verification is where you find out whether it actually got built right, and AI changed that step almost as much as it changed writing code in the first place. AI review collapsed the cost of the mechanical layer: style drift, missing null checks, the obvious misses, the nits. That floor is now cheap and automatic, and it’s tempting to call review solved.

But the nits were never the expensive part. The expensive part is judgment that lives outside the diff. Does this feature do what it was actually meant to do? Is the spec satisfied, or just plausibly satisfied? Does the flow hold up when a real person walks through it, not just when the tests pass? Are these the edge cases that matter, and is this still the right shape six months from now?

A reviewer model can tell you the code is correct. It can’t tell you the code is right.

What counts as “right” is measured against intent, and intent lives in the spec, the design, and the user’s head, none of which are in the changeset.

This gets more important as velocity rises, not less. Ship 10× more and the cost of shipping something technically correct but wrong (wrong feature, misread requirement, a flow that confuses the user) multiplies in proportion. AI made the cheap half of review cheaper and handed you the expensive half whole. That half is now the bottleneck, and it’s the half that protects the user.

It’s also where the loop closes. Verification is checking the output against the bet you made at the top: the feature you decided was worth building, specced precisely enough to evaluate. Sharp direction gives verification something concrete to check against; vague direction leaves you guessing whether the thing in front of you is what anyone wanted. Direction and verification are the same discipline seen from both ends: the human bookends around an automated middle.

So spend your review attention accordingly. The machine has already cleared the mechanical layer; what’s left for you is the part only you can do: confirm it matches intent, confirm the experience works, confirm it was worth building. That isn’t what’s left over after automation. It’s the job.

Four Habits, One Pattern

Direction and verification are the two calls only a person can make, and everything we’ve described so far is about protecting them. Everything in between, turning a validated idea into merged, reviewable code, is where the agent does the actual work, and that middle needs its own structure to stay disciplined at AI speed. The four skills below are that structure: they don’t replace either human call, they hold the automated middle to the same discipline, so that what lands in front of you at review is small enough, clean enough, and honest enough for your judgment to actually count.

Four habits, each a small intervention at a critical point in the loop: plan, refine, review, hand off, then back to plan. They run as a loop, not a line, and each handoff sharpens the plan for the next unit of work.

Underneath three of the four is the same move, and it’s the part worth stealing even if you never touch our skills: fan out to parallel sub-agents, then synthesize. Instead of asking one agent to plan, audit, or review in a single pass, we split the job across specialists working in parallel, then reconcile their output. It’s how you get something close to senior-engineer judgment at machine speed: breadth from the fan-out, coherence from the synthesis, without asking a single context window to hold the whole problem at once.

What we call “skills” below isn’t Claude-specific. The same patterns translate to any stack that lets you shape an agent with structured instructions: a custom command in Cursor, an extension in Copilot, an MCP server, or a system-prompt template for a local model through Cline or Continue.dev. We picked Claude Code because one subscription replaced what would otherwise be several point tools. Then we built four skills on top, one per step. Three we built in-house; the fourth we adapted from open source.