The Coding Agent Landscape

Not long ago, AI help with code meant autocomplete: a gray suggestion that finished the line you were already typing. Today you can describe a feature in a paragraph, go make coffee, and come back to an agent that has read your codebase, edited a dozen files, run the tests, fixed what broke, and written you a summary of what it did. That is a different kind of tool, and it rewards a different way of working.

The catch is that there are now many of these tools, they look alike on the surface, and the marketing all sounds the same. This lesson gives you a clear map: the three shapes coding agents come in, what the major tools are actually like to use, how to pick one without agonizing, and the skills that transfer no matter which one you choose.

What a coding agent actually does#

A coding agent is an AI model wired into a loop with tools that let it work on a real codebase: it can search and read files, edit them, run terminal commands (tests, builds, linters), look at the results, and decide what to do next. It keeps going until it believes the task is done or it needs you.

That loop is what separates it from the two kinds of AI help you may already know:

Here is what a short agent run looks like. This is illustrative, but it's representative of what you'll see on screen:

You:   The signup form accepts emails without an @. Fix it and add a test.
 
Agent: Searches the project for "signup"
       Reads src/components/SignupForm.tsx and src/lib/validation.ts
       Runs the test suite to get a baseline (all passing)
       Edits validation.ts to add an email format check
       Adds two test cases to validation.test.ts
       Runs the tests: one old test now fails ("dev@localhost" is rejected)
       Reads the failing test, decides local addresses must stay valid
       Adjusts the rule and re-runs the tests: all passing
       Summarizes the change and flags the localhost edge case for you

Notice the most important step: the agent ran the tests, saw a failure, and corrected itself. The loop plus real feedback is the whole trick. An agent with a good test suite to run is dramatically more reliable than the same model without one. If you want the deeper mechanics, they're covered in the agent loop.

The three shapes: terminal, IDE, and cloud agents#

Every coding agent comes in one of three shapes, and most vendors now offer more than one.

Terminal agents#

A terminal agent runs in your command line (the text window where you type commands like npm test), inside your project folder. You talk to it in plain English; it reads and edits files and runs commands right there. Claude Code and OpenAI Codex CLI are the best-known examples; Google offers its own terminal agents too.

Terminal agents work alongside any editor, can use every tool already installed on your machine, and are easy to script. Don't be put off if you're not a terminal person: the interface is just a conversation, and you'll rarely type anything other than English.

IDE agents#

An IDE agent lives inside a code editor (an IDE, or integrated development environment, is the app you write code in, like VS Code). Cursor and GitHub Copilot's agent mode in VS Code are the leading examples, and Claude Code and Codex both offer editor extensions too.

The big advantage is visibility: you watch changes appear in your files, see diffs inline, and accept or reject them piece by piece. If you're newer to code, seeing the changes in context helps a lot.

Cloud agents#

A cloud agent (sometimes called a background agent) works on a copy of your repository on a remote machine. You hand it a task from a web page, an issue tracker, or chat, and it comes back later with a branch or pull request for you to review. Examples include Codex cloud tasks, the GitHub Copilot coding agent (hand it a GitHub issue and it works on a branch and opens a pull request for you to review), Claude Code on the web, and Cursor's cloud agents.

Cloud agents shine for parallel, asynchronous work: you can kick off three tasks before lunch and review three pull requests after. The trade-off is less live steering and some setup, since the remote environment needs to know how to install and test your project.

Pick the shape for the task, not the brand. Plenty of people use a terminal or IDE agent for focused work and a cloud agent for a queue of small, well-defined chores.

A quick tour of the major tools#

Features change monthly, so treat this as a description of each tool's character rather than a feature checklist. Check each vendor's docs for current details and pricing.

Claude Code (Anthropic). Terminal-first, also available as IDE extensions, a desktop app, and on the web. It reads a CLAUDE.md file for project instructions, has a dedicated plan mode, and supports subagents, hooks (scripts that run at set points in the agent's work), and MCP tool connections. It runs on Claude models and is especially strong at long, multi-step tasks across large codebases.

OpenAI Codex. An open-source CLI, an IDE extension, and cloud tasks you launch from ChatGPT that run in sandboxed environments and propose changes as pull requests. It reads AGENTS.md for project instructions and runs on OpenAI models.

Cursor. An AI-first code editor built on VS Code, so your existing extensions and keybindings mostly carry over. Its agent works in a side panel, you can choose between models from several providers, and project rules let you store instructions in the repo. A natural choice if you want to stay in an editor all day.

GitHub Copilot. Agent mode in VS Code and other editors for local work, plus the Copilot coding agent that works from GitHub issues and opens pull requests. Project instructions live in .github/copilot-instructions.md, and it also reads AGENTS.md. Strongest when your team already lives in GitHub.

Gemini CLI and Antigravity CLI (Google). Gemini CLI is an open-source terminal agent running on Gemini models, with project instructions in a GEMINI.md file. Since June 2026 it's aimed at companies using Gemini Code Assist; individuals on free or Google AI plans were moved to Google's newer Antigravity CLI. If you want to try Google's models from the terminal, check which of the two your account currently supports and what its limits are.

How to choose without overthinking it#

Six questions settle the choice for most people:

1. Where do you like to work? In an editor all day, pick an IDE agent. Comfortable in a terminal, or using an editor you don't want to change, pick a terminal agent.
2. How much autonomy do you want? Close collaboration favors terminal and IDE agents. Queues of small, well-specified tasks favor cloud agents.
3. Which models do you trust? Some tools are tied to one provider's models; others let you switch.
4. Where does your code live? If your work is organized around GitHub issues and pull requests, Copilot's coding agent and the cloud options fit neatly.
5. How do you want to pay? Options range from free tiers to monthly subscriptions to pay-per-use API billing. Heavy agent use can get expensive on usage billing, so compare plans against how much you'll actually use it.
6. What does your employer allow? Many companies approve specific vendors because your code is sent to their servers. Check before using an agent on work code.

If you still can't decide, use this:

Then commit to it for two weeks. Tool-hopping is the most common way to stay a beginner. The skills in this module transfer almost completely, so switching later is cheap.

The skills that transfer to every tool#

Here's the good news: the difference between frustrating and fantastic results is mostly not the tool. It's a handful of habits, and they work in every agent listed above. They are exactly what the rest of this module teaches:

• Writing tasks an agent can finish, with a clear goal, context, constraints, and a definition of done. Next lesson.
• Teaching the agent your project once with an instructions file like CLAUDE.md or AGENTS.md. Lesson 3.
• Planning before coding, so misunderstandings surface while they're cheap. Lesson 4.
• Reviewing code you didn't type, quickly and reliably, starting from the tests. Lesson 5.
• Using git as a safety net, including running several agents in parallel without collisions. Lesson 6.
• Putting it all together by building and deploying a real web app from an empty folder. Lesson 7.

Honest limitations to know on day one#

Coding agents are genuinely powerful, and they fail in predictable ways. Knowing the failure modes up front saves you a lot of grief.

• They sound confident when they're wrong. An agent will report "done, all tests pass" when it skipped a test or misread the goal. Verify claims, especially ones about running things.
• They overreach. Ask for a bug fix and you may get a bug fix plus a refactor, a renamed variable, and a new dependency. Constraints in your task prevent most of this.
• They don't know your unwritten rules. Conventions that live in your team's heads are invisible to the agent until you write them down.
• They run real commands on your machine. Deleting files, installing packages, and touching databases are real actions. Read permission prompts instead of approving them on autopilot; permissions and approvals covers this in depth.
• Cost can creep up. Long sessions on large codebases consume a lot of tokens. On usage billing, keep an eye on it.
• Taste is still your job. Agents default to generic designs and conventional architecture. Good when that's what you need; your call when it isn't.

None of these are reasons to avoid agents. They're reasons to work with them deliberately, which is what this module is about.

Don't change any files. Explore this project and tell me:
1. What it does and how it's structured, in two short paragraphs.
2. The commands to install, run, and test it. Actually run the tests to confirm.
3. The three files you'd read first if you were new here, and why.
4. One thing that looks fragile or confusing, with the file and line number.
Finally, tell me which of your claims you verified by running something
and which you inferred from reading code.