Habr post describes an AI framework that steers Claude through Clean Architecture and a TDD loop
Habr has published a walkthrough of an AI framework that makes Claude write code through stories, progress files and TDD cycles. The author says that over 3.5 months the approach produced 4,000 commits, 1,500 tests and about 25,000 lines of production code. The key idea: fewer bare prompts, more tests, quality gates and mandatory human review.
AI-processed from Habr AI; edited by Hamidun News
Habr has published a detailed walkthrough of an AI framework that forces an LLM to write code through a strict engineering process rather than free-form "vibe coding." The author claims that almost all of their development now runs through this approach, which relies on Clean Architecture, TDD and mandatory human review.
How the flow works
The approach rests on a simple idea: good software is not a set of files but a set of confirmed behavior scenarios. So work starts not with code generation but with splitting the product into independent stories, each delivering separate user value.
For each story, Claude first goes through a specification stage: it conducts an interview, drafts a description and acceptance criteria, designs the API, builds mockups, and only then compiles a list of test cases. Implementation begins after that.
The author writes that they tested the process in practice over 3.5 months: about 4,000 commits went through it, along with 1,500 tests, roughly 350 e2e checks and about 25,000 lines of production code, not counting the test layer.
The central element of the scheme is the /continue command. It looks at the list of stories and the progress.md file, determines which step development stopped at, and moves the task forward without the user manually choosing the next action.
TDD and gates
The framework does not simply ask the model to "write a feature"; it literally walks it through an ATDD cycle with nested TDD steps. For the backend, this starts with a red acceptance test. Claude then descends to the use case and adapters, turning each level green in stages. The logic is the same for the other parts of the product: verifiable behavior is fixed first, then the code is written, not the other way around. This is how the author tries to tie the model's work to the architecture rather than to random luck.
- interview and formalization of requirements for the story
- generation of a test plan and cases before implementation starts
- red-green-refactor cycle for the use case, adapters and acceptance tests
- quality gates checking test strictness, architecture and coverage
- a commit after each step and a mandatory pause for human review
"You won't get far on bare prompts."
On top of TDD, the author added safety-net quality gates. At the red step, the model separately checks how strict the tests are and that they do not break the test architecture; at the green step, it refactors the code and verifies coverage. Each gate has a checklist the LLM must explicitly work through.
Context management gets particular emphasis: each sub-step runs in a separate agent, and progress.md lets the system reset context after every commit and load only the minimum data needed for the next pass.
Parallel IDE windows
The practical side of this approach matters no less than the architecture itself. A single /continue run can take 5 to 20 minutes, and up to 40 minutes or even an hour on heavy tests. To avoid waiting on one thread, the author advises cloning the demo repository several times, or using worktrees, and running different stories in parallel in separate IDEs. In their own process, up to six windows are open at once: four or five are occupied by agent work, and the rest are used for review, refactoring and tech debt.
For non-standard cases, additional commands sit alongside the main flow. To get started, the author published two repos: a demo Kanban app in Java + React and an empty framework skeleton. /task is for bugfixes, infrastructure and long tasks that do not fit a story with the full TDD ritual. /prompt-update is for improving the framework itself when the model keeps tripping over a recurring problem.
The author openly admits the limitations: the solution grew out of a specific web stack, is tailored to Clean Architecture and ATDD, burns a lot of tokens and does not make development fully autonomous. If a bug is not caught in review, it will ship to production without trouble.
What this means
The approach shows where mature AI development is heading: from one-off prompts to reproducible pipelines in which the model works inside the process, not in place of it. The main takeaway is fairly blunt: an LLM can already speed up production development, but only if it is kept within tests, checklists, short steps and constant human oversight.
- Nov 2, 2026Bun creator uses Claude Code to port 750K lines from Zig to Rust in 11 days
- Nov 2, 2026mcp-linter finds 18 undescribed parameters in Anthropic's filesystem server
- Nov 2, 2026The Verge reviewer builds a $50 Meta Muse Charm alternative with Claude Code
- Nov 2, 20268 Skills for video in Claude Code: from 244 pixel effects to rough-cut editing
Key Questions Answered
How the flow works?
The approach rests on a simple idea: good software is not a set of files but a set of confirmed behavior scenarios. So work starts not with code generation but with splitting the product into independent stories, each delivering separate user value. For each story, Claude first goes through a specification stage: it conducts an interview, drafts a description and acceptance criteria, designs the API, builds mockups, and only then compiles a list of test cases. Implementation begins after that. The author writes that they tested the process in practice over 3.5 months: about
What are the key details on TDD and gates?
The framework does not simply ask the model to "write a feature"; it literally walks it through an ATDD cycle with nested TDD steps. For the backend, this starts with a red acceptance test. Claude then descends to the use case and adapters, turning each level green in stages. The logic is the same for the other parts of the product: verifiable behavior is fixed first, then the code is written, not the other way around. This is how the author tries to tie the model's work to the architecture rather than to random luck. interview and formalization of requirements for the stor
What are the key details on Parallel IDE windows?
The practical side of this approach matters no less than the architecture itself. A single /continue run can take 5 to 20 minutes, and up to 40 minutes or even an hour on heavy tests. To avoid waiting on one thread, the author advises cloning the demo repository several times, or using worktrees, and running different stories in parallel in separate IDEs. In their own process, up to six windows are open at once: four or five are occupied by agent work, and the rest are used for review, refactoring and tech debt. For non-standard cases, additional commands sit alongside the
Test Frontier LLMs & Autonomous Agents in One Workspace
Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.
The AI world, distilled — once a week
Seven stories that actually mattered, hand-picked. No noise, no reposts, no press releases.
Done! Check your inbox for a confirmation.