How I write software with LLMs

TL;DR Highlight

A developer who's been building and maintaining real projects with tens of thousands of lines using LLMs shares a concrete workflow — an Architect->Developer->Reviewer pipeline — along with actual sessions, covering how to keep defect rates low and maintain system understanding.

Who Should Read

Developers actively using or starting to use LLMs for real projects, especially those who've experienced AI-generated code turning into a mess a few days later.

Core Mechanics

The Architect->Developer->Reviewer three-role pipeline divides the LLM's responsibilities: Architect designs the high-level structure, Developer implements, and Reviewer checks quality. Using different context or prompts for each role reduces cross-contamination.
Keeping a 'living document' — a continuously updated spec that reflects the current system state — is the most important practice. Rather than re-explaining the system to the LLM each session, you maintain this document and feed it as context.
The author recommends small, incremental commits rather than large feature drops. This is both for debugging ease and for training the LLM to work in manageable chunks.
The Reviewer role is key to defect reduction. Having the LLM check its own output — especially for edge cases and error handling — catches surprisingly many bugs.
When the LLM shows confidence issues or starts repeating suggestions, that's a signal to end the session and start fresh. Continuing a degraded session compounds errors.

Evidence

The author shared actual session transcripts demonstrating the Architect->Developer->Reviewer flow, with concrete examples showing where the pattern catches bugs.
Commenters who tried similar workflows reported that the biggest improvement was the living document practice — without it, LLMs often 'forget' earlier design decisions and make inconsistent choices.
Several developers noted that the three-role split is essentially applying software engineering's separation of concerns principle to AI-assisted development, and it works for the same reasons.
There was discussion about whether this approach scales — some argued it works well up to ~10K lines but needs different strategies beyond that.

How to Apply

Maintain a SPEC.md or ARCHITECTURE.md that's always up to date with the current state. Start every LLM session by feeding this document as context.
When starting a new feature, first use the Architect prompt to get the high-level design, then switch to Developer mode for implementation. Don't mix the two in the same conversation.
After implementation, run a dedicated Reviewer prompt: 'Review the code just written for edge cases, error handling, and security issues.' Treat this as a standard step, not optional.
When the LLM starts going in circles or producing inconsistent suggestions, stop the session, commit what you have, and start a new session with fresh context.

Terminology

Architect->Developer->Reviewer PipelineA workflow that separates LLM responsibilities into design, implementation, and review phases to reduce errors and maintain system coherence.

Living DocumentA continuously updated spec document that always reflects the current system state, used as persistent context across LLM sessions.

Defect RateThe proportion of generated code that contains bugs or issues, used as a quality metric for LLM-assisted development.