Your AI Agent Can Write the Code. Docod Knows Whether the Engineering Is Still Valid.

Fabio Valencio

7 min read

·

Sep 12, 2026

--

Listen

Share

AI-native development does not only need better specs, agents, and workflows. It needs a way to determine whether requirements, decisions, approvals, implementation, and evidence still agree after the project changes.

Press enter or click to view image in full size

AI has made implementation dramatically faster.

An agent can inspect a repository, change multiple files, run tests, fix failures, review a diff, and deliver working code in minutes.

That changes the bottleneck.

The difficult question is no longer only:

Can the agent implement this?

It is:

After dozens of humans and agents change the project, can we still prove what is valid?

That is the problem Docod was built to address.

Docod is executable governance for AI-native software engineering.

It does not only record engineering state.

It derives that state from the repository and determines when previously valid engineering decisions are no longer valid.

The problem is not missing documentation

Imagine a project with everything modern AI engineering says you should have:

PRD
 ↓
Functional Requirements
 ↓
Architecture
 ↓
Tasks
 ↓
Implementation
 ↓
Tests

The PRD was approved.

The architecture was reviewed.

The tasks were extracted.

The implementation was completed.

The tests passed.

Everything looks healthy.

Then someone changes the PRD.

One sentence.

Now answer these questions:

• Is the FRD still valid?
• Is the architecture still approved?
• Are the extracted tasks still correct?
• Does the implementation still satisfy the requirement?
• Do the existing tests still prove the right behavior?

The fact that all those artifacts exist does not answer those questions.

Neither does Git.

Git tells you what changed.

An audit trail tells you what happened.

A workflow tells you what should happen next.

Docod asks something different:

What is still valid now?

Approval is not a status

A common workflow represents approval like this:

status: approved

That creates an important ambiguity.

Approved what?

Suppose architecture.md is approved today and edited tomorrow.

Is it still approved?

Docod binds approval to the content itself:

approval:
  by: reviewer
  at: timestamp
  content_hash: abc123

Change the content:

previous hash: abc123
current hash:  def456

The approval no longer matches.

Docod can determine mechanically:

APPROVAL INVALID

No agent needs to remember that the document changed.

No developer needs to manually reset a status.

No prompt needs to say:

Please check whether this approval is still current.

The repository already contains enough information to answer the question.

This distinction is fundamental:

“This was approved” is history.
“This is still approved” is validity.

Docod cares about both.

Validity propagates

Engineering artifacts do not exist independently.

A requirement can justify a design decision.

That design can produce tasks.

Those tasks produce implementation.

The implementation produces evidence.

Conceptually:

PRD
 ↓
FRD
 ↓
Architecture
 ↓
Tasks
 ↓
Implementation
 ↓
Evidence

When something upstream changes, Docod does not simply assume everything downstream remains correct.

It can require impact analysis.

For example:

PRD
CHANGED

FRD
IMPACT REQUIREDArchitecture
IMPACT UNKNOWNTasks
BLOCKED

This does not mean every change invalidates everything.

That would turn governance into bureaucracy.

Sometimes the correct conclusion is:

No downstream impact.

Fine.

But now that conclusion is explicit.

Someone analyzed it.

The reasoning can be preserved.

And the project can continue deliberately rather than accidentally.

“Done” is also a claim

AI agents are extremely good at sounding certain.

An agent can say:

Implementation complete. All tests pass.

That is useful.

It is not evidence.

Docod treats completion as something that needs proof.

For example:

command:
npm test

result:
217 tests passed

Or:

command:
pnpm lint

result:
0 errors

The important distinction is:

“The agent says the tests passed.”

versus:

“The repository contains verifiable evidence that the tests passed.”

And even stored evidence has a lifecycle.

Tests passing yesterday does not necessarily mean they pass against today’s repository.

So evidence can be reverified.

Again, the question is not only:

What happened?

It is:

Does that evidence still apply to the current state?

The producer should not be the verifier

Consider an autonomous workflow where one agent:

1. interprets the requirement;
2. designs the solution;
3. writes the code;
4. writes the tests;
5. runs the tests;
6. reviews itself;
7. declares success.

That is automation.

It is not necessarily governance.

Docod applies a simple principle:

producer ≠ verifier

The entity producing the work should not automatically become the final authority declaring the same work correct.

Humans have used separation of responsibility for decades.

AI makes that distinction more important, not less.

Docod is about lifecycle validity

A lot of the current discussion around AI software engineering focuses on artifacts.

Specs. Plans. Tasks. Rules. ADRs. Tests. Audit logs.

That is progress.

But artifacts alone are not enough.

A project can have excellent documentation and still be inconsistent.

A spec can be outdated.

An ADR can depend on assumptions that no longer exist.

A test can perfectly validate obsolete behavior.

A completed task can belong to an older requirement.

An approval can refer to content that has since changed.

So Docod treats software engineering as a graph of relationships whose state can change over time.

The important question is not:

Do we have the artifact?

It is:

Is this artifact, decision, approval, task, or evidence still valid in the current project state?

That is the layer Docod makes executable.

Define · Orchestrate · Confirm · Observe · [re]Define

Docod structures the lifecycle around five movements.

Define

Establish what must be true.

Requirements. Functional behavior. Architecture. Constraints. Trade-offs. Decisions.

And human approval where judgment matters.

Orchestrate

Translate approved intent into executable work.

Generate project-specific rules.

Extract tasks.

Provide agents with the context and constraints required to execute them safely.

Confirm

Do not accept implementation because an agent reports success.

Build. Test. Run behavioral QA. Review code. Review design. Collect and verify evidence.

Observe

Derive the current state of the project.

What remains approved?

What became stale?

What is blocked?

Where did upstream changes create uncertainty?

What claims still have valid evidence?

[re]Define

Software does not stop changing after deployment.

Production reveals new information.

Requirements evolve.

Architecture assumptions stop being true.

Incidents expose missing constraints.

That reality feeds back into definition.

And the validity graph changes again.

Why Docod has a runtime

You can describe all these ideas in documentation.

But documentation cannot enforce itself.

A rule can say:

Re-run impact analysis when an approved requirement changes.

Who notices the change?

A process can say:

Never execute against an invalid specification.

Who determines that the specification is invalid?

A methodology can say:

Obtain approval before proceeding.

What happens when the approved content changes afterward?

That is why Docod has a runtime.

The method defines the engineering contract.
The runtime verifies the parts of that contract that machines can verify.

The repository is the source of state

Docod does not depend on an agent remembering what happened in previous conversations.

Sessions disappear.

Models change.

Context gets compressed.

People leave teams.

The repository remains.

Docod derives state from the artifacts themselves.

That includes things such as:

what exists
what was approved
whether that approval is still valid
what depends on what
what changed
what requires impact analysis
what is blocked
what has evidence
whether that evidence still verifies

The state is not a story maintained by an LLM.

It is derived.

This matters even more in legacy systems

Greenfield development is the easy version of the problem.

Real systems often look more like:

years of code
+ undocumented behavior
+ stale documentation
+ old architecture decisions
+ partial tests
+ production reality

You cannot simply create a new specification and declare it the source of truth.

The code already contains truth.

The database contains truth.

Production behavior contains truth.

And sometimes those truths contradict the documentation.

Docod approaches legacy software from the opposite direction:

code
 ↓
rules extraction
 ↓
reverse design
 ↓
data / API understanding
 ↓
baseline
 ↓
approved evolution

The goal is to establish a trustworthy baseline before asking agents to accelerate change.

Better agents do not eliminate this problem

Claude Code will improve.

Codex will improve.

Gemini will improve.

Future coding agents will be vastly more capable than today’s.

Docod assumes they will.

But better generation does not remove the need for engineering validity.

It increases the number of changes an organization can produce.

And that makes questions like these more important:

Why does this code exist?

Which requirement does it implement?

Who approved the decision behind it?

Is that approval still valid?

What changed upstream?

What evidence proves this behavior?

What needs reconsideration because something else changed?

As throughput increases, relying on humans to keep all those relationships synchronized becomes less realistic.

Agents need autonomy. Engineering needs invariants.

Docod is not trying to control every decision an AI agent makes.

An agent should be free to decide:

How should I implement this?

It should not silently decide:

What should this requirement mean now?

An agent should be free to ask:

How do I fix this failing test?

But governance should answer:

Does this test still prove the current requirement?

Agents operate inside the boundaries.

Docod makes the boundaries explicit.

The goal is not more process

Executable governance can easily become executable bureaucracy.

That would miss the point.

A small change should not require the same controls as a security-sensitive architecture change.

A prototype should not behave like a regulated production system.

Governance should be proportional to risk.

Docod should be able to conclude:

No meaningful impact.
Proceed.

just as confidently as:

Upstream changed.
Impact unknown.
Blocked.

The objective is not to maximize gates.

It is to minimize silent inconsistency.

Knowing what happened is not the same as knowing what is still true

This is the central idea behind Docod.

Software engineering already has excellent systems for history.

Git records changes.

CI records executions.

Issue trackers record work.

Audit logs record actions.

What AI-native engineering increasingly needs is another capability:

continuous knowledge of engineering validity.

Was this exact content approved?

Does that approval still apply?

Does this downstream artifact still correspond to its upstream dependency?

Does this evidence still prove the current implementation?

Can execution safely continue?

That is what Docod is trying to make executable.

That is Docod

Docod is an open-source governance runtime for a world where humans and AI agents build software together.

Its premise is simple:

Do not confuse recorded state with valid state.

Make intent explicit.

Bind approvals to content.

Track dependencies.

Propagate impact.

Separate production from verification.

Require evidence for claims.

Reverify that evidence when necessary.

Derive state from the repository.

And when something changes, determine what is still true before continuing.

Define · Orchestrate · Confirm · Observe · [re]Define

Agents can write software faster than ever.

Docod exists to make sure the engineering around that software remains valid.

visit: https://docod.ai runtime: https://github.com/docod-ai/getdocod