Last week I argued that cybersecurity may be solving the wrong problem i.e. that instead of chasing perfect prevention, we should change the conditions around the problem: build for resilience, make compromise matter less, design security in from the start. I leaned on the car to make the point. We never stopped crashes; we made them survivable, with seatbelts, crumple zones, airbags and the laws that forced them.
There’s a darker chapter in that same car story. And it’s the one on my mind now that AI is rewriting how software actually gets built.
I sat down recently with John Krewson, CEO of Sketch Development and author of Pitch Sketch Launch, just as Anthropic pulled the covers off Project Glasswing, a frontier model, Mythos Preview, so capable at finding software flaws that the company decided not to release it publicly, handing it instead to a small circle of trusted partners for defensive work.
The model can outperform all but the most skilled humans at finding and exploiting vulnerabilities. It has already surfaced thousands of high-severity flaws across every major operating system and browser, many of them one or two decades old. In the weeks since John and I spoke, the programme has widened to around two hundred organisations, and partners have reported more than ten thousand high- and critical-severity flaws.
A machine that finds vulnerabilities faster than almost any human alive. Gold in the right hands. Catastrophic in the wrong ones. If you wanted a single, dramatic signal that the speed-and-power era has arrived, this is it.
Which brings me to the brakes.
The Anti-Lock Brake Problem
Here’s the thing most people miss about brakes. We think of them as the part that stops the car, but ask any racing driver and they’ll tell you the opposite. Brakes are what let you go fast. The better you can stop, the harder you can push everywhere else. Brakes aren’t a constraint on speed; they’re the enabler of it.
What far fewer people appreciate is the second half of that truth – the behavioural half. The moment a safety system makes us feel safer, we tend to spend the margin it buys us, and not always wisely.
In What the Dog Saw, Malcolm Gladwell tells the story of risk homeostasis through anti-lock braking systems. The expectation was simple…give drivers better brakes and accidents will fall. A much-cited study of taxi drivers tested it, and the accident rate didn’t drop. Knowing they had ABS, drivers simply drove faster, tailgated more and cornered harder. They spent the entire safety margin on speed. The technology worked perfectly; the benefit evaporated, because human behaviour adapted to the new baseline.
John named it without prompting in our conversation:
“We’re watching it happen again with AI. Teams are taking the enormous productivity gains these tools deliver and spending almost all of them in one place – shipping faster. The dividend is real. It’s just going straight back into velocity.”
Then he asked the question that has stayed with me since:
What if we spent those speed gains on safety and quality instead? Still a little faster, but also a little safer, a little less defect-ridden. Not all of the windfall poured into the accelerator.
That is exactly the dynamic last week’s piece was about, seen from the inside. A safety advance, neutralised by behaviour. The brakes were never the problem. The problem is what we choose to do with the room they create.
The Debt Hiding Inside “Build Fast”
This is where John’s world and mine collide. The dominant model in product development is ship, test, learn, improve, and it’s there for good reason. Speed is a genuine competitive advantage. As John put it,
“The market no longer believes the big fish eats the small fish; it believes the fast fish eats the slow one. Teams are rewarded for velocity and judged on it.”
But from the cybersecurity side, the bill is coming due in ways most organisations can’t see, and this year the numbers caught up with the worry. For the first time in the report’s 19-year history, the 2026 Verizon Data Breach Investigations Report found that exploiting a software vulnerability, not stealing a credential, is now the single most common way attackers break in: 31% of breaches, up from 20% the year before. And we are getting worse at closing the door behind us. Only 26% of the flaws on the US government’s known-exploited list (CISA) were fully patched last year, down from 38%; the median time to remediate stretched from 32 to 43 days; and organisations faced roughly 50% more critical vulnerabilities than the year before. Attackers now weaponise a disclosed flaw in hours. Defenders are still answering in weeks.
“Patch it in the next iteration” feels agile and pragmatic. In reality it’s debt – systemic exposure that stays invisible until an incident forces it into the open. Teams believe they’re banking speed. They’re actually banking risk they have no way to measure until it detonates.
This is Not a Plea to Slow Down
Here’s the trap I’m determined to avoid, because it’s the lazy conclusion. None of this is an argument to slow down in some Luddite sense, and John’s case for speed is one I think he’s largely right about.
Software is a creative, non-deterministic process. Most ideas in it are wrong. Sturgeon’s Law puts it bluntly: 90% of everything is crap. Most features, most bets, most clever hunches deserve to fail, and the discipline is to stop tying your identity to them. The real gift of AI, John argues, is that it makes throwing things away cheap.
“You can test an idea and get the instant verdict a live audience gives a performer – the laugh, or the silence – and move on without getting attached. Speed-to-learn is a virtue.”
So the danger isn’t fast iteration. It’s confusing speed-to-learn with speed-to-ship-unsafely. They are not the same thing, and the anti-lock-brake effect is precisely what happens when you let the first quietly excuse the second.
Spend the Dividend on Resilience & Make it Cultural
So the real question is John’s question: where does the windfall go?
My answer, and increasingly his, lands in the same place last week’s piece did – into cyber resilience and design, not just velocity.
Start with how he frames the work. There are three Ds to DevOps, he says:
- the developmentof a feature,
- the deliveryof it, and
- the defendingof it once it’s in production.
Most organisations resource only the first. Delivery is an afterthought; defending the live thing is a never-thought. Yet the economics are damning – something like 90% of a feature’s lifetime cost arrives after it ships. Shaving cost during the build doesn’t remove that cost; it relocates and inflates it, often as a breach. Safe software isn’t the expensive option. It’s the cheaper one. And as John says, change begins in language: stop calling security a tax, and start calling it the margin you keep.
Practically, that means building security into every stage of the development lifecycle, not auditing for it at the end. I was evangelising this years ago, in my penetration-testing days – shift left, bake security into the SDLC, stop treating it as a gate you slam shut the week before launch.
It’s the same instinct John describes when he talks about pitch, sketch, stage, test and launch as a gradient where the security questions get louder at every step rather than all arriving at once, and where the failure mode is leaping from pitch straight to launch, skipping the hardening in between. In practice it looks like a definition of done that lets nothing reach production until the security constraints are resolved, and a delivery pipeline that acts as the guardrail a speed-only culture skips. Call it secure-by-design, brought down to the level of the daily build.
But tooling is not the deepest layer. John pointed me to the Alcoa story – the way Paul O’Neill made worker safety the single obsession of the company, the number on the board that resets after every incident. It didn’t just cut injuries; it transformed the whole organisation, because safety became the keystone that forced everything else to get better.
Picture the tech equivalent – a board on the wall that reads “355 days since our last breach”and is treated as the primary number, not a vanity metric. As John said,
“It’s a good reminder. But you have to bake it into the fabric, not bolt it on.”
That’s my own lens too. I’ve been describing cyber as a hierarchy of needs with leadership at the base, then culture, then governance, then defence, then collaboration. The uncomfortable truth is that most resilience today is performed, not built, because those foundational layers are hollow. You can buy the defensive tooling, but if the layers beneath it – leadership, culture, governance – were never built, what you have is the appearance of resilience, not the substance.
And the human keystone is psychological safety. It’s why John’s company is named for a sketch. In 1976, during a live broadcast, a performer was accidentally cut on air, and rather than freeze or call a meeting, the entire cast quietly improvised the same fix, together, in real time. That instinct – ego-free challenge, the safety to say “this feels wrong,” the reflex to adapt as a team – is exactly what lets people catch the flaw before it ships and absorb the shock when something gets through anyway. It isn’t soft. It’s the load-bearing wall of resilience under pressure.
Do We Add a Layer or Remove One?
Which brings me back to Glasswing, and the most provocative thing John said all conversation. He compared this moment to the way we’ve handled processed food: rather than fix the food, we invented a weekly injection to offset its effects.
“We didn’t solve a problem… We just added a layer.”
And he wondered aloud whether powerful vulnerability-finding AI is a layer we’re adding, or one we’re removing.
And there’s a hard number underneath his worry. When Anthropic reported on Glasswing’s first results, its partners had surfaced more than a thousand confirmed high- and critical-severity flaws across a thousand-odd open-source projects, and only a few dozen had actually been patched. That gap is the whole story. Finding vulnerabilities is no longer the hard part; AI has made it almost trivial. Fixing them i.e., validating, prioritising, shipping the patch, getting it deployed — is where defence actually happens, and it is where we are falling behind. It’s the anti-lock-brake effect written in code: the new capability handed us an enormous margin, and so far we’ve spent almost all of it on finding faster rather than fixing.
It’s the same question last week’s piece asked about secure by design: are we treating the symptom, or changing the condition? A model like Mythos can go either way. Point it downstream and it’s just another turn of the arms-race ratchet – find faster, patch faster, ship faster, repeat, with the attackers a step behind on the same treadmill. Point it upstream – into the design, into the definition of done, into hardening the critical software everyone else is built on, finding flaws before they’re ever written into the world – and it genuinely removes a layer. Same tool. Different choice. And the window to make that choice is narrow, because these capabilities will not stay in responsible hands forever.
To End
The brakes are here. Glasswing is simply the loudest proof that the dividend of speed and power has landed in our laps. Risk homeostasis warns us how this usually ends: we pour all of it into going faster and arrive exactly where we started – same crash rate, higher speeds, more to lose.
But that’s a pattern, not a law. We can decide to spend the dividend differently i.e., on safety, on quality, on defending what we ship, on the culture that catches the band-aid moment before it becomes a breach.
Last week I argued the goal was to make compromise matter less. This week, I’m arguing for one layer deeper, in the room where the software is actually built – make speed serve safety, rather than replace it. Same instinct. Harder discipline.
To return to the start of my blog, we just gave software its anti-lock brakes. The only question that matters now is whether we’ll use them to drive faster, or to drive better and safer.
Now I Want to Hear from You
Join me on LinkedIn and tell me in the comments, what’s the strongest argument you’ve heard for spending some of AI’s speed dividend on safety rather than shipping — and what do you think is really stopping more teams from making that trade?
Further Reading
2026 Verizon DBIR — https://www.verizon.com/business/resources/reports/dbir/
Malcolm Gladwell, What the Dog Saw (risk homeostasis via anti-lock brakes) — https://www.goodreads.com/book/show/6516450-what-the-dog-saw-and-other-adventures
Risk compensation / risk homeostasis (the behavioural concept itself and a plain explainer) — https://en.wikipedia.org/wiki/Risk_compensation
Sturgeon’s Law — https://en.wikipedia.org/wiki/Sturgeon%27s_law
Alcoa’s drive to safety — Paul O’Neill’s keystone habit, from Charles Duhigg’s The Power of Habit. O’Neill made worker safety his single focus as CEO in 1987, which cut injury rates dramatically and coincided with Alcoa becoming one of the best-performing stocks in the Dow — https://www.anecdote.com/2013/12/changing-keystone-habit-story-alcoa/ NATO ACT
The three Ds of DevOps and John Krewson’s book ‘Pitch Sketch Launch’ — The book is co-authored with comedy writer Rob Kutner — https://www.sketchdev.io/pitch-sketch-launch
Project Glasswing / Mythos Preview https://www.anthropic.com/glasswing For the specific “found 1,000+, patched only a few dozen” figure, the source is the initial update —https://www.anthropic.com/research/glasswing-initial-update
CISA Known Exploited Vulnerabilities catalog (the “US government’s known-exploited list”) — https://www.cisa.gov/known-exploited-vulnerabilities-catalog
