Experience the design problem before worshipping the pattern.
This is not a tutorial library. It explains why each idea matters, when to learn it, how deep to go now and what small practice makes it real.
The AI-era bottleneck
Producing code became easier. Understanding, verifying and changing it safely did not.
As AI output grows, so does the responsibility to review it. These ideas are not decorative vocabulary; they are practical lenses for questioning generated code, reducing needless complexity and containing failure before you merge.
A disciplined way to improve design without changing behavior.
Why it matters more with AI
Small verified refactors control regression, token and review cost better than asking AI to rewrite an entire working area.
When to learn it
After the code works and can be protected by tests.
Enough for now
Recognize the problem, explain the vocabulary and apply it deliberately once in a small project.
Small practice
Add a characterization test, then simplify one function.
Avoid
Do not rewrite broken behavior and architecture at the same time.
04
Defensive Programming
Why it matters
Makes assumptions about inputs, dependencies and failure explicit so a system can fail safely.
Why it matters more with AI
AI can look convincing on the happy path; malformed input, timeouts, missing permissions and incomplete context still belong to the engineer.
When to learn it
As soon as you add a user input, API, file, database or AI-output boundary.
Enough for now
Recognize the problem, explain the vocabulary and apply it deliberately once in a small project.
Small practice
Validate one external input, return an explicit failure and test a malformed case.
Avoid
Do not swallow every exception, log secrets or silently accept impossible states.
05
SOLID Principles
Why it matters
Vocabulary for discussing dependencies and responsibilities.
Why it matters more with AI
AI can produce sophisticated abstractions; SOLID questions help you detect mixed reasons to change and dependencies that are unnecessarily hard to replace or test.
When to learn it
After building a small application and feeling change pain.
Enough for now
Recognize the problem, explain the vocabulary and apply it deliberately once in a small project.
Small practice
Explain whether splitting one responsibility improves a real change.
Avoid
Do not create an interface for every letter and call it architecture.
06
Design Principles
Why it matters
Cohesion, coupling, information hiding and dependency direction reduce change cost.
Why it matters more with AI
Principles let you judge an AI suggestion: which boundary should remain stable, which dependency should point inward and where simple code is enough.
When to learn it
When projects have multiple modules and change reasons.
Enough for now
Recognize the problem, explain the vocabulary and apply it deliberately once in a small project.
Small practice
Reverse one dependency arrow to improve testability.
Avoid
A beautiful diagram is not evidence of a good design.
07
Design Patterns
Why it matters
Shared vocabulary for recurring design pressures.
Why it matters more with AI
AI knows pattern names but not your trade-off. Understanding patterns lets you recognize a suggestion, discuss it and reject complexity that solves no present problem.
When to learn it
After meeting the problem firsthand.
Enough for now
Recognize the problem, explain the vocabulary and apply it deliberately once in a small project.
Small practice
Use Strategy or Adapter on a real pain and compare an alternative.
Avoid
Do not memorize all 23 GoF patterns and see Factory in your breakfast.
Connects readability, simplicity, duplication and tests to the real maintenance cost of code—including code drafted with AI.
Do this much: Read the clean-code characteristics, then improve names, duplication or one oversized function in working code. Protect behavior with tests before a larger refactor.
A visual vocabulary for spotting maintainability pressure that compiling and AI-generated confidence do not reveal.
Do this much: Begin with Bloaters, Change Preventers and Couplers. Find one example in your own project, describe its change cost and refactor only with behavior protected.
Explains patterns as adaptable design blueprints and shared team language, while also making room for their limits and misuse.
Do this much: Read what a pattern is, its benefits and criticism. Study Strategy or Adapter only after you can point to that problem in working code; compare it with the simpler option.
Last reviewed:
Go deeper · optionalCommunity-maintained open guide·book·Free