What Are AI Coding Agents and How Do They Differ from Autocomplete?

An AI coding agent is a tool that takes a goal in plain language, such as "add a rate limit to the login endpoint", and then works towards it by reading your files, editing code and running commands until it believes the job is done. Autocomplete predicts the next few tokens while you type. An agent plans and acts across many files and checks its own work. That difference in autonomy is the whole story, and it changes how you should work with these tools.

Three levels of AI help

Most tools you use today offer three modes. They overlap, but it helps to separate them.

• Autocomplete. Suggestions appear inline as you type. You accept with a key press. The model sees your current file and a bit of context. You stay in full control of every line.
• Chat. You ask questions in a side panel or terminal and get an answer. You copy code into your project yourself. Good for explanations and small snippets.
• Agent. You describe an outcome. The tool searches the repository, edits several files, runs your tests or build, reads the output and tries again if something fails. You review the result.

Claude Code, GitHub Copilot (in its agent mode) and Cursor (in its agent mode) all offer the third level. Some are terminal tools, some live inside an editor, and some run in the cloud against a repository. The details differ, but the shape of the work is the same.

What an agent can actually do

An agent is more than a model. It is a model plus a set of tools that the surrounding program lets it call. Typical tools are:

• Read a file or list a directory
• Search the code for a string or pattern
• Edit or create a file
• Run a shell command, such as your test runner
• Sometimes: fetch a web page or call an external service

The model does not touch your disk directly. It asks the tool to do something, the program (often after asking your permission) does it, and the result goes back to the model. This request-and-observe cycle repeats until the model stops asking for tools and gives you a final answer. The next post in this course walks through that loop in detail.

A concrete example

Suppose you have a small Node.js project and you give an agent this task in the terminal:

Add a function slugify(title) to src/text.js that lowercases the text,
replaces runs of non-alphanumeric characters with a single hyphen,
and trims hyphens from the ends. Add tests in test/text.test.js and
run them with npm test.

A good agent will open src/text.js, look at how existing functions are exported, add the function in the same style, create or extend the test file, run npm test, and report the result. If a test fails, it reads the failure and fixes either the code or the test. The function it writes might look like this:

// src/text.js
function slugify(title) {
  return title
    .toLowerCase()
    .replace(/[^a-z0-9]+/g, '-')
    .replace(/^-+|-+$/g, '');
}

module.exports = { slugify };

Run against slugify('Hello, World!') it returns hello-world. Notice what you did not do: you did not open three files, copy a pattern, or run the tests by hand. You did still need to check the result, and that is the skill the rest of this course teaches.

Where agents shine and where they struggle

Agents work best on tasks that are well defined and easy to verify. Adding a field through several layers, writing tests for existing code, renaming across a codebase, fixing a bug with a clear failing test, and updating documentation are all good fits. They struggle with vague goals, with decisions that depend on business context the model cannot see, and with code that has no tests, because nothing tells the agent when it is wrong.

Agents also make confident mistakes. They can call a function that does not exist, misread a requirement, or change more than you asked. Treat the output as a pull request from a fast, tireless junior colleague who has never seen your product: useful, but it needs review.

What changes in your role

You spend less time typing and more time specifying, steering and reviewing. Clear task descriptions, good project instructions, fast tests and careful diff reading become the bottleneck. Those are the topics of the next ninety-nine posts.

Checklist for getting started

• Pick one tool and learn its permission prompts before anything else.
• Start with small, verifiable tasks on a branch.
• Make sure the project has a command that runs tests.
• Read every diff before you commit.
• Do not paste secrets into prompts or files the agent can read.