Agents already write code.The hard part now is engineering.
Once AI takes part in implementation, writing stops being the centre of the work. Intent, context, decisions, limits and evidence are what decide whether software can be trusted and whether it stays trustworthy as the project changes.
DOCOD is a method for organising that work, and an open-source runtime that makes it executable.
One practical AI-native engineering challenge a day, straight to your inbox.
2026
Execution got cheaper. Accountability did not.
Agents can implement, test, refactor and review ever larger parts of a system.
That does not remove the engineering work. It moves where the work happens.
You turned requirements into code, and carried most of the context needed to keep it correct.
You have to make intent, context, constraints and criteria explicit enough for agents to execute and produce evidence strong enough for the result to be accepted.
AI takes on more execution. Engineering takes on more control.
Producing more code does not fix what is lost between a decision and the next execution.
- A specification changes.
- An architecture decision changes.
- One agent joins the project. Another picks up the work.
- The code changes again.
When intent, decisions, dependencies and evidence stop being connected, every new execution depends on a human or an agent rebuilding the context and interpreting all over again what was supposed to be true.
That is where speed turns into drift.
DOCOD exists to preserve continuity between what was decided, what was executed and what was confirmed.
Five movements. One responsibility that is never delegated.
- 01
Define
What needs to be true?
Turn intent into requirements, decisions, design, contracts, risks and work that can be executed without relying on implicit context.
- 02
Orchestrate
Who executes what and under which conditions?
Coordinate agents, tools, context, environments and rules to carry out the work that was decided.
- 03
Confirm
What evidence proves the result is correct?
Test behaviour, review results, check them against the criteria, and keep human decisions where approval genuinely means accountability.
- 04
Observe
What happens when the software meets reality?
Follow behaviour, failures, cost, drift and the outcomes that only show up after execution.
- 05
[Re]define
What does the learning change about what we decided?
Take evidence back to the decisions. Analyse impact, revise what changed, and start the next cycle from a better state than the last.
The method says how the work should run.The runtime makes the process leave a trail.
The DOCOD Method does not depend on a particular model, IDE or agent.
Method
The engineering model behind the five movements.
The DOCOD Runtime is the open-source reference implementation: it turns documents, decisions, approvals, tasks and checks into a flow the project can inspect, not something a conversation has to remember.
Runtime
The executable implementation for applying the method on real projects.
If a machine can verify it, trust does not have to rest on the word of an agent.
In the runtime, trust leaves evidence.
- Approval belongs to what was approved
- An approval is bound to the content of that version. Once the artefact changes, the previous approval does not pretend to still hold.
- Verification has to show where it came from
- Declaring that it passed is not enough. Evidence points at the command, the result or the artefact used to support the conclusion.
- Whoever produces does not get to close the discussion
- Execution and verification carry different responsibilities. Producing a change grants no authority to approve it.
- Upstream change has consequences
- Changing an earlier decision means understanding the impact on what depends on it, or recording explicitly why that impact was waived.
The runtime is open source. You can check these rules in the code.
Read before you buy
Get a free chapter and decide for yourself whether this approach is useful for your work.
AI-Native Software Engineering
An operating manual for people who have to build software with agents without outsourcing the engineering to them.
The book develops the discipline behind DOCOD: how to move from a still-ambiguous intent to decisions, organise execution with agents, confirm results, and learn from what happens once the software meets reality.
- It is not a book of prompts.
- It does not depend on any particular tool.
- It is about the engineering work that remains once writing code stops being the hard part.
You cannot confirm well what you cannot judge.
Agents increase how much code an engineer can put in motion. That makes fundamentals more valuable, not less, and with them the ability to recognise when an implementation is wrong.
The Daily Challenge turns that into daily practice.
One problem a day. Runnable. With input, output and test cases.
You train on everything from classic fundamentals to the problems that show up once AI is in the product, agents are in the process, and generated code has to be supervised.
Fundamentals
Data structures, algorithms, state, concurrency, invariants and edge cases.
AI in the product
RAG, search, evals, observability, cost, guardrails and the deterministic components around models.
Building with AI
Context engineering, agents, handoffs, decomposition, verification and coordination.
Where AI usually gets it wrong
Problems built around failure patterns that look correct until someone knows exactly where to look.
Next challenge coming soon
We're preparing the next challenge. Turn on the daily loop to get it first.
Free
Get the challenge of the day by email. Statement, context and test cases.
The form is unavailable right now. Please try again in a moment.
Premium
Go past finding out whether your answer works: the full solution, the reasoning, alternatives, trade-offs, and where AI-generated code tends to fail on that problem.
Understand. Train. Apply.
Book
Understand the principles and the reasoning behind AI-native engineering.
See the bookChallenges
Train the ability to build and judge software with AI, every day.
Explore the challengesMethod
Use the five movements to structure the work.
See the methodRuntime
Take the method into a real project.
Get the runtime