00. Engineering Principles — The Five-Year-Old Version¶
You are here after building excitement, and right before messy scaling decisions.
Look.
Imagine a captain steering a ship through busy water.
The sea is changing.
The crew is asking questions.
Supplies are limited.
And the captain must still reach the right port.
AI engineering feels like that.
A demo can look smooth for one day.
Then real users arrive.
Costs rise.
Edge cases appear.
Teams disagree.
Now the captain needs more than confidence.
The captain needs principles.
See.
Principles are not fancy slogans on a slide.
They are simple rules for repeated choices.
They tell you where to aim.
They tell you how to choose.
They tell the crew what good work looks like.
They tell you when danger is near.
And they help you write things down clearly.
Simple, no?
So what to do?
Use the ship analogy as your memory hook.
The course means technical direction.
The compass means the decision framework.
The crew means your team and stakeholders.
The weather check means risk assessment.
The ship's log means documentation and ADRs.
If those five stay clear,
engineering stays calm even when delivery is noisy.
If those five stay fuzzy,
every urgent ticket feels like a new argument.
Yes?
The placeholders you will see called back¶
| Placeholder | Meaning |
|---|---|
| the course | The technical direction the team is trying to hold |
| the compass | The decision framework used when choices feel noisy |
| the crew | The team, partners, and stakeholders who must move together |
| the weather check | The habit of checking risk before committing hard |
| the ship's log | Documentation and ADRs that survive team changes |
Top resources¶
- Martin Fowler — Architecture Decision Records — clean ADR basics without fluff.
- Google Cloud — Architecture decision records — practical ADR template and usage guidance.
- Google SRE Book — reliability thinking, error budgets, and operating discipline.
- OpenAI Cookbook — Evals — useful starting point for testing AI behaviour.
- DORA research — evidence on delivery habits, feedback loops, and engineering performance.
- AWS Builders Library — strong writing on trade-offs, operations, and decision quality.
What's coming¶
- 01-opening-failure.md — Sprint chaos without principles
- 02-build-buy-finetune.md — The classic captain decision
- 03-reversibility-one-way-doors.md — Two-way doors move fast, one-way doors need ceremony
- 04-decision-records-adrs.md — The ship's log that survives crew changes
- 05-unit-tests-evals-monitoring.md — Three instruments for three layers
- 06-observability-error-budgets.md — Signals and the reliability forcing function
- 07-technical-debt-ai.md — Debt that hides behind working demos
- 08-code-review-ai.md — Reviewing probabilistic systems
- 09-sprint-planning-research.md — Planning under uncertainty
- 10-stakeholder-communication.md — Translating decisions for different audiences
- 11-managing-expectations.md — Defusing magical thinking about AI
- 12-honest-admission.md — What principles cannot solve
See the whole ship once more.
The course stops drift.
The compass stops random choices.
The crew keeps alignment.
The weather check slows foolish bets.
The ship's log keeps memory alive.
That is the whole module in one picture.
Next we start with the pain.
Why do teams feel heroic in Sprint 1,
and haunted by Sprint 5?
Because speed without principles creates silent confusion.
Bridge. First feel the chaos clearly. Then the need for principles becomes obvious. → 01-opening-failure.md