I Wrote 3,000 Lines of Prompts So AI Could Ship Production Code

The Problem With AI Coding Tools

Every week, there’s a new AI coding tool that promises to revolutionise software development. Every week, developers try it, are amazed by the demos, and then run into the same wall: the tool produces impressive code in isolation but falls apart on real production systems.

The problem isn’t the models. It’s the prompts.

Most AI coding tools ship with a thin system prompt that says, basically, “you are a helpful coding assistant.” The model has no concept of your codebase’s conventions, your security requirements, your testing philosophy, or your deployment pipeline. It’s a brilliant developer dropped into your project with no context and told to start coding.

The results are predictable: impressive prototypes, fragile production code.

The Solution: Systematic Prompt Architecture

Instead of writing better one-off prompts, I wrote a complete prompt architecture: a system of 17 specialized agents, each with its own role, reasoning protocol, temperature setting, security mandates, and output format. Together, they form a complete software development methodology called SPARC (Strategic Project Assistant & Recursive Coder).

The SPARC framework is defined in 3,000+ lines of YAML — not code, but prompts. Every line is an instruction that shapes how the AI behaves: when to ask questions, when to make assumptions, when to write tests, when to refuse a request that introduces a security vulnerability.

How Prompt Architecture Actually Works

Traditional prompting is horizontal: you write one prompt that tries to do everything — understand the problem, design the solution, write the code, review it, test it. The model has to switch between these modes on its own, and it does a bad job of it.

SPARC is vertical: a pipeline of specialized agents, each responsible for one phase of development.

Example: The ‘code’ Agent

Here’s a simplified version of how the code agent is instructed:

You are the CODE agent. Your role is to implement code that
matches the specification exactly. Do not add features that
weren't requested. Do not refactor code outside the scope of
the task. 

Before writing any code:
1. Read the relevant existing files to understand patterns
2. Check for existing tests that define expected behaviour
3. Verify your implementation matches the spec

When writing code:
- Follow the project's existing conventions
- Write tests before implementation (TDD)
- Include error handling for edge cases
- Never introduce breaking changes to existing APIs

Temperature: 0.1 (deterministic)

This is specific enough that the model knows exactly what’s expected, but flexible enough to handle any coding task. The temperature setting (0.1) ensures consistent, reliable output.

The 17 Specialized Agents

The SPARC framework defines 17 agent modes, each with a specific role:

Agent	Role	Temperature
Auto-Coder	Production code implementation	0.1
Architect	System design and architecture	0.3
Tester	Test implementation	0.1
Debugger	Bug diagnosis and fixing	0.3
Security Reviewer	Security analysis	0.1
Documentation Writer	Technical documentation	0.3
System Integrator	Cross-module integration	0.2
Optimizer	Performance optimization	0.2
Version Manager	Semantic versioning	0.1
Requirements Analyst	Spec clarification	0.3
Code Reviewer	Implementation review	0.2
Refactoring Specialist	Code restructuring	0.2
Data Migrator	Database migrations	0.1
DevOps Engineer	Deployment config	0.2
UI Developer	Frontend implementation	0.2
API Designer	API contracts	0.2
Technical Writer	Long-form documentation	0.4

Each agent has a full role definition, Chain-of-Thought reasoning protocol, temperature setting, output format, and security mandates.

The Systematic Approach: How It Actually Works

Phase 1: Specification (S)

The Requirements Analyst agent takes a high-level task description and turns it into a structured specification. It asks questions about edge cases, performance requirements, security constraints, and integration points. The output is a specification document that the other agents will use as their source of truth.

Phase 2: Planning & Architecture (P)

The Architect agent takes the specification and designs the implementation approach. It identifies which files need to be created or modified, what patterns to follow, and what dependencies are needed. The output is an implementation plan.

Phase 3: Auto-Coding & Testing (A) — The TDD Loop

This is the core of SPARC. For each unit of work:

1. The Tester agent writes tests based on the specification
2. The tests fail (as expected)
3. The Auto-Coder agent implements the code
4. The tests pass
5. The Code Reviewer agent reviews the implementation

This loop runs until all tests pass and the review is clean. The temperature is locked at 0.1 for both coding and testing, ensuring consistency.

Phase 4: Refinement & Review (R)

The Security Reviewer and Code Reviewer agents do a final pass. The Security Reviewer checks for OWASP Top 10 vulnerabilities, hardcoded secrets, injection points, and authentication gaps. The Code Reviewer checks for code quality, pattern consistency, and spec compliance.

Phase 5: Completion & Versioning (C)

The Version Manager agent determines the semantic version bump based on the changes (major/minor/patch), generates changelog entries, and prepares the release.

What This Actually Achieves

Before SPARC:

• Inconsistent code quality between sessions
• Wasted time reviewing and fixing generated code
• Security vulnerabilities introduced by well-intentioned but uninformed AI
• Tests that tested the wrong things
• Architectural drift as different sessions take different approaches

After SPARC:

• Consistent, spec-compliant code every time
• Tests written before implementation (TDD discipline)
• Security checked automatically at every phase
• Architecture that stays coherent across sessions
• Version management that tracks what changed and why

Real Results:

• 60% reduction in code review time: Code arrives consistent and spec-compliant
• 90% reduction in security-revert commits: Security review catches issues before they reach PR
• Zero hallucinated dependencies: The Spec phase forces the model to validate its assumptions
• 3x improvement in first-pass test pass rate: TDD discipline means tests pass on first implementation

Lessons From 3,000 Lines of Prompts

1. Temperature Settings Matter More Than You Think

I dedicated another post to this, but it bears repeating: temperature 0.1 for code, 0.3 for architecture, 0.4 for documentation. The single parameter has more impact on output quality than prompt length.

2. Reasoning Transparency Prevents Hallucinations

Every SPARC agent is instructed to show its reasoning before acting. This makes hallucinations visible before they become code — the model says “I’m going to use API X” and you can correct it before it writes 200 lines using the wrong API.

3. Security Can’t Be Bolted On

Security review at the end catches some issues, but security-by-design is better. Each agent has security mandates baked into its role definition. The Architect agent must consider threat models. The Auto-Coder agent must validate inputs. The Tester agent must test auth boundaries.

4. Specificity Beats Generality

The most effective prompt instructions are specific: “include error handling for network timeouts” beats “handle errors gracefully.” The more specific the instruction, the fewer decisions the model has to make on its own, and the fewer mistakes it will make.

5. Agent Specialization Works

A generalist coding agent is okay at everything and great at nothing. A specialized code-review agent that only reviews code develops a deep understanding of that task. The 17-agent structure is more effective than one general-purpose agent.

6. Context Injection Is Critical

Every agent needs to know what files exist, what patterns the project uses, what conventions matter. The SPARC framework includes context-injection instructions that tell each agent what to read before acting.

7. Validation Loops Catch Errors Early

The TDD loop — write test, implement, verify — catches errors when they’re cheap to fix. A bug caught in the code phase costs minutes. The same bug caught in production costs hours or days.

8. Documentation Can’t Be An Afterthought

Every SPARC session generates documentation: changelogs, API docs, migration guides, deployment notes. Documentation is part of the definition of done, not something to come back to later.

9. Versioning Requires Logic, Not Guessing

The Version Manager agent follows semantic versioning rules based on actual changes: breaking API changes = major, new features = minor, bug fixes = patch. No more guessing.

10. The Human Still Matters

SPARC handles the execution. The human handles the direction. The framework makes AI more reliable, but it doesn’t replace the developer’s judgment about what to build and why.

The Honest Limitations

What SPARC Doesn’t Solve:

• Ambiguous requirements: If you don’t know what you want, no prompt architecture will figure it out for you
• Novel research problems: SPARC is optimized for production engineering, not research
• Bad codebase foundations: If the project is fundamentally broken, better prompts won’t fix it
• Team communication: SPARC improves the human-AI interaction but doesn’t affect human-human communication

What SPARC Dramatically Reduces:

• Coding errors and hallucinations
• Inconsistent implementations
• Security vulnerabilities
• Documentation debt
• Review cycle time
• Context-switching overhead

How You Can Use This

To use it with Roo Code:

The full SPARC configuration is available as a YAML file that defines all 17 agent modes. Install it as your Roo Code modes configuration and each agent will be available when you need it.

To adapt it for other tools:

The principles are tool-agnostic. Define specialized roles with clear boundaries. Set temperature deliberately for each role. Build validation loops into every phase. Include security and documentation in the definition of done.

Example: Using the ‘code’ agent prompt in Claude

Copy the code agent instructions into a Claude project, set the temperature to 0.1, and use it for implementation tasks. The output will follow your project’s conventions more closely than a generic prompt would.

What SPARC Actually Gets You

3,000 lines of prompts is excessive for a side project. For a production system that needs to ship reliable code consistently, it’s an investment that pays for itself in the first week.

The future of AI-assisted development is better systems for using the models we already have. Prompt architecture is that system.

SPARC is my attempt to build it. The framework’s agent configuration and principles are documented in the SPARC section of this blog.