0.1 The curve

Software has always been constrained by how fast people can write it. That constraint is dissolving on a measurable curve.

METR, which tracks what frontier AI agents can actually complete, reports that the length of a coding task an agent finishes reliably has been doubling roughly every four months. Today the leading model completes tasks that take a person a working day. If the curve holds even loosely, agents will carry week-long engineering tasks before this document is a year old. At the same time, industry surveys already put AI-generated code at around 42 percent of everything committed, and rising.

Every prediction about AI deserves suspicion, including this one. The same research community measured experienced engineers working 19 percent slower with AI assistance while believing they were faster. The curve is real and so is the self-deception it produces. A standard that only works if the optimists are right is not a standard. This one assumes both: agents that grow more capable every quarter, and humans who consistently overestimate how well they supervise them.

What follows from the curve is simple and uncomfortable. The marginal cost of producing code is collapsing toward zero. The cost of knowing whether that code is right is not.

0.2 The inversion

For seventy years, since the first commercial compilers, the scarce resource in software was production. Teams were sized, processes designed, and careers built around the difficulty of writing correct code. Testing, review, and release management existed to protect a slow, expensive stream of human-authored changes.

That world inverted. When an agent produces in an afternoon what a team used to ship in a sprint, production is no longer the bottleneck. Verification is. The review queue, not the backlog, is where delivery now stalls. DORA's research says it plainly: the return on AI investment runs through code review and the strength of the engineering system around the tools, not through the tools themselves. AI amplifies the system it lands in. Strong systems compound their strengths. Weak systems compound their defects, faster than any human can read the diffs.

There is a second inversion hiding inside the first, and Google's engineers wrote it down years before agents arrived: software engineering is programming integrated over time. A line of code is written once and then read, changed, and depended on for a decade. Its true cost was never the writing; it is the living with. Agents collapse the cost of writing and leave the cost of living with untouched, so every shortcut taken at generation time is a loan taken out against the maintainers. And Hyrum's Law tightens as volume grows: with enough consumers, every observable behavior of a system will be depended on by somebody, and agents produce observable behaviors faster than any team can document them. Cheap code is easy to over-produce. A quality system for the agent era therefore optimizes for the whole life of the code, not the moment of its creation: the question at every merge is not only "is this right today" but "can we still change this safely in five years, at a cost the business can carry."

The profession inverts with it. The engineer's craft is moving from writing code to proving code: specifying what must be true, deciding what evidence would demonstrate it, and refusing to accept work, from a person or an agent, that arrives without that evidence. The developers who thrive in the next decade will not be the ones who type fastest alongside a model. They will be the ones a business trusts to say, with evidence, that the system works, and keeps working as it changes.

This is not a diminished role. It is the senior role. Machines produce. Professionals attest.

0.3 What quality means now

A green pipeline is a claim, not a fact. The tests passed. Passed at what? If the agent that wrote the change also adjusted the test, green means the change agrees with itself. Quality has to mean something stronger than agreement.

The Certance Standard defines it in one sentence: quality is the evidence you can hand to someone else. A colleague who must maintain the code. A customer whose money it moves. A supervisor who asks, months later, what you knew and when. If the evidence would not survive that handover, the quality is an opinion.

Three properties make evidence hold.

Provenance. You can say what produced every change: which person, which agent, which model, with what access. In April 2026 an autonomous coding agent at a small SaaS company hit a credential mismatch, found an over-privileged token in an unrelated file, and deleted the production database and every backup in nine seconds. Nothing malfunctioned. The agent solved its problem with the permissions it had. Provenance and least privilege are not compliance decoration; they are the difference between an incident and an extinction event.

Behavior. The change is demonstrated against what the business needs to be true, not against its own implementation. A portfolio screen can render perfectly, every test green, and still show the wrong balance. Tests that assert real outcomes on the journeys that move money, expose data, or inform decisions are evidence. Tests that assert that the code does what the code does are tautology at scale.

Durability. The evidence still exists when the question arrives. Regulators enforcing operational resilience no longer ask whether you test. They ask you to show it, for systems that mattered, at a date in the past. CI logs that expire in ninety days are not an answer.

None of this slows a team down. It is what allows a team to go fast without lying to itself. The gates in this standard are how a team accepts a torrent of machine-written change and still knows, at every merge, what it knows.

0.4 Why this standard, why now

The incidents are no longer hypothetical, and the pattern behind them is always the same: every stage of the pipeline assumed the stage before it had checked. The agent produced a change wider than the request. The tests moved with the change. The review read clean. Production found the gap.

Meanwhile the supervisory question has already changed. In its first year of DORA enforcement, EU financial entities reported 3,383 major ICT incidents, and system failures, not attacks, were the largest cause. The regulator's follow-up is never whether your pipeline was green. It is whether you can prove the system that failed was tested for the thing that broke.

Most teams are answering a 2027 question with a 2020 quality system. This standard exists to close that gap: written for teams where agents write most of the code, tested against the failure modes those agents actually produce, and framed so the same discipline that keeps engineering honest doubles as the evidence a risk function can act on.

It will age. The models named here will be obsolete in a year; the curve guarantees it. The principles are capability-invariant by design: they bind tighter, not looser, as agents grow stronger, because every one of them is a statement about evidence, and evidence does not go out of fashion.

Sources

METR, Time Horizon 1.1 (metr.org) and the 2025 randomized trial on AI-assisted developers; Google DORA, State of AI-assisted Software Development; Sonar, State of Code 2026; the ESAs' first annual report on major ICT incidents under DORA (June 2026); public reporting on the April 2026 agent incident (The Register); Winters, Manshreck and Wright, Software Engineering at Google (O'Reilly). Figures re-verified August 2026. The full annotated source list ships with the First Edition.