How to Generate 4K Lines of Maintainable C Code in 9 Prompts with Claude Code
A developer recently demonstrated what's possible when you approach Claude Code with a structured plan. They generated a complete JPEG/MJPEG decoder in pure C99—4,103 lines total—using just 9 prompts in a single session. The result: 2,403 lines of library code, 509 lines of tools, and 1,069 lines of tests, all passing 16/16 unit tests.
The Structured 9-Prompt Plan That Made It Work
The developer didn't just ask Claude Code to "write a JPEG decoder." They broke it down into six logical phases, each with specific objectives:
- Phase 1 — Scaffolding: Created project structure, public API header, CLI tools, and CMake build system
- Phase 2 — JPEG Parsing: Implemented SOI/SOF0/DHT/DQT/SOS/DRI marker parsing per ITU-T T.81 spec
- Phase 3 — Huffman Decoding: Bit-by-bit decoding implementation
- Phase 4 — IDCT: Inverse Discrete Cosine Transform
- Phase 5 — AVI Integration: MJPEG frame extraction from AVI containers
- Phase 6 — Optimization: Performance improvements
Each phase had clear deliverables and validation criteria. The developer noted: "The JPEG spec is surprisingly well-written — the pseudocode maps almost directly to C."
Why This Approach Produces Better Code
This structured prompting approach works because it:
- Leverages Claude's reasoning capabilities: Breaking complex problems into smaller, manageable chunks plays to Claude's strengths in step-by-step reasoning
- Maintains context: Each phase builds on the previous one, keeping the model focused on the current task while understanding the overall architecture
- Enables validation: By generating tests alongside implementation, you catch issues early
- Produces readable code: The 2,403 lines of C99 are described as "readable C99 that a human can actually understand"
The Performance Trade-Off (And Why It Doesn't Matter)
The AI-generated decoder benchmarks at 8% the speed of FFmpeg's hand-tuned implementation. FFmpeg is 12x faster, thanks to decades of optimization and SIMD assembly.
But here's the key insight: For most projects, initial implementation speed matters more than peak performance. The developer achieved:
- PSNR: 24.49 dB
- SSIM: 0.9789
- 91.7% of color channels identical
- Visually nearly indistinguishable output
The differences come from integer rounding in YCbCr-to-RGB conversion and chroma upsampling edge cases—minor issues that can be optimized later if needed.
How to Apply This to Your Projects
- Start with scaffolding: Use Claude Code to generate your project structure, build system, and API headers first
- Follow the spec: When implementing standards (like JPEG), reference the actual specification documents
- Generate tests concurrently: Don't wait until the end—write tests alongside implementation
- Accept "good enough" performance: Get a working implementation first, optimize critical paths later
- Use zero dependencies when possible: The pure C99 approach makes the code more portable and easier to understand
The Real Win: Maintainable Code
The most significant outcome isn't the line count or even the functionality—it's that the generated code is maintainable. A human developer can read, understand, and modify this codebase. This addresses one of the biggest concerns about AI-generated code: that it produces unmaintainable spaghetti.
By structuring prompts around clear phases and validation criteria, you guide Claude Code toward producing code that follows good software engineering practices, not just functional implementations.
Try It Yourself
Next time you need to implement a complex feature, try this approach:
// Phase 1: Scaffolding
"Create a CMake project structure for a [library name] with these components:
- src/ for implementation
- include/ for public headers
- tests/ for unit tests
- tools/ for CLI utilities
Include a basic API header with these functions..."
// Phase 2: Core parsing
"Implement the [specific parsing function] according to [spec document].
Generate unit tests that verify edge cases including..."
// Continue with remaining phases
Remember: The goal isn't to replace hand-optimized production code on day one. It's to rapidly prototype working implementations that you can then refine and optimize as needed.

