Engineering changes when humans are no longer the only ones executing the work.
Agents can write, modify and review software at a scale that changes the economics of implementation.
But speed does not remove accountability. It makes intent, decisions, context, constraints and evidence more important, because they need to survive the next execution.
DOCOD exists to investigate and operationalize that shift.
Execution changed. The discipline has to follow.
Requirements. Design. ADRs. Tests. Reviews. Runbooks. Postmortems.
None of that became less valuable because agents started writing code. The opposite happened. As more implementation can be delegated, what directs and confirms that implementation needs to become more explicit.
The future of software engineering is not about producing code faster. It is about delegating more execution without delegating accountability for the system.
AI should not be a layer placed on top of the old process.
Less effort goes into manually translating every decision into code.
More effort moves toward:
- defining what must be true
- preserving context
- making decisions and constraints explicit
- coordinating execution
- confirming results with evidence
- observing the system in operation
- learning without losing the history that led there
That is what we call AI-Native Software Engineering. It is not a new name for writing code with AI assistance. It is a way to think about engineering when AI stops being only a tool and starts taking part in execution.
DOCOD is not a single tool.
- The book
- Develops the discipline, the principles and the mental model.
- The method
- Organizes the work into five movements: DEFINE, ORCHESTRATE, CONFIRM, OBSERVE and [re]DEFINE.
- The runtime
- Explores what happens when parts of that discipline stop depending only on convention and gain contracts, derived state, gates and executable verification.
- The challenges
- Turn the fundamentals and the problems of AI-native engineering into recurring practice.
- The articles
- Develop ideas, problems, decisions and lessons in public.
These do not exist to form a product catalog. They are different ways to investigate, teach, practice and apply the same discipline.
A discipline about verifiability should itself be open to scrutiny.
That is deliberate. DOCOD should not be trusted because its documentation says it is right. It should be possible to read it, test it, challenge it and improve it.
The same idea that appears in the runtime applies to the project itself: claims are the beginning, and evidence is what makes them trustworthy.
DOCOD is created and developed by Codenroll Technologies.
DOCOD is the public expression of that work. The method, the book, the runtime and the resources can all evolve.
How do we build software with agents without giving up the discipline that makes software engineering?
Models change. Tools change. Harnesses change.
- Intent must survive execution.
- Decisions must survive the next agent.
- Evidence must survive the claim of whoever produced the work.
Implementations can change. That accountability remains.