The Model Should Decide. The System Should Edit.

AI coding agents are useful because software work contains judgment.

A model can look across code, runtime evidence, product context, and alternative designs and answer questions such as:

• What does this mangled binding represent?
• Which responsibility owns this behavior?
• Which of three module boundaries is clearest?
• Is this vendor-like region safe to replace or should it remain captured?
• Does the current evidence support a change?
• What additional evidence would resolve the ambiguity?

Those are meaningful decisions.

They do not require giving the model unrestricted authority over the repository.

That distinction is the center of Kalu Kode’s current architecture.

The conventional agent loop

A normal coding-agent workflow often looks like this:

1. The agent reads the repository.
2. The agent forms a plan.
3. The agent edits files.
4. The agent runs commands.
5. The agent repairs what failed.
6. The agent declares completion.

This can work extremely well.

It also combines four different responsibilities in one actor:

• interpretation;
• mutation planning;
• mutation execution;
• acceptance.

When the task is ambiguous or long-running, that combination creates avoidable risk.

The same model that chose the design can widen the scope, alter the contract, weaken a test, create a compatibility layer, and then interpret its own checks as sufficient.

Even a highly capable agent is being asked to supervise itself.

A different loop

The judgment-loop model separates the roles.

1. The system inspects the current source and evidence.
2. It drains work that can already be proved and applied deterministically.
3. When it reaches one semantic uncertainty, it creates a bounded packet.
4. The model returns a typed decision.
5. A source-aware engine converts that decision into an exact plan.
6. The system previews and applies the plan transactionally.
7. Independent checks accept, reject, or request more evidence.
8. The result is checkpointed or rolled back.
9. The system refreshes evidence and continues.

The model is still essential.

It is no longer the repository operator.

What belongs in a judgment packet

A good packet should be small enough to reason about and complete enough to avoid blind guessing.

Depending on the task, it may contain:

• exact source checkpoint and hashes;
• target symbol or region identity;
• relevant code slice;
• callers and consumers;
• runtime observations;
• protected surfaces;
• dependency and ownership evidence;
• candidate options;
• rejected or unsafe options;
• allowed decision type;
• required response schema;
• confidence request;
• refusal reasons;
• validation tier that will follow.

The packet should not ask:

Clean up this repository.

It should ask something closer to:

This source-bound binding is observed as a Three.js object followed by the active camera and updated from input state. Choose one semantic role from the supplied candidates, propose another, or refuse because the evidence is insufficient.

That is a judgment task, not an open-ended migration.

Typed responses create discipline

A useful response can include:

• decision;
• confidence;
• evidence used;
• concise rationale;
• rejected alternatives;
• more-evidence request;
• refusal reason;
• authority escalation where required.

The system should distinguish:

• accepted;
• rejected;
• needs more evidence;
• wrong task type;
• unsupported;
• policy decision required.

A refusal is not a failed model call.

It can be the safest and most informative result.

The actuator owns mechanics

Once a decision exists, a deterministic actuator should own the mutation.

For a rename, that means:

• resolve binding identity;
• enumerate references;
• exclude protected or textual surfaces;
• check collisions and shadowing;
• generate the exact patch;
• bind the patch to source hashes;
• preview the diff;
• apply atomically;
• run the declared evidence;
• roll back if red.

For a module move, it may mean:

• establish the move set;
• rewrite direct consumers;
• preserve exports;
• test cycles;
• preserve initialization-sensitive declarations;
• delete the old path only after consumers move;
• reject barrels or compatibility bridges when policy forbids them.

For dependency externalization, it may mean:

• prove package identity;
• identify the whole runtime family;
• plan consumer rewrites;
• compare export shape;
• run module and runtime checks;
• refuse partial singleton replacement.

These are mechanical responsibilities with exact inputs and outputs.

They should not be reconstructed through ad hoc text editing every time.

Why this helps weaker and stronger models

A strong model can make better semantic decisions on difficult packets. A cheaper model may still handle clear classifications or choose among bounded options.

Because the system owns the evidence and edit mechanics, the product does not depend on one model vendor.

The routing policy can be:

• inexpensive model for simple, high-evidence choices;
• stronger model for ambiguous cross-file reasoning;
• multiple models for adjudication;
• human decision for authority or product-policy questions;
• no model when the deterministic rule already exists.

As models improve, the judgment quality can improve.

The control system remains valuable.

The deterministic frontier should expand

The judgment loop is not an excuse to ask models the same question forever.

Every packet and outcome can become a learning episode:

• what evidence was present;
• what decision was made;
• whether it passed;
• whether it was later corrected;
• which conditions predicted success;
• which refusal was appropriate.

Repeated successful patterns can become candidate deterministic rules.

Those rules should then be tested against:

• positive fixtures;
• negative fixtures;
• known-bad mutations;
• framework and version constraints;
• held-out applications.

Once a rule is calibrated, the system no longer needs judgment for that class.

The deterministic frontier grows.

This applies to recovery and change control

In KodeBack, the model may decide:

• a semantic role;
• a source ownership boundary;
• an ambiguous vendor classification;
• a scoped capability policy;
• a decomposition option;
• whether evidence is insufficient.

KodeBack then performs the exact recovery or cleanup transaction and checks it against the deployed authority.

In KodeProof, the model or coding agent may choose the desired refactor. KodeProof binds that intention to an isolated transaction, deterministic plans where available, configured evidence, and controlled transfer.

The products use different evidence and success criteria.

They share the same principle:

Judgment does not require unrestricted mutation authority.

What this architecture does not solve

Not every change can be expressed through a mature actuator today.

New features, unfamiliar frameworks, product design, and broad architectural work may still require an engineering agent to write code.

Even then, the transaction model remains useful:

• isolate the candidate;
• bind the objective;
• declare protected contracts;
• preserve exact evidence;
• prevent unauthorized transfer;
• distinguish behavior from coverage;
• retain a rollback and audit trail.

The architecture should expand coverage without pretending it already covers every task.

The practical promise

Kalu Kode is not trying to remove models from software engineering.

It is trying to put their strongest capability—judgment—inside a system that does not confuse a good explanation with a safe mutation.

The model should decide where meaning is required.

The system should edit where mechanics can be controlled.

The evidence should decide what survives.