Skip to main content
About DOCOD

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.

Why DOCOD exists

Execution changed. The discipline has to follow.

For decades, software engineering developed practices for dealing with systems that grow, teams that change, and decisions that need to survive over time.

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 premise
The future of software engineering is not about producing code faster. It is about delegating more execution without delegating accountability for the system.
AI-Native Software Engineering

AI should not be a layer placed on top of the old process.

If agents take part in engineering, the process needs to be designed with agents in mind from the beginning. That changes where human work concentrates.

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.

The project

DOCOD is not a single tool.

It is a project for turning this discipline into knowledge, practice and software. It began as an investigation into how software should be built when agents become part of the engineering process, and today that investigation takes several forms.
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.

Built in the open

A discipline about verifiability should itself be open to scrutiny.

The method is public. The runtime is open source. Important claims can be compared with what was actually implemented.

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.

Codenroll Technologies

DOCOD is created and developed by Codenroll Technologies.

Codenroll Technologies is an AI-first software engineering company. DOCOD grew out of its work on how engineering, agents and AI systems can operate together without turning speed into loss of control.

DOCOD is the public expression of that work. The method, the book, the runtime and the resources can all evolve.

The question that connects them
How do we build software with agents without giving up the discipline that makes software engineering?
What does not change

Models change. Tools change. Harnesses change.

The project was not created to depend on this year's winning model, or on one IDE, or on a single agent harness. The bet is on something more durable.
  • 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.