Who does what, and how a single automatic development attempt (a “run”) unfolds — in two diagrams.
01The cast and their roles
AuteDev runs on four layers. The local LLMs at the bottom build the apps. Claude Code grows the system that makes them (the framework), and a human sets the direction.
👤 Human the owner
Says what app to build (e.g. “Make me an Invaders game”)
Judges only the finished app (the final output), and gives a quick instruction if a feature is missing. Honestly, never even looked at the app spec
Decides AuteDev's goals, policy and spec changes (when Claude Code asks; e.g. “3 PASSes in a row on INVADERS”, “no app-specific logic in the framework”)
🛠 Claude Code develops the framework (ChatGPT did too, earlier)
① Writes the spec for AuteDev from the human's request
② Starts and monitors AuteDev, then analyzes the logs to find why it failed
③ Fixes AuteDev itself: write the tests first → bump the version → release gate (1,200+ tests) → deploy AuteDev → back to ② until app generation succeeds reproducibly
④ Writes handoff notes in case the Claude Code session gets cut off
spec · start · fix ↓↓↑↑ run results · logs
⚙️ AuteDev an automatic development workflow built on LangGraph
It takes a spec and hands out work to the agents below, in order. When an agent gets stuck, it automatically swaps in a different model. At the end of a run, it also writes a user guide to go with the finished app.
Leaderrequirements, design, test plan Qwen3.8-Flash-Next (Strata)if stuck → Qwen3.8-27B → Gemma-4-26B-A4B-it → gpt-oss-120b
Reviewerchecks that the design and tests really mean what the spec says Gemma-4-26B-A4B-it / Qwen3.8-27B
Test writerwrites and rewrites the test code that decides pass or fail Gemma-4-26B-A4B-it / Qwen3.8-27B
App buildersbuild and fix two separate copies of the app with an off-the-shelf agent (OpenHands) Qwen3.8-Flash-Next (Strata) + Qwen3.8-27B
Since Oct 1, a new approach ("Plan B"; the story is in section 02 below): an off-the-shelf agent builds the app, and AuteDev focuses on analyzing the spec, the API contract, the tests and verification. Since Oct 2, Qwen3.8-Flash-Next runs on Strata, and Qwen3.8-27B builds the second copy at the same time. When both copies fail the same test, the leader is asked to define whatever the spec left open.
prompts ↓↓↑↑ answers (JSON · code)
🖥 Local LLMs running on my home PC with llama.cpp (llama-server) and Strata
As a rule, one model at a time is loaded across five GPUs and swapped whenever the role changes. Only during app building do Strata (1 GPU) and Qwen3.8-27B (2 GPUs) run side by side. No cloud AI is used.
RTX 5070 Ti 16GBRTX 5060 Ti 16GBRTX 5060 Ti 16GBRTX 5060 Ti 16GBRTX 5060 Ti 16GB= 80GB VRAM
02The flow of one run
Until September, AuteDev did everything through its own steps: analyzing the spec, coding, testing and fixing ("Plan A", in the collapsed section below). But on INVADERS, about 40 runs produced zero PASSes. Most of them stopped not because of the finished app, but because of things AuteDev produced for itself along the way, such as bugs in its own tests.
So on Sep 30 – Oct 1 we ran a comparison: an off-the-shelf coding agent was handed AuteDev's spec and API contract (the blueprint) and asked to build the app. In 16–27 minutes it produced an app about as good as the one AuteDev itself had taken about 3 hours to build. Without the blueprint, it took longer and the results were unstable. In other words, AuteDev's strength isn't the building; it's analyzing the spec, designing and verifying.
Based on that, the approach changed on Oct 1. We call it "Plan B". AuteDev focuses on analyzing the spec, the design (the API contract), writing the acceptance tests and checking the results, while the app itself is built twice, separately, by an off-the-shelf coding agent (OpenHands). If the better of the two passes every acceptance test, it's a PASS.
The key is what happens when a test fails on both copies. If two apps built independently trip over the same thing, the problem may be the test or the spec rather than the app. So AuteDev doesn't rush to fix the test. It first asks the leader: "please define X."
Check the design for gaps and evidenceContract Gate + evidence audit
freeze the design
Plan and write the acceptance testsTest plan → Acceptance testsTest writer
Static and meaning checks on the testsquality gate + semantic auditReviewer
tests fixed (hidden from the builders)
Build app Aagent build A (OpenHands)Qwen3.8-Flash-Next (Strata, 1 GPU)
Build app Bagent build B (OpenHands)Qwen3.8-27B (2 GPUs)
Both are built at the same time, from the spec and the API contract only (30-minute limit)
Run the acceptance tests on both appsAcceptance on both builds → cross-check
all passed
🎉 PASS
fails on one only
A bug in the app → fixed in fix roundsimplementation failure → fix rounds
fails on both
The test or the spec may be wrongsuspect
for tests that failed on both
Definition request: "please define X"contract clarificationthe leader decides each one
The spec was missing something → define the valuedefine (+ setup operation)
The apps were wrong after allimplementation bug (SPEC quote)
The test was wrongtest defect (SPEC quote)
Review the answers (sent back once if flagged)clarification auditReviewer
Rewrite only the tests that need it → reviewregenerate → auditTest writer + Reviewer
Apply the definitions to both apps and re-scorerecheck both builds
Up to 3 rounds of definition requests. Still failing → NOT PASS, and a different model analyzes the cause and leaves "notes for the next run"
at the end of the run
📦 Output: the app files + 📘 user guideproject files + USAGE_GUIDE.md
* A definition may add an operation to the API contract that directly sets, say, "how many invaders are left" or "how many lives remain". That lets tests create scenes like winning or game over, which normal play only reaches after a long time. Only causes (counts, positions and so on) can be set, never the outcome itself, like "game over"; moving into the outcome is left to the normal operations. From v188 on Oct 2, such operations are prepared at the first design step.
* If half or more of all tests fail on both apps, the suspect is the tests' scaffolding (setup or cleanup), not the apps.
The flow up to September (Plan A: when AuteDev's own worker wrote the code)
Match code against designImplementation Contract Gate
Run the testsQuality: Public + Acceptance tests
all passed
🎉 PASS
failures
Diagnose the causeDiagnose (Public / Acceptance)
A bug in the testsfixture / test bug
Safely repair or regenerate the teststest repair / regenerate
A gap in the designcontract gap
Review the designcontract reconcile / review
A bug in the codeimplementation bug
Fix the codecode repair (coding)
Verify again → continue if it made progressre-validate → validated progress?
Repeats the same failure → switch to another model. Still no progress → the run ends (NOT PASS)
at the end of the run
📦 Output: the app files + 📘 user guideproject files + USAGE_GUIDE.md
The user guide is written by a program, not an LLM: it states only what can be verified from the spec, the design and the generated code (the launch command comes from the real code, so “I did what it says and it didn't start” is unlikely).
* The real workflow has more than 20 steps, including test-plan audits, harness recovery and scope checks. The diagram shows only the main path.
03After a run
If it's NOT PASS, Claude Code analyzes the logs and the "notes for the next run". Then it fixes the framework in a general way — never with a fix tailored to one specific app — bumps the version, and starts the next run. At milestones, Claude Fable is asked for a review too. Thanks to this loop, the version number has passed 180. Each app also gets its own app ID, recording which runs built it.
The results are updated day by day in the dev log.