2.3 — Engineering Principles
These are not rules for writing code. They are rules for thinking about problems. You will use them whether you write a single line of code or orchestrate AI agents all day.
The Six Principles
Section titled “The Six Principles”| Principle | What It Means | Why It Matters |
|---|---|---|
| YAGNI (You Ain’t Gonna Need It) | Don’t build features you might need later. Build what you need now. | Over-building wastes time and adds complexity that creates bugs. The feature you imagined needing rarely matches what you actually need. |
| First Principles | Break problems down to their fundamental truths, then build up from there. Don’t copy solutions — understand the problem. | Copied solutions break when your situation is slightly different. Understanding the why lets you adapt. |
| DRY (Don’t Repeat Yourself) | If you’re writing the same thing in multiple places, something’s wrong. Put it in one place and reference it. | When you need to change it, you change it once — not in 12 places where you’ll forget one. |
| Separation of Concerns | Each piece of your system should do ONE thing. | When something breaks, you know exactly where to look. When you improve something, you don’t accidentally break something else. |
| Fail Fast | If something is going to break, make it break loudly and immediately — not silently and later. | Silent failures compound. A crash you see today is better than corrupt data you discover next month. |
| Don’t Over-Engineer | The right amount of complexity is what the task actually requires. No more. | Three simple lines of code is better than an “elegant” abstraction you’ll never reuse. Simple is not stupid — simple is professional. |
Key Insight
Section titled “Key Insight”These are not beginner rules you graduate from. Senior engineers with 20 years of experience follow these daily. They’re not training wheels — they’re the actual wheels.
When you violate these principles, you create technical debt — shortcuts now that cost more later. When you follow them, you build systems that are easier to debug, easier to extend, and easier for other people (and AI) to read.
The best prompt you can give an AI is one that asks it to follow these principles. “Don’t add anything I didn’t ask for. Don’t repeat logic that already exists. Keep this simple.” That’s YAGNI, DRY, and Don’t Over-Engineer in one sentence.
Next: 2.4 — Project Architecture | Phase overview: Phase 2