The agentic coding loop verified by execution

Generative AI used solely through a conversational chat interface serves primarily as a search and drafting tool. Commanded as an autonomous agent, however, it shoulders repetitive, mechanical execution. That shift frees your attention for the decisions that require genuine human judgment: determining what to build, establishing the standards it must satisfy, and knowing when to reject inadequate work. The output remains only as sound as your architectural direction and the constraints you establish. Every pattern in this module acts as a structural mold: a concrete method for translating your engineering judgment into enforceable instructions that govern the model as it edits.

A coding agent immediately encounters a physical boundary: a modern codebase is far larger than any single context window can accommodate. The foundation module on language models demonstrated that a context window represents a strict token budget: a 128,000-token window holds roughly 96,000 words, comparable to a 350-page book. An active repository quickly exceeds that boundary. When you paste an entire repository into the prompt, you saturate the window with irrelevant material that has nothing to do with the immediate task. Because every token in the active context conditions every subsequent output token, this extraneous text degrades the model’s attention, and critical source files get overlooked. If you overfill the window, one of two failures occurs: the underlying API returns an error, or the execution harness quietly truncates the earliest conversation turns without indicating what was lost. Effective agentic coding is therefore an exercise in context management: carefully governing what enters the window, and precisely when.

We examine two core structures in this module. The first is the agentic coding loop: plan, edit, run, verify, and commit, where verification depends strictly on external execution rather than textual inspection. The second is a system of four repository instruments that load at different phases of execution, enabling an agent to navigate a large repository without loading the entire codebase into the context window. Our concrete specimen is the build system for this educational platform itself. One statement about this module’s specimen and pictures, made once. The trace records the run that built the interactive checkpoints in these lessons, with turns removed so it fits the page and nothing added. The loop figure draws one trip around a loop that a real feature circles several times. The bar lengths in the context-cost figure are shaped to show which instrument is in the window and when it is paid for, and measure no token count; the staircase figure is shaped the same way. By the end of this module, you will be able to operate the loop, assign instructions to their proper repository instruments, and explain how the repository’s context accumulates across development cycles.

agentic coding follows a five-step loop

The workflow follows five clear steps, and the fourth is the one developers most often neglect.

The worked example is a small web app with its own backend: a page, a server that handles the visitor’s questions at /api/ask, and an agent behind it.

A one-line feature request arrives:

“Refuse a question longer than 500 characters with a message the visitor can read.”

Plan. Read the relevant portions of the codebase, map the required changes, and produce a structured, human-reviewable plan before modifying any files. In this repository’s workflow a human approves that plan before editing begins; that approval is a policy we chose, and the coding tools leave the choice to you.

Edit. Apply precise, targeted modifications to specific files.

Run. Execute the build system, invoke the linter (the tool that statically checks code for syntax and style errors), and start the local environment to move the changes from theory into execution.

Verify. Run the test suite, inspect the resulting runtime output, and confirm that every test passes. A passing run establishes that the behaviors those tests exercise hold, for the new feature and for the existing code.

Commit. Update any documentation affected by the implementation, and commit those documentation updates alongside the code.

If tests fail during verification, the agent returns to the edit step with the concrete failure output in hand, repeating the cycle until the test suite passes.

The agent finishes implementing the 500-character limit on questions and reports: “I’ve added the length check to the /api/ask handler. I reviewed the diff and the code looks correct.”

verification means execution, not model judgment

Why is an agent incapable of verifying software simply by reading its own code? Because asserting that “the code looks correct” is precisely the sort of plausible text language models are optimized to generate. Recall the core mechanism: a model produces the most statistically probable continuation of a prompt. After generating a plausible code diff, the statement “this change is correct” represents an overwhelmingly likely sequence of tokens. That assertion, however, provides zero technical evidence that the code actually compiles, runs, or handles edge cases. It is a confabulation about software state. Nothing inside a generated response distinguishes an ungrounded fabrication from an empirical fact, so verification has to originate outside the model.

The same vulnerability shows up in tool execution. Asked whether a write operation succeeded, an agent routinely generates the expected continuation: “done.” The safeguard is read-back verification: refusing to report success until a subsequent read confirms the updated state in the underlying system. Executing the build pipeline is simply read-back verification applied to software engineering.

Genuine verification requires running the compiler and reading the process exit code, running the test runner and recording which test assertions failed, and issuing real HTTP requests to verify status codes returned by the server. These are empirical facts generated outside the neural network. This discipline forms the foundational rule of the agentic loop:

Verification comes from outside the model. It is a fact the run produced: an exit code, the name of a failing test, an HTTP status, a page exercised in a real browser. “The code looks correct” is a continuation, never a check. Anything not run is still a proposal.

Develop this operational habit: whenever an agent claims an implementation works, examine what commands it actually executed. If its only evidence is that it inspected the diff, the workflow has not completed step four. A clean exit code establishes that the assertions the suite executed passed under the tested conditions. Branches no test exercises, the readability of the diff, and whether the documentation describes the new behavior lie outside what the run checked; a person, or a further check such as a page exercised in a browser, still covers them before you accept the commit.

Consider an agent executing this complete loop on a live repository feature: the run that implemented the interactive checkpoints on this platform.

In that run, the four repository instruments enter the context in sequence. The rules file resided in the prompt before the session began. The first skill activated before any code was planned, retrieving two specific knowledge documents. A human-approved plan locked in the architectural design before any files were modified. The build ran, followed by an automated browser session that intentionally submitted incorrect answers to test validation boundaries. Two additional skills executed at completion, bundling documentation updates into the final commit alongside the code. The resulting inventory is exact: one rules file, three skills, and one reviewed plan artifact enforced rigorous engineering standards without requiring manual line-by-line prompting. Let us examine how each instrument functions.