Everything in this explainer can be written down: the loops, the rules, the gates, the skills. Most of it already is, in files an agent reads. But the files are not what made the difference. The people who wrote them did.
Everyone has the same models and the same tools. Some engineers say agents are useless; others say they have changed everything. Both are usually reporting honestly what happened to them.
The difference is the operator. The same model, given a vague prompt in an unprepared codebase, produces plausible rubbish. Given a hard correctness signal, a structure that makes the right change obvious and an operator who reads the failures, it climbs. Same model, opposite results; the model is the same for everyone, your judgement isn’t.
“It doesn’t work” and “it changed everything” are both true reports.
They describe the operator and the codebase as much as the model. That is good news: models are bought, but operator skill can be learned.
Across the case studies, the engineers who got there had three things in common. None of them is a tool.
Engineer B built a whole product from a plan in five weeks, just to see what would happen. Engineer A pointed the spare capacity at questions nobody could afford to ask before: profile every workload, then research the process itself. (Three shapes, the Cambrian explosion.)
Changing how you work means letting go of the craft you were proud of. Openness also points outward: Engineer A taught the approach to an intern and a QA team, and c8ctl took contributions from 26 people. (c8ctl.)
Each of them built structure around the agents: a fence, a gate, a loop, a registry that makes incomplete commands impossible. They fixed the class, not the instance. (Rules that enforce themselves, The bottleneck moved.)
Engineers B and C were not taught this. We found them when we went looking for people to spread it to, and they were already there, by different paths. What they shared was not prior experience with agents; nobody had much. It was the willingness to try, to look at the results honestly, and to change the system when it failed.
The experience came afterwards, from doing it. That means you can’t hire for this experience yet, and you don’t need to. Look for the attitude, give it a garden to start in, and the skill follows.
Velocity: 20× the commits a month for the same engineer, one repository becoming 21, a product in five weeks. Innovation: seven language SDKs from one spec, a performance matrix nobody had time to build, a research garden, a template migration engine in c8ctl.
Stability is the surprising one. Going fast with agents breaks things quickly, so you can’t ignore the cracks. You build the structure that stops them: derived code, self-enforcing rules, no flaky tests, a merge gate only green changes pass. In c8ctl, a whole class of bug stopped appearing once the registry made it impossible to write. Done right, the speed pays for the stability, and the stability makes the speed safe.
We think this moment is as significant as the arrival of the internet, or of computers themselves. Moments like that are disruptive: the way software gets made is changing under everyone at once.
Teams that disrupt themselves, that change how they work before they have to, will build the businesses that disrupt their industry. At the very least, they won’t be the ones disrupted by a competitor who did. Waiting for the tools to settle doesn’t avoid the change. It only means someone else learns it first.
The tools are the same for everyone. What differs is the operator: curious enough to try, open enough to change, and thinking in systems rather than outputs. Start with that attitude, and the experience follows. Done right, you get more speed, more new things, and, perhaps surprisingly, more stability. In a moment this disruptive, the teams that disrupt themselves are the ones that won’t be disrupted.