The Loop Engineering Commandments
Prompting gives answers. Loops ship work.
That is the core shift behind agentic coding.
Most people still treat AI coding agents as smarter autocomplete: ask for a function, get a patch, review the output, repeat. That is useful, but it is not the real unlock.
The unlock is loop engineering.
A prompt is a single instruction. A loop is a system: define the goal, build, verify, fail, repair, restart, and repeat until the work survives contact with tests, reviewers, and users.
After building Lexomat, a full-stack legal AI product, across enough real features to see the same patterns repeat, these are the commandments I now use for agentic building.
- Write the loop, not the prompt
The question is not "what should I ask the agent?"
The better question is: "what loop will let the agent verify its own work?"
An agent that can write code but cannot test, inspect, or evaluate it is only doing half the job. The human becomes the verification layer, which means the loop never really closes.
The goal is to design workflows where the agent can build, check, fail, fix, and retry without needing you every five minutes.
- Separate planner, builder, and evaluator
The planner should turn vague goals into a concrete spec.
The builder should implement against that spec.
The evaluator should assume the work is broken and try to prove it.
Mixing these roles is one of the fastest ways to produce slop. When the same agent writes and grades its own work, it becomes too forgiving. Separate roles create tension, and that tension improves the output.
- Define the contract before code
Before the builder writes a single line, define what "done" means.
Not in vague language.
Not "the login should work."
A real contract says what happens for invalid credentials, expired sessions, missing tokens, valid sessions, edge cases, and regressions. It gives the evaluator something concrete to test.
The quality of the build is usually decided before the build starts.
- Write state to disk
Context windows drift. Files do not.
Long-running agent sessions need persistent state outside the chat: plans, verification notes, architectural rules, progress logs, and decisions.
In Lexomat, this means files like CLAUDE.md, PLAN.md, VERIFICATION.md, and STATE.md. They act as long-term memory that survives context resets and prevents the agent from quietly losing the plot.
If the state matters, write it down.
- Make verification adversarial
A soft evaluator finds soft bugs.
A good evaluator starts with the assumption that the code is broken. Its job is not to admire the implementation. Its job is to attack it.
Run tests. Read diffs. Look for missing coverage. Check edge cases. Ask what could regress. Treat independent reviewers that converge on the same issue as a serious signal.
The evaluator should not be polite. It should be useful.
- Keep the harness short
Your agent harness should be a living artifact, not a junk drawer.
Every permanent instruction has a cost. If the model now handles something reliably without being told, delete the rule. Keep only the invariants that still matter.
A short harness that the agent actually follows is better than a long harness full of ignored rules.
- Let bad iterations die
The best agents are willing to restart.
That is a feature, not a failure.
Patching a bad direction forever creates archaeological code: layers of fixes over a flawed foundation. Sometimes the cleanest path is to throw away iteration nine and ship iteration eleven.
The human should intervene when the contract is wrong, not every time the build struggles.
- Review at the right cadence
Review too often and you become the bottleneck.
Review too rarely and the agent compounds the wrong direction.
The developer feedback loop should run over meaningful chunks of work: long enough for the agent to complete real inner-loop iterations, short enough for the human to correct direction before the cost grows.
For me, that usually means reviewing after the agent has had time to produce something substantive, not after every tiny step.
- Follow the bottleneck
When coding stops being the bottleneck, planning becomes the bottleneck.
When planning improves, verification becomes the bottleneck.
When verification improves, taste becomes the bottleneck.
In domain-heavy products, another bottleneck appears: correctness. For Lexomat, the hard question eventually became whether the product was actually right about Slovak law.
The point of better loops is not to remove bottlenecks forever. It is to make the next bottleneck visible.
- One problem per context
When problem B appears while solving problem A, file it. Do not fix it inline.
This feels slower. It is usually faster.
Bundling unrelated problems pollutes the context, complicates the diff, makes review harder, and makes rollback riskier.
One problem. One contract. One context. One clean loop.
The real skill is not prompting
The biggest misconception about agentic coding is that success comes from clever wording.
It does not.
The real skill is designing the system around the agent:
a planner that asks the right questions, a builder that works against a testable contract, an evaluator that assumes the work is broken, persistent state that survives context loss, and a human who knows when to steer instead of micromanage.
That is loop engineering.
Prompting gives answers.
Loops ship work.