Verification Is the New Programming

We still tell computers what to do. That part of programming hasn’t changed. What changed is the language. The latest AI tools take instructions in our language, and they carry them out very well.

That moves programming up a level. And at the new level, the hard part is no longer writing the code. It’s knowing whether the code is right, and making sure every agent checks that the same way every time.

Verification is the new programming.

The threshold

In the past year, AI agents crossed a threshold. Senior engineers used to be clearly better than AI at real engineering work. On a large share of well-specified work, they aren’t any more.

The best evidence is Every’s Senior Engineer Benchmark, version 1.0 from June 2026. It asks an agent to rewrite a real production codebase “the way a senior engineer would.” The grading rubric isn’t just “do the tests pass.” A quarter of the points go to correctness proof: evidence of feature parity, preserved regressions for past incidents, a green final state and honest notes about gaps. Two human senior engineers set the reference at 89 and 96. Claude Fable 5 scored 91. Claude Opus 4.7, one generation earlier, scored 33.5, as Every reported in How We Work Now. Every has since removed that row from the table, but the gap between one model generation and the next is the point.

There is a harsher counterpoint, and it’s worth taking seriously. Snorkel’s Senior SWE-Bench builds 100 tasks from real pull requests in 12 production repositories, and it counts a task only when the solution both works and looks like what a maintainer would merge. In Snorkel’s June 30 analysis, Claude Opus 4.8 solved 24% that way. After a July refresh it was 30.5%, and the top of the current leaderboard is 39.3%.

So the honest claim is not that AI beats senior engineers at everything. It is that agents crossed into senior range on well-specified work, and the jump was sudden.

My own view is stronger than that, and I’ll state it as my argument: the share of work where AI matches or beats a senior engineer is already large, and it is growing every few months.

A phase change

Thresholds make change sudden. When an agent is worse than you at a task, it’s rational not to use it for that task: checking its work costs more than doing the work yourself. When it is as good as you, the math flips. Now it’s rational to use it for everything it can do, and to spend your own time on what it can’t.

There is no comfortable middle. Water at 99 degrees Celsius and water at 101 degrees Celsius are two degrees apart, and they behave completely differently. Software engineering just went through 100 degrees.

The gain

On the far side of the threshold, one human engineer can oversee a whole team of AI agents. I argue the productivity gain is enormous: 100x, and more. That number is my argument, not a measured result. But the throughput it predicts is already visible.

Lauren Tan, known as poteto, reports that her workflow has “allowed me to ship 2,000 PRs a month to production with high confidence” (Part 1 of her pstack guide). That figure is self-reported, and it’s hers.

On this site, two posts this week went from filed issue to verified production in 22 minutes each, cover image included, with an independent review and a release checked over HTTPS. The timelines are recorded on issues #309 and #313 in this site’s repository.

I’ve already written about what this does to the job and about the tooling. This post is about the part in between: how engineering knowledge actually gets into a team of agents.

“Tests pass” is not proof

poteto is the clearest writer on this subject, and her guide starts in the right place. Part 1 of The Complete Guide to pstack puts verification first: an agent must be able to verify its own work. In Part 2 she sums it up: “if an agent can’t verify its own work, nothing else matters.”

The key word is verify. An agent saying “tests pass” is not proof that the product works. Her playbook “tells agents that tests alone are not sufficient verification.” Work counts as verified only when the agent has actually run the code and seen it work. The guide’s verify-and-ship page opens with “It compiles” is not evidence, and asks for proof you can inspect: the failing test and then the passing one, a before-and-after video, a trace, a screenshot. As she puts it, “Green is not the same as safe.”

pstack, which lives in Cursor’s plugins repository, turns that into skills:

• /create-verification-skill generates a verification skill for your own app: a scripted way to launch it, drive a feature the way a user would and capture evidence, plus a feature map that tells the next agent what each feature is and what proves it works.
• /maintain-verification-skill keeps that skill honest as the product changes. She recommends running it at least daily.
• /poteto-mode is the entry point that routes everyday work through her playbooks, which lean on the verification skill.

Her public verification-skill-example shows the shape: a project-local skill and about 30 feature files for a fictional desktop app, each saying what exists, how a user reaches it, how to drive it and what usually breaks.

She is also honest about the limits. Rigor costs money: the setup guide says pstack “spends extra tokens on subagents and review panels,” and calls that the price of the rigor. And formal verification has no single answer. pstack has a skill for it, but the tool depends on the question: a model checker for bad orderings, a verifier for every input, and generated-input tests when no verifier runs on your language.

What I take from her work is that a verification skill is infrastructure, not a prompt. It is engineering knowledge, written down where every agent reads it.

Deterministic workflows

Verification tells an agent whether one change works. The software development lifecycle is everything around it: who takes which task, who reviews it, what must pass before it merges, what order things land in and how a release is checked. Senior engineers carry all of that in their heads. Agents don’t, unless you tell them.

So tell them. Write down everything you know about the lifecycle, especially verification. And don’t stop at writing it down. Encode it as a deterministic workflow: a tool that enforces the rule, so no agent can skip it, however confident it is.

This site is my worked example. Its repository tool, rxc, and the rules in its AGENTS.md and skills enforce the lifecycle:

• Issues say how we’ll know it works. Every issue states a clear outcome and a verification section before any agent claims it.
• Claims and leases. Each claim is a Git ref on GitHub, and only one agent can win it. A claim carries a lease that the holder’s actions renew. If a holder stops on its turn, the lease runs out and another session can take the work over.
• One worker per claim. Each issue or review gets its own worker, with its own name, worktree and branch.
• Independent review. Review always runs in a different session from the code. The tool refuses a pass, and the merge, while the pull request or its issue has unanswered discussion.
• Human gates. On issues that need my approval, nothing can pass or merge until I approve the current head myself. The tool refuses to post that approval for an agent.
• Ordering. A post and its cover are made in parallel, but the post can’t merge until its cover has.
• Checks. Every change runs the build, tests, type checks, lint and formatting, and the browser tests mapped to what it touched.
• Mechanical taste. This site never turns its motion off. That rule is a test, verify-no-reduced-motion.ts, which fails the run if any code tries. Another check fails a post whose cover prompt still carries its alt text and caption.
• Verified releases. Only the deploy role publishes, through a release journal that records success only after the live site is verified over HTTPS.

The lesson is in that list. Every rule that matters is enforced by a tool, not by an agent’s good intentions. An agent will forget a rule in a long session. A tool that refuses the merge never forgets.

The new job

When agents write the code, the engineer’s job moves to the layer above it:

• Write the verification. Teach the agents how to prove your product works, in your product, with evidence a human can inspect.
• Write the workflow. Turn the lifecycle in your head into rules a tool enforces: claims, independent review, required checks, gates and verified releases.
• Fix the process, not the output. When something slips through, don’t patch the result by hand. Add the check that would have caught it.

Teams of agents that follow those rules, and run the whole flow of work automatically, get the massive gains. Teams that skip them get confident output they can’t trust.

That is why verification is the new programming. We still tell computers what to do. Now the most valuable thing we tell them is how to prove they did it.