Everyone I know bought a ten-times speed-up in writing code this year. Almost nobody shipped ten times as much.
That gap is the most interesting fact in engineering right now, and most teams are looking straight past it. They point another agent at the problem, generate more branches, open more pull requests, and wonder why the release calendar looks the same as last year.
The code was never the constraint. It just looked like it was.
The queue moved
Picture the old pipeline. One engineer picks up one task, writes the change, runs it locally, pushes it to staging, waits for review, waits for CI, and ships. Every stage was sized for that cadence: one person, one thing, one branch at a time. Staging was a single shared environment because a team only needed one. Review was a human reading a human-sized diff.
Now put fifty engineers on that pipeline, each running three agents. The front of the line produces work at a rate the back of the line was never built to absorb. Changes pile up at review. They pile up at the one staging environment everyone fights over. They pile up waiting for someone to answer the only question that matters: does this actually work?
So you bought ten-times development speed and got maybe two-times throughput, because the bottleneck was never coding. It was validation. Review, staging, verification (the work of deciding a change is safe) is now the wall every change hits, and it did not get faster when the writing did.
Deterministic gates raise the floor, not the ceiling
The first instinct is to automate the gate. Add a linter. Add a formatter. Add a schema check that rejects anything malformed before a human ever sees it. Do this; it is genuinely worth doing.
I run exactly this discipline on my own work. Before a specification reaches a reviewer, a deterministic pre-check runs over it: structure, references, format, the mechanical things a machine can settle without an argument. When it passes, nobody debates whitespace or a missing field. The floor is raised. The noise is gone.
But here is what I learned watching it run. A batch of specifications can pass the mechanical gate cleanly, every one of them, and still fail review completely. Every one. Because the defects that matter are not mechanical. They are a reference to a symbol that was renamed. A design that reads a value from a place the value does not exist. A database column added with no migration to create it. A test placed in a directory the test runner never looks at.
A deterministic check cannot see any of that. It can confirm the shape is right. It cannot confirm the thing is correct. The floor came up; the ceiling did not move an inch. Teams that bolt on a linter and expect quality to follow are measuring the wrong thing, and the wall is still there, one layer back.
Correctness is a question about running behaviour
The reason the mechanical gate cannot reach the ceiling is that correctness is not a property of the text. It is a property of the running system.
You cannot read a diff and know an API still enforces the authorisation rule it enforced yesterday. You cannot read it and know the rate limit still holds, that the error path still returns what callers depend on, that a workflow spanning five operations still completes. Those are claims about behaviour, and behaviour only answers when you exercise it against the live service.
That is also why "the agent says it's done" is not an answer. An agent is a confident narrator of its own work. So is a junior engineer. The question is not whether the author believes the change is correct. The question is whether anything independent has watched the system do the thing and recorded what happened.
Engineering decisions
A short interactive run through real engineering decisions; the first one asks how you actually know an agent's change works.
Engineering decisions
A short interactive run through real engineering decisions; the first one asks how you actually know an agent's change works.
A short interactive run through real engineering decisions; the first one asks how you actually know an agent's change works.
Interactive figure: Engineering decisions. A short interactive run through real engineering decisions; the first one asks how you actually know an agent's change works.
The simulator opens on the question the whole wall comes down to: an agent changed the code. How do you know it works?
Fig. 1Engineering decisions. The simulator opens on the question the whole wall comes down to: an agent changed the code. How do you know it works? Open the full exhibit
What actually scales
If the bottleneck is validation, then the fix has the shape of the bottleneck. It has to be independent, so it does not inherit the author's confidence. It has to be parallel, so fifty engineers and their agents are not queued behind one shared environment. And it has to rest on evidence of running behaviour, not on a reading of the source.
Independent, because a verdict from the same mind that wrote the change is not a check, it is a second opinion from the first opinion. Parallel, because the whole point of agent-written software is that work arrives concurrently, and a serial gate turns concurrency back into a line. Evidence-based, because the only durable answer to "does it work" is a record of the system working, captured when the test ran, reproducible when someone doubts it.
This is the reason I built Dino. Not as a QA tool for a human running a scan on a Friday, but as the verification layer for teams where most of the code is written by agents. It discovers the API, tests the running service across input validation, authorisation, rate limiting, error handling and the rest, and returns a verdict backed by what it actually observed. Each run stands on its own, so they fan out as wide as the work does. And teams set the gate that failing changes cannot pass, a real bar, not a format check.
The wall is where the next advantage is
Everyone can generate code now. That is settled, and it is no longer where anyone wins.
The teams that pull ahead will be the ones who made validation as cheap and as parallel as generation became. The ones who can look at a hundred agent-written changes and know, with evidence, which ones are safe, without a human reading every line and without one staging environment holding the whole company hostage.
The agents will keep getting faster at writing. The question is whether you can keep up at knowing it works.
Decision 01
How do you know an agent's change actually works?
A coding agent has changed an API endpoint. Before it merges, someone has to be confident the running service still behaves.
Agent changes code→
Same agent writes tests→
Tests pass→
Merge
Confidence earned
Low
Independence from the author
None
Speed to a decision
Fast
Why this choice?
Fast, but the tests share the author's assumptions. If the agent misunderstood the requirement, its tests encode the same misunderstanding and pass.
What was actually built
This is the problem Dino exists to solve: independent, deterministic verification of running APIs, with a sealed verdict a pipeline can gate on.