We keep debating AGI in the abstract. Meanwhile, something concrete already arrived for engineers. With Anthropic’s Fable, the model now generalizes across the entire development lifecycle — architecture, implementation, review, operations — not narrow autocomplete on a single file. I call it Developer General Intelligence (DGI): AGI’s practical cousin for the way we actually build.
“AI writes code” undersells what changed. A frontier model that can hold the whole lifecycle at once — reason about a system’s architecture, implement against a contract, review its own work adversarially, and operate the result — is a categorically different collaborator than an autocomplete engine. That generality is the story.
I’ve spent the last year building this way full-time. The pattern that emerged is not “prompt for code, faster.” It’s the opposite.
Here’s the part I’m most excited about. I embedded a multi-model LLM council directly into the architecture view. Click any component in the system — the agent fleet, the async queue, the memory layer, the control plane — and put it to a council of four frontier models (Claude, OpenAI, Gemini, Grok):
“Why this design choice over the obvious alternative?”
“What breaks at scale, and what’s the mitigation?”
Claude synthesizes; each of the others lands its own take in adversarial parallel. And here’s what makes it more than a chat widget: their critique feeds the design decisions that get recorded and locked into the spec underneath the diagram. The architecture stops being a static picture you draw once and hope — it becomes a living artifact you interrogate, and the spec crystallizes beneath it.
This is a discipline, not a slogan. The architecture is designed, reviewed, and locked as a deliverable — then the code is generated one-shot against it.
The code is a one-shot compile of a reviewed, locked spec — not the artifact you iterate blind.
Design mistakes surface in the spec, not buried in ten thousand lines you’ve already written.
Four independent model families. The default Claude reaches for is exactly what Grok or Gemini pushes back on.
Every decision maps to a requirement and a rationale before a line of product code exists.
The architecture doc is a git-versioned project of its own, and it’s finished — reviewed and locked — before the code project is created.
1 Ingest the requirements verbatim (JD / PRD / brief)
2 Iterate the design in conversation — record every decision
3 Draw the system; validate traceability against every requirement line
4 Run the LLM council + an AI-partner review on the architecture
5 Lock the spec: final decisions + a phased build plan + a deployment
playbook with concrete values, so the build never stops to ask
6 ONLY NOW create the code project
7 Build one shot against the locked contract; keep a build log
8 The council ships embedded in the product — every design choice stays interrogableArchitecture-as-the-Product · the replay sequence
The system in these captures is a personal AI scaled from one user to a billion — a seven-layer topology with a desired-state control plane that autoscales each tier out and in. Every node is interrogable by the council. It’s the architecture teaching — and stress-testing — itself.
The fleet holds no per-user state — it pulls a per-turn context pack from shared stores, so scaling is more replicas, not a redesign. A desired-state control plane reconciles the fleet out and in.
Online eval/guard on the response path; token accounting, traces, and audit underneath. The demo makes the invisible infrastructure visible — which is the whole point of teaching an architecture.
A single model is an echo chamber — it agrees with its own defaults. The council runs Claude, OpenAI, Gemini, and Grok in parallel as adversarial reviewers; Claude synthesizes their takes. Safety and observability live in the pattern, not bolted on:
Names, emails, phones, DOB are stripped before any model call — the risk profile is discussed, never the person.
Every answer carries a "what was sent" trace and a "no PII present" shield you can inspect.
A live per-answer cost estimate — governance you can see, on every turn.
You architect out loud. A council of models pressure-tests the design live. The spec writes itself underneath. The code follows from a contract that was already reviewed. The hard part was never the code — it was the thinking, and DGI now generalizes across the whole of it.
When the model can hold the entire lifecycle, the bottleneck moves from “can we build it?” to “did we design the right thing?” — which is precisely where a council of adversarial reviewers earns its keep.
For engineering leaders: DGI changes the unit of leverage from lines-of-code to decisions-per-spec. The teams that win won’t be the ones generating code fastest — they’ll be the ones whose architecture is designed, adversarially reviewed, and locked before implementation, so the build is a compile and the review already happened. This is the first in a series on DGI.