Playbook topic
AI-First Engineering
AI increases the need for engineering discipline rather than reducing it.
Engineering Playbook
CONTEXT → AIM → EXECUTE → VERIFY → LEARN
A control system for engineering in the age of AI agents.
Most organisations already have the pieces. A coding assistant. CI/CD. Static analysis. A ticket system. Architecture standards. DORA dashboards. Security policy.
What they generally do not have is a coherent operating model explaining how those pieces work together when humans and agents jointly build software.
This playbook is that missing layer. It is deliberately tool-agnostic: the rails outlive whichever assistant, agent or vendor is current.
- Give humans and agents enough context to make good decisions.
- Define what we are aiming at before expensive mistakes become code.
- Delegate execution according to risk.
- Require evidence before trusting output.
- Turn every lesson into a stronger engineering system.
When execution becomes cheap, verification becomes valuable.
CONTEXT
Give engineers and AI the right information before asking them to solve the problem.
High-performing engineering starts with shared understanding. Context reduces rework, ambiguity and fragile AI-assisted output.
Without it: Without shared context, teams and AI tools optimise locally and create rework, inconsistency and fragile delivery.
Architectural context
Business context
Product context
Engineering standards
Constraints
Definition of Ready
Agent context
Context Economy
Architect of Context
AIM
Define what we are aiming at before implementation begins.
Aiming is not bureaucracy. It is the cheapest place to discover bad assumptions, and the stage where a vague target gets made explicit.
Without it: Without deliberate planning, assumptions hide until implementation — where correction is expensive and confidence is fake.
Plan Mode
Architecture decisions
Technical decomposition
Acceptance criteria
Risk identification
Test strategy
Dependency analysis
Design before code
Spec-driven development
EXECUTE
Delegate according to risk. Engineering discipline remains mandatory even when AI increases velocity.
Speed without structure creates debt. Execution should be guided by specs, tests, clear ownership and explicit limits on agent authority.
Without it: Without structured execution, speed creates debt: uneven quality, weak ownership and systems that cannot be operated safely.
Spec-driven implementation
TDD
Small changes
Delegated agentic engineering
Autonomy levels
Engineering guardrails
Deterministic hooks
Progressive controls
Blast radius
VERIFY
When execution becomes cheap, verification becomes valuable.
Verification protects customers, teams and reputation. It is where confidence is earned — and it is the stage that matters most once generating a change costs almost nothing.
Without it: Without verification, "done" means merged, not correct. Customers and operators discover the truth first.
Unit testing
Integration testing
Security verification
Static analysis
Peer review
Agent evals
Quality gates
Production readiness
Observability
Evidence packs
LEARN
Every lesson should change the system, not just the people in the room.
Learning converts experience into organisational advantage. Without it, teams repeat expensive mistakes.
Without it: Without learning loops, organisations repeat the same incidents, debates and bottlenecks under new names.
Retrospectives
Incident learning
Engineering metrics
DORA
Reusable context
Executable standards
Knowledge propagation
Compound Engineering
Topic pages
Crawlable playbook thinking
Playbook topic
DORA Metrics as Leadership Signals
Deployment frequency, lead time, change failure rate and MTTR are decision signals — not vanity scores.
Playbook topic
Technical Debt Framework
Treat technical debt as a portfolio of constrained bets with explicit cost, risk and paydown strategy.
Playbook topic
Context Engineering
Give engineers and AI the right information before asking them to solve the problem.
The rails
Two things run across every stage
The five stages describe how work moves. GOVERN and MEASURE decide what work is allowed to do, and whether any of it improved the system.
GOVERN
Decide how much authority a change is allowed to carry.
Governance is not a committee. It is the set of answered questions that lets work move without asking permission every time.
- Who is allowed to do what — and does that include agents?
- What data may agents access, and under what classification?
- Which tools, models and integrations are approved?
- Where is human approval required before execution, and where before merge?
- Which actions must be auditable after the fact?
- What is the maximum blast radius of an autonomous change?
- How are agent identities issued, scoped and retired?
MEASURE
Prove the system improved — not that it produced more.
Volume of generated code is not an outcome. Measurement exists to tell you whether the engineering system got healthier, and what it cost to get there. Decide what you are aiming at first — aim at nothing and you will hit it, while the dashboard stays busy enough that nobody notices.
Flow
Where does work wait?
Lead time Cycle time Review time Queue time Change size
Quality
What does speed cost us?
Change failure rate Escaped defects Rework rate Security findings Rollback rate
AI effectiveness
Is delegation actually working?
Agent completion rate Human intervention rate Retry rate Acceptance without rework Agent-introduced defects Verification failure rate
Economics
Did this create value?
Cost per accepted change Inference cost Engineering hours reclaimed Rework avoided Time to value
DORA remains the spine of Flow and Quality. The AI effectiveness and Economics categories exist because an organisation can improve DORA numbers while spending more to get less.
Platform
The paved road underneath
A playbook explains how engineers should work. It only scales if the organisation also provides the road they work on.
Standards that live only in documents get followed unevenly. Standards embedded in templates, pipelines, hooks and platform defaults get followed by default — by humans and agents alike.
- Engineer or agent
- Engineering Playbook
- Golden path
- Internal developer platform
- CI/CD
- Security, quality and observability
- Production
The further down this stack a rule lives, the less it depends on anyone remembering it.
Go deeper
The same thesis, at closer range
The playbook is the operating model. These are the parts of it worth their own page.
Architecture
How structure gets decided — and what the decisions cost later.
Engineering Leadership
Team health, delivery, quality, metrics and how engineers grow.
Engineering Decisions
Concrete calls, the trade-offs behind them, and what would make me reconsider.
CTO Toolkit
Scorecards, templates and checklists you can take and use.
Implementation
Put this in a repository
The philosophy lives here. The adoptable scaffold — context packs, autonomy levels, evidence contracts, agent evals and the scorecard — is a download.
AI has changed who can execute software engineering work. It has not changed our responsibility to understand, govern and verify that work.
Related work