Build software you can throw away. Fable 5 makes it possible.

The morning after Anthropic released Fable 5, I gave it a prompt and walked away.

“Read and understand this project. I want you to improve the drilldown behaviour. At the moment, if you drill down, then try and filter within that drilldown, it errors. For instance, if I am looking at a chart that shows sales by Country, I drill down to see sales by Store, then in the chat ask ‘Show me this same chart but just for this year’, I get errors. Fix that. Next, at the moment you cannot drill down from a drill down. This should be possible, I should be able to drill down until I get to the raw data.”

That was the whole prompt. No specification phase. No implementation plan. No iterating with the model over how it would approach the work, the disciplined sequence I have written about before and follow as a matter of course. Just a description of two problems and an instruction to fix them.

It ran for eighteen minutes, unattended. When I came back, both issues were fixed and every test passed. And it had made a design decision I would not have made.

I would have built cascading modal dialogues, one for each layer of the drilldown. It is the obvious approach, and it is the wrong one, because three layers deep you are buried in a stack of windows. Fable did something better. It put the drilldown into the chat dialogue itself, then added breadcrumb navigation so you could step back through the layers cleanly. It is more intuitive than what I would have specified. Fable has taste.

I had one concern before I tested it. If a filter applied inside one drilldown persisted, every subsequent drilldown would inherit it, and you would end up looking at this week’s data when you wanted all of it. It did not happen. Subsequent drilldowns behaved perfectly. The model had thought about the state management more carefully than my worry assumed.

What Fable 5 actually is

Anthropic announced Claude Fable 5 on 9 June, the first Mythos-class model made generally available. Mythos is the tier that sent the security world into a spin in April, when Anthropic withheld the preview from public release because of its ability to autonomously find and exploit vulnerabilities in critical infrastructure. The question that left hanging was how a model that powerful would ever ship broadly.

Fable 5 is the answer, and the answer is constraint. It is the same class of capability, made deployable not by making the model weaker but by engineering the boundaries around it. Queries in high-risk areas like cybersecurity and biology are routed to the next-most-capable model, Opus 4.8, with safeguards expected to trigger in under five percent of sessions. Anthropic ran more than a thousand hours of external testing and found no universal jailbreak. It is priced at ten dollars per million input tokens and fifty per million output.

I have made this argument before, about our own systems. The generative capability that makes a model dangerous is the same capability that makes it valuable, and the variable that decides which one you get is constraint. Anthropic did not wait for a safer model. It built the dial that made this one shippable. The same engineering discipline we apply to a database expert system, Anthropic has applied at the scale of a frontier lab.

The floor and the ceiling

The obvious reading of my eighteen-minute story is that the floor just rose. People who cannot really code will now produce working software. Amateur developers will ship things of genuinely higher quality. That is true, and it is what most of the posts about Fable 5 will say this week.

The more interesting claim is that the ceiling rose further. For experienced engineers, Fable-class capability does not just make the easy things easier. It changes what is worth building, what is worth committing to, and where the value in your work actually sits. The rest of this post is why.

The discipline did not retire. It moved.

I need to deal with the obvious objection first, because it comes from my own back catalogue. In April I wrote that disciplined agentic engineering means exhaustive specification, several adversarial review passes, an iterated implementation plan, and gated build phases. This morning I skipped almost all of it, and it worked. A fair reader will ask whether Fable 5 just made my own thesis obsolete.

It did not. It redistributed it.

The specification phase survives, for new and large projects. But it was never really for the model. Working through a detailed specification forces the humans to decide what they actually want, to surface the disagreements and the half-formed assumptions before any code exists. That value does not go away because the model got better. The reason I could skip it this morning is that the change was contained within an application that was already well defined. The specification already existed, in the code and the documents around it.

The implementation plan iteration is a different story. That step, where you work with the model over how it will build something before it builds it, existed to compensate for a weakness. Previous models lost the thread mid-build. They would start well, then drift, and the plan was the rail that kept them on track. That weakness may simply not exist any more. So I am going to stop iterating implementation plans and see what breaks. I want to be precise about that framing. This is one run, one contained change, in a well-prepared repository. I am running the experiment, not announcing the result. But my expectation is that the implementation plan is the part of the discipline that this model class makes redundant.

The part that appreciated in value is the structural artefacts. Every module in that codebase carries a header describing what it does, what depends on it, and what it depends on. Every function carries a description and a list of every method that calls it across the project. There is a CLAUDE.md that orients the model to the whole system. When Fable “read and understood” the project, that is what it read. Those artefacts are what let an eighteen-minute unattended run land a correct, well-designed change in unfamiliar territory.

And they do a second job. At ten dollars in and fifty out per million tokens, the cost of feeding a model context is not trivial. Good structural documentation is the most efficient possible representation of a codebase. It is progressive schema narrowing applied to your own source. The model gets a dense, accurate map instead of having to read and infer everything from raw files. Cheaper, faster, and more reliable, all from the same artefacts.

Nobody read the code

Here is the part some readers will object to, so I will state it as plainly as I can. No human reviewed the diff before it shipped. The verification was performed entirely by machines.

We run automated code review and Claude Code security scans on every pull request. Both fired on this change. Both passed clean. We run an extensive unit test suite that encodes all the documented behaviour of the system, and it runs before anything is checked in, so any regression against known behaviour stops the change cold. We still run our penetration test suite manually after every release, which is the one gate in this chain that is not yet automated, and closing that gap is the next thing on the list.

I am not going to pretend this is anything other than what it is. We shipped a change to production and no person read the code. The instinct to call that negligence is understandable, and I want to meet it head on rather than wave it away.

Human diff review misses things. It misses them constantly. A reviewer skims, pattern-matches, trusts the author, runs out of attention three files in. The review feels like diligence, but its actual yield on subtle defects is far lower than we like to admit. The machinery, by contrast, runs every time, at full attention, on every line. It does not get bored. It does not assume the author knew what they were doing.

But the deeper point is this. The reason I could hand Fable an open-ended prompt and walk away was not that the model is trustworthy. It is that the gates existed before the model arrived. We built the automated review, the security scanning, and the behaviour-encoding test suite over months, as a matter of engineering discipline, long before this morning. The autonomy was safe because it was earned, by infrastructure, not granted by faith.

This is trust escalation, the pattern I have written about for agents acting on enterprise systems, applied to a coding agent. You do not start by trusting the agent with everything. You build the means to verify what it does, and you extend autonomy in proportion to what your verification can catch.

This is also exactly where the vibe coder and the experienced engineer diverge. They get the same model. They get the same eighteen minutes. What they do not have is the gates. A vibe coder handing Fable an open-ended prompt is extending trust they have built no means to verify. The model is identical. The surrounding architecture is not. That is the whole difference between the floor and the ceiling, and it is the constraint argument again, the dial that decides whether capability produces value or damage.

Implementations just became disposable

Now the part that actually changes how we plan.

A few years ago we stopped selling our analytics platform, inmydata, as an analytics platform. That market had been commoditised, mostly by Power BI, and there was no future in competing there. But the platform itself is close to perfect for a problem that matters far more now. It is the bridge between agentic AI and operational data. It provides extremely fast data access, which is what conversational interfaces need to feel responsive. It enforces row and column level security and auditing, which is what you need before you let an agent anywhere near real business data. And it has a metadata layer that turns raw operational data into something with business meaning.

So we are rebuilding the interface. The current one is built for analysts clicking through dashboards. The new one is conversational. You talk to the agent. “I want my sales data out of Salesforce,” and the agent talks you through engineering exactly that.

The question we have been circling is which technology to build it in. It is currently Blazor. Our more recent projects are React, and Blazor is starting to feel like a dead end, which is an argument for moving everything to React and being consistent. But there is an old fear lurking behind that decision. What if we commit to React and, two years from now, React is the thing that feels like a dead end?

With Fable-class models, that fear dissolves. If the design documents are good enough, the front end can be spun up in almost any technology, quickly. The technology choice stops being a ten-year commitment and becomes closer to a rendering decision. What matters is not which framework you picked. What matters is that everything is built in a modular way.

Because something around the corner will make some part of our stack obsolete tomorrow, and something we cannot currently imagine will become possible next week. That is the actual pace of this landscape. Modularity is what lets you add and throw away pieces quickly enough to keep up with it. You build a component, and if the ground shifts, you rebuild it in whatever the new best option is, without the rest of the system caring.

The code is the cheap part now. The thinking is the asset. The design documents, the modular boundaries, the decisions about what the system should do and how its pieces fit together, those appreciate in value, because they are what makes the cheap, fast rebuilding possible. Vibe coders get working software. Engineers get optionality, and in a landscape moving this fast, optionality is worth far more than any single artefact.

The boundary that holds

There is a self-consistency challenge to answer before I close, because a careful reader will already have it ready. In an earlier post I argued that the right move with decades-old systems is to wrap the business logic rather than rewrite it. If implementations are now disposable, does that advice fall over?

It does not. The dividing line is sharper than old code versus new code. It is functional software versus business logic.

A dashboard designer, an Excel replacement, a conversational interface, these are functional software. They are disposable because their errors are visible. When the drilldown breaks, you see it break, in front of you, and you fix it. The cost of getting it wrong is bounded and immediate.

Business logic is the set of real-world rules an organisation needs to function. The approval chains, the compliance checks, the pricing rules, the edge cases that took years to encode correctly. That logic is complex, frequently undocumented, and its errors are silent. A mistake in a business rule does not announce itself. It compounds quietly for months before anyone notices, and by then it has touched everything downstream. You do not throw that away and regenerate it, because you cannot see when the regeneration is wrong.

So the freedom to throw software away applies to the interaction and presentation layers, the parts I have argued for a while are becoming irrelevant as fixed artefacts. The business rules stay wrapped, stable, and protected. The two arguments do not conflict. They describe different layers of the same stack.

The discipline did not become obsolete on 9 June. It moved up the stack. The engineers who built the specifications, the structural artefacts, and the verification gates before Fable arrived are the ones who can now hand it open-ended work and walk away. Same capability for everyone. Different surrounding architecture. That is what separates the engineers who will use what shipped from the ones who will only be impressed by it.