Maybe the next big developer tool isn't another AI that writes code.
Maybe it's an AI that proves the code is safe to ship.
We've spent an enormous amount of effort making software faster to produce. Coding agents can research a problem, navigate a codebase, implement features, refactor systems, write tests, and iterate at speeds that would have seemed unrealistic a few years ago.
But there's an interesting consequence: the bottleneck is starting to move.
It used to be implementation. Increasingly, I think it's verification.
The bottleneck is moving
We can generate more code, but humans still review PRs. We can implement features faster, but QA still has finite capacity. We can create hundreds of changes, but regression testing, visual testing, accessibility, security, observability, and deployment safeguards don't automatically scale with them.
So maybe we need to rethink the problem.
Instead of asking "How can AI write even more code?" maybe we should start asking: "How can AI prove that this particular change is safe?"
What a proof layer would actually do
Imagine a system that understands the requirement, the code change, the architecture, and the risk involved. Before anything ships, it determines:
- What needs to be proven?
- What could this change break?
- Which tools already available to the engineering team can prove those things?
- What evidence do those tools provide?
- What's still uncertain?
- And ultimately: is there enough evidence to safely ship this change?
That last set of questions deserves its own walk-through. A change touching a shared Button component implies different proofs than a change touching a cron job:
Importantly, I don't think that means replacing the tools engineering teams already use. One company might use Playwright, Chromatic, and Sentry. Another might use Cypress, Percy, and Datadog.
The underlying question is the same: what needs to be proven, and what evidence can our existing engineering stack provide?
"Insufficient evidence" is a valid answer
And sometimes the correct answer shouldn't be passed or failed.
It should be: "Insufficient evidence. We haven't proven this is safe yet."
Most CI systems today can only answer a narrow question: do the tests that exist pass? A proof layer answers a harder one: do the right checks exist, did they run, and is the combined evidence enough to support shipping this change? Those are different questions, and the second one is the one that actually protects users.
Verification at machine speed
As AI pushes implementation toward machine speed, I think verification eventually has to move toward machine speed too.
That doesn't mean humans stop deciding. Engineers and designers still define what "correct" means — the accepted baselines, the risk tolerance, the product behavior worth protecting. What changes is the speed of the evidence gathering: which checks to run, against what, and whether the results actually address the risk.
The future of AI-assisted engineering isn't just about generating more software.
It's about being able to trust the software we're generating.