Coding Agents, Step by Step

This is the hands-on version of the "Next Level" page. It's the agent loop, running on your own computer, on your own files. Don't come here until using AI in a chat every day feels completely normal, and you have a real thing you want built.

A coding agent is an AI that lives in your terminal or code editor, reads the files in a folder, writes and changes files, and runs commands, all from a plain-English request. It's the same loop from the last page: it picks a tool, sees the result, and keeps going until the job is done. The word "coding" scares people off, but you don't have to write or read any code. You describe what you want; it does the work; you watch and approve.

The options: they all work the same way

There isn't one "coding agent." There's a category, and the tools in it work alike. The names you'll run into most:

• Claude Code, Anthropic's coding agent, run from your terminal or inside an editor.
• Codex CLI, OpenAI's coding agent for the command line.
• Gemini CLI, Google's coding agent for the command line.
• Cursor, an editor (from the Codebase page) with a coding agent built in.
• GitHub Copilot, coding help and an agent that live inside popular editors.

They differ in small ways: which AI model is behind them, the exact commands, the price. But the shape is identical: open a folder, type a request, watch it read and edit files, approve or undo. The ideas below transfer to all of them. So learn the concepts once and you can switch tools later without starting over.

Part 1: Setting it up (one time)

You'll do this once. Take it slowly; every step is just downloading or clicking, nothing to memorize.

1. Install a code editor. VS Code is a free, standard one: think of it as the window you'll look at your project through. Download it from the official Microsoft site and install it like any app. (Cursor works too, and has an agent built in.)
2. Add the coding-agent extension. Inside VS Code there's an Extensions tab (the stacked-squares icon on the left). Search for the tool you chose, "Claude Code," for example, find the official one, and click Install.
3. Sign in. The extension will ask you to log in with your account for that tool. Most coding agents need a paid plan; the exact tier and price move around, so check the tool's own site as of when you read this.
4. Make a project folder. Create a new empty folder somewhere sensible, a plain name, no spaces (e.g. my-workspace), and open it in VS Code. This is the room the agent will work in.
5. Let it set itself up. Most coding agents have a first-run command (in Claude Code it's /init) that looks around your folder and writes a starter instructions file. Run it and let it create that file. (More on that below.)
6. Later: a private file for secrets. When a project needs a password or key to another service, those go in a private file (often called .env) that you keep out of sight. You don't need this on day one, just know the word for when a project calls for it.

Part 2: The five ideas you actually need

You don't need to understand how any of this works under the hood. You need five plain-English ideas that show up in every coding agent, under slightly different names. Each one has a simple analogy, so hold the analogy and ignore the rest.

The instructions file: the "never forget" note

A single file the agent reads before every message (Claude Code calls it CLAUDE.md; other tools have their own name for the same thing). Think of it as a job description and a map to the rest of your folder, taped to the inside of a locker. It doesn't hold everything, it just says "the project details live in about-project.md, the rules live here, the folders are laid out like this." Keep it short (under ~200 lines). It's the difference between the agent guessing and the agent knowing.

Context: the working memory

The agent has a limited short-term memory for the current session: everything it's read and said so far (this is the "context window" from the Basics page). When that memory fills up, it gets sloppy: it forgets things, repeats itself, starts making mistakes. Most tools give you a way to see how full it is, to summarize and free up room, and to wipe the slate clean when you switch tasks. Clearing between different jobs is a habit that keeps answers sharp.

Connected tools: the universal adapter

A coding agent can plug into other software, your email, your calendar, a spreadsheet, a web search, without anyone writing fiddly custom code. This is the MCP idea from the last page: a universal plug shape, like an app store for your agent. Once a service is connected, you just say "check my calendar" and the agent figures out the rest.

Saved recipes: your reusable instructions

A recipe is a saved set of step-by-step instructions for a task you do often, written once in a small file (Claude Code calls these "skills"; the idea exists across tools). Instead of re-explaining "here's exactly how I want my weekly summary formatted" every time, you save it once and just run it. Same input, same reliable result, every time.

Helpers: the specialists

For big or messy jobs, a coding agent can hand a focused task to a helper, often called a "sub-agent," that does one thing (like checking its own work, or reading a huge pile of data) and reports back a clean summary. Think of it as calling in a specialist for one specific job so your main task doesn't get bogged down. You'll rarely touch this early, but it's why these tools can handle surprisingly large work.

Part 3: The project ladder

Skill comes from reps, not from watching. Build these in order. Each one is a real, personally useful thing and teaches the next skill up. Start at the bottom rung and don't skip. Notice that none of these are for a client, they're for you. That's on purpose. Get good on your own stuff first.

• 1

  WORKSPACE BASICS

  Your own AI workspace

  Set up the folder, run the first-run command, and have the agent interview you and write your first files: about-me.md, projects.md, notes.md. You're not building anything fancy; you're learning how a workspace and the instructions file feel. Teaches: the basic loop of talking to the agent and watching files appear.

• 2

  FILES & EDITING

  A script that renames your photos

  Point it at a messy folder: "rename every photo in here to the date it was taken, and group them into folders by month." Watch it read the files and do the whole batch in one pass. Teaches: the agent reading and writing real files, and doing tedious bulk work you'd never do by hand.

• 3

  TOOLS & FIXING ERRORS

  Gather a list from the web

  Have it collect something you actually want, a list of hiking trails within an hour's drive, or every used bookstore in your city, and hand you a tidy spreadsheet. Things will error partway; you'll watch it fix its own mistakes. Teaches: connecting a tool, and that errors are normal and recoverable, not the end of the world.

• 4

  DATA & VISUALS

  A page that tracks something you care about

  Feed it a spreadsheet you keep, your running times, your grocery spending, a reading log, and ask for a simple page with a couple of charts and a short summary of what changed. Teaches: turning raw numbers into something you'd actually glance at each week.

• 5

  A SMALL REAL TOOL

  A little tool for a hobby

  Build something small and specific to a thing you love: a chord-progression generator, a recipe scaler, a workout planner, a dice roller for a game night. Teaches: making a small program that does one job well, and getting a taste for building the thing you wished existed.

• 6

  A REAL WEBSITE

  A simple site, live on the internet

  Build a clean one-page site: a personal homepage, a page for a club, a landing page for a hobby project, and put it online (the agent can walk you through publishing it for free). Teaches: making something anyone can visit, start to finish.

• 7

  OPTIONAL: FOR SOMEONE ELSE

  Something you could hand to another person

  Only if you want to: build something a bit bigger for someone other than yourself, a site for a friend's band, a small tool for a family member, and have the agent test it, clicking through every page and fixing what looks wrong until it passes. Teaches: the quality control that separates "a fun experiment" from "something another person can rely on."

By rung 6 you can build a real, working thing from a plain-English description. Rung 7 is the first step toward doing this for other people, and if that appeals to you, the optional Getting Paid page picks up exactly there.

Daily habits that keep the answers good

These few habits, straight from how people who use these tools well actually work, matter more than any clever trick:

Memory that lasts between sessions (and computers)

A coding agent forgets everything when the session ends. The instructions file covers your standing rules, but over weeks of work you pile up other things worth keeping: a decision you made, a correction you had to give twice, a preference, a fact about the project that isn't written down anywhere in the files. Here is the setup I use so those survive, and so they follow me between my laptop and my desktop.

One small file per fact, plus a short index

Each project gets a memory folder. Every fact lives in its own small markdown file, with a one-line description at the top and a note on why it matters. Next to them sits one index file with exactly one line per memory. The agent loads the index every session and opens a full file only when its line looks relevant, so the always-loaded part stays small and the detail is there when needed.

Only durable, non-obvious facts go in. If the code, the git history or the README already says it, it doesn't belong in memory. Each memory also says where it came from (a file, a command's output, a link, or your own words) so it can be checked later. And a memory is only what was true when it was written: if one names a file or a command, the agent confirms that thing still exists before relying on it.

The memory folder is a git repo

Every change to memory is a commit, so you get a full history, a diff of what changed, and a way to undo a bad edit. Each project's memory is its own private repo, which keeps projects from tripping over each other. Two small scripts that run automatically at the start and end of each session (Claude Code calls these "hooks") do the syncing: one pulls the latest copy when a session starts, the other commits and pushes when it ends. Work on the laptop in the morning and the desktop at night, and both see the same notes. If both computers changed the same project, git merges the two versions. Usually only the index line needs a look.

Keep the always-loaded part short

Whatever loads in every session takes up room in every session. My core rules file for agents has a hard cap of 70 lines, and any rule that doesn't apply to every tool and every project moves to a file that's read only when it's needed. One more file loads everywhere: a short map of all my projects, a few lines each, so an agent working in one project knows the others exist. Detail about any of them gets pulled in on demand.