Your Tests Passed. Nobody Looked at the Chain.

The bike had come out of the service the day before we left. A long trip ahead of us, most of a continent. Every box on the service log was ticked. Some highway, then around Salzburg we turned south into the Alps. Twisty roads, the kind where these machines stop being transport and start being the reason you own one.

At the first pass we pulled in. Forty degrees, no wind, everyone heading for shade and something cold. Everyone except one of us. He was knee down beside his bike in the full sun, which in our world is a phrase that is supposed to mean something else entirely.

His voice was tense when we asked. The chain had felt loose to him somewhere in the last few kilometres. We measured it. The tolerance was wider than it should have been. So we tensioned it there at the checkpoint, put the laser on it, brought the alignment true. And while we were down there, hands already dirty, we saw the chain slider had gone old and hard. Test ride. The bike seemed sweet again.

The next morning we were on new passes, Austria behind us, Italy opening in front. Somewhere in a fast mixed section the intercom filled with this:

”@#$%&!! … @#$%&@#$&!! … &%$#@!!”

We have a name for that transmission. The brown map call. Anybody who rides knows what the map is drawn with. It was the same rider, the one who had been on his knees in the sun the day before. He had felt a hole in the power delivery, mid corner, and the bike had started shaking under him the way a house shakes in an earthquake.

We stopped and looked at the chain. The chain slider was gone. The guy was pale as a ghost and speechless. The new chain slider had been sitting in the workshop the whole time. Five minutes of work. But the bike had left with the old one, and every box on the service log was ticked. Nobody at that service was careless. The checklist was complete, but the checklist was not the machine. The only thing that read the true condition of that bike was the pale rider who felt something wrong and said so out loud. Twice, and both times before it cost anybody anything.

I have sat with CXOs describing a quarter that looked exactly like that afternoon. The pipeline green, the board pack green, and the incidents arriving from somewhere the green does not cover. If that sounds familiar, you already know the green is not the machine, and that is why it leaves you uneasy rather than relieved. Half of this job got cheap this year, for everyone, and nobody sent a note explaining that the other half did not.

Quality and security are not features of an AI-native organisation. They are what its speed rests on. Today we open two of the six axes: the one where we score 80, and the one where we score 25.

Twelve months, two curves

The parts of a system nobody sees are the ones that decide whether it survives contact with the real world, and that is where we put the last year and more: the security side of the Software Factory, static and dynamic Cyber Security analysis, DevSecOps, whose whole job is to look hard at what the agents produce.

That work needs a baseline. You cannot tell whether your own numbers are any good until you have set them beside somebody else’s, so we went looking for what the field actually knows about the security of AI-written code.

We started where the research started, in 2025.

ETH Zurich went first. BaxBench: Can LLMs Generate Correct and Secure Backends? They do it with working exploits written by hand rather than a scanner. “On average, we could successfully execute security exploits on around half of the correct programs generated by each LLM.” Then, the same year, SecRepoBench: Benchmarking LLMs for Secure Code Generation in Real-World Repositories, the one that should reach your architecture review. It measured Claude 3.7 Sonnet Thinking, a frontier model of that moment. On self-contained tasks it scores 58%. Put it inside a real repository, with the surrounding code and the existing conventions, and it scores 28%.

A year later, Veracode. They built 80 coding tasks designed to invite four common weakness classes, a benchmark that has now been run against more than 100 models over four years. Their 2026 GenAI Code Security Report: AI Is Writing More of Your Code but Security Hasn’t Caught Up, published at the end of July, found the models produced secure code 56% of the time. A year earlier the same benchmark returned 55%. And note what that number is not: those tasks were built to be dangerous, so it is a pass rate on a hostile benchmark, not a reading of your codebase.

Now hold the two dates side by side. In 2025 the model the research pointed at was Claude 3.7 Sonnet. Set it beside whatever you are running this morning and the distance is not subtle: it reasons for longer, it holds far more of your codebase at once, it writes in one pass what used to take three. Every curve in this industry went almost vertical.

But, Cyber Security moved only one point.

And security is now the axis on which access itself gets decided. In June, Claude Fable 5 and Mythos 5 were suspended under a US government directive over what they could do inside a codebase. By Anthropic’s own account, the jailbreak that was shared with the government amounted to “asking the model to read a specific codebase and fix any software flaws”. Whatever you conclude about that decision, notice what it establishes: a model’s security profile can remove it from your supply chain overnight, and nobody will consult you first.

So security now sits on both sides of the ledger. It decides which models you are allowed to build on, and it is the one property of their output that has not improved in twelve months. That is the gap we are continuously improving nWave SW Factory against. The security work there is not a module we bolted on because it was fashionable. It is the axis we could feel ourselves scoring worst on long before a benchmark agreed, and the one the market has just demonstrated is load-bearing.

The ground it is landing on

None of this arrives on clean ground.

The latest Verizon Data Breach Investigations Report has moved the exploitation of software vulnerabilities to the top of the list of ways attackers get in, at 31% of initial access vectors, ahead of stolen credentials. The way in is no longer the borrowed password. It is the flaw you shipped.

Separately, and about software in general rather than the AI-written kind, Veracode’s 2026 State of Software Security found security debt in 82% of organisations, critical security debt in 60%, and high-risk vulnerabilities up 36% year over year. Read those together, and the picture is not simply that more code is being written. It is that more vulnerable code is arriving into estates already carrying more unresolved risk than they were clearing.

That is the quiet part of this. Speed is what everyone bought, so speed is what everyone watches; the defect count arrives later, when the tickets pile up and the NPS starts to fall. Security debt does not appear on any dashboard until the day it introduces itself with a major incident in the news or a case in front of a judge.

The bottleneck moved, and the dashboard did not

As we saw in the previous articles looking at the code quality, Faros AI’s telemetry across 22,000 developers found pull requests merged with no review at all rose 31.3%. Median time to first review rose 156.6%. Incidents per pull request merged rose 242.7%. Code churn rose 861%, and bugs per developer rose 54% against 9% in their 2025 report.

Now the part that should stop a CXO mid-sentence. A team at Nicolaus Copernicus University examined 33,596 AI-authored pull requests. The result: AI-generated pull requests are frequently unreviewed and, when reviewed, are predominantly evaluated by agents or through mixed human and agent configurations. And here is the part that hides it: human participation on those pull requests looks almost identical to human participation on human ones, 30.1% against 30.8%. The headline metric did not move. That is why nobody caught it. Your people did not stop reviewing. What they were doing changed, and the dashboard went on calling it the same thing.

That is the chain tolerance: inside spec on the service log, slacking in the hand of an experienced driver, and the only reason anyone knew was the rider who could feel it after using it.

Green is not the same as read

Last week I promised you the check that catches what your tests miss. We designed it into nWave on engineering grounds, and rather than ask you to take our word for that, the evidence below is somebody else’s. Meta deployed this Mutation-Guided LLM-based Test Generation on its own code, across 10,795 Android Kotlin classes in seven of their platforms. A mutation-guided system generated tests; Meta’s engineers reviewed those tests in two internal test-a-thons and accepted 73% of them. Then the finding, in their words: “Approximately half of all tests generated, although finding faults missed by all existing tests, do not add line coverage.”

277 of 571 tests would have been discarded by a coverage gate. Every one caught something no existing test caught.

Mutation testing alters your code on purpose, one small change at a time, then asks whether any test notices. A test that never notices is not a test. It is a receipt. Coverage tells you a line ran. Mutation testing tells you whether anything would have noticed if that line were wrong. And the honest limit, because your best engineer will raise it within a day: across 357 real Java faults, 17% coupled to no mutant at all [*10]. Mutation is the next increment after coverage, not a replacement for it. And indeed, it is why we have been running mutation testing since long before it went popular, to test what we call ‘AI test theater’. A core practice of our nWave SW Factory, to ensure code is testing behaviour and not implementation.

Why we ship that check switched off

Now the part that sounds like a contradiction. In the nWave open source line, mutation testing is off by default. We wrote it, we stand behind it, and it does not run unless you turn it on.

Google, in an old research paper from 2021, explains the reason better than we can. Six years across their monorepo: the naive approach produces a median of 820 mutants per change, their deployed system generates 7, and when they began developers rated 85% of the mutants they saw as unproductive. A check that cries wolf gets switched off by the team. And a check the team has switched off is worse than one never installed, because everyone still believes it is running. So we ship it off, and it comes on when the workflow around it can carry the weight.

This is why in the SW Factory that switch is infrastructural. The industry ships defaults that flatter the demo. We ship defaults that hold on a Monday morning. And it is why we would never have left the new chain slider in the workshop. Five minutes of work. The part existed, the knowledge existed, and the bike went out without it, completely unnoticed.

Eighty, and twenty-five

The service log that came back with that bike was a compliance document. Complete, signed, defensible. The condition of the chain slider was a security question, and nobody had asked it, because it was not on the log.

Last week we published the scoreboard: six axes of software delivery, 100 points each, and three lines drawn across them. A vanilla model reaches 125 points of the 600. A generic harness reaches 200. The Factory fills all six. Episode 102 walks through how each axis is scored. This week we open two of them.

The scoreboard: a radar chart on six axes, Speed, Quality, UX, Cyber Security, Infrastructure and Token Economy, 100 points each. The Helm, the nWave Software Factory, fills all six for 600. A generic harness reaches 200. A vanilla model reaches 125.

The open source line does not reach those outer edges, and that is not an oversight. It is free, it is real, and it carries the limits a free thing carries: partial scores on axes it was never built to fill. The Software Factory was designed to take all six to the top, which is the whole reason it exists. Here are the two we open this week.

Quality: 80 in the open source line. 100 in the Software Factory.

Cyber Security: 25 in the open source line. 100 in the Software Factory.

25 is not a typo. It is the lowest score on that board and the widest gap on it, and I am not going to close it for you here, because what closes it is not in the open source line. It is also why we spent this summer reading security research instead of sunbathing with a mojito. What we can give you costs nothing.

Start with your agentic AI inventory. A Cloud Security Alliance survey of 418 IT and security professionals found that 82% of enterprises have unknown AI agents running in their environments. You cannot govern what you have never counted, and no vendor is required for that step.

Stephan Johansen, a friend and Cyber Security expert who does this for a living, put it in three lines:

“Compliance gives you the right to sell your products and build trust with customers. Security gives you the ability to sleep at night and done right increases your ability to innovate. The CEO needs both.”

No audit ever gave anyone a quiet night. A green report is a photograph of one moment, taken by somebody looking at the things on the list. Security is the one property you never get to confirm: you learn its real value in the moment something arrives to tell you. That worn chain slider held at touring pace. At racing pace it ends the story somewhere else entirely.

You are not behind. The cheap half of this work got cheap for everyone at once. The other half is where the next years get decided.

The AI tools work, the throughput is real, and the gap that opened this year is not a gap in anybody’s judgment. We have walked this mile with organisations who had every box ticked and an incident rate that disagreed with all of them.

Before anything else, take the reading. The AI Readiness self-check is free, about five minutes, no email gate, four dimensions of your own: focus and cognitive capacity, engineering discipline, product and backlog clarity, customer feedback and learning speed. It will tell you whether your capacity to examine has kept pace with your capacity to produce, and you will know it before anyone tries to sell you anything, including me.

When you want the machine and the people ready to run it arriving together, that is what The Helm is for. Your timeline. Your choice.

→ ai-readiness.dev Four dimensions, about five minutes, no email gate.

Next week: the two axes everybody actually bought AI for. Speed, and knowing what to build. One of them is why your board approved the budget. The other is why speed sometimes costs more than it saves.

Sources

Every number in this piece traces to one of these. They open in a new tab, so the article stays where you left it.