
When I say I’m codifying everything, I don’t mean filling shared drives with more PDFs. I mean writing things down so precisely they can be executed by people, systems and agents reliably, measured for impact, and improved continuously. With AI moving from a novelty to an operational lever, the single biggest limiter to automation isn’t compute — it’s the quality of what we can hand off to a machine.
What I mean by codification
Codification is the discipline of turning tacit practices into explicit, executable artefacts. It sits between good documentation and product design: clearly stated outcomes, acceptance criteria, steps, decision rules, data contracts, and measurement points. The point is not bureaucracy; it’s repeatability, observability and optimisation.
Three attributes that make codification valuable
- Executable: a human or an agent should be able to follow the artefact and produce the intended outcome.
- Measurable: each step has a success metric and an observable signal.
- Versioned and owned: it’s living — with a clear owner, review cadence and change log.
Why now: AI turns instructions into leverage
Language models and agents are hungry for structure. Whether you’re using an agent to draft user journeys, a model to score leads, or a workflow orchestrator to resolve customer incidents, the output quality maps back to the quality of your inputs. That’s obvious for prompt engineers, but it matters across the organisation: the better we write our processes and interfaces, the more we can safely delegate.
Look at how organisations with public, disciplined playbooks scaled. The GitLab Handbook is not a vanity project — it’s a scaling mechanism for a distributed company. Google’s SRE runbooks turn tribal knowledge into automation triggers. These aren’t sexy tasks, but they are the foundation upon which reliable automation sits.
What to codify first: prioritise for impact
Not everything needs the same level of formality. Start where codification delivers immediate returns:
- High-frequency, high-variance tasks: customer support responses, incident triage, recurring marketing campaigns.
- Cross-team handoffs: anything that depends on fragile, human-dependent coordination.
- Decision rules that touch customers or revenue: pricing adjustments, fraud signals, eligibility checks.
Practical rule: if a task is done more than weekly and causes friction when done badly, codify it.
How to codify well — a practical checklist
Codification is a craft. Here are practical steps leaders can adopt today.
1. Start with outcomes, not steps
Define the customer or business outcome first. A script that describes steps but lacks the why becomes brittle. State the objective, the success metric, and the tolerance for error.
2. Use standard templates
Create simple, reusable templates for playbooks, runbooks and agent prompts. A good template contains: intent, inputs, expected outputs, decision rules, rollback criteria, observability signals and owners.
3. Build test harnesses
Treat codified artefacts like code. Run automated or tabletop tests against them. For prompts and agents, use example cases and error cases to watch for hallucination or bias. Testing reduces risk and speeds iteration.
4. Instrument everything
Attach metrics and logs to actions. If an agent executes a decision, capture the inputs, the model’s confidence, the final decision and downstream outcomes. Observability is how codification becomes a learning loop.
5. Guardrails and governance
Not every decision should be automated. Define thresholds where human review is required. Document privacy, compliance and ethical checks alongside the playbook so automation respects constraints.
6. Invest in writing and review skills
Writing for execution is a skill. Train product owners, engineers and designers to author for machines and humans. Peer reviews and a single-source-of-truth repository prevent drift.
One real-world example: playbooks that scale
Amazon’s operational culture is often held up for good reason: playbooks and “working backwards” thinking create predictable behaviour across distributed teams. The Working Backwards approach formalises how teams define customer outcomes before building features — a form of codification that reduces wasted effort. Combine that with public-facing handbooks like GitLab’s and you get systems that scale with less managerial friction.
Risks and how to avoid them
- Overfitting: Don’t make instructions so rigid they can’t adapt. Keep decision rules parameterised.
- Brittleness: Instrument and monitor for edge cases; have fallback paths.
- Complacency: Codified processes can lull leaders into thinking automation is the same as improvement. Keep experiments and user feedback part of the loop.
Where this leads
Codification isn’t an end state; it’s infrastructure for continuous improvement. When you can hand an agent a tested, instrumented playbook and have it operate within guardrails, you gain speed, consistency and learning velocity. For product leaders, that translates into faster hypothesis cycles, lower operational risk and a clearer line of sight from actions to outcomes.
If you’re starting small: pick one repeatable process, write the template, instrument it and run a test. You’ll find gaps you didn’t know you had — and a clear path to automating the boring bits so your teams can focus on the valuable ones.
Leave a Reply