The agentic coding workflow

What it isCopy Anchor Link

A coding agent reads your code, edits files and runs commands in a loop. The reliable way to use one has four phases. Explore: let it read the relevant code and answer questions before changing anything. Plan: have it write the approach and review it yourself. Implement: let it work in small steps. Verify: run tests, linters and the app itself, and give the agent those same checks so it can fix its own failures.

Why verification mattersCopy Anchor Link

Google's agentic engineering paper puts the difference between vibe coding and engineering in one place: how output is verified. Tests check the deterministic parts. Evals check the parts that are not. If the agent can run the check, it iterates to green on its own. If only you can run it, you are the bottleneck and the agent stops at "looks right".

Habits that pay offCopy Anchor Link

Start each task from a clean branch or worktree. Keep tasks small enough to review as one diff. Ask the agent to write a failing test first for bugs. Correct it early, because a wrong direction compounds. Clear context between unrelated tasks.

A worked example: a bug fixCopy Anchor Link

Explore: "Read the code around the checkout total and explain how the total is computed." Plan: "Propose a fix for rounding errors. Do not change code yet." Implement: "Write a failing test showing the rounding error, then fix it." Verify: run the full test suite and read the diff. Four short steps, each reviewable, beat one huge prompt.

Keeping the agent honestCopy Anchor Link

Ask for the diff, not a summary. Ask "what did you not verify?" Treat it like a very fast junior colleague: confident, tireless, sometimes wrong.

How the loop worksCopy Anchor Link

A coding agent repeats a cycle. It reads the situation, picks an action such as opening a file or running a command, sees the result, and decides the next step. This continues until it thinks it is done or you stop it. Each result is added to its context window, so the agent can react to real output instead of guessing.

Here is a short trace with invented details. You ask it to fix a failing test.

1. It runs the tests and sees one failure in a price function.
2. It opens that function and the test.
3. It edits one line, then runs the tests again.
4. A different test now fails, so it opens that one and adjusts.
5. All tests pass and it reports.

The checks in step 1 and step 3 are what steer it. Without them it would stop at step 2 with a guess.

A second example: when the plan is not neededCopy Anchor Link

Not every task needs four phases. Renaming a variable in one file, or fixing a typo in a message, takes a single instruction and a glance at the diff. Writing a plan for it costs more than doing it. Use the full routine when the change touches several files, when you do not understand the code, or when a mistake would be costly.

What goes wrongCopy Anchor Link

The typical failure is the agent saying "fixed" when it is not. You will see passing output from a test it rewrote to be easier, or a change that solves the example but breaks a nearby case. To confirm, read the diff and check whether any test file changed. Then run the tests yourself. A second failure is drift: after many steps the agent forgets an early rule. Starting a fresh session with a short summary usually helps.

Try it yourselfCopy Anchor Link

Pick a small project with tests, or write a tiny function with two tests.

1. Introduce a bug on purpose.
2. Ask the agent to explain the code, not change it.
3. Ask for a plan, and approve it.
4. Let it fix the bug, then read the diff.

Expect the diff to be short. If it touched test files, ask why.

Common mistakesCopy Anchor Link

Starting with implementation. Letting the diff grow to hundreds of lines before looking. Skipping tests because the code "looks right".

Asking for moreCopy Anchor Link

Felix Rieseberg, who works on Claude, describes four ways to ask models for more. Speed is the same work in less time. Altitude is asking for the outcome instead of the task, such as "keep our app crash-free" instead of "fix this crash". Depth is pushing the model to use the tools and rigor an expert would, for example real statistics instead of a summary table. Range is drawing on several fields instead of the one the task sits in.

A worked example of altitude. Level 1: "Write a summary of last month's sales." Level 2: "Tell me what changed last month, why, and what we should do about it." Level 3: "Design a better way for leadership to catch problems early than a monthly report, and show from our history that it would have caught last spring's dip sooner." Each level gives the model more of the goal and less of the steps.

The cost of ambition is verification. A bigger goal needs data to work from and checks that run, because a high-level goal without checks is how errors get big. "Make my business grow" fails. "Find the three biggest reasons customers cancel, using these exports" works.