Coding Agent
A code-completion tool suggests the next few lines; a coding agent is handed an issue and expected to come back with a change that works. It reads the repository, decides which files to touch, edits them, runs the tests, reads the failures, and tries again — without a human approving each keystroke.
Why code suits agents
Software engineering is where the plan–act–observe loop closes most cleanly, because the environment answers honestly. A test suite is a verifier the agent can consult as often as it likes: a compiler error, a failing assertion or a linter complaint is unambiguous feedback, unlike the vague signal most tasks return. That is what makes long unattended runs productive here, and why progress in the field is tracked on SWE-bench, where agents resolve real GitHub issues and are graded by the project’s own tests.
What it actually has to solve
Four problems sit between an issue and a working change:
- Navigation — a repository far exceeds any context window, so the agent searches and reads selectively instead of loading the project.
- Multi-file edits — a correct change often spans a module, its caller and its tests, and has to stay internally consistent.
- Knowing when to stop — a green suite is a signal to finish; without a termination condition an agent keeps polishing, or keeps retrying a broken approach until its budget is gone.
- Supervision — SWE-agent, Devin and Aider differ mainly in how much they do unattended versus how often they show you a diff first.
A coding agent is an agent specialised for software-engineering work on a real codebase: it locates the relevant files, makes multi-file edits, runs the test suite, and iterates on the failures until the task is done or its budget ends. The test suite supplies the unambiguous feedback the loop needs, which is why code is the strongest proving ground for autonomy — and why SWE-bench scores track the field.
Most AI help with code works like autocomplete: you type, it finishes the line. A coding agent is closer to handing a contractor a job list and leaving.
Given something like “the export button crashes on empty files”, it looks through the project, changes the files it thinks are at fault, runs the project’s own tests, and reads what broke. If the tests fail, it tries again.
That last part is why coding suits this kind of software. The tests are an honest scoreboard, so the program can check its own work without asking anyone — rarely true of other jobs.