How coding agents are built, and how to work with them
A coding agent is an LLM in a loop with tools to read files, search code, edit files and run commands, so it can explore a codebase, make changes, run the tests, read the errors and fix them. Claude Code, Cursor, GitHub Copilot's agent mode and similar tools all follow this pattern. They do much of a junior developer's work well, and they still lose earlier instructions as context fills, make changes you didn't ask for, and fix one thing by breaking another. Work with them the way a senior engineer works with a junior: understand the design, give one component at a time, review every change, and run the tests.
How a coding agent works
A coding agent is the agent loop from this section applied to a codebase.
Its tools usually include:
- Read a file, list a directory, search the code (often with grep-like search).
- Edit or create files.
- Run shell commands: tests, linters, builds, scripts, Git.
- Sometimes a browser, web search, or MCP servers for other systems.
The loop:
- Read the task and explore the relevant code.
- Make a plan.
- Edit files.
- Run the tests or the program.
- Read the output, and if something fails, fix it and run again.
- Stop when the tests pass or the task is done, and summarise what changed.
The test loop is what makes coding a good fit for agents. Code gives clear feedback: it runs or it doesn't, the tests pass or they don't, so the agent can check its own work against something real.
Context is the hard part
A codebase is far bigger than any context window, so a coding agent has to decide what to read. Good agents search for relevant files instead of reading everything, keep notes and plans in files, and compact the conversation when it gets long.
Even so, as a session goes on and the context fills with file contents, outputs and earlier decisions, the agent can miss instructions you gave at the start. That is why the advice below is mostly about keeping tasks small and context clean. See context engineering.
Most coding agents also read a project instruction file, like CLAUDE.md for Claude Code or AGENTS.md for several others, at the start of every session. Put your project's conventions there: how to run tests, the folder structure, the style rules, what not to touch.
Vibe coding and engineering
Vibe coding means building software by prompting, describing what you want and letting the tool write the code, often without reading it closely. It is excellent for prototypes, demos and exploring ideas. Tools like v0, Lovable, Bolt and Replit can produce a working prototype from a description in minutes.
But coding and engineering are different. Coding is writing programs. Engineering is designing a system made of many programs, so it works, scales, can be maintained and can be explained. A prompt can produce a prototype, and it can't, today, produce a scalable system on its own. You use AI for the parts, and the design of the whole is your job.
How to work with coding agents
Understand the design first
Know what you're building, how the parts connect and what each part should do, before you ask an agent to write it. If you don't understand the design, you can't judge whether the agent's code is right.
Give one component at a time
Divide the work into small, clear tasks: one function, one module, one bug. Small tasks keep the context focused and make the changes easy to review.
Review every change
Open the files the agent changed, understand what it changed and why, and check that it didn't change things you didn't ask for.
Run the tests every time
After each change, run the earlier tests too, to check that other parts still work. If there are no tests, ask the agent to write them first, and review those as well.
Ask for explanations
Ask the agent to explain the errors it found and how it fixed them. That turns every fix into something you learn, and it's what you'll need when someone asks you about the code in an interview.
Keep Git clean
Commit before each task, so you can see the diff and roll back easily.
Running agents safely
Coding agents run commands on your machine. Most ask for permission before running commands or editing files, and you can configure what they're allowed to do without asking. Be careful with broad permissions, run unfamiliar tasks in a container or a separate environment, keep secrets out of the repository, and review any command that deletes, deploys or touches production.
Measuring coding agents
Benchmarks like SWE-bench measure how often agents resolve real GitHub issues from open-source projects, and scores have risen fast. For your own team, measure on your own codebase: give agents real tasks with tests, and check how often the result passes the tests and is acceptable in review.
Building your own
If you build a coding agent, the essential parts are file tools, a command runner inside a sandbox, a test loop, step limits, and a clear way to show the human what changed. A narrow agent, for example one that fixes failing tests in one service, is much easier to make reliable than a general one.
From the floor
I gave Claude Code the errors in my project and asked it to fix them and explain what went wrong. It checked the files and made the changes, and the agent was running again, and it also explained what went wrong, which is the part that matters most for learning. But as we keep working on the project and the context fills up, it can miss some of the earlier instructions, so I give it smaller tasks, one component at a time, and check what it changed before moving forward.
In a session, the instruction I gave Claude Code to get a Streamlit app working was: run the app, check for errors and fix them, tell me the reason for each error and how you fixed it, and use the web if needed. Asking for the reason is the difference between using the tool and learning from it.
In AI Engineer HQ, we built our own coding agent, DevFix, a command line tool that writes a function, runs it, checks the errors and fixes them until it works and the tests pass, built with LangGraph, sandboxing and Docker, so builders understand what tools like Claude Code are doing inside.
In the vibe coding session, I said there is vibe coding and there is no such thing as vibe engineering: the tools save time and do the heavy lifting on individual parts, and the people who understand the whole flow, the architecture, the environment and how the parts fit, are the ones who can turn those parts into software.