One-shot with Fable
I built one of the last apps with Fable before it got banned! Its one-shot capabilities are a preview of where development is going.
Friday night, inspired by what others were building, I decided to take Fable for a spin — not yet knowing it had already been banned. Ten minutes with Fable 5 in the Claude desktop app produced a spec for a Cocktail Recipe app targeting Apple Foundation Models. Then I opened Claude Code in Terminal went to kick off the build and couldn’t find Fable. Logged out, logged back in. There it was. (That second login finally makes sense now.)
All that existed at that point was an implementation plan in a folder. I ran:
/goal Implement @IMPLEMENTATION_PLAN.md and follow Apple Human Interface Guidelines for iOS. End when app is tested and builds
Twenty-two minutes later: a working app.
Three thoughts on where we are headed:
One. As one-shot capabilities mature, the supporting files — standards docs, patterns, guidelines, security reqs — become the differentiator. This matters even more in enterprise contexts where consistency across teams is the whole game.
Two. “Tested and built” is not the same as “working.” All unit tests passed. The app compiled. It did not, however, produce a cocktail recipe. Acceptance criteria need to be airtight for one-shot to truly impress.
Three. Two distinct modes are crystallizing for tools like Claude Code and Codex: one-shot — full infrastructure, complete spec, output lands at UAT-ready — and exploratory, for rapidly converging on what you actually want to build. Both will reshape every role in the development process.
Saturday morning I woke up, read about the Fable ban, and now to finish the build the “old-fashioned” way: Opus and Sonnet.
Originally posted on LinkedIn.