Coding agents (SWE agents) from first principles — AI that independently does software tasks, one of the clearest practical AI successes. What a coding agent is (the shift from autocomplete to chat to agent; why code is a near-ideal agent domain because it's verifiable; the engineer's new role as director-reviewer), the agent loop for code (observe-decide-act-observe, closing the loop against code's concrete feedback — errors as rich signals — so the agent converges to working code; the loop is only as reliable as its feedback), grounding in the codebase (understanding a huge codebase through a small window via search, navigation, strategic reading, repo conventions, and semantic retrieval — most failures are comprehension failures), tools for coding agents (read/edit, shell, tests, search, version control — tool design determines quality, and safety is first-class: least privilege, sandboxing, confirmation, git as the undo button), planning and multi-step tasks (decompose, plan, track progress, manage context — the hierarchical structure that scales from edits to real engineering), verification and trust (verification drives self-correction and your trust; the layered toolkit of tests/type-checks/diff/human review; trust is earned through verification and the human stays accountable), evaluating coding agents (SWE-bench and measuring real capability by test-verified task resolution; the pitfalls of contamination, overfitting, weak tests, and cherry-picked demos), and coding agents in practice (where they shine vs struggle, working with them well, and the future of software engineering). Grounded in Wikipedia (software agent, pair programming, debugging, source code, information retrieval, command-line interface, version control, automated planning, decomposition, software testing, code review, benchmark).
An AI that answers coding questions is an assistant; an AI that independently reads a codebase, makes changes across many files, runs the tests, sees what broke, and fixes it is a coding agent. That shift — from suggesting code to doing the work in a real repository — is one of the most consequential developments in software engineering, and it has its own distinct engineering. This series builds coding agents from first principles, starting with what makes an agent different from autocomplete.
An AI that answers coding questions is an assistant; one that reads a codebase, edits across files, runs the tests, and fixes what broke is a coding agent. The shift from suggesting code to doing the work, why code is a near-ideal agent domain (it's verifiable), and the engineer's new role as director-reviewer.
Every coding agent, under the hood, runs the same loop: understand the situation, take an action, observe what happened, and decide the next action — repeating until the task is done. This read-edit-run-observe loop is the engine of a coding agent, and it works for code precisely because each action produces concrete, verifiable feedback. This post builds that loop and shows why closing it against real results is what separates an agent from a code generator.
Every coding agent runs the same loop: observe the state, decide an action, act through a tool, observe the result, repeat. Closing the loop against code's concrete feedback (errors as rich signals) is what makes it an agent that converges to working code, not a one-shot generator — and the loop is only as reliable as the feedback driving it.
A coding agent is only as good as its understanding of the code it's changing, and real codebases are enormous — far larger than any context window. The agent can't read everything, so it must find and load the right code for the task: navigate the repository, search for what's relevant, and build enough understanding to make correct changes. This grounding problem — understanding a large codebase through a small window — is where many coding-agent successes and failures are decided.
A coding agent is only as good as its understanding of the code it's changing, and codebases dwarf the context window. How agents find and understand the right code — search, navigation, strategic reading, repo conventions, semantic retrieval — and why most coding-agent failures are comprehension failures, so grounding is decisive.
An agent's reasoning is useless without the ability to act, and for a coding agent, acting means tools: editing files, running commands, executing tests, searching code, using version control. The tools define what the agent can do, and their design — what they expose, how safe they are, how reliable their feedback — shapes how well the agent works. This post is about the tools that turn a reasoning model into an agent that changes real software.
An agent's reasoning is useless without the ability to act, which means tools: read/edit files, run commands, run tests, search, version control. Tool design (reliability, clear feedback) largely determines agent quality, and because tools (the shell) can do irreversible things, safety is first-class: least privilege, sandboxing, confirmation gates, and git as the undo button.
Fixing a typo is one tool call; implementing a feature across a dozen files, with new tests and a migration, is a project. As coding tasks grow, a coding agent needs more than a tight edit-run loop — it needs to plan, decompose, track progress, and manage its own context over a long effort. This post is about how coding agents handle big, multi-step tasks, and why planning and decomposition are what let them tackle real work rather than just small edits.
Fixing a typo is one tool call; implementing a feature is a project. How coding agents handle big tasks: decompose into ordered subtasks, plan before acting, track progress, and manage context over a long effort — a hierarchical plan-plus-loop structure that scales from edits to real engineering, and benefits hugely from human direction.
A coding agent can produce a confident, plausible change that's subtly wrong — and the whole value collapses if you can't tell. Verification is how you know the agent's code actually works, and trust is what you build (or lose) based on it. Because code is verifiable, coding agents can check much of their own work — but the human reviewer remains the final, accountable arbiter. This post is about verifying agent-written code and the trust that makes coding agents usable.
A coding agent can produce a confident, plausible, subtly-wrong change — verification is how you know it's actually right. Why verification drives the agent's self-correction AND your trust, the layered toolkit (tests, type-checks, diff review, human review), and the rule: trust is earned through verification, and the human stays accountable.
How good is a coding agent, really? The honest answer requires evaluation — measuring whether an agent can actually resolve real software tasks, not just produce plausible-looking code. Benchmarks like SWE-bench made coding-agent progress measurable by testing agents on real GitHub issues verified by real tests, and understanding how coding agents are evaluated (and the pitfalls) is how you cut through the hype to what agents can actually do. This post is about measuring coding-agent capability honestly.
How good is a coding agent, really? Because code is verifiable, you can measure task resolution by tests on real issues — which is what SWE-bench does. The pitfalls that inflate numbers (contamination, overfitting, weak tests, cherry-picked demos), and why your real tasks are the real benchmark.
Coding agents are genuinely transformative on the right tasks and frustrating on the wrong ones, and knowing the difference is the practical skill that separates productive use from disappointment. This closing post is the honest field guide: where coding agents excel, where they struggle, how to work with them well, and where software engineering is heading. It turns the series into judgment you can apply today.
Coding agents are transformative on the right tasks and frustrating on the wrong ones. Where they shine (well-scoped, verifiable, groundable, reviewable work), where they struggle (ambiguous, weakly-verified, large/architectural), how to work with them well (scope, verify, ground, review, delegate the mechanical), and where software engineering is heading.
This series is part of a larger body of work by Pratik Dhanave, an Agentic AI Architect writing about production AI systems, distributed systems, and cloud-native engineering. Explore all course series, browse every post, or find topics via the tag index.