How Coding Agents Work on a Real Task
To understand why coding agents can become part of a software workflow, it helps to follow one task through the loop rather than treating the agent as a mysterious source of generated code. The focus here is the interaction among a developer, an agent, the tools around it, and the repository that supplies feedback. By the end, the useful question is not whether the model can produce a plausible answer, but where context and human judgment enter before a change is accepted.
A coding agent is an LLM running repeatedly with access to tools in pursuit of a goal. The goal might be to implement a feature, investigate a bug, or change a project’s behavior in response to a description. Unlike a conventional completion assistant, the agent can act on the environment, observe the result, and use that result to decide what to do next. The agentic quality lies in this loop of proposal, action, feedback, and further proposal.
From a task description to environmental feedback
The loop starts with an interaction sequence. At first, the sequence may contain only the developer’s task description and any context they supplied. The agent then proposes a solution or requests a tool action in a structured form. A harness—the software that connects the model to its tools—parses that response. If there is a tool call, the harness invokes the corresponding capability, sometimes after asking the developer to approve a sensitive action. The tool’s result is added to the interaction, and the agent receives that expanded context for its next step.
The sequence can be understood as a chain of state changes:
- A goal enters the loop. The developer supplies the desired outcome, constraints, or relevant project knowledge. A detailed request can reduce the amount of exploration required, but the agent may still need to inspect the repository.
- The agent forms a next action. It may ask to search files, inspect a symbol, edit a file, run a command, or perform another supported operation. The available actions depend on the harness; an agent cannot use a capability that has not been exposed to it.
- The environment answers. A search returns context, an edit changes repository state, and a build or test returns a success signal or an error. These results are not decoration. They are the observations that allow the next model call to be different from the previous one.
- The loop either continues or stops. If the goal is not complete, the agent incorporates the latest result and proposes another modification. It may stop when it judges the task complete, when a developer interrupts it, or when it needs a decision or permission that it cannot obtain on its own.
- A human-owned workflow receives the result. Depending on configuration, the agent may leave changes in the working tree, create a commit, or author a pull request. The repository’s normal review and acceptance process remains the point at which the change becomes part of the project.
The important detail is that the interaction sequence is itself a changing working context. The model does not receive one timeless description of the repository and then act outside it. It receives selected facts, requests more facts through tools, and gets results that may confirm or contradict its current assumption. Because a software project is usually larger than a model’s context window, the agent cannot hold every file and history in view at once. Dynamic queries are therefore a way to select context as the task unfolds, not merely a convenience for automating commands.
This selection can move the task through several levels of understanding. A request to change a behavior may first lead to a search for its implementation, then to an inspection of callers or related tests, then to an edit, and finally to a build or test run. Each result changes what the agent can reasonably propose next. If the search reveals that the behavior is shared by several interfaces, the original “small” change may need a wider plan. If a test fails, the failure becomes evidence about the implementation rather than an interruption unrelated to the task.
This sequence explains why repository access changes the unit of assistance. A line-completion system can be useful when the developer already knows what to write and where to put it. An agent can help when the work begins with a less localized question: find the code that handles this behavior, trace how the pieces connect, make the change, and check what breaks. The agent is not merely predicting a longer string. It is using the environment to narrow the problem and to obtain evidence about its own proposed solution.
The feedback path is especially important. A compiler can expose a type or syntax error. A test can reveal that a behavior does not match the expected contract. A repository search can show that an apparently local change has several callers. The agent can then revise its proposal in response. Without such feedback, the loop may still produce a large change, but its apparent completion rests more heavily on the model’s judgment and the developer’s review.
The loop can also produce useful context without producing a final change. An agent may investigate an unfamiliar code path, compare possible approaches, or prepare an explanation before the developer decides not to edit the repository. Conversely, an agent may produce a change that compiles but should not be accepted because the task’s intent was misunderstood. “Completion” in the agent’s interface is therefore a report about the loop’s stopping condition, not an independent certificate that the software requirement has been met.
The same mechanism also permits exploratory work. The agent can adapt its context to the task by querying the codebase rather than receiving a fixed prompt assembled in advance. It can inspect unfamiliar areas, test an assumption, and continue from what it finds. That flexibility is one reason coding agents can attempt work at a broader scope than a completion assistant. It is also a reason their behavior is harder to predict from the initial request alone: the eventual path depends on what the environment reveals and on which tools are available.
The diagram’s loop is not a promise that every agent follows the same path. Some tools expose a terminal with broad flexibility; others provide narrower, more controlled operations. Some ask permission before edits or shell commands, while others are configured for more autonomy. The mechanism is stable enough to describe, but the exact boundary of action belongs to the product and its harness.
Where autonomy stops and responsibility begins
Calling an agent “autonomous” can hide several different responsibilities. The agent may be able to choose its next search or modification without a new sentence from the developer, but that does not mean it owns the project’s goal, the permissions around the repository, or the decision to merge. A more useful account follows what crosses each boundary.
The developer owns the objective and the acceptance judgment. They decide what problem matters, what constraints are relevant, and whether the final change is appropriate. They can supply guidance at the start, correct the agent during the loop, or stop it when the work has moved in the wrong direction. In an asynchronous workflow, the developer may let the agent work while attending to another task, but the ability to return later is not the same as transferring responsibility for the outcome.
The harness owns the interface between model output and real actions. It presents the available tools, interprets structured tool requests, applies permission rules, and sends results back into the interaction. This is the control surface for autonomy. If a sensitive operation requires approval, the harness can pause the loop at that point. If the tool is unavailable or restricted, the agent must work within that limit or ask for another path. The model’s apparent freedom is therefore bounded by the harness’s design.
The boundary can be narrow or broad. A controlled environment may expose only selected operations, making the agent’s possible actions easier to constrain. A terminal-like tool can provide more flexibility, but it also places more importance on permission settings and on the developer’s understanding of what the agent may execute. The supplied evidence describes these as different workflow choices, not as a universal progression from safe to capable. More tools can provide more ways to gather context and act, while also creating more points at which an unsuitable action must be stopped or reviewed.
The repository and its surrounding tools own environmental facts. They can report what files exist, what a command produced, or whether a test passed. That feedback can constrain the agent’s next proposal, but it does not itself decide whether the change is desirable. A green test suite may show that the exercised behavior still passes; it does not necessarily show that the untested requirement was understood. Conversely, a failing test can be useful evidence even when it does not immediately identify the right fix.
The developer’s review process owns acceptance. An agent can make a commit or open a pull request when configured to do so, but those actions are records or requests within a software workflow, not proof that the work belongs in the main branch. The handoff from agent to repository is therefore not a single “done” event. It is a boundary: the agent reports a proposed completion, and human-controlled review decides what becomes durable project state.
Project-specific guidance influences every boundary. General model knowledge cannot contain all of a repository’s tacit conventions. A guidance file or equivalent instruction can describe project structure, coding norms, build and test commands, contribution expectations, and other local knowledge. The agent can use that material when starting or continuing an interaction, reducing the need to rediscover it. In this sense, guidance is part of the workflow’s memory.
The public-project evidence shows that this memory varies substantially. Among projects with visible guidance or rule files, more than half had a single such file and more than 85% had five or fewer. A smaller group maintained much larger collections. Maintenance varied as well: some projects added a file and never changed it, while others revised or added guidance repeatedly. These figures show that teams are encoding local knowledge at very different levels of intensity; they do not show that a longer or more frequently edited set of instructions produces better agent outcomes.
That memory has limits. A guidance file may be minimal, extensive, unchanged, or frequently maintained; its presence alone does not show that the agent is used intensively or that the instructions are effective. Nor can guidance replace feedback from the repository. Instructions can state how a project should behave, while tests and builds reveal how the current change actually behaves. Durable use depends on the two forms of context working together: explicit local knowledge sets expectations, and environmental feedback checks the consequences.
Tacit knowledge is the harder case. Experienced developers often know which parts of a system are fragile, which shortcuts create maintenance problems, and which apparent requirements are incomplete. If that knowledge never reaches the agent, the model may explore the wrong area or choose a locally reasonable but globally awkward design. Providing context can improve the odds of a useful delegation, but the evidence does not support a rule that more guidance always produces better outcomes. The quality of the interface between guidance, task description, and feedback matters more than the mere volume of instructions.
Failure can occur at each point in the loop. The initial task may be underspecified. The agent may search too broadly or misread the returned context. A permission boundary may halt the task until the developer clarifies the next step. The repository may have no test suite capable of checking the relevant behavior. A build may pass while an important non-functional requirement remains unexamined. Or the agent may stop because it believes the goal is complete even though the human reviewer sees a missing case. These are not exceptional defects in an otherwise autonomous system; they are normal consequences of distributing work across a model, a harness, an environment, and a person.
The failure path also explains why retries are not automatically progress. If the agent receives the same incomplete context and repeats a similar proposal, another loop iteration may add activity without adding understanding. A useful retry changes something material: the developer clarifies the goal, the agent gathers a missing part of the codebase, a test supplies new evidence, or a permission decision changes what action is possible. Without a new fact or a changed constraint, repetition can make a workflow look active while leaving the underlying uncertainty untouched.
This distribution is why the transition from trial to workflow is a systems question. A one-off experiment can succeed because the task is small, the developer supplies unusually rich context, or the result receives unusually close inspection. Repeated use asks whether the same boundaries remain intelligible under ordinary conditions: whether tasks can be framed, local knowledge can be supplied, feedback can be obtained, and responsibility can be handed back to the human process without ambiguity.
A coding agent therefore should not be judged only by how much it can do without interruption. The more consequential measure is whether its loop produces changes that people can understand, verify, and own. The next question is how researchers can observe these loops at all when much of the interaction occurs inside a developer environment or a cloud service and may leave only partial traces in the project record.