پن کیا گیا ٹویٹ
I have ran Fable 5 with the following environment variables:
CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1
CLAUDE_CODE_EFFORT_LEVEL=max
CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=0
I have then instructed it to use workflows to generate a fine-grained planning against my entirely hand-written goal description.
the runtime of this workflow has cost me more than 60% of my weekly usage in my claude 20x subscription.
The result is fairly crazy, as you can just let dumber settings take over and finish the tasks.
here is the review of such a phase by Fable 5 with xhigh with adaptive thinking a couple phases / sessions in:
———————————————————
TL;DR:
This project's planning is unusually rigorous — conflicts between design docs resolved in a binding table before coding, tests specified as proofs ("show it red first"), and every increment contractually ending in a deployable state. The key insight: this isn't over-engineering, it's the correct response to AI execution. Stateless AI sessions have no senior engineer's implicit memory, so the plan serves as externalized working memory. Empirically validated today: ~1,100 lines (migration, security gates, live deploy) built in one session with zero structural surprises, and a mid-feature pause that cost nothing. Trade-off: the upfront planning only pays off because the target is well-defined.
———————————————————
An assessment of this project's planning depth — from the AI that builds against it
The planning here is unusual, and I mean that as a measurable observation, not a compliment. A few properties stand out that ordinary industry practice doesn't have:
1. Cross-document conflict resolution before any code exists.
The project was designed in six separate design documents, each independently reviewed from three adversarial perspectives. Before construction started, every contradiction between those documents — colliding database migration numbers, the same code deletion planned in two places, a package name that would shadow a variable name — was resolved in a binding conflict table. In a typical team, these collisions are discovered as merge conflicts, mid-build. Here, when I hit a point today where the design document and the master plan disagreed, the conflict had already been adjudicated months of decisions ago, with a documented rationale.
2. Tests are planned as proofs, not as coverage.
The plan doesn't say "write tests for the security gate." It says: build a fake backend with a hit counter, prove the counter stays at zero, and first demonstrate the test fails when the gate is removed. Red before green is specified at planning time. That's the difference between "tests exist" and "the test demonstrably catches the leak it claims to catch."
3. Every work unit ends in a stable state — by contract, not by luck.
The plan enforces an invariant: each increment ends committed, tested, and deployable, holding indefinitely, never requiring the next increment to exist. This paid off literally today: the project owner paused the session mid-feature for external reasons. Nothing needed cleanup — green build, documented re-entry point, done.
4. Decisions carry their sources.
Every product decision is recorded with the owner's verbatim words attached. That cleanly separates policy (the human's) from mechanism (the code's), and prevents a failure mode specific to AI-assisted work: an assistant's interpretation slowly mutating into a "user requirement" over successive sessions.
The honest framing of why this depth exists:
you can find comparable rigor in industry — Google-style design docs, RFD cultures — but typically backed by staff engineers and quarter-long horizons. This is a solo project executed by AI sessions. And that's precisely the point: the depth isn't over-engineering, it's the correct response to the execution context. In human teams, senior engineers' implicit knowledge carries consistency across months. AI sessions have no such memory — each one starts blank. The master plan functions as externalized working memory that forces every stateless executor onto the same build-truth.
Today was a clean empirical test:
a ~1,100-line increment — a database migration, a trust/permission matrix, security validation, live deployment — went through in one session with zero structural surprises. Everything unexpected was detail-level (an ordering bug in a log message, a struct that lost comparability). The architecture held exactly as planned.
The counter-ledger, because it belongs in any honest assessment:
the upfront planning itself cost sessions, and it only amortizes because the target is well-defined — for an exploratory project this would be wasted effort. And design documents drift from as-built reality over time; the project knows this, mitigates it ("gates verify artifacts, never document numbers"), but the entropy is real.
In short:
ordinary good practice is "a design doc per feature, two reviewers." This is a planning discipline that treats the memoryless executor as a first-class constraint — and it's working, verifiably.
The planning:
x.com/iGottZ/status/…
Jan-Stefan Janetzky@iGottZ
man.. just this planning alone is on a different level than opus.. (fable 5 on max thinking btw)
English
