Verification is the new bottleneck: Blacksmith, Warp Factories, and juniors retrained as reviewers

Three signals in four weeks, none of them about writing code. On August 12 Blacksmith closed a $45 million Series B at a $550 million valuation, roughly ten times its value in under a year, with over 5,000 customers up from about 700, selling CI infrastructure plus an agent called Codesmith that fixes failed checks. On August 18 Warp opened a closed beta of Factories, a cloud pipeline for fleets of coding agents. On September 8 IEEE Spectrum reported that the volume of AI-generated code is pushing companies to train junior engineers as reviewers rather than authors. The common thread is the thesis in Blacksmith's own pitch: Cursor, Codex and Claude Code generate changes faster than verification can absorb them.

What each of them actually ships

Blacksmith sells the boring layer. Faster CI runners, and Codesmith, an agent whose only job is a red check. The valuation tells you where buyers think the pain is: not in producing a diff, but in getting the diff through the gate.

Warp Factories is the more ambitious shape: a repeatable pipeline of triage, spec, implement, review, verify and monitor, running any model on any harness, with evals on your own data plus self-improvement and memory. Warp says Factories already handles 30-35% of its own internal tasks, and qualified organizations get $10,000 in credits. Strip the branding and it is agents plus evals plus CI in one loop; the defensible part, if there is one, is the eval on your data.

Ramen Aura 1.0, a game-development agent for Unity and Unreal released this week, is a smaller example of the same instinct: it ships a dedicated Verification Agent and persistent project memory as headline features, ahead of generation speed.

And the IEEE Spectrum piece is the human side. When the marginal cost of a pull request approaches zero, the scarce skill is spotting the subtle defect in a plausible diff, and companies are retraining juniors for exactly that.

Why the bottleneck moved

A senior engineer's day used to be split between writing and checking. Agents took the writing. The checking did not shrink; it grew, because review load scales with the number of diffs, and the number of diffs went up. CI did not get faster to compensate. Human attention did not get cheaper. So the queue formed at verification, and now there is a market forming around the queue.

There is a cost wrinkle too. Some orchestration-style models bill verification rounds as ordinary tokens, so a "verify before you merge" loop shows up on the invoice, not just in wall-clock time. Verification is now a line item.

Writing code stopped being the constraint the day a diff cost nothing; the constraint is now whoever, or whatever, says yes.

What to change in your own pipeline

• Measure the queue. Time from PR open to merge, split into CI wait, review wait and rework. If review wait dominates, buying faster runners will not help.
• Put a verifier agent before the human. Not to approve, to reject: run the tests, check the spec, flag the diff that touches files the task did not mention. I described the shape of this in Codex code review on GitHub.
• Make the agent write the test first. A diff with a failing test attached is reviewable; a diff with a paragraph of explanation is not.
• Budget verification tokens separately. Track them as their own line so a cheaper generator model that produces more rework does not look cheap.
• Retrain reviewers deliberately. The IEEE Spectrum point is a hiring and onboarding decision. A junior who can read a 400-line agent diff and find the off-by-one is worth more this year than one who can write it.
• Run agents in parallel only when the gate scales. A fleet of parallel agents multiplies diffs, and if the gate is one senior engineer, the fleet just builds a longer queue.

The honest gap

The strongest numbers here are funding rounds and a vendor's internal adoption figure. Blacksmith's valuation says investors believe the thesis; it does not measure defect rates. Warp's 30-35% is Warp's count of Warp's tasks, in a closed beta. And the IEEE Spectrum piece is reporting on a trend, not a controlled study of whether junior reviewers actually catch more. I believe the thesis because it matches my own queue. I cannot yet prove it with anyone else's data.