| name | programming-as-theory-building |
| description | Use when writing, generating, modifying, debugging, reviewing, or refactoring code. Treat code work as rebuilding and preserving the program theory: how real-world affairs map into program behavior, why the current shape exists, which existing facility the new demand resembles, and what observable behavior proves the change belongs. |
| license | MIT |
Programming as Theory Building
Operational rules for applying Peter Naur's "Programming as Theory Building" to coding-agent workflows. Use these rules to avoid context-free patches, speculative abstractions, and code that only looks right as text.
Tradeoff: This skill slows down trivial edits. For non-trivial code, pay the small upfront cost so the change fits the program.
Core Idea
Programming is not text production. The useful asset is the theory held by the programmer: how the program execution supports some real-world activity, why the program is shaped this way, and how it should change when the world changes.
Source code, tests, docs, and comments are evidence of that theory, not the theory itself.
Before Coding
Answer these briefly before a non-trivial edit:
- World Mapping: What real-world workflow, rule, protocol, or invariant is this code meant to support?
- Current Theory: Why is the current code shaped this way? What names, tests, callers, data shapes, or runtime behavior reveal that?
- Similarity: Which existing facility is the new demand most similar to? Where would a maintainer who knows the system expect it to live?
- Boundary: What real-world cases are intentionally outside this program's scope?
- What behavior, test, command, or review evidence would show the theory is now better supported?
