One long read for a slow Sunday. Coding agents have gone from party trick to daily tool remarkably fast. Most of what makes them good, and most of what makes them maddening, comes from a surprisingly simple design. This week we open the hood.
The whole trick is a loop
Autocomplete suggests the next line. A chatbot answers a question. An agent is different because it acts, looks at what happened, and decides what to do next. Anthropic’s widely read guide to building agents describes them in much the same way: a model using tools in a loop, guided by feedback from its environment.
In practice, a session looks like this:
- You describe the task.
- The model decides on a step, such as searching the code or opening a file.
- The tool runs, and the result goes back to the model.
- The model reads that result and picks the next step.
- Repeat until the model decides it is done.
The tools are ordinary things: read a file, edit a file, run a command, run the tests. There is no magic in any single step. The power comes from the feedback. An agent that can run the tests sees its own mistakes and gets another try, which is why a project with a good test suite gets much better results than one without.
Short memory, big consequences
A model can hold only so much text in mind at once. That limit is called the context window, and everything has to fit in it: your request, the files it read, the command output, its own earlier reasoning.
A big codebase does not come close to fitting. So an agent behaves like a new colleague with a very small desk. It searches, opens a few files, and has to decide what to keep in front of it. When the desk fills up, the tool typically summarizes older material or starts dropping it.
This explains several familiar frustrations. An agent that was sharp for an hour starts forgetting a decision you made early on. It rewrites a helper function that already exists because it never opened that file. It confidently names a function that sounds right. None of this is really random. The information simply was not on the desk.
Memory lives in plain files
The fix is low-tech and quite charming: notes. Many tools now read a project file at the start of each session, with instructions like how to run the tests, which conventions to follow and what to avoid. Some also keep notes of their own between sessions.
These files work because they put the right facts on the desk from the first minute. A few lines that say “we use this test command, and never touch that folder” can save more time than a stronger model. A useful habit: every time you correct an agent twice for the same thing, write it down in that file.
Connecting agents to the rest of your work is getting more standardized as well. The Model Context Protocol is an open standard that lets tools expose data and actions in a common way, so an assistant can reach a ticket tracker or a database without a custom integration for every pairing.
Why agents go off the rails
Because each step builds on the last, one wrong assumption early on can send a session down a long, tidy, completely wrong path. The agent will not usually stop to say it feels unsure. It keeps going, and the output keeps looking professional.
Two habits help a lot. Ask for a plan before any edits, because correcting a paragraph is much cheaper than untangling 400 changed lines. And keep tasks small enough that you can actually review the result. If you cannot read the change, you are not supervising, you are hoping.
Permissions matter too. An agent that can run commands can also delete things. Sensible tools ask before anything risky and keep work inside a sandbox or a separate branch. It is worth taking those guardrails seriously, particularly as the same loop moves beyond code. OpenAI’s decision to halt its Astra rollout turned on exactly this question of staying within authorized scope.
The inconvenient study
Do these tools actually make you faster? Everyone feels that they do, which makes one experiment so interesting.
In early 2025, the research group METR ran a randomized trial with 16 experienced open source developers working on 246 real tasks in projects they knew well. Each task was randomly allowed or disallowed AI. Developers took 19 percent longer with AI. Before starting, they had predicted a 24 percent speedup, and even afterward they believed AI had sped them up by about 20 percent.
Careful, though. That was a small group of experts on their own familiar code, using tools that have changed a lot since, and METR itself now says those results are out of date and has published an update on newer tools. The lasting lesson is not “AI slows you down.” It is that our own sense of speed is unreliable. Waiting on a machine feels like progress in a way that thinking hard does not.
So measure things that matter on your own team: how long a change takes to reach production, and how often it comes back broken.
Where it’s heading
Two trends are worth following. Agents are starting to run in teams, with one model planning and others doing the work. And more of that work is moving onto your own machine: our recent Lunch Byte covered hybrid setups where almost everything stays offline.
The job is shifting as well. Less typing, more describing what you want, checking what came back and deciding what is good enough. Those were always the hard parts of engineering. Now there is just nowhere left to hide from them.
