Paul Hammant's Blog: Charting AI Today: What It Leaves Behind
A few days ago I wrote about build-time AI vs run-time AI, after the Thoughtworks Future of Software Development Retreat in Engelberg - three days in June, convened by Martin Fowler and Thoughtworks, following an earlier gathering in Utah in February. Two write-ups are out now: Martin’s closing fragment and the official Thoughtworks report. Five headline findings, of which the first is the one that matters here: code generation is no longer the bottleneck - verification is. Agents can produce code, specs, tests and infrastructure faster than any team can trust it. The trick is - how to match the generated code’s tests to the generated code’s prod source.
My post was a 3×2 table. I’ve been thinking about it since, and the table wasn’t really getting accross what I wanted it to. Too many things sat awkwardly across the line, and the interesting distinctions were happening inside the cells rather than between them.
So Claude and I made a chart instead. It’s here, and it has toggles so you can play with it. 15 years ago I was using AngularJS for interactivty within SVG, and today I don’t ask Claude what it picked. Indeed Claude would have said yes to any of 50 JS/TS techs.
The axis that took the longest
I started with “artefact surface”: versioned artifacts on the left, operational state on the right. Two halves, four quadrants, done. My biases toward source control systems were clear - which I what I wanted.
It wasn’t two halves though. Pure chat has no versioned artifact and doesn’t touch operational state. Media synthesis has a library - durable, real, yours - that nothing downstream reads. And agents like OpenClaw don’t have a surface so much as an absence of one: whatever the machine can reach by whatever means … which is why I’ve not tried one of the many claws.
The version I settled on runs through six waypoints:
Chat Log → Versioned Artifacts → Media Library → Change Specific → Change Anything → Become
The ordering isn’t reach, and it isn’t persistence. It’s what’s left behind that someone can inspect. A transcript you can read. A commit that gets reviewed before it counts. Assets in a library. Records other biz systems depend on. Traces wherever the thing happened to reach. And then ultimately “Become” rightmost.
Persistence rises, then does something strange
If you follow the waypoints expecting durability to climb steadily, you’ll be wrong twice.
A chat log is less durable than a generated video file. And a media library is arguably more durable than a commit while being far less connected - nothing downstream reads it, which is why it sits where it does rather than further right. Durability and consequence aren’t the same axis, and conflating them is how you end up thinking Sora and alike are more consequential than Dependabot.
What “Become” means
The last waypoint is the one I keep coming back to. Someone built an operating system that was all AI - no code for the file editor, no code for the browser, no code for the spreadsheet. Just a model behaving editor-ly on demand. I’ll add the link when I can find it again.
My first instinct was that nothing survives there. That’s wrong. If the AI-generated word
processor saves a .docx file, the file is on a filesystem, as real as one written by actual code.
Two artifacts are in play and “Become” splits them:
- The output: your
.docxfile. Survives fine. - The producer: the word processor itself. Doesn’t exist as reviewable code, and may not be the same word processor next time you open the document.
And the sharper edge: with real code, save either worked or threw an exception. Here, “Saved!” is generated text. The file might be there. Might be elsewhere. Might not exist. You can’t read the save path to check, because there is no save path. You’re verifying from outside, every time.
Sam Ruby, on what survived contact: “rigor doesn’t vanish when the agent writes the code - it migrates. Upstream into specifications, down into test suites treated as first-class artifacts.” His sharper claim is that the oracle - the objective, and how you evaluate whether you met it - is the asset that can’t be delegated. Implementation can be generated and thrown away; the oracle can’t.
Which gives me a cleaner way to say what Become is. Not the absence of code - the absence of an oracle. Nothing independent left to check the output against.
That’s not the absence of an artifact. It’s the absence of any guarantee about one, which is worse. Perhaos thats absence you’d notice. See “side story” at the bottom about how the industry does historicaly like things that work but bobody can explain how precesiley - with the risk being “if it breaks, can it be fixed and how long will that take and what guarantees.”
The overlays
The chart has three toggle rows, and the reason they’re overlays rather than axes is that none of them are positional. They cut across.
Containment - Augmented, Harnessed, Unharnessed. Augmented is the bottom of the chart, and it’s mostly classic products with a model bolted into an existing deterministic frame. Zapier didn’t get displaced by LLMs; it became a distribution channel for them. The model fills a slot; the workflow around it stays developer-defined. That’s the deployment pattern most organisations actually reach for, and it’s the least discussed.
I’m using “harness” in roughly Thoughtworks’ sense - the scaffolding round an agent - though I care less about how well it’s built than whether it exists at all, and whether anything checks the output before it counts. That’s a looser test than theirs, which is why the Harnessed lasso picks up commercial CRM and support agents where the vendor built the rig rather than you. The rig is still there. You just didn’t assemble it, and can’t see much of it.
When it goes wrong - the four MTTD/MTTR regimes. Mean time to detect and mean time to repair are independent, and people conflate them constantly. Fast/fast is CI linters and autocomplete: wrong is visible immediately and costs seconds. Fast/slow is a Zapier job that mangled 10,000 records overnight - you know by morning, and unwinding takes a week.
Slow/slow is where it gets uncomfortable. Data enrichment writing a plausible summary into a CRM
field. Nobody notices for months. By then humans have read it and trusted it, it’s been exported
into reports, and there’s no git revert for “this record has been quietly wrong since March.”
Note that MTTR correlates with the x-axis - versioned artifacts are revertable by construction - but MTTD doesn’t correlate with anything on the chart. Detection time is a property of how the output gets consumed, not of what the system is. That’s why it needed its own overlay.
This is the retreat’s “verification is the bottleneck” finding wearing different clothes. If verification is what’s scarce, then MTTD is just the measure of how long unverified output sits around being trusted. The chart’s slow-detect region is where verification isn’t happening at all - not because it’s hard, but because nobody scheduled it.
The Thoughtworks report gets to a recommendation I’d endorse from a different direction:
Adopt a risk-tiered autonomy model per system or component (cobot-style human oversight vs. dark-factory-style full automation), explicitly based on risk, reversibility and blast radius - do not apply a single autonomy policy uniformly across a portfolio.
Reversibility and blast radius are precisely what the x-axis and the MTTx overlay are measuring. If you want a risk-tiered autonomy model, you need a way to see which tier a given system is actually in - and “it’s agentic” doesn’t tell you. Dependabot and OpenClaw are both agents. They’re nowhere near each other on any dimension that matters for setting a policy.
Human veto - before it counts, after the fact, or not at all.
I got this one wrong first time. I had the whole chat column as “human-free,” reasoning that there’s no PR, no approval workflow, no review artifact. But chat has the tightest veto on the chart: you read every token before anything happens, and rejection costs one prompt. I’d confused the absence of a formal review process with the absence of oversight. They’re not the same thing, and the informal one is often stronger.
Kief Morris, writing up the same retreat, reduces the whole thing to: “how much do we let an agent decide, and how do we stay confident in what it does?” His ops teams keep a narrow remit - “diagnose, yes; decide, no.” That’s a veto boundary drawn inside a single system, which my chart can’t show; one dot per product doesn’t have the resolution. He also found line-by-line code review had stopped working as a guardrail, with rigor migrating upstream to acceptance criteria and downstream to automated checks. Worth holding against my “before it counts” lasso: the gate is there, but it may not be carrying the weight we assume it is.
Ian Cooper’s gears make the same point from another angle: he drives in high gear for boilerplate and drops to low gear when certainty falls or the blast radius grows - auth, payments. So it isn’t just that the veto boundary sits inside a system rather than around it. It moves, hour to hour, with the same tool in the same hands. My chart gives each dot one veto state and holds it there.
Kief and I were at the same three-day event. Showing him the open source thing I’ve been building in exactly his space was in my top five must-dos for the trip. I flew home without having done it. Forty sessions (albeit multi-track) and plenty of hallway time, and the one conversation I’d specifically planned was the one I missed.
Only two dots are genuinely veto-free, both at the right-hand end, and they fail differently. OpenClaw’s defects get found late and can’t be cleanly undone. The AI-native applications one is worse in an odd way - there’s no defect to point at, because there’s no code to diff against intent. You just sense that something is off - “uncanny valley” in the modern age.
Abby Bangser makes a point I hadn’t considered: “removing humans from the loop also removes organisational and product learning.” The veto isn’t only a correctness mechanism. It’s where people find out what the system actually does - which is the apprenticeship problem arriving by a side door.
Caveats
Dot placement is editorial, not measured. I’d defend the clusters and the general diagonal; I would not defend any individual coordinate to two decimal places. The chart is a thinking tool, not a dataset.
The Media Library island property is a fact about today’s integrations, not about the technology. The moment someone wires generated assets into a publishing pipeline, that dot slides right. Integrations by another name.
And the whole right-hand end is thinly evidenced - one shipping product and one experiment. That’s the nature of drawing a chart about where things are going rather than where they’ve been.
Have a play with it. The overlays combine - Augmented plus slow/slow detect is the combination I find most interesting, and it isn’t the one anyone is writing threads about.
Others who wrote it up
Worth your time, and I’ve only borrowed from some of them above: Ivett Ördög on whether agents should maintain codebases like engineers or regenerate them like compilers - the question my x-axis is really about; David Whitney on why “almost always working isn’t enough”, and code mattering more rather than less; Bartosz Ocytko on software factories and the handoff points where humans still sit; Giles Edwards-Alexander on “Optimisers vs Learners” as two organisational shapes, and on learning being the constraint now rather than delivery; Andrew Harmel Law asking which of our practices were rafts we can put down.
Footnote: a reversibility I’m not measuring
Mathias Verraes argues for keeping the ability to “revert from agentic code generation to human engineering.” That’s a reversibility my chart doesn’t measure - not undoing a change, but undoing a way of working. The x-axis says nothing about whether you can walk back from a waypoint once you’re standing on it.
Side Story
In the mid-1990s, at the University of Sussex, researcher Adrian Thompson used a genetic algorithm to repeatedly reconfigure a Xilinx FPGA until it evolved a circuit that could distinguish between two audio tones. Instead of producing a neat digital design, evolution exploited subtle analogue properties of the physical silicon timing delays, capacitance and other quirks to create a solution that worked but was largely incomprehensible to its creators and often depended on the characteristics of that specific chip. The result was a striking demonstration that evolutionary search can discover highly effective solutions beyond human intuition, but it was never adopted for telecoms or other safety-critical industries because engineers could neither fully explain nor reliably verify its behaviour across different devices, temperatures and operating conditions. In the end, its greatest strength finding unconventional solutions unconstrained by human assumptions was also the reason it could not satisfy industries that require predictable, reproducible and certifiable designs. Are we back in that risk place now?