Tags
Share
The agent finishes the task in four minutes. A few hundred lines of code, the tests pass, and the summary is nothing but green checkmarks.
Then you open the diff. And spend the rest of the afternoon on it.
If that sounds familiar, you are doing a kind of work that still lacks a shared name.
Writing code stopped being expensive. Checking whether that code does what it was supposed to do is now the expensive part.
Over the past three years we learned one way of working with models after another: prompt engineering, context engineering, harness engineering, loop engineering. Each of them got agents to produce more, and faster.
None of them answered the question left at the end of each one: how do we know the result is correct? Agents that write code are becoming a commodity, and the market is moving to that question. At Exadel we are betting on it, and we call the discipline that deals with it Verification Engineering.
Coding Was A Small Part Of The Job
You have probably heard the story: developers used to spend half their day writing code, and now AI will do it for them. The research says otherwise. IDC put application development at 16% of developers' time in 2024, a 2025 Microsoft study of 484 of its developers put coding at about 11% of the actual work week, and a field study of 78 professionals found that about 58% of their time went to understanding code.
So AI sped up the part of the job that was small to begin with. The biggest part, understanding code, got a lot more material.
The Cost Of AI-generated Code Moved To Review
It shows most clearly in data from real teams. Faros AI analyzed two years of telemetry from 22,000 developers on more than 4,000 teams, comparing each company's periods of lowest and highest AI adoption. Epics completed per developer went up 66% and the PR merge rate per developer went up 16%. Median time in review went up 441%, and the chance that a merged change causes a production incident more than tripled.
These numbers come from a company that sells engineering analytics, and they show correlation, not causation. The direction is still clear: the more code AI writes, the longer someone has to spend checking it.
Surveys say the same thing. In the Stack Overflow Developer Survey 2026, 48% of the developers who answered the question on trust said they trust AI when they can easily verify the result. Only 6.6% trust it with important decisions. DORA's 2025 report describes AI as an amplifier: teams with strong practices gain throughput without losing stability, and the rest see their existing problems grow.
There is also a perception problem. In a randomized 2025 study by METR, 16 experienced open-source developers worked 19% slower with AI, even though they estimated they had sped up by 20%. Newer METR data from 2026 points to a speedup, but METR itself calls that signal unreliable. Without verification, we don't even know whether we are faster.
From Prompt Engineering To Verification Engineering
The names of new skills changed every few months. Each one answered a different question about how to get the model to work better.
Prompt engineering
2023-2024
How do I ask the model?
Context engineering
June 2025 (Tobi Lütke, Andrej Karpathy)
What does the model need to know?
Harness engineering
February 2026 (Mitchell Hashimoto, OpenAI)
What environment does the agent run in?
Loop engineering
June 2026 (Peter Steinberger, Boris Cherny, Addy Osmani)
What starts the agent, and when should it stop?
Verification engineering
now
How do we know the result is correct?
Each of these layers already included some verification. The harness added tests and linters, and a loop needs a stop condition that a machine can check. Only now, with generation cheap, is verification becoming a discipline of its own.
In July 2025, Jason Wei formulated "verifier's law": AI gets good fastest at tasks that are easy to verify. Karpathy gave the practical version in his 2025 Software 3.0 talk: keep the generation-verification loop fast and keep AI on a tight leash, with changes small enough for a person to check.
What Is Verification Engineering
Verification Engineering is designing proof that software built by AI does what it was supposed to do. It starts before generation, with correctness criteria, and ends after deployment, with evidence from production.
The discipline is made up of specifications and acceptance criteria, independent verifiers (tests, types, static analysis, a reviewer agent, formal proofs), and human review scaled to the risk of the change. It also covers validation: whether we are building the right thing at all.
You can write it as a multiplication: delivered value = generation × verification. If verification is zero, the result is zero too, no matter how much code was written.
The workflow changes with it. A person used to go through every step. Now they stay at the beginning, where "correct" gets defined, and at the end, where the evidence gets judged.
Six Principles Of Verification Engineering
- Correctness is defined before the code. Acceptance criteria and tests are ready before the agent starts generating.
- Whoever writes doesn't grade. The reviewer works in a separate context, and tests are not written in the same step as the implementation. Agents can change a test so that it passes instead of fixing the code.
- Run it, don't claim it. The model will happily say "done, everything works". What counts is a test that passed.
- Changes sized for review. Nobody can properly review a 10,000-line diff, so a change is only as big as a person can realistically review.
- The verification budget grows with risk. A styling fix and a change to payments don't get the same review.
- The evidence stays. Test results and reviewer decisions are recorded, so you can reconstruct why a change reached production.
Alex Lavaee of Microsoft Research has described a similar set of principles and also uses the name verification engineering. It looks like the practice already exists and only lacks a shared vocabulary.
Verification Engineering In Practice With Exadel Colleague
At Exadel we build Exadel Colleague (available on AWS Marketplace) for the place where those Faros numbers say AI-assisted teams now lose time: checking the work.
What a delivery lead gets is something to point at. The agent reads the ticket and proposes a verification plan, and a person approves it before anything runs. Each test becomes its own subtask, with video and logs attached, and the verdict lands on the parent ticket. That is the first principle and the last one at work: correctness defined before anything runs, and evidence that stays with the ticket.
The way we built it, the agent picks up a ticket once the code is done and writes its verification plan as Gherkin scenarios. If the acceptance criteria leave gaps, it asks before it plans and explains why each question matters. Besides video, a test can carry screenshots and console and network logs, and you can download all of it as one package. The agent checks work that a different agent wrote, and Colleague's testing agent writes TDD and BDD tests before any code exists, so whoever writes doesn't grade. QA engineers stay in charge of the result: the agent prepares the proof, and they decide whether it is enough.
What Software Can Learn From Chip Verification
The semiconductor industry went down this road earlier. A design error there means a new set of masks and months of delay, so verification has long been a separate profession, with an IEEE standard for its main methodology (UVM). According to Wilson Research Group's 2026 study for Siemens EDA, verification takes about half of a chip project's time. Software is on the same path: when producing a design gets easy, the work shifts to proving that the design is correct. Because chip design already has verification engineers, for software written by AI it is clearer to say AI Verification Engineering.
What Does An AI Verification Engineer Do?
If verification is becoming a discipline of its own, someone has to own it. I propose calling that role AI Verification Engineer. It's the person responsible for the team being able to show that code written by agents does what it was supposed to do. In a small team, this can be an extra responsibility for one of the developers. In a large organization, it's a separate position, as it is in chip design.
The job covers:
Criteria
Turns requirements into acceptance criteria and tests before the agent starts writing
A specification you can run
Verifiers
Chooses and builds independent verifiers: tests, types, static analysis, a reviewer agent, formal proofs
A set of checks in CI
Independence
Makes sure tests and review don't come from the same context as the code, and catches cases where the agent fixed the test instead of the code
Separate contexts and protected test files
Risk
Sorts changes into risk classes and decides how much verification and what kind of review each class gets
A review policy
Change size
Sets how big a change can be for a person to review it properly
PR size limits
Verifier quality
Checks whether the verifiers catch bugs, for example with mutation testing and by analyzing incidents that got past every check
Verifier effectiveness metrics
Evidence
Makes sure test results and reviewer decisions are recorded, and collects evidence from production after deployment
A record that lets you reconstruct every decision
Other roles already handle some of these tasks, and none of them owns the whole thing:
Tester, QA
Checking the finished product, usually after the code is written
Starts before generation, with the definition of correct, and designs a system that checks every change
SDET, test automation engineer
Writing automated tests for code written by people
Code reviewer, tech lead
Reading changes and judging their quality
Decides what a machine checks and what a person checks, and matches the depth of review to the risk
SRE
Reliability of the system in production
Uses production data as the final piece of evidence, and starts much earlier
Verification engineer in chip design
Verifying a chip design before the masks are made, with established methodologies
Brings that approach to software, where an agent delivers a change in a few minutes
I'd measure this work by the share of deployed changes that have complete proof of correctness.
Can AI Verify Itself?
This is the strongest objection to the argument. AI agents already review pull requests, and models write tests and, more and more often, formal proofs.
Verifier's law cuts both ways here: since AI takes over tasks that are easy to verify first, routine code checking will be automated just like code writing.
The question of what "correct" means stays with us, though. When AI writes both the code and the tests, the tests stop being independent evidence. The authors of "The Verification Horizon" (2026) show that there is no universal verifier and that the verification system has to grow along with the agents.
So the form of verification changes: instead of reading diffs, we will design verifiers. Someone still has to define the intent, the criteria, and the acceptable risk, and someone takes responsibility for the outcome.
The Last Layer Of Human Responsibility
Prompts, context, harnesses, and loops are ways to get a machine to produce more. Verification Engineering is a way to make that output safe to use.
The tools will keep changing. Verification is the layer you can't hand off without handing off responsibility. An agent can write the code and another agent can check it, but a person decides what "works" means.
Written by: Michał Jaroń, Lead Data Science Engineer
October, 2026
Sources
- IDC, "How Do Software Developers Spend Their Time?" (Adam Resnick, February 2025; 2024 data), reported by InfoWorld
- Kumar et al., "Time Warp: The Gap Between Developers' Ideal vs Actual Workweeks in an AI-Driven Era", Microsoft, 2025 (arXiv 2502.15287)
- Xia et al., "Measuring Program Comprehension: A Large-Scale Field Study with Professionals", IEEE Transactions on Software Engineering, 2018
- Faros AI, "AI Engineering Report 2026: The Acceleration Whiplash" (vendor telemetry, correlational)
- Stack Overflow Developer Survey 2026, AI trust data (48.0% of 14,304 respondents to the trust question; 6.6% for important decisions)
- DORA, "State of AI-assisted Software Development", 2025
- METR, randomized study of experienced open-source developers, July 2025, and update, February 2026
- Jason Wei, "Asymmetry of verification and verifier's law", July 2025
- Andrej Karpathy, "Software Is Changing (Again)", Y Combinator AI Startup School, June 2025
- codecentric, "Loop, Harness, Context Engineering: The Terms Explained"
- The Neuron, "The Future of Coding Agents, According to Microsoft Research", with Alex Lavaee, October 2026
- Siemens EDA and Wilson Research Group, 2026 Functional Verification Study
- "The Verification Horizon: No Silver Bullet for Coding Agent Rewards", arXiv 2606.26300, 2026
