Documentation for Prompts (folio.benguzovsky.com)

Andrej Karpathy frames prompts as “software 3.0” and warns that they’re increasingly replacing conventional code — but unlike Software 1.0 (handwritten code) and 2.0 (models with notebook-driven docs), prompts are hard to document and maintain. Because a prompt mixes instructions, examples, formatting, and implicit assumptions into a single blob, engineers often mistake the prompt itself for documentation. That makes safe refactors (switching to a cheaper/faster model, changing rules, or trimming context) risky: small edits can silently break behavior, and inline comments aren’t supported inside the prompt text. Karpathy recommends treating prompts as first-class code artifacts: modularize them (split into variables and concatenate, despite the awkwardness), expose a way to inspect the exact LLM input emitted by your callLLM() helper, and pair prompts with targeted evals. Useful practices include annotated eval examples (one set for breadth, one matching production distribution), prompt versioning or sticky-note tools (cross-editor support is tricky), and a culture of leaving persistent documentation when fixing issues. The upshot for AI/ML teams: invest in tooling, tests, and accessible docs so prompts remain debuggable, refactorable, and maintainable as systems scale.