The Sixty Per Cent

If you have ever worked in certified software development, for aircraft, for defence, for cars, for medical devices, you will know a fact that surprises everyone outside it. Writing the software is about 40 per cent of the programme. The other 60 per cent is proving that the software does what it is supposed to do and nothing else, to the satisfaction of a regulator, in a form the regulator can audit. At CoreAVI, the company I founded in 2005 to build graphics and compute software for avionics, the development side was hard enough on its own. High-performance, high-reliability drivers for graphics processors are structurally complex, and unlike the processors that run ordinary software, much of the inner working of a graphics chip is kept secret by its manufacturer to protect a competitive advantage, so the people writing the driver were often reasoning about a machine they were not allowed to see. That was the 40 per cent. The 60 per cent was worse, and it is the subject of this essay.

Certification is a people process. It consists of documenting requirements, linking them to the code that implements them and to the tests that exercise them, and assembling the whole into evidence that the system does what it was intended to do. The evidence takes the form of artefacts, thousands of them on even a modest programme, and I have been both the programme manager and the owner of the company, so I know the black hole that this process becomes. The number of artefacts a project will require is not known at the start, not exactly and not even approximately, and there are stages in every programme where the estimate of what remains grows faster than the artefacts are being completed. You are digging, and the hole is getting deeper.

It became obvious to me, some years before it was fashionable, that if we could use AI to produce those artefacts faster than people could, we would have a significant advantage over every competitor still doing it by hand. I was right, and I was wrong, and the way in which I was wrong took me longer to understand than I like to admit.

The Unit of Work

The standard that governs airborne software is called DO-178C, and the artefact at the centre of it is the low-level requirement, which the industry abbreviates to LLR. A low-level requirement is a single, precise statement of what one piece of code shall do: when the board initialisation function is executing, the software shall configure the clock, the interrupt priorities, the USB source and so on, each clause traceable to a line of code below it and to a higher-level requirement above it. A simple system needs thousands of them. They can account for up to 40 per cent of the artefacts a programme produces, and producing them is laborious, formulaic in places and expert in others. At CoreAVI the authoring of low-level requirements represented about 13 per cent of the company’s cost base, which is a remarkable figure for a single administrative step, and it was the obvious place to start.

What is less obvious, and what I did not weigh properly at the time, is that writing the requirement sentence is the first of eight steps, not the whole job. After the sentence is written it has to be classified under the grammar the standard expects, assigned a verification method, given its design assurance level, scoped to the modules it governs, attached to the documentation that describes its intent, traced in both directions to the code and the requirements around it, and each of those links has to be justified so that a reviewer can see why it exists. The sentence is the visible part. The other seven steps are where the effort lives and where audit findings cluster, because in every certification shop I have known they are done by hand, by engineers and reviewers, and they go stale the moment the code changes.

Where I Was Right

The first phase was easy, and the dashboards were beautiful. With prompt engineering, then fine-tuning, then a good deal of careful integration, we brought the time to author a low-level requirement down from about three-quarters of an hour of engineering time to about a quarter of an hour. That is a two-thirds reduction in the time of the step, and the team was using it in production, not in a pilot. The pilot had translated. For a while I believed we were on the way to taking that 13 per cent of the cost base to under three.

The cost of the step fell by about a quarter, and then it stopped falling. We tried larger context windows. We tried better prompts. We tried further fine-tuning, and the model got better by every measure we could apply to the model, and the plateau did not move. The general shape of that plateau, and why Eliyahu Goldratt would have recognised it at once, is the subject of AI Interviews Well. What belongs here is the more specific reason, the one particular to certification, because it is the reason I was wrong.

Where I Was Wrong

The number that did not move was the audit failure rate. Before the AI, something under 15 per cent of our low-level requirements came back from review with a finding: a link that could not be justified, a clause that did not match the code, a requirement that had drifted from the function it described. After the AI, the figure was the same. The requirements arrived three times faster and they failed review at the same rate, which meant that every one of them still needed the same human review it had always needed, and the reviewers were now receiving three times as many. The bottleneck had not been removed. It had been moved one desk to the right, and the desk it moved to was staffed by the most senior and most expensive people in the company.

The reason is that a certification artefact is not a document. It is a piece of evidence, and evidence has properties that a plausible document does not. The regulator’s delegate, the designated engineering representative who signs on the regulator’s behalf, is not asking whether the requirement reads well. She is asking three questions of every artefact: is it coherent, is it current, and is it connected to the artefacts above and below it, and she is asking a fourth of the process that produced it, which is whether the reasoning behind it can be shown. A frontier model produced requirements that read very well. The reasoning that connected them to the code was still in the head of the engineer, and the model’s audit trail was a set of engineering notes, which is what it had been before. We had automated the sentence and left the evidence exactly where it was.

There was a second problem, smaller in appearance and larger in consequence. If you give a frontier model a function and ask for its low-level requirements, it will oblige, and if you give it the same function again it will oblige differently: a different number of requirements, a different decomposition, sometimes a better one and sometimes a worse one. I have described this in The Employee You Have to Check, and the point for the certification case is what it does to the people process. An organisation that must decide, for every output, whether this particular version is the acceptable one, builds a review layer to decide it, and the review layer grows with the volume. The more autonomy we gave the model, and the more precision the certification environment demanded, the larger the containment infrastructure around the model became: validation stages, reconciliation checks, sign-offs, exception handling. The AI had accelerated the generation of outputs. The company still carried the whole burden of deciding whether the outputs could be trusted, and that burden is the 60 per cent.

Underneath both problems is a piece of mathematics I did not have at the time and have spent the years since helping to work out. A single-objective optimiser, which is what every frontier model is, produces its likeliest answer and cannot know when that answer is wrong, because the information that would tell it was discarded in the act of compressing everything to one number. I have set the idea out in The Three Faces of Information and will not rehearse it here. What it means for certification is precise. A certification programme is a chain of thousands of sequenced decisions, each of which must be right, and the acceptable error rate is not small, it is zero, because a single unjustified link is a finding and a pattern of findings is a failed audit. Ken Wenger and I later measured how a task’s demands for precision and horizon push the best available models towards failure, and the finding, which I hold as an experimental result rather than a theorem, is that at the precision and the horizon certification requires, the models we were using at CoreAVI could not have done the whole job however well we prompted them. The plateau was not a failure of effort. It was a property of the instrument.

What the Industry Is Seeing

I thought for some years that this was a story about certification. It has since become clear that certification was simply the place where a general pattern showed itself early, because certification is unforgiving in a way that most work is not.

The pattern is now visible across the industry, and it has a shape. Give a capable person a frontier model and the gains are large and immediate: the figures circulating in the trade, which I take as indicative rather than measured, put them at 40 to 60 per cent on the individual’s own output. Give the same tool to a team and the gains shrink to 20 or 30 per cent, because the team’s output is not the sum of its members’ output but the product of their handoffs, and the handoffs have not changed. Embed it in a process and the 20 or 30 per cent becomes harder to sustain, because the process has reviewers and gates and queues that absorb the speed. Deploy it across a company and the return becomes, in the word the industry has settled on, variable, which is a polite way of saying that nobody can find it: unsanctioned tools in every department, tool sprawl, disconnected systems, no shared platform, and metrics that measure the individual’s productivity while the company’s throughput stays where it was. The larger studies say the same thing more bluntly. The MIT survey of enterprise deployments in 2025 found that 95 per cent of generative AI pilots had produced no measurable effect on profit and loss, and Gartner expected a large fraction of agentic projects to be cancelled within two years. Meanwhile the projected spend on AI infrastructure runs to trillions of dollars by the end of the decade, all of it premised on the assumption that the gains at the top of the staircase will be found at the bottom.

That staircase is a precise description of what happened at CoreAVI. The individual engineer got the two-thirds reduction in the time of the step, the top of the staircase. The team got a quarter off the cost. The process got nothing, because the process is where the audit lives, and the audit did not care how fast the sentence had been written. A model that is a superb personal productivity tool is being sold, and bought, as an enterprise tool, and the two are not the same class of thing. A personal tool is judged by the person using it, who can see when it is wrong and correct it in the moment. An enterprise tool is judged by people who never see the output being made, against a standard the tool does not know it is being held to, over a horizon of thousands of steps. Certification is an enterprise task by definition. The artefact is not accepted by the engineer who wrote it; it is accepted by an auditor, on behalf of a regulator, as part of a programme, and it is the company that signs. Any gain that lives only at the desk of the person prompting the model is invisible at the level where certification is decided, which is why the industry’s staircase and my plateau are the same object seen from two distances.

The Reversal

The lesson did not arrive in time to be useful at CoreAVI. It arrived at Squint Cognition, the company I went on to found with Ken, where we came back to the same problem and reversed the order of operations.

At CoreAVI we had started with the language model and asked it to write requirements, then built process around its output. At Squint we started with the code and built the ground truth first. Before a single requirement is written, the platform ingests the whole source tree and constructs what we call a concept model: the call graph, the module hierarchy, which functions govern which behaviours, which documents describe which features, and the grammar and rules of the standard the programme is being certified against. From that structure the requirements are derived mechanically. The decomposition of a function into its requirements is the same every time because it follows from the shape of the code, not from a sample drawn by an optimiser. The language model is used for one thing only, which is to write the human-readable sentence, and the sentence is emitted alongside a deterministic rewrite that names the exact calls it describes, so that it cannot drift from the source without the link breaking.

The other seven steps, the ones we had left to people, are done by construction. Classification, verification method, assurance level, module scope, documentation and the bidirectional trace fall out of the concept model on every run, and the run is repeated on every commit, so the evidence is always a function of the current code rather than a snapshot somebody curated before the auditor’s visit. The step that had no manual equivalent at all is the one that changed the auditor’s job. Every trace link carries a confidence score assembled from three independent methods, one structural, one lexical, one semantic, and the three are recorded separately so that a reviewer can see why the number is what it is. Anything below a threshold is flagged for a person. The delegate’s review moves from a uniform sample of everything to a risk-weighted inspection of the links the system itself is least sure of, which is the first time in my career that an AI has told a certification engineer where to look rather than asking her to look everywhere.

The objection any certification engineer will raise at this point is the right one, and I would rather meet it than have it raised for me. A requirement derived mechanically from the code is a description of what the code does. It cannot catch the code being wrong, because it has no independent idea of what the code was for, and the standard’s whole purpose is to establish that the software does what was intended, not that it does what it does. That is true, and it is why the derivation is only half of the evidence. The other half is the trace upward. Every low-level requirement the platform derives has to find a high-level requirement to stand under, and every high-level requirement has to find low-level requirements beneath it, and it is at that join that a wrong implementation surfaces: a function that does something no requirement asked for, or a requirement with nothing below it that implements it, is a finding, and the platform raises it rather than papering over it. The derivation makes the evidence of what was built honest and complete. The trace to intent, and the tests against it, are what make it evidence that the right thing was built, and neither of those is manufactured from the code. I should also grade the case. The standard expects low-level requirements to be written before the code on a green-field programme, and the platform’s strongest ground so far is the far larger world of existing software being certified, re-certified or brought under a newer standard, where the code exists and the evidence does not.

To grade what I am claiming: that a deterministic derivation is repeatable is not in doubt; it is what deterministic means. That it produces requirements a regulator will accept is an empirical matter, and the evidence so far is this. With two European customers, on real programmes, and by the customers’ own count, the platform produced 2,000 low-level requirements in hours rather than months, with fewer than 20 audit findings between them, a failure rate under two and a half per cent against the 15 we had lived with. As a harder test we pointed it at an open-source USB stack with no design documents at all, only the public repository, and in under a week, by our own count, it produced 506 high-level and 17,895 low-level requirements traced to 2,027 functions at line level, with a design description for 478 modules. Customers rated the traceability and the evidence above what their current methods produce. That is a small number of programmes and I would not yet call it a law. It is enough to say that the cost reduction CoreAVI chased for years, and got a quarter of, arrived only when the last of the eight steps was inside the system and the evidence was produced by the same mechanism that produced the sentence.

One more thing should be said, because it is unflattering to the incumbent and true. Squint could do this partly because it was new. There were no teams built around the eight steps, no reviewers whose job was step five, no process for the AI to be inserted into and absorbed by. We could design the flow as a flow. A company with a mature certification department cannot easily do that, and the resistance it meets will not be technical.

What the Sixty Per Cent Is For

It would be easy to end on cost, and the cost matters; certification at 20 or 30 per cent of the engineering hours it used to take changes what can be built and who can afford to build it. The point I care more about is what the 60 per cent was always for. Those artefacts exist so that a human being can sign her name under the claim that this software will not bring down an aircraft, and can show anyone who asks why she believed it. An AI that made the artefacts faster and left the reasoning in an engineer’s head did nothing for her. An AI that produces the reasoning with the artefact, records how sure it is, and points her at the places it is least sure, does something for her that no previous tool has done, and the systems it certifies are safer for it, not merely cheaper.

That is the shape of my mistake. I was right that the artefacts could be produced faster than people could produce them. I was wrong about what was being produced. Certification does not run on documents. It runs on evidence, and until the machine could make evidence, its speed at making documents was worth about a quarter of what I had promised.