# What I got done with Fable that kept slipping before A field note on handing a large Rust refactor to Fable: knowledge-graph analysis, a full graph rebuild that survived a mid-run failure, and a 9,859-line file cut to 877 across six verified commits. Source: https://appheat.co/posts/what-i-got-done-with-fable/ Published: 2026-07-02 Tags: coding-agents, developer-workflow, refactoring ## Quick answers - Fable held one coherent thread across a multi-hour task — graph analysis, a full rebuild, and a verified refactor — without losing context. - The refactor cut a 9,859-line source file to 877 lines across eight cohesive modules in six commits, each with the full test suite green and no public API change. - It stayed honest under failure — it recovered corrupted sub-agent output and reported the exact coverage gap instead of hiding it. - It pushed back on my framing and revised its own analysis when the evidence changed, which is the part I could never get reliably before. I keep a running list of jobs I do not hand to coding agents. Anything that runs longer than a few minutes, touches a lot of files, or needs an actual judgment call usually lands on it. The agents I had been using were great at the small stuff and unreliable at everything else. They would lose the thread, quietly hand back a green checkmark that was not real, or agree with whatever I had just suggested. I spent an afternoon giving Fable the worst item on that list: the architecture of a large Rust codebase, and one source file in it that had grown to almost ten thousand lines. Here is what actually happened, because the specifics are the point. ## Evidence note The counts in this post are first-party measurements from the local session: `git log` and changed-file summaries for commit activity, manifest hashes for graph staleness, and before/after line counts plus reconstruction and test outputs for the refactor. The source repository and raw run logs are not public, so these figures are a build report, not an independently reproducible benchmark. ## It reasoned over the graph, not just the files I had already built a knowledge graph of the codebase and loaded it into Neo4j. Most agents ignore that and start reading files one at a time. Fable queried the graph. It pulled the most-connected nodes, measured how tangled the modules were, and ran queries to separate real code dependencies from noise. It treated my architecture as data instead of scrolling through it. ## It measured staleness instead of guessing The graph was five days old. A weaker agent either trusts a stale analysis or wastes an hour rebuilding everything from scratch. Fable re-hashed every file against the old manifest, cross-referenced git history — 117 commits, 184 files changed — and told me precisely how stale it was: 38 percent of the relevant files had changed, and it named the hot spots. Then it did the smaller thing: an incremental update, not a full rebuild. ## It fanned out, and stayed honest when it broke Rebuilding the full graph meant extracting about 1,500 files across the whole project, so Fable dispatched dozens of parallel sub-agents. Partway through, it hit a session limit and several of those workers died mid-write, leaving corrupted, half-finished output. This is the exact moment most agents either fall over or silently move on. Fable wrote a parser to recover the intact data from the truncated files, pulled back hundreds of nodes that would otherwise have been lost, and then told me plainly what it could not recover and why it did not change the finding. It kept an honest ledger of its own coverage. I did not have to catch it cutting a corner, because it flagged the corner itself. ## It corrected its own conclusion Its first pass surfaced something alarming: more than 2,300 dependencies crossing a boundary that was supposed to be clean. Instead of running with the scary headline, it dug in, separated documentation references from actual code calls, and found the real number was about 60. It revised itself out loud, and the corrected version was the good news. An agent that will walk back its own analysis when the evidence says so is worth ten that sound certain and are wrong. ## It disagreed with me I suggested a direction. Fable pushed back. It walked me through why I already had what I was asking for where it counted, pointed at my own written architecture decisions, and explained that the real problem lived somewhere else. It did not flatter me into a pointless restructure. That one honest "no, and here is why" saved me weeks. ## Then it did the work, and proved every step The centerpiece was a single 9,859-line file, the kind of thing you keep meaning to break up and never do. Fable took it to 877 lines across eight clean modules. A 91 percent cut to the worst file in the codebase. What sold me was how. No big risky rewrite. It went one slice at a time, six commits, each independently verified with the full test suite green — every run — and zero public API changes. For the trickiest split, where the code clusters were interleaved through the file, it wrote a byte-for-byte reconstruction check across all 119 items before it touched anything, to guarantee nothing was lost or duplicated. It caught its own off-by-one mistakes mid-flight and fixed them. It tracked the work in my issue tracker and committed each verified step. It never once handed me a "done" I had to re-check. ## What was actually different None of these are party tricks on their own. Added up, they are the thing I could not get before: an agent that stays coherent across hours of genuinely hard work, tells the truth about what it did and did not do, argues when I am wrong, and refuses to claim a result it has not verified. That is not a faster autocomplete. It is something I can hand the scary work to and still trust the report at the end. I got more durable work done in one afternoon than in weeks of babysitting other tools, which is the whole reason I am still using it. ## FAQ ### What was the hardest thing it did? It split a single 9,859-line source file into eight cohesive modules, one verified commit at a time, without changing the public API. The trickiest split had interleaved code, so it wrote a byte-for-byte reconstruction check across all 119 items before touching anything. ### Did anything go wrong during the run? Yes. It hit a session limit mid-run and several parallel sub-agents died with half-written, corrupted output. Instead of crashing or pretending, it salvaged the intact data, recovered hundreds of nodes, and told me exactly what it could not recover and why it did not change the conclusion. ### Is any of this specific to one codebase? The codebase was Rust, but the pattern is not language-specific — reason over a knowledge graph, separate real dependencies from noise, verify every step against tests, and keep an honest ledger of coverage.