In short: A coding rule from a 1990s university computer science class — where the hard constraint was the size of a CRT screen — turned out to be one of the most practical pieces of advice I’ve ever...

Standard mode and TDD mode cover most use cases, but sometimes you want a custom sequence — run two review loops in a row, skip deployment tests, or run a domain-specific agent you added yourself. This post covers pipeline.yaml: a separate config file that lets you define any stage sequence with explicit loop blocks, and a drag-and-drop GUI that builds it without hand-editing YAML.

The standard pipeline writes code first, then tests. This post covers a TDD mode that flips the order: QA writes tests before the engineers see the problem, then engineers implement against those tests, then a fix loop runs until the suite is green. It also covers how this forced a proper stage registry — replacing hardcoded stage sequences with a configurable system.

The original pipeline was hardwired to GitHub Models. This post covers how I extracted every LLM backend into its own class with a shared interface, added a relay that automatically falls back to the next backend on connection failure, and what I learned about building resilient AI infrastructure around unreliable upstream APIs.

Seven posts of technical depth, but what does it all mean? This closing post steps back to reflect on the lessons learned, how this project vindicates what Builder.ai was attempting, where the remaining hard problems are, and what I’m building next.

The first draft is never the best draft — not for requirements, not for system designs. This post covers how the pipeline runs structured review-and-revise loops before any code is written: the PM rewrites the requirements based on critique, the Architect rewrites the design based on critique, up to three times each. Better inputs at the top produce dramatically better code at the bottom.

Agents that can only read what you put in their prompt are flying blind. This post covers how agents get access to external tools — searching the web, querying GitHub, reading the codebase — and how the system automatically switches strategy based on repo size: smaller projects get the full code in the prompt, larger ones use semantic search to find what’s relevant.

A one-way pipeline that can’t respond to feedback is just a code generator. This post covers two features that make the system a real collaborator: a feedback loop where review comments on a pull request trigger automatic code revisions, and a Q&A mechanism where the AI pauses mid-run to ask clarifying questions before building the wrong thing.

Without memory, every pipeline run starts from scratch — the agents forget what frameworks you chose last week, what they built last month, what the reviewer rejected last time. This post covers a three-tier memory system: per-run context, a searchable history of past projects, and a living knowledge base kept inside each target repo.

A pipeline that crashes halfway through loses all the AI work done so far. This post explains how the system saves progress after every stage so a failed run can resume exactly where it left off — never repeating work. It also covers how to route different projects to different GitHub repos from a single pipeline.

The pipeline has six core roles — Product Manager, Architect, Engineers (running in parallel), Code Reviewer, and QA Engineer. Each role hands a structured output to the next. The quality of those handoffs matters more than any individual agent. A vague requirement produces a vague design, which produces broken code. Getting the handoffs right is the whole game.

Instead of building a new database or custom framework to run the AI team, I used GitHub itself — issues, branches, pull requests, and Actions — as the backbone. Agent behaviour lives in plain markdown files, not code, so anyone can read and change it. This design means adding a new agent takes minutes, not days.

Introduction post in the AI Software House series.I spent three and a half years at Builder.ai believing in an idea: that software development could be industrialised. That you could describe an app...