The short version
David Tielke, a software architect who describes himself as addicted to quality, rebuilt his company's business application with AI agents: 420,000 lines of .NET microservices and about 200 n8n workflows, solo, in 45 working days, for roughly $25k. Two of his client teams estimated the same scope at around 19 person-years, about $2M.
The useful part of the talk is not the speed claim. It's his "harness" method: architecture and design guidelines fed to the agent as a system prompt, with static analysis run as a hard quality gate after every generation step, so he reviews the harness instead of the code.
The experiment
Tielke went in as a skeptic. His stated goal was to find AI's limits fast, because his clients were vibe coding replacements for ERP systems with no software background, and he wanted to stop that. So he set enterprise constraints on purpose: .NET microservices behind a Traefik API gateway, Blazor and React frontends, n8n as the workflow engine, a local Qwen model on AMD hardware acting as the brain of an office-work agent, plus full test and production environments with CI on self-hosted Gitea. This was his real accounting, invoicing and booking system, rebuilt from scratch over 4.5 months of night work.
The method, in four phases
Micromanagement
Prompt, generate, review every line. The way most of us work today. It doesn't scale.
Quality-driven
He wrote his architecture and design guidelines into the agent's system prompt, then ran ReSharper and NDepend (880 structural rules) as a quality gate after every generation step. The key move: when output was wrong, he didn't fix the code, he fixed the harness so the mistake couldn't recur. After this phase he says he essentially stopped reading generated code.
Spec-driven and test-driven
One spec document per feature as the single source of truth; the agent derives its prompts from it. Tests are generated only from the spec's acceptance criteria, never from the code, so they verify the requirement rather than the implementation.
Idea and voice-driven
A nightly regenerated system prompt of about 440 pages describing the whole app, loaded into Claude on his phone. He designed his largest module during a 4.5-hour voice conversation while driving to Vienna. Claude pushed back with references to existing modules and German tax law, then produced the idea file that became the spec.
The numbers
- Effort: 45 working days solo, versus roughly 19 person-years (the average of estimates from two of his client teams, from Claude and Codex, and from his own three-day estimation exercise).
- Cost: about $25k all in. He burned 22 billion tokens, which would be $21k at Anthropic API rates but cost him about $1,600 through two Claude Max subscriptions.
- Quality: 85% test coverage, 0% technical and structural debt (everything gated by the 880 NDepend rules), documentation regenerated nightly. His client teams' comparable projects average around 30% debt, 33% documentation (mostly stale) and 60% coverage.
The caveats he names himself
Greenfield only; brownfield needs a different approach. He's a very experienced architect who already knew the domain and the requirements. And he tells the audience to ignore the "93x faster" headline the German press ran with: in his words, it doesn't matter whether it's 39x or 25x, it's way faster, and the quality is outstanding if you do it the right way.
What's worth stealing
The claim worth debating in our channel: code review doesn't scale with AI output volume, but harness review does. Tielke stopped inspecting output and invested in the machinery that constrains output instead. Guidelines live in the system prompt, static analysis acts as the gate, specs are the source of truth. His closing advice on where developers should invest their skills: specification writing, architecture, DevOps, testing, and harness building.
Join the discussion
I'm no expert on testing methodologies, but I expect some tests are easier to generate (unit tests), some much harder (end-to-end), and some close to impossible when you don't have access to every component of the production environment. So a question for the more experienced test automation engineers here: what mix of test types, and what level of coverage, would be enough to fully trust AI-generated code? And one more attribute that's hard to measure: how maintainable will this code still be after 6 months, or 3 years, of changes made by AI agents?