Working with AI Coding Agents: A Disciplined Loop

A coding agent can write a hundred lines in the time it takes you to read ten. That speed is useful only if you can still say what the code does and why you trust it. This page describes a loop for using agents so that you ship changes you can explain, not code you merely accepted.

The method is a working recommendation, not a law of nature. Agents and their commands change quickly, so check the current documentation for whatever tool you use. Provisional

The goal: explainable change

The useful unit of progress is a change you could defend to a colleague: what it does, how you checked it, and how to undo it. If the agent wrote it and you cannot explain it, you have borrowed code, and the debt arrives later as a bug you cannot localise.

The term "vibe coding" was popularised by Andrej Karpathy in early 2025 for the style of accepting whatever the model produces and pasting error messages back until it runs. He described it as fine for throwaway projects. The loop below is for work you intend to keep. Established as to the term's origin; the judgment about when each style is appropriate is Provisional.

The loop for one change

Write the outcome and acceptance checks first. One sentence of behavior, plus how you will know it works, including at least one failure case. You write these, before prompting.
Give the agent a context file. Most agents read a plain file in the repository (Claude Code reads CLAUDE.md; other tools use similar files).
Ask for a plan before any edit. Correct the plan, not the code. A wrong plan is cheap to fix; a wrong diff is not.
Request the smallest coherent change. One feature or fix per session.
Review the diff. Explain the important lines yourself. Ask the agent, "What could this break?" and treat the answer as a lead to check, not as a verdict.
Verify. Run the checks yourself. Once, break something on purpose and confirm the check fails; a check that cannot fail proves nothing.
Commit a known-good state with a message you will understand in six months.

What belongs in the context file

Keep it short and current. A reader, human or machine, should find:

Purpose: what the project is for, in two sentences.
Structure: where the important directories and files live.
Commands: how to run, test and build it.
Conventions: naming, style, how errors are handled.
Never-touch list: generated files, secrets, vendored code, anything the agent must not edit.

Out-of-date context is worse than none, because the agent will follow it confidently.

Guardrails

Guardrail	Why it matters
One repository, one task, one known-good commit	Gives you a place to return to; Pro Git shows how to inspect and restore earlier revisions.
Secrets never in the repository or in prompts	Keys committed to history are hard to retract, and prompts may be logged. OWASP names sensitive information disclosure as a risk for LLM applications.
Synthetic data before real data	You can predict the right answer for data you made up, so you can tell when the output is wrong.
Local checks first, automated checks after	Automate only what you have already seen work by hand.
Frameworks only when coordination pain is real	Each added layer is something else you must understand and review.

Signs you have slipped into vibe-coding

You cannot say, in a sentence, what changed.
You accepted a fix without first reproducing the bug.
The agent "fixed" the test instead of the code. This is a recognisable failure shape: the goal "make the checks pass" can be satisfied by weakening the checks.
Three prompts in a row ended in "still broken."

The response is the same in every case: stop, revert to the last good commit, shrink the task, and restate the failure from evidence.

Reviewed versus accepted

Keep an honest label on every piece of agent-written code.

Reviewed: you read it and can explain what it does and what it assumes.
Accepted: it ran, and you moved on.

Only reviewed code counts as your evidence of skill. Accepted code is not forbidden, but keep it away from the parts of a system where a failure would be expensive.

A habit that helps is predict, check, correct. Before the agent answers, write down what you expect: which files will change, what the output will be. Then compare. The gap between prediction and result is where you learn; skipping the prediction removes the learning and leaves only the outcome. For the wider habit, see The Weekly Loop: Read, Reconstruct, Make, Defend, Log and Deliberate Practice: Choose Targets You Can Observe.

A prompt template

Goal: [one useful behavior]
Environment/versions: [observed facts]
Relevant files: [paths]
My attempt / current failure: [evidence]
Acceptance checks: [normal result + important failure behavior]
Constraints: [scope, data boundary, cost/time]

Inspect first and propose a plan before editing.
Make the smallest coherent change and show how to verify it.
Separate verified behavior from assumptions.
Then ask me to explain one important part before we move on.

The last line matters most. It turns the agent from author into examiner, which keeps you in the loop.

A bounded tutor prompt and a stop rule

When you use an agent to learn rather than to build, bound the exchange:

Topic and remaining time: [one topic, minutes]
Source and version: [specific section]
My explanation or attempt: [my own words]

Find the first important mistake or unsupported assumption.
Ask one question at a time and wait for my answer.
Give the smallest useful hint, then change one condition.
Check version-sensitive claims against the official source.
Separate fact, inference, and unknown.

Stop rule: when you can explain the mechanism, solve a changed case, and name the remaining limit, record the next action and end the session. More tools and tabs are optional until the next real question needs them. This is the stance of Technology, AI and Human Judgment: use the machine to sharpen the struggle, not replace it.

Why the discipline is also reasoning

Each step has a counterpart in careful thinking. Acceptance checks are predictions committed before the result; reviewing the diff is checking premises; breaking a test on purpose is looking for a counterexample, as described in Proof and Precise Reasoning: From Arguments to Theorems. An articulate agent explanation is exactly the kind of answer that Technical Writing as Reasoning teaches you to separate into observation, inference and assumption. When you are ready for agents that call tools on their own, read From Assistant to Agent: Tools, MCP and Evaluation.

Try this

Choose a small script you own. Write three acceptance checks, including one failure case, then ask an agent for a plan only. Mark where the plan is wrong before it edits anything.
After any agent-made change, close the chat and explain the diff aloud, line by line. Note each line you could not explain, and either learn it or remove it.
Take a passing test, change the code so it should fail, and confirm that it does. If it still passes, the check was not testing what you thought.