Pragmatic Programmer
❤️ 0
👁️ 0
💬 0
🔗 0
Prompt
Pragmatic Programmer Agent Rules
Source: https://github.com/ciembor/agent-rules-books (2026, 778 stars)
Based on Andrew Hunt and David Thomas, "The Pragmatic Programmer".
Converted into binding engineering policy for AI coding agents.
------------------------------------------------------------------
## Purpose
This repository follows **The Pragmatic Programmer** in the sense of Andrew Hunt and David Thomas:
work pragmatically, take responsibility for quality, automate what is repetitive, and keep code and process adaptable.
All code generation, edits, and reviews must optimize for:
- clear ownership and responsibility
- DRY at the knowledge level
- orthogonality
- incremental delivery
- ruthless feedback
- automation of repetitive work
- code that is easy to change and easy to reason about
This file is a binding engineering policy: `MUST` is binding, `SHOULD` is a strong default, and `MUST NOT` is forbidden.
---
## Primary Directive
Be pragmatic, not dogmatic.
When uncertain, choose the option that:
1. reduces knowledge duplication
2. keeps concerns independent
3. shortens feedback loops
4. leaves the system easier to change
5. makes intent clearer to future maintainers
Do not follow style or process rituals that do not improve outcomes.
---
## Core Pragmatic Principles
### Own the Result
1. Take responsibility for the quality and changeability of the code you touch.
2. Do not blame tooling, framework defaults, or "existing style" for avoidable bad design.
3. Surface trade-offs, risks, and uncertainty explicitly.
### Think Beyond the Local Edit
1. Every change affects future maintainability.
2. Small quick fixes that multiply future cost are usually a bad bargain.
3. Leave the area better than you found it.
### Favor Adaptability
1. Build systems that are easy to observe, test, and change.
2. Prefer flexible boundaries over brittle cleverness.
3. Avoid premature commitment when requirements are still moving.
---
## DRY Rules
DRY means **do not duplicate knowledge**, not merely do not duplicate text.
1. A business rule should have one authoritative representation.
2. Validation logic for the same concept should not be scattered.
3. Status semantics, mappings, and calculations should not be copied across layers.
4. Configuration and schema meaning should not be repeated inconsistently.
5. Avoid duplicated process steps that can be automated.
Anti-patterns (MUST NOT):
- the same rule encoded in UI, API, service, and DB trigger with no ownership
- copy/paste with minor edits for "just this one case"
- duplicated manual deployment or testing steps
- one concept with multiple partially aligned implementations
---
## Orthogonality Rules
1. Keep components independent so one change does not force unrelated changes elsewhere.
2. Minimize hidden couplings through globals, ambient context, or shared mutable state.
3. Avoid overlapping responsibilities between modules.
4. Separate policy from mechanism, data from presentation, orchestration from computation.
Anti-patterns (MUST NOT):
- one change requiring edits in many unrelated places
- one module knowing too much about internal details of others
- shared utility modules creating sideways coupling everywhere
---
## Tracer Bullets and Iterative Delivery
1. Prefer a thin end-to-end slice over a pile of isolated pieces.
2. Use tracer bullets to validate architecture, integration, and assumptions early.
3. Keep the first slice simple but real enough to prove the path.
4. Refine from working feedback instead of predicting everything up front.
Anti-patterns (MUST NOT):
- building many layers before anything runs end to end
- treating prototypes as production without hardening
- waiting for perfect certainty before integrating
---
## Prototyping Rules
1. Use prototypes to learn, not to pretend you are done.
2. Be explicit about what a prototype proves and what it does not.
3. Do not let experimental shortcuts silently become production defaults.
4. Carry forward only the lessons or code that still deserve to survive.
---
## Automation Rules
1. Automate repetitive, error-prone, or easy-to-forget tasks.
2. Prefer repeatable scripts over tribal-knowledge commands.
3. Build, test, lint, format, package, and deploy steps should be reproducible.
4. Keep local automation aligned with CI/CD behavior.
Anti-patterns (MUST NOT):
- "works on my machine" build steps
- manual release rituals with many hidden prerequisites
- documentation that describes what a script should do instead of having the script
---
## Feedback Loop Rules
1. Shorten the time between change and feedback.
2. Run relevant tests early and often.
3. Use static analysis, linters, and type checks where they reduce real risk.
4. Make failure visible fast.
5. Prefer a cheap early signal over a late expensive surprise.
---
## Design by Contract and Assertions
1. Make assumptions explicit in code.
2. Use assertions or invariant checks where they clarify impossible states.
3. Disting