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
↓
CONTEXT → AIM → EXECUTE → VERIFY → LEARN
↑ │
└─────────────────────────────────┘
MEASURE
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.
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
Where these principles show up in practice
Fintech Payments
Scaling a High-Volume Payments Platform
A consumer payments platform was approaching throughput limits across instant mobile and EFT payment rails, and needed significant improvements in scalability, resilience and processing performance — without ever putting customer money in doubt.
Constrained → Scaled
Transaction throughput across instant and EFT rails
Higher sustained capacity with stronger resilience and settlement integrity
My roleLed the engineering effort within the Payments team across technical strategy, architecture, prioritisation and delivery. Partnered with senior engineers to identify processing bottlenecks across each payment rail and introduce a more scalable approach to asynchronous, distributed transaction processing.
View case study
AI Engineering
Building an AI-First Engineering Operating Model
AI development tools were being adopted across engineering teams, but usage stopped at the coding step and varied team to team — creating inconsistent quality, security, governance and repeatability, and no measurable engineering value to point at.
1× → 3×
Project execution and delivery speed
Averaged across participating teams, from inception and ideation through to rollout
My roleDesigned and introduced an AI-First approach across multiple engineering teams, covering the full delivery lifecycle — inception, ideation, design, build, verification and rollout — rather than treating AI as an autocomplete tool inside the coding step alone.
View case study
Platform Modernisation
Modernising Legacy Technology Without Disrupting the Business
A mature technology estate contained legacy frameworks, applications and components that created increasing maintenance, security and engineering productivity risks.
Unsupported → Supported
Legacy platform estate
Modernised incrementally, with no big-bang rewrite
My roleLed and influenced modernisation strategy, architecture decisions, prioritisation and technical-risk management while ensuring business-critical capabilities continued operating throughout the transformation.
View case study
Fintech & Blockchain
Accepting FIAT and Crypto, Issuing Share Contracts On-Chain
A private members' club needed to accept share purchases from its members in both traditional currency and crypto, and to give each member a verifiable record of what they owned — across two settlement models that have almost nothing in common.
FIAT + Crypto → On-chain
One share-purchase flow, five settlement assets
Every purchase produced its own Solidity contract on the Ethereum Virtual Machine
My rolePart of the team that built and maintained the platform end to end: payment acceptance across FIAT and crypto rails, the member share-purchase flow, and the generation and deployment of a Solidity smart contract for every purchase to the Ethereum Virtual Machine.
View case study