SaaS developer uses AI agents to build 13K-line prototype in 2 weeks

The developer is not an engineer but ran an agentic development experiment on a legacy SaaS codebase: 1M+ lines, 15 years old, written primarily in C# and React, and hosted on Azure. The goal was to build an MVP prototype for customer testing in September using AI agents, because no developers were available full-time.

The planning phase began with customer interviews in June, which fed into an MVP spec. The process was structured in four steps: (1) a PRD was written; (2) an LLM converted the PRD into an architecture document, which was reviewed by an architect; (3) product designs were created as screen images and markdown files with Claude Design, detailing interactions and edge cases; (4) an agent broke the work into epics using the PRD and architecture document as guardrails. The epics were the most granular planning artifacts to receive human review.

The development workflow was designed to run with minimal intervention. A planner agent converted epics into markdown story files and Jira stories. A coding agent then implemented each story, including tests, and opened pull requests. A reviewer agent reviewed the PRs, requested changes, and merged them. The coding agent could poll PRs for review comments and escalate issues to the planner. Both agents had a "stop and ask" list—decisions they were not allowed to make autonomously—and the developer (and occasionally an engineer) resolved these escalations. The developer also manually tested accumulated changes end-to-end each day. Most work used Claude-based agents; for riskier PRs, the developer also used Codex as a reviewer. Codex found substantially more relevant issues in the Claude-generated code, but token quotas limited its use. The developer also ran separate refactoring and hardening passes.

The results were brisk: planning and environment setup took about two weeks, and the agents then built the entire MVP in about two weeks. The output was 13k lines of functional code plus the same amount for tests. Now the developer is seeking community advice on how to further harden the code before an engineer reviews it in August to decide whether the AI-generated code is close enough to production-grade that the path forward is "copy-paste" rather than a full rebuild. The developer's specific questions are: which checks or development loops would give the largest improvement in confidence; how to use independent agents or models to reduce the risk that the coder and reviewer make the same incorrect assumptions; whether tests should be generated by a separate agent from the coder; what documentation would make the engineering review faster and more reliable; and, given only a few weeks, what to prioritize.

The experiment reflects a pragmatic response to resource constraints—using AI agents to offset the unavailability of full-time developers. The developer structured the agentic workflow to include multiple checkpoints: agents received a "stop and ask" list of decisions they could not make autonomously, the developer and an engineer manually tested accumulated changes end-to-end each day, and the architecture and epics (the most granular planning artifacts) received human review. This human-in-the-loop design suggests the developer understood the risks of fully autonomous AI code generation.

The use of two models (Claude and Codex) for review is particularly telling. The developer discovered that Codex found substantially more relevant issues than Claude in the same code—implying that a single model's code and review can have correlated blind spots. This finding underpins several of the developer's own questions, especially whether tests should be generated by a separate agent and whether independent agents can reduce the risk of shared incorrect assumptions. The core challenge is that the August engineering review will be the ground truth: the code either is robust enough to ship with minimal rework, or it is not.

No comments yet. Be the first to share your thoughts!