The Idea Was Right, The Timing Wasn’t — Why I Built ai-dev-team
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 in plain English and a system — part AI, part process, part tooling — would build it.
Builder.ai had that vision. Their pitch was making software development “as simple as ordering a pizza” — an AI assistant named Natasha would guide you from idea to app, handling the entire software lifecycle. And it worked, to a point. But the reality was a human-AI hybrid: a large team of engineers filling the gaps left by the AI — fixing code that was partially unusable, patching integration failures, and sometimes rewriting entire modules from scratch, with AI handling project management and scoping. It required a lot of human developers to patch, fix, and guide what the platform produced. The process was sound. The AI wasn’t there yet.
In March 2025, Builder.ai went through a large redundancy round. In May 2025, it went bankrupt.
I keep thinking about this: if they had lasted six more months, the story might have been completely different.
Where the idea came from — and why I believed in it
Before Builder.ai, I ran my own company — Linkomnia Limited — for ten years. We built cloud infrastructure, mobile apps, and IoT integrations. We also built Centipede, a low-latency massively multiplayer mobile gaming platform. I spent a decade taking client requirements and turning them into working software, over and over again.
That experience taught me something: most software projects follow the same pattern. Someone has a requirement. An architect breaks it into modules. Engineers implement the modules. Someone reviews the code. Someone writes the tests. Most of the variation is in the domain — the underlying process is almost always the same.
When I joined Builder.ai in 2021, I recognised immediately what they were trying to do. They were trying to encode that process. I’d been thinking about the same thing from the other side — as the person delivering the output. Their core insight was right.
The problem was timing. The AI models in 2021 and 2022 could scaffold, but they couldn’t reason. They could produce code that looked plausible but fell apart on integration. Every generated output needed a developer to review it seriously — often to rewrite it. The human-to-AI ratio was too high to make the economics work.
The gap that felt like opportunity
When I left Builder.ai, I joined VoidBridge Software Ltd as a team lead. But the idea didn’t leave me.
By late 2024, something had shifted. The models were genuinely different. GPT-4.1 wasn’t just better at code — it was better at following structured processes, at producing outputs in consistent formats, at reasoning about what it had built. The problem that had made Builder.ai’s approach uneconomical — the need for constant human intervention to fix hallucinations and integration failures — seemed solvable in a way it hadn’t been before.
So I started building. Not to recreate Builder.ai, but to test whether the original vision was achievable with the models available now.
What I built
The project is called ai-dev-team. It’s a team of AI agents that builds software from a plain-English requirement:
A Product Manager turns the requirement into a structured PRD
An Architect designs the system and breaks it into modules
Multiple Engineers implement the code in parallel
A Code Reviewer checks the output
A QA Engineer writes and runs tests
A Deployment Tester verifies the service comes up correctly
All of it runs on the GitHub Models API — the same AI backbone that powers GitHub Copilot — using the same GITHUB_TOKEN you already have. No separate bills. No new vendor relationships. Everything lands in GitHub: issues, branches, pull requests, review comments.
This series of posts is about how I built it, the decisions I made, what broke, and what works. Each post goes deep on one aspect of the system.
What Builder.ai taught me
Working at Builder.ai gave me a very specific education in where automated software development breaks down:
Ambiguity kills pipelines. Vague requirements produce confident but wrong code. You need a structured PM stage that extracts acceptance criteria before a line of code is written.
Single-pass reviews aren’t enough. An AI-generated design reviewed once by another AI isn’t quality control — it’s theatre. You need iterative feedback loops where the original author rewrites based on specific critique.
Humans should direct, not babysit. The worst-case scenario is a system that requires constant supervision to produce anything. The goal is a system where humans review outputs and give feedback — not where they fix every third line.
The process is the product. What makes the difference isn’t model capability alone — it’s the structure of how models are orchestrated. A well-designed pipeline with a slightly weaker model beats a poorly designed pipeline with a stronger one.
These lessons shaped every design decision in this project.
The timing was right
Builder.ai was not wrong. It was early.
The models available in 2021-2022 required too much human scaffolding to make the economics work at scale. By 2024-2025, that ratio had inverted. The same structured process that required five developers to oversee now runs with one — to review the pull request before merging.
I built this project to prove that the original vision works. Not as a startup, not as a product — as a technical proof of concept that I’m using in my own work, that you can use in yours.
The rest of this series explains how.
The series
The Architecture: Why GitHub Is the Best Backbone for an AI Dev Team
Never Lose Work Again: Checkpoints, Resume, and Multi-Repo Routing
Closing the Loop: PR Feedback, Human Review, and Clarification Q&A
Iterating Toward Quality: Revision Loops for PM and Architect