AI Tools Field GuideCoding with models
A coding agent reads your files, edits them and runs commands, and its results are program output: long, precise, and the first thing the window drops. Run a session that produces something you would sign, keep the record outside the transcript, and apply the review that tells a working script from a plausible one.
What an agentic coding session is
A coding agent is the agent loop with a specific tool set: read and edit files, run commands, read what the commands printed. You describe the change; it reads the code, plans, edits, runs the tests, reads the failures, edits again, and reports. The model is the same one you chat with. The difference is that its tool results are program output, and program output is long, precise, and unforgiving of the two things a context window does to it.
Where this happens is a question for your organization. Coding agents run as vendor command-line tools or editor extensions on a developer workstation, against the vendor's API, and whether any of that is authorized where you sit is for your CIO or data shop to say. The discipline below is the same wherever the session runs.
Two caveats that explain "it forgot the error"
| Caveat | What happens | What good sessions do |
|---|---|---|
| Truncation | Large outputs are cut (the head and tail of a log, the first kilobytes of a file) before they enter the context. The model may not have seen the whole thing. | Redirect big output to a file and search it for the lines that matter. |
| Compaction | Tool results are the first thing summarized or dropped when the window fills. | Write the error, the fix, and the test result to a file or a commit message. |
After compaction the agent may remember that something worked and not why the previous attempt failed, and repeat the attempt. The record has to live outside the transcript: in files, in version control, in a notes file the agent is told to keep.
The shape of a session that produces signable work
- State the task and the test for done
- Let it plan; correct the plan
- Let it edit and run the tests
- Read the diff, not the summary
- Commit small
- Repeat
The fourth step is the review discipline. Everything else is setup for it.
- State the test for done before the agent starts: the command that must pass, the output that must appear. "Make the report script work" is not a task; "the script runs on last week's inputs and produces a CSV with these columns and no empty rows" is.
- Read the plan and correct it. An agent that starts with a wrong plan produces a convincing wrong solution. Two minutes here saves an hour.
- Small scope. One change, one commit, one test. Large tasks compact the transcript before they finish and the agent loses the thread.
- Read the diff. The agent's summary of what it did is its opinion. The diff is what it did. Reading the diff is the whole job of the person in the loop, and it is not optional because "the tests pass".
- Version control is the memory. Every accepted step is a commit. When the session goes wrong, you revert to the last good one instead of asking the agent to remember.
Where sessions go wrong
| Failure | What it looks like | Your defense |
|---|---|---|
| Claims the tests passed | "All tests pass" with no test run in the transcript | Find the run. No run, no pass. |
| Makes the test pass by changing the test | The diff touches the test file more than the code | Read the diff; tests are reviewed harder than code |
| Guesses a library's interface | Code that looks right and fails at run time | Make it run the code, and read the output yourself |
| Deletes or overwrites to "clean up" | Files gone that the task did not mention | Commit before the session; narrow the tools; read the diff |
| Loops on the same error | The same fix applied three times after compaction | Stop; write the error and the attempts to a file; restart from it |
| Secrets in the transcript | A key or a password pasted into the chat | Never. Environment variables; the transcript is a document like any other. |
The last row is the one with consequences beyond the code. A coding session sees your files; it must never see a credential, and it must never run against production data or a system of record. Give it a copy.
The review discipline
The model wrote it, so you own it. That is the rule, and it is the same as the verification checklist for a memo, with harder consequences: a wrong number in a draft is caught by a reader, a wrong condition in a script runs every night. So the output of a session goes through the same review as a colleague's change would: someone who did not write it reads the diff, runs the test, and asks what happens on the input nobody thought of. The agent is fast; the review is not, and it is not supposed to be.
What to do with this
Next time you use a coding agent, write the done test first and read every diff before you accept it. That ends the Advanced tier. If you want the depth this guide points at, the four companion books are on the training page; if you want a program or a credential, read Training and certification.