Most conversations about AI in software development focus on the tools: which model writes the cleanest code, which IDE has the best autocomplete. But at Cube5, the real competitive advantage isn’t the tools. It’s the process.
In the second of two episodes, Cube5 AI co-founder Greger Ottosson is joined by Jean-Baptiste Renault, the company’s tech lead, to walk through exactly how they take a customer requirement all the way to shipped code, and what it means to run a five-person team with the output of twenty-five.
The factory model
Part one covered the “top half”: capturing customer conversations, transcribing meetings, and converting discussions into requirements and epics. Part two picks up where English starts giving way to code.
Once an epic is drafted and reviewed (by both humans and what Greger calls a “product manager agent”), JB’s job is to break it down. That starts with a spike: a research document that looks outward at how others have solved the problem, then inward at the existing codebase, before settling on an architecture. The spike isn’t written by AI or by JB alone. It’s a back-and-forth: AI generates, JB challenges, AI responds. Sometimes the AI is the critic. Sometimes JB is. The goal is the best version of the document in the least amount of time.
From there, a technical spec gets built block by block, with checkpoints at every stage, because an error in the first block tends to ripple through everything that follows. Then comes an implementation plan, phase-by-phase execution, and a log that captures what was actually done. If something breaks, there’s a clear record of where the deviation happened.
The team practices test-driven development: the AI writes failing tests first, then implements against them. It’s not perfect, but passing tests give JB enough confidence to move forward without reading every line of generated code. He focuses his attention on the parts most likely to go wrong: either because they’re objectively complex, or because they’re the kind of thing LLMs consistently struggle with.
Where AI still falls short
That second category is worth naming: spatial reasoning. Getting a UI element into exactly the right position on screen remains stubborn work. As Greger put it, “they’re language models, not spatial models, not real-world models.” Anyone who’s tried vibe-coding a polished interface has run into this: the first 80% comes quickly, and the last 20% takes longer than everything before it.
The less obvious limitation is knowledge management. At Cube5, every project runs against a “constitution”: a document that defines design patterns, libraries, and rules that the AI coding assistant reads at the start of every session. The challenge is keeping that constitution current. In a fast-moving environment, a document from three months ago can already be misleading. JB’s rule: it’s better to delete outdated documentation than to leave it in place. An AI agent treats outdated docs with the same weight as current ones — if it’s written down, it assumes it’s right.
The same logic applies beyond software. In any domain where AI is helping you build or create, the quality of your context files matters as much as the quality of your prompts.
What 5x actually costs
JB estimates that the Cube5 team today outputs what would have taken twenty-five people two years ago. But he’s careful about what that number includes. Getting a working prototype is more like 20x faster. Getting to production-quality software with proper architecture, test coverage, and documented decisions is closer to five.
The other cost is cognitive. Moving at AI speed means making a lot of decisions in a very short period of time. Decision fatigue is real. Greger compares it to grading essays: you can do fifty with full attention. Give someone two hundred fifty and they start cutting corners. The process Cube5 has built addresses both: the AI’s tendency to drift and the human reviewer’s limited attention.
The software factory isn’t just a metaphor. It’s a way of managing human attention at machine speed.