The Spec Layer
Fable, agentic coding, and why autonomous software needs a source of truth
Like many of you, I spent a huge chunk of this weekend using Fable. From Thursday until Sunday morning, I spent a majority of my time working with Fable on projects I’ve either gotten stuck on or wanted to accelerate. I can confidently say Fable is an unlock. It really isn’t hype, the technology behind the model is genuinely incredible. It feels like another important moment in the history of personal AI usage.
Much like with electric cars, range anxiety has turned into token anxiety. I found myself checking my usage limits on my Claude Max plan every half hour, and intentionally kept prompts as limited as possible to prevent overuse. Which is a shame, because some of the most intriguing and frankly unbelievable projects that were showcased on X this weekend were the result of long-running tasks at maximum effort.
The last week has been a major eye-opener for what Fable is capable of when it comes to tool usage, ability to reason across domains, and both holistically understand projects as well as nail difficult engineering problems in a single go. I’m more convinced than ever that frontier models like Fable, when combined with MCP (Model Context Protocol) usage and high-quality data, will result in jaw-dropping projects in the near future. Key disruptions include 3D asset generation, constructing world models, mastering tools like Autodesk and Unity, and even better general computer use. Oh, and everything else.
Performance Gaps and Model Routing
My god, these frontier models are expensive. It’s clear that the gap is closing when it comes to the difference in capability between open and closed models. In fact, GLM 5.2 beats Opus and many other closed frontier models in some public benchmarks, which is shocking. GLM tokens cost on average 5 to 6 times less than Opus, while at times offering similar performance.
Most people won’t be running frontier-level models on their personal computers anytime soon, which means model-routing is becoming increasingly important.
Many of the top tips for efficient Fable 5 usage are similar to when Opus and other frontier models were released.
Use the strongest model for judgment, not grunt work. Don’t waste expensive model tokens on running obvious edits. Use it for architecture, planning, and the really hard stuff.
Keep context clean. Compact when needed and don’t drag old context forward.
Be targeted about scope. Tell it what you want done specifically.
Preprocess noisy material prior to giving it to the model. It can still handle large gobs of text, but it is often unnecessary.
Cap output verbosity. Why use many token when few token do trick?
Use cheaper models for well-bounded subtasks.
However, many of the top tips for utilizing Fable differ significantly from previous models like Opus.
Fable 5 is built for long-running projects. You can let it drive and go, and it’ll keep going.
Default to lower effort. Extra high is largely unnecessary unless you’re doing insane 3D or modeling work. Effort is a central control surface.
Fable can handle bigger handoffs than other models. You don’t need to spoon-feed it, but that also doesn’t mean the structure stops mattering.
Where Opus was expensive intelligence, Fable is expensive autonomy, and you need to make sure you don’t allow it to waste itself endlessly searching, combing through logs, or doing repetitive reasoning. It has a solid gauge on when to end things, but it isn’t perfect.
Until we have cheap versions of Fable that are close to AGI, things like model routing and spec-driven development (SDD) are going to be important. Arguably, they’re more important than ever.
Model-routing is straightforward. You, or an agentic system, decides based on a query or conversation what model makes sense for a request. We see this pretty efficiently used in OpenAI’s GPT series. The more automated systems can take the guesswork away, the easier our lives can be.. But frontier companies are not incentivized to make it perfect. They want you in their ecosystem, and if you strictly use an ecosystem like Claude, you’re going to pay more on average for basic requests.
Being cognizant of the usefulness of model-routing is important. But it isn’t the only piece. Spec-driven development is something that you should be equally familiar with.
The Necessity of Spec-Driven Development
The problem comes up a lot if you’re making new projects: AI will either build too much, or completely miss the mark for what you’re aiming for. Taking the time for alignment prior to building is now necessary. Making it a part of your workflow will save you time, money, and headache. Who knows, you may even need to read the document it produces!
Spec-driven development is very straightforward. Clear specifications are created before creating or implementing software, and that spec is used as the source of truth for building, testing, and reviewing work. Agents work against it and come back to it, and you can use a docs-driven approach to wrangle them when they proceed to over-engineer basic functionality.
The flow is simple:
Define the desired behavior, constraints, files, edge cases, and success criteria
Have a model plan against the spec
Let a cheaper and/or faster model or agent system implement it
Use the spec to verify the output
The contract tries to keep things honest. There are entire IDEs like Kiro built around this idea, and skills within Claude and other platforms are becoming durable artifacts. Kiro is an agentic IDE built around turning prompts into executable specs, validating code, and managing long-running work across larger codebases.
There are frameworks like OpenSpec, which are useful lightweight tools that work alongside what you already use. As long as you have a repeatable flow for generating specs, creating associated plans and tasks for implementation can just fall into place. The idea is to stop vibe coding and start generating markdown artifacts that serve as structured content for whatever is touching your project (agents, people, etc).
At Artifact, we encountered this problem months ago. We wanted a lightweight tool we could use inside of Claude to help create structured documents, flesh out requirements, and check if the code the agent was building was actually matching the intent. The tool we created is called Arnold, and you can freely install and use it here. Once Arnold is installed, Fable actually uses it, which is the entire point.
Arnold is useful because it forces the agent to externalize intent. Arnold helps turn goals, requirements, decisions, and notes into durable project artifacts. Agents are capable of building for hours, but they need something stable to return to.
Making specs is one thing. Ensuring they don’t go stale inside your project is another, so either you’ve got to constantly manually ask whatever model you’re using to update documentation, or you need a tool to keep that at the top of mind.
Frontier models and their harnesses are getting better at keeping documentation in focus, but they still do not reliably treat doc drift seriously. Even if you add pre-prompting or rules asking for them to keep it in mind, they’ll disregard making updates as a priority. The only way to keep things clean is to use another tool, at least for now. To be fair, Fable is better about adhering to document management rules compared to older models. Use Fable to plan, and use Codex to program.
Our Spec’d Future
Utilizing some of the latest spec-driven development techniques and being conscious of model routing goes a long way. The new models and platforms are incredible, but what is separating great from amazing output is context engineering. Teams and individuals are going to learn this one way or another. Great documentation and solid agentic workflows go hand-in-hand.
As they say, knowing is half the battle. A/B testing your results using SDD and tasteful model-routing will save you time and money. SDD can become second nature, and even preferable when building using AI.
I’ve been building a few projects that I’m excited to share soon, and I can confidently say I wouldn’t be as far along as I am without having such a focus on documentation. Fable may make the work faster, but specs make it coherent.
Code is getting cheaper, and knowing what should exist is becoming more valuable than ever.
Thanks for reading.