Turning Imagination into Production Code

On June 9, Anthropic released Claude Fable 5, the most capable AI model it has ever made generally available. Within days, a 200-video trading curriculum had become a working, safety-gated trading agent: 122 source files, 785 automated tests, and a decision log I could review in one sitting. The build was basically one overnight run on my personal Claude plan, plus a few hours of my own interaction, all after business hours. This is not a story about a trading bot. It is a story about a repeatable pattern: gather the domain knowledge, structure it into a knowledge graph, generate a specification from the graph, and let Fable 5 turn that specification into verified, production-grade code with minimal human input.

Fable 5 is a Mythos-class model, a new tier that sits above Claude Opus in capability, with state-of-the-art results across the software engineering and scientific reasoning benchmarks Anthropic published at launch. That's not hyperbole; every number in this post is what one subscription produced basically overnight, with a few hours of human interaction. Anthropic is including the model at no extra cost on Pro, Max, Team, and seat-based Enterprise plans through June 22. After that, using it requires usage credits at ten dollars per million input tokens and fifty dollars per million output tokens, double the price of Opus 4.8. That pricing tells you exactly what Anthropic believes the model is worth. For the next two weeks, that capability is sitting inside subscriptions most of us already pay for. Which makes this, above everything else, a story about a window that closes on June 22, and what anyone with a Claude Pro or Max plan can build before it does.

Numbers on a pricing page do not tell you what a model can do. Builds do. So I ran one on my own time, evenings and overnight, on my personal plan rather than anything INS provides, and I deliberately chose a domain far from my day job. Here is the anatomy of that build, step by step, because every step is one you can copy.

Two Hundred Transcripts, One Million Words

The experiment started with a question: could I turn the way human experts teach a skill on YouTube into a specification rigorous enough for an AI agent to build against? The skill I chose was the break and retest options strategy taught by two trading educators, Scarface Trades and JdubTrades.

Step one was gathering the raw domain knowledge. Using Claude Code, I pulled down the transcripts of both channels' teaching libraries: 111 videos from JdubTrades and 89 from Scarface Trades. Two hundred transcripts in total, just over one million words of unstructured teaching, repetition, tangents, and live trade narration.

A million words is far more than anyone can paste into a prompt, and reading it linearly would take a week. So step two was structure. I used Graphify to build a knowledge graph of the entire corpus: 1,211 nodes, 1,310 edges, and 53 distinct concept communities with names like "Risk, Stops and Profit Taking," "Opening Range Entry Models," and "Break and Retest Core System." Processing the corpus consumed roughly 1.5 million input tokens. What came out the other side was the thing the transcripts never state explicitly: the actual structure of the strategy, deduplicated across two teachers and two hundred videos.

This is the pattern from When Domain Knowledge Compounds: the hard part of building software is not the code. It is understanding the domain deeply enough that the code becomes obvious. The knowledge graph compressed months of apprenticeship into a queryable artifact.

From Graph to Specification

Armed with the graph, I generated a specification. Not a wish list. A real one: a 795-line strategy document defining what the system trades, including twelve distinct named setups, level engines, risk rules, and a full state machine, plus a 308-line application document defining how it is built, covering architecture, broker integration, safety layers, and promotion gates. More than 2,200 lines of design documentation in total, every section traceable back to nodes in the graph.

Here is what matters about that step. The specification was generated from structured domain knowledge, then reviewed by a human who understood the domain through that same graph. The graph did not just feed the spec. It gave me the fluency to judge the spec.

The Overnight Prompt

With the spec written, I handed Fable 5 a single prompt one evening and went to bed. Here it is in full:

Let's be clear about what this prompt actually does, because every clause is load-bearing.

• "Decompose the spec into independent work packages and generate acceptance tests directly from the spec." This uses Anthropic's workflow capability in Claude Code, which orchestrates fleets of subagents deterministically. The acceptance tests are written from the specification before the code exists, so every implementation is graded against intent, never against itself.
• "Verify, fix, and re-verify until a round finds nothing new, max 5 rounds." This is a bounded convergence loop. Fresh verification agents adversarially check each package, and the cap prevents infinite churn. Because each package gets its own focused agents, the build also sidesteps context rot, the reliability decay that sets in when one long session tries to hold everything.
• "If a package won't converge, quarantine it and continue." Failure is contained and documented, never hidden. The build does not stall on its hardest problem.
• "Record ambiguities with rationale in DECISIONS.md." Where the spec was unclear, the agent chose the simplest consistent interpretation and wrote down why, instead of waking me up.
• "Commit after each completed package. Finish with a report." Full traceability, reviewed once, in the morning, by a human applying taste and judgment to outcomes rather than keystrokes.

This is the 10-80-10 model made operational. Ten percent human ideation up front: the corpus, the graph, the spec. Eighty percent autonomous execution overnight. Ten percent human review at the end, focused exactly where human judgment matters.

What the Morning Report Showed

The numbers in the repository after the overnight run and a few hours of my interaction around it:

Look at those numbers carefully, and then look at one more pair: the application is roughly 14,400 lines of Python, and the test suite is just over 16,000 lines. The agent wrote more test code than application code, spread across unit, integration, golden, chaos, and determinism suites. That ratio was not an accident. It is what the prompt's verify-and-re-verify loop produces naturally.

The decision log is where the build gets genuinely interesting. Decision D3 records that when a trade is closed outside the engine, the system stores a null result rather than a fabricated zero, because "a trade closed outside the engine is not evidence about the strategy" and fabricated numbers would pollute the gate statistics. Decision D13 records the moment a verification round caught the agent's own commit message claiming fixes that were not actually in the diff, after which it imposed a new discipline on itself: every claimed fix must be verified in the working tree before any commit. The agent caught itself misreporting and tightened its own process, in writing.

The quarantine file tells a similar story. One sub-feature, re-adopting in-flight trade management after a restart, refused to converge within its five verification rounds. The agent did not quietly ship something broken. It disabled the feature loudly, wiring the code to raise an error that points directly at the quarantine document, recorded the exact open findings, and kept building. A later work package resolved the quarantine cleanly. Honest failure handling, it turns out, can be specified in a prompt.

And because the domain is real money, the spec demanded defense in depth: five safety layers covering pre-trade validation, a news filter that fails closed, portfolio limits, drawdown circuit breakers, and broker-side bracket orders with a kill switch. Autonomy in this system is earned, never assumed. Every strategy must pass a backtest gate and a paper trading gate before it may touch a live order, and as of this writing the system runs paper trading only.

The Pipeline You Can Copy

Strip away the trading domain and what remains is a repeatable five-step pipeline from imagination to production code. None of it requires a software engineering background. All of it requires your domain knowledge.

1. Gather the domain knowledge. Transcripts, manuals, process documents, support tickets, recorded walkthroughs. The raw material is usually already lying around your organization as tribal knowledge. Collect it into files.
2. Structure it. Build a knowledge graph or an organized digest of the corpus. The goal is to surface the real structure of the domain: the concepts, the rules, the exceptions, the things every expert knows but no document states.
3. Generate the specification. Have the model draft a spec from the structured knowledge, then review it yourself. You are the domain authority here. The graph gives you the fluency to judge what the model drafted.
4. Direct the build with a verification-first prompt. Use the directive pattern above: decompose into packages, generate acceptance tests from the spec, implement, verify in bounded loops, quarantine what will not converge, log every ambiguity decision, commit continuously, report once.
5. Review the report, not the keystrokes. In the morning, read the report, the decision log, and the quarantine file. Spend your judgment where it counts: on the decisions the agent flagged for you.

What to Do Before June 22

If you hold a Pro or Max plan, here is a concrete way to spend the window. Pick one problem you have accepted as unavoidable, the spreadsheet ritual, the manual report, the tool you wish existed. Spend one evening on steps one through three. Then run step four overnight and read the report with your coffee. The worst case is a free education in directing agents. The likely case, based on everything I have built this way, is a working tool you keep.

What This Means for INS

The Encouraging Reality

It is fair to feel a kind of vertigo reading this. A system that would have taken a contracted team a quarter to build came together basically overnight, with a few hours of human interaction, mostly unattended. If a model can do that, it is natural to ask what is left for the rest of us. But there's a deeply encouraging flip side, and it shows in where every hour of my own effort actually went: choosing the domain, judging which knowledge mattered, reviewing the spec, deciding what "safe" had to mean, and reading the morning report with informed skepticism. The model amplified that judgment. It could not supply it.

Nobody without the domain knowledge could have specified the twelve setups, or known that a trade closed outside the engine must not count as evidence, or insisted that autonomy be earned through gates. The overnight build did not make domain expertise less valuable. It made domain expertise the entire input. That is the abundance hiding inside the vertigo: your years of accumulated understanding just became directly executable.