Agentic coding

Agentic coding is letting an AI agent read, write, and run code in a loop, checking its own results and trying again, rather than handing back a single block of code and stopping. Once the agent can do the typing, the hard part is no longer producing code. It is giving the agent an accurate picture of the system it is about to change.

What agentic coding actually is

A plain code assistant does one thing: you ask for some code, it writes some code, you copy it somewhere and see if it works. The loop of trying, failing, and fixing is all yours. An agent closes that loop itself. It is a language model wrapped in software that lets it take actions, and in coding those actions are the everyday moves a developer makes: open a file and read it, change some lines, create a new file, run the tests, read what the tests printed, and go around again.

The word that matters is loop. The agent does not produce one answer and stop. It works toward a goal in steps, and after each step it looks at what happened and decides what to do next. Ask it to fix a failing test and it might read the test, read the code the test exercises, form a guess about the bug, change a line, run the test again, see it still fail but differently, and adjust. That cycle of act, observe, adjust is what makes it agentic rather than a one-shot generator.

Concretely, an agentic coding tool has a small set of powers. It can list and read files, so it can look at the code as it exists. It can write and edit files, so it can make changes. It can run commands, most importantly the tests and the program itself, so it can see whether a change worked. And it can read the output of those commands, so the result of each action feeds the next decision. Those few powers, used in a loop, cover a large share of what building and fixing software involves.

Where it is genuinely strong

It helps to be honest about what this does well, because the strengths are real. An agent is fast and tireless at the mechanical parts of coding. It can make the same small change across many files without getting bored or missing one out of forty. It can write the routine code that surrounds an idea, the parts that are more typing than thinking. It can read an error message and a stack trace faster than a person can scroll to them, and it does not need coffee or a good night’s sleep to do it at three in the afternoon or three in the morning.

It is also strong at starting things. Faced with a blank file, a person often stalls. An agent will produce a reasonable first version of almost anything, which you can then correct. It is good at translating between forms it has seen many times: turning a description into a standard piece of code, turning one data format into another, writing the tests that match a function. For work that is well-trodden and self-contained, an agent is a strong pair of hands.

And because it runs the tests, it can tell when a well-defined change succeeded. If the goal is crisp, make this test pass, add this field, rename this thing everywhere, the agent has a clear signal for whether it is done. That combination, tireless typing plus a clear pass or fail signal, is where agentic coding earns its place.

Where it fails

The failures are just as real, and they cluster in one place: whenever the task depends on understanding that is not in front of the agent. A model brings general knowledge of how code usually looks. It does not, on its own, know how this particular system is wired, which piece depends on which, or why a past decision was made the way it was. When it lacks that and acts anyway, it acts on a plausible guess.

The most common failure is a change that is locally correct and globally wrong. The agent edits a function so that the function itself looks perfect, and the tests it thought to run pass. But the function was used in six other places it never looked at, and three of them now misbehave. Nothing in the file it edited hinted at those six callers. The agent did good work on the wrong understanding, and the mistake will not show up until something far away breaks.

A related failure is confident invention. Asked about a part of the system it cannot see, an agent will often produce a fluent, reasonable-sounding account that is simply not true of this codebase, because it filled the gap from general patterns rather than from the actual code. The danger is not that the agent says “I do not know.” The danger is that it says something specific and wrong with exactly the same confidence it uses when it is right.

The loop itself can also mislead, in a subtle way. Because the agent checks its work by running the tests, it tends to trust that a passing test means the job is done. But tests only cover what someone thought to test. A change can pass every test that exists and still break behavior no test watches. So the agent declares victory, honestly, on the evidence it has, while a real problem slips through in the gap between what the tests check and what the change actually touched. A green result is a good sign, not a guarantee, and an agent that treats it as a guarantee will sometimes finish confidently wrong.

The bottleneck is context, not code

Step back and a pattern emerges. When agentic coding works, it is usually because the agent had what it needed to understand the situation. When it fails, it is usually because it did not, and no amount of skill at writing code makes up for not knowing what the code you are writing will affect. The scarce thing is not the ability to produce code. Modern agents produce code easily. The scarce thing is an accurate picture of the system the code lives in.

Generating code is no longer the hard part. Knowing what the code you are about to change is connected to is the hard part, and it is where agentic coding lives or dies.

This is a real shift in where the effort goes. For a long time the slow step in programming was the typing and the syntax, getting the code written and correct in its details. An agent largely removes that step. What it does not remove is the need to understand the web of relationships a change sits inside, and that understanding is now the bottleneck. The everything an agent can see while it works is called its context, and the limit on agentic coding is the quality of that context far more than the cleverness of the model.

You can watch this play out in the difference between two runs of the same agent on the same task. Give it only the file to change and it does careful, narrow work that may quietly break the surroundings. Give it, in addition, an accurate account of what that file connects to, which functions call into it and which depend on its output, and the same agent makes a change that respects the whole. The model is identical. The context is not, and the context decided the outcome.

The danger of editing what looked relevant

It is worth naming a specific trap, because it is so common. An agent, or a person, searches the code for a name and finds several places it appears. The natural move is to treat those matches as the things to edit. But a text match is not the same as a real connection. The same name can mean different things in different corners of a system. A function called process in one module may have nothing to do with a function called process in another. A name inside a comment is not a use at all.

So an agent that edits everything that looked relevant will edit some things that were never connected and miss some things that were connected under a different name. It changes code that merely resembled the target, and it leaves untouched a caller that reaches the target indirectly. Both errors come from the same root: mistaking surface resemblance for actual dependency. Knowing which pieces are truly connected, and which only look alike, is not something a search over text can tell you, and it is exactly what an agent needs before it starts editing.

Why knowing the blast radius comes first

There is a precise name for the thing an agent should learn before it changes anything: the blast radius. The blast radius of a change is the full set of things that could be affected by it, everything downstream that depends on the code you are about to touch. If you change what a function returns, its blast radius includes every place that calls it and relies on the old shape of the answer. Knowing the blast radius is knowing, before you act, what you are putting at risk.

This changes the order of work. The instinct is to edit first and discover the consequences when something breaks. The safer method is to find the blast radius first, then edit with the whole affected set in view. If you know the six callers before you change the function, you can update all six together, or you can decide the change is too costly and choose a smaller one. Either way you are deciding with your eyes open. Editing first and learning the blast radius from the wreckage is the same information arriving too late to help.

For an agent the point is sharper still, because an agent cannot fall back on the years of memory a long-serving developer has about a system. A veteran might just know that touching this function is dangerous. The agent knows only what it is shown. If it is shown the blast radius, it can act like the veteran. If it is not, it acts like someone editing a system they have never seen, which, absent that context, it is.

An accurate map is the leverage point

All of this converges on a single conclusion. The way to make agentic coding reliable is not chiefly to make the agent write better code. It is to make sure the agent has an accurate map of the codebase: which pieces exist, which call which, which depend on which, and therefore what any given change will reach. With that map, the agent’s real strengths, its speed and its tirelessness, are pointed in the right direction. Without it, those same strengths let it make the wrong change quickly and confidently.

This is why a faithful account of a system’s structure is the highest-leverage thing you can give a coding agent. A small improvement in the map often does more for the final result than a large improvement in the model, because the map is what turns raw capability into correct action. An agent that can see the connections edits with care. An agent that cannot see them edits with hope.

Building and using such a map has its own name and its own methods. Working out, before a change, exactly what that change can reach is the subject of the concept called blast radius, and the broader practice of choosing what accurate information to place in front of an agent is the subject of prompt and context engineering and, underneath it, the context layer.