The Verification Frontier
The most surprising change in my work over the past few years is not that AI can write code. It is that I increasingly trust it to work at levels of abstraction where I no longer inspect every line.
That trust accumulated through repeated use. At first, I delegated small, well-defined functions. Then components. Then entire features. I reviewed the output, ran the tests, and watched the implementations work. Over time, I developed an intuition for where AI could operate reliably.
But the boundary was not merely becoming clearer. It was moving upward.
Frontier labs were increasingly evaluating and training models against outcomes defined at higher levels of abstraction: not just whether an individual unit test was correct, a repository built successfully, or an agent completed a larger software task similar to those in SWE-bench. As more complex outcomes became verifiable, more complex behavior became trainable.
This suggests a broader principle behind recent AI progress:
I can verify, therefore I can.
One important mechanism behind this progress is reinforcement learning with verifiable rewards, or RLVR. A model attempts a task, receives an automatically checkable signal about whether it succeeded, and learns through repeated trials which actions are more likely to work.
Why coding improved so quickly
Software provides this feedback unusually well. An agent can write code, call tools, run tests, inspect failures, and revise its approach within seconds. Thousands of attempts can run in parallel, each receiving a relatively clear signal: the code compiles or it does not; the tests pass or they do not; the website behaves as expected or it does not.
Bigger models, longer context windows, and better tools matter too. But cheap, parallel, verifiable rollouts are a major reason coding agents have improved so quickly.
Act. Observe. Verify. Revise.
From implementation to specification
The traditional software development process begins with a business problem. Engineers gather requirements, translate them into a high-level architecture, divide the architecture into components, define the interfaces between them, and implement each component.
AI has not eliminated this process. It has changed where the difficult work occurs.
We still need to understand the business problem. Requirements are often incomplete, contradictory, or based on assumptions that have never been stated. Someone must decide what the system should optimize for, which tradeoffs are acceptable, and what could go wrong.
My workflow now looks roughly like this:
- I develop an initial architecture.
- Use AI to critique the design and investigate alternatives, risks, and unfamiliar concepts.
- Revise the architecture and define its interfaces.
- Use AI to implement well-specified components.
- Verify the integrated system through tests and code review.
The greatest acceleration occurs during implementation(step 4). When an API is clearly defined and its expected behavior is precise, AI can often implement routine components with little intervention.
The important skill is no longer simply deciding whether AI is trustworthy. It is knowing where it is trustworthy and which parts of a system still require close human judgment.
The next abstraction layer
This shift belongs to a familiar pattern in the history of programming.
Early programmers worked directly with machine instructions. Assembly languages replaced numeric instructions with symbolic representations. Languages such as FORTRAN allowed programmers to describe computations at a higher level. Later languages such as Python brought programming closer to readable pseudocode.
Each abstraction layer allowed programmers to specify less of the underlying mechanism and focus more on the intended behavior.
A Python programmer rarely thinks about processor instructions or machine registers. Those operations still happen, but lower layers of the system handle them.
AI-assisted development continues this progression. Instead of specifying every operation in code, we increasingly describe the desired behavior in natural language. We provide the goal, constraints, interfaces, examples, and acceptance criteria. The model fills in more of the implementation.
Natural language will not simply replace programming languages. Software still requires precision, while ordinary language is ambiguous. The deeper change is that developers can increasingly work at the level of intent while AI translates that intent into executable systems.
As AI absorbs more of the implementation layer, specification becomes more important. A vague requirement can now produce a large amount of incorrect software faster than before. The bottleneck moves upward, from writing every instruction to deciding what should be built and expressing that decision clearly enough to evaluate.
Eventually, the interface between intention and implementation may become even thinner. We may communicate with machines through speech, continuous context, behavior, or perhaps one day brain signals rather than carefully constructed prompts.
The endpoint would be a system that translates intent directly into reality. But the more independently such a system acts, the more important it becomes to determine whether its actions actually worked.
When implementation becomes cheap
If this trend continues, AI agents may eventually perform software projects that currently require large engineering teams. They may execute repository-wide refactors, migrate backends of a huge monolith to new tech stacks, reproduce standardized product features and continuously maintain production systems, each of them verifiable through increasingly sophisticated RL environments.
This does not mean every software company becomes replaceable.
A company may still be protected by proprietary data, distribution, customer relationships, regulatory approval, workflow integration, network effects, brand, or operational expertise. These advantages are not automatically reproduced by generating code.
But companies whose primary advantage is that their software was difficult or expensive to implement may face increasing pressure. As implementation becomes cheaper, the moat moves elsewhere.
The same shift may occur within engineering teams. Routine implementation done by junior ICs becomes less valuable, while system design, product judgment, domain knowledge, evals, and accountability become more valuable.
AI does not remove engineering. It changes which layer of engineering matters most.
Where verification slows down
Beyond software, particularly in the physical sciences, the verification loop becomes slower and more expensive.
Suppose we ask a model to discover a material that is stronger than diamond, less dense than lithium, and conductive only on its surface.
A model could apply theoretical constraints, search known structures, run simulations, and propose candidates. Researchers could then attempt to synthesize those candidates and measure their properties.
But this feedback loop is much slower and more expensive than running a software test.
A simulation may predict that a material is stable, but the material may be impossible to manufacture. It may work only under idealized conditions. Heat, pressure, contamination, structural defects, or unknown physical interactions may cause it to behave differently in reality.
Eventually, the proposal must confront the physical world. Faithfully simulating a material’s real-world behavior is difficult because it may require quantum-mechanical modeling of extremely complex systems.
Drug discovery faces the same limitation. AI can propose molecular structures, predict binding affinities, identify biological targets, and rank promising candidates. But those predictions are proxies. Researchers still need laboratory experiments, toxicity studies, animal testing, and clinical trials to determine whether a drug is safe and effective.
The feedback may take months or years to arrive. It may also be noisy. A treatment can behave differently across patients because of genetics, environment, dosage, disease progression, and biological interactions that no simulation captures completely.
These tasks are not impossible to verify. They are difficult to verify quickly and faithfully.
Simulations can shorten the feedback loop, but a simulation is still a map of the territory, not the territory itself. It simplifies assumptions, omits variables, and approximates systems that may be too complex to model perfectly.
Progress in science may therefore depend not only on stronger models, but also on better ways to connect those models to reality. Automated laboratories, robotic experimentation, faster clinical infrastructure, and more accurate simulations could make physical feedback faster and more useful.
Conclusion
AI capability advances fastest when the distance between action and consequence is short. In software, that distance can be measured in seconds. In the physical world, it may take months or years.
Simulations, automated laboratories, and robotic experimentation can shorten that loop, even if no verifier captures reality perfectly. The closer our verification environments approximate real-world consequences, the more complex the behavior we can reliably train.
I can verify, therefore I can.