Three years ago, AI in the code editor meant autocomplete: you typed a few characters, and a model suggested the rest of the line. Today, a growing set of tools can read your entire repository, plan a multi-file change, write the code, run your tests, and fix what breaks β largely without you touching the keyboard. That shift, from suggestion to execution, is what people mean when they talk about "AI coding agents," and it's arguably the most mature real-world application of agentic AI so far. If you want the general concept behind this shift, we've laid it out in What Is an AI Agent? A Practical Guide β this piece is about how it plays out specifically in software development.
From Autocomplete to Autonomy
The first wave of AI coding tools, like early versions of GitHub Copilot, worked one suggestion at a time: you write a comment, it proposes a function. That's useful, but it still puts the human in charge of every decision β what to build, how to structure it, when it's done. The newer generation of tools closes that loop. You describe a task in plain language β "add pagination to this API endpoint and update the tests" β and the agent reads the relevant files, makes the edit across however many files that requires, runs the test suite, and iterates on its own output until the tests pass or it hits something it can't resolve alone.
This works well specifically in coding because software has an unusually clean feedback signal: tests either pass or they don't, the linter either complains or it doesn't, the build either compiles or it doesn't. That objective signal lets an agent self-correct without a human reviewing every intermediate step, which is a big part of why this category has moved faster than, say, general browser automation.
Aider: The Terminal-Native Pioneer
Aider is one of the earlier and more influential tools in this space, and it took a distinctly different approach from the IDE-embedded competition: it lives in your terminal and works directly with git. You point it at your repository, describe what you want changed, and it edits files and commits the results, using your existing version control as the safety net rather than building a custom undo system. Because it isn't tied to a specific editor, Aider works with whatever development setup you already have, and it supports pairing with multiple different underlying models, so you can choose the balance of cost and capability that fits your project.
Aider's philosophy is minimalism: it doesn't try to be an IDE, a project manager, or a chat companion. It tries to be very good at one loop β read code, propose a diff, apply it, commit it β and that focus has made it a favorite among developers who want an agent that stays out of the way.
Claude Code: Deep Repository Understanding
Claude Code takes a broader approach, functioning as an agentic coding assistant that operates directly in your terminal and can be given fairly open-ended tasks: fix a failing test suite, refactor a module, investigate a bug across a large codebase. It's built to read extensively across a project before acting, which matters a lot in large, unfamiliar codebases where the right fix in one file depends on conventions defined somewhere else entirely.
What differentiates agentic tools like this from earlier assistants is the willingness to take many steps in a row β reading files, running commands, checking results, adjusting course β without needing the developer to manually re-prompt at each stage. That's a genuinely different working style: instead of writing code together with the AI line by line, you delegate a task and review the outcome. For developers deciding between this style and a more traditional inline-suggestion tool, Claude Code vs GitHub Copilot is a useful comparison, and it's just as relevant when weighing it against Aider's terminal-first minimalism, since both take the same delegate-and-review approach but differ sharply in scope and structure.
Continue: The Open, Customizable Middle Ground
Continue sits in an interesting spot: it's an open-source coding assistant that plugs into your IDE and lets you configure which models power it, rather than locking you into one vendor's backend. That matters for teams with specific requirements β data residency, cost control, or a preference for a particular open-weight model. Continue supports both the quick, inline-suggestion style of coding assistance and more agent-like multi-step tasks, and because it's open source, technical teams can customize its behavior in ways that closed products don't allow. For a head-to-head on the two open, terminal-and-editor-oriented approaches, see Aider vs Continue.
Why the Model Underneath Still Matters
It's tempting to think the agent framework is the whole story, but the underlying language model still does most of the heavy lifting β the framework just decides how the model's outputs get turned into file edits, commands, and test runs. This is why the same agent framework can feel dramatically different depending on which model powers it, and why several of these tools (Aider and Continue especially) let you swap models rather than locking you into one. A model that's strong at reasoning through unfamiliar code but weaker at strict instruction-following will behave differently in an agent loop than one that's the reverse, even with identical scaffolding around it.
This flexibility also shows up in cost. Running an agent loop against a large, expensive model on every small task adds up quickly, especially on big codebases where the agent reads many files before making a single edit. Tools that let you pick the model per task β a cheaper, faster model for simple mechanical changes, a more capable one for genuinely hard debugging β give teams a way to control that cost without giving up the workflow. It's one reason open frameworks like Aider and Continue, which aren't tied to a single model provider, have found a loyal following among cost-conscious teams and individual developers alike.
Other Tools Worth Knowing
The category extends beyond these three. GitHub Copilot remains the most widely deployed AI coding tool overall, and while it started as an autocomplete engine, it has steadily added agent-like features of its own. Amazon CodeWhisperer targets a similar space with tighter integration into AWS-centric workflows, and tools like Sourcegraph Cody lean into large-codebase understanding for enterprise teams. On the review side, CodeRabbit and Qodo apply the same agentic pattern β read, reason, act β to the pull request review process itself rather than to writing the original code, automatically flagging issues and suggesting fixes as part of your CI pipeline. The common thread across all of these is the same shift described above: less "suggest the next token" and more "understand the goal and get there."
How This Compares to IDE-Native Tools
Not every AI coding tool is a terminal agent. Cursor and Windsurf build the AI experience into a full IDE, blending inline completions, chat-based editing, and increasingly agentic multi-file changes into one interface. The trade-off is largely about workflow preference: terminal-native tools like Aider and Claude Code fit naturally into a keyboard-driven, git-centric workflow and are easy to script or run in CI, while IDE-native tools offer a more visual, integrated experience with the file tree, diff view, and chat all in one window. If you're deciding between the two philosophies, Cursor vs Windsurf is a good comparison of two IDE-native leaders, while the terminal tools above serve developers who want the agent to fit into an existing toolchain rather than replace their editor.
What This Means for How Developers Work
The practical effect of this shift is that a growing share of routine engineering work β writing tests for existing code, fixing a well-described bug, upgrading a dependency and patching the breakage, adding a small feature that follows an existing pattern β can be delegated and checked rather than typed out by hand. That doesn't eliminate the need for engineering judgment; it changes where that judgment gets applied. Instead of deciding every line, developers increasingly decide what to delegate, review the agent's diff, and step in when the agent gets stuck or makes a choice that doesn't fit the broader architecture.
This also raises the bar on code review discipline. An agent that can make sweeping, multi-file changes quickly can also make sweeping, multi-file mistakes quickly, so teams adopting these tools tend to lean harder on tests, CI, and careful diff review rather than less. The tools that succeed long-term in this category are the ones that make it easy to see exactly what changed and why, not just the ones that produce a plausible-looking diff.
Where This Is Heading
The trajectory across Aider, Claude Code, and Continue points toward agents that can handle increasingly large units of work with less hand-holding β not just "write this function" but "take this ticket and open a pull request." The limiting factor isn't really enthusiasm; it's trust. Teams give an agent more autonomy as they build confidence that its test-passing code is also correct, maintainable, and consistent with how the rest of the codebase is written. That trust gets built incrementally, tool by tool and repository by repository, which is exactly why terminal-native agents that integrate tightly with git and existing test suites β rather than replacing them β have found traction so quickly. The direction is clear even if the exact shape of "fully autonomous software engineering" is still being worked out in practice.