Wanleung's Workshop

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...

An Arduino project that enables ESP32-C3 to act as a display driver for lcd4linux daemon using an I2C OLED 128x32 display (SSD1306).