Track: coding
This is the track where the tooling changes fastest and where the gap between people who use it well and people who use it badly is widest. Both facts have the same cause: the tools will now do a great deal on their own, and a great deal done wrongly is worse than nothing.
Five stages. Each one is genuinely useful on its own and each one is only worth taking when the one before it feels slow.
---
Stage 1 — the error message stage
You are stuck on something specific.
What to try first. Paste the whole error, the code around it, and what you expected to happen. All three. An error message alone gets you the top Stack Overflow answer; an error message plus the surrounding code plus your intent gets you an answer about your problem.
Then ask the question underneath: not "fix this" but "why is this happening". You want the explanation, because the same class of bug will find you again next month.
What goes wrong. Pasting the error alone and getting a generic answer. Or accepting a fix that makes the message go away without understanding it — that is how a project accumulates code nobody can maintain, including you.
When you have got it. You stop searching for error messages first.
---
Stage 2 — the small piece stage
You know what you want and writing it is tedious.
What to try first. Whole small units with a clearly stated contract. "A function that takes X and returns Y, handling the case where Z is empty. No dependencies beyond the standard library." The tighter the contract, the better the result — and the easier it is to tell whether it did the job.
Ask for the tests too, and read them before the code: they tell you what the model thought you meant, which is where the misunderstanding will be if there is one.
What goes wrong. Asking for something big and vaguely specified, then spending longer reading the result than writing it would have taken. There is a size above which reviewing is slower than writing, it is smaller than you expect, and it moves down as the code gets less familiar.
When you have got it. You can feel which requests are the right size before you make them.
---
Stage 3 — the whole-file stage
You work inside an editor that can see your project.
What to try first. An editor-integrated assistant — Copilot, Cursor, the AI built into your IDE, or Claude Code and Codex CLI in a terminal. The step change here is that it can see your existing code, so it writes things that match your conventions instead of generic examples.
Start it on something contained and unglamorous: a refactor, a set of tests for code that has none, a migration from one library to another. These are jobs with a clear right answer, they are boring to do by hand, and a mistake shows up immediately.
What goes wrong. Letting it touch things you have not read. The failure mode is not dramatic — it is a plausible change in a file you did not open, which works, and which quietly does something slightly different from what the old code did.
When you have got it. You review its diffs the way you would review a colleague's pull request, and you are as willing to reject one.
---
Stage 4 — the agent stage
It runs commands, reads files, and works for minutes at a time.
This is the current frontier and it is a real jump. An agent can read your repository, run your tests, make a change, see it fail, and try again — a loop you never see the middle of.
What to try first. Something with a hard, automatic success criterion. "Make this failing test pass." "Get the type checker clean." "Update every call site of this function." The test suite is what makes it safe: the agent has something to check itself against that is not its own opinion.
Work in git and commit before you start. Not as caution — as the thing that makes the whole approach usable. An agent that can be reverted in one command is a tool you can let run; one that cannot is a risk you have to supervise, which removes the point of it.
What goes wrong. The two big ones:
- No verification. An agent working on something with no tests is generating plausible code and telling you it worked. It believes that. It has no way not to.
- Too large a task. "Add authentication to this app" produces a large amount of code that is 90% right, and finding the 10% takes longer than writing all of it. Give it the size of task you would give a competent contractor who has never seen your codebase.
When you have got it. You know which of your tasks have a verifiable finish line, and you only hand it those.
---
Stage 5 — the systems stage
You build things that use models, rather than using models to build things.
The shift is from "AI helps me write the program" to "the program calls a model as part of what it does". Different skill, different failure modes.
What to try first. The smallest possible version: one API call, in a script, that does one useful thing — classify your inbox, summarise a log file, turn a paragraph into structured data. Ask for JSON rather than prose the moment another program has to read the answer.
What goes wrong. Building the interesting part and skipping the boring part. The boring part is: what happens when the model is slow, when it returns something that does not parse, when it is confidently wrong, and how you tell whether a change to your prompt made things better or just different. That last one — evaluation — is what separates a demo from something you can rely on.
When you have got it. You have a way of measuring your own system that does not depend on the last answer having looked nice.
---
The tools, roughly in the order you meet them
A chat interface for stage 1 and 2. Any of the good ones.
An editor assistant for stage 3. Copilot is the most widely used; Cursor and the newer AI-first editors go further; the built-in assistants in JetBrains and VS Code are perfectly adequate to start.
A terminal agent for stage 4 — Claude Code, Codex CLI, and the rest. These live in your repository and run your commands, which is the source of both their power and the need for git.
An API and an SDK for stage 5. Start with the provider's own library and a script, not a framework.
Something to run models locally if your code cannot leave the building — see running AI on your own machine.
---
The five habits that matter
- Commit before you let anything loose. Everything else on this list is easier when the undo button works.
- Read every diff. Every one. The moment you stop is the moment the codebase stops being yours.
- Have something that says "it works" other than the model. Tests, a type checker, a linter, a script that exercises the thing.
- Give it the constraints you would give a person. "Match the existing style", "no new dependencies", "the file is 400 lines, do not rewrite it" — models comply with explicit constraints and invent freely without them.
- Never let it near secrets. Your
.env, your keys, your production credentials. Not because it is malicious — because they end up in a prompt, and a prompt goes somewhere.
---
Where it genuinely does not help
Anything where the hard part is deciding. Architecture, what to build, whether this abstraction earns its keep. It will produce a confident answer to all of these and it has no stake in living with the result.
Unfamiliar codebases with no tests. The two things that make an agent safe are both missing, and this is exactly the situation where people reach for one hardest.
Very recent libraries. Its knowledge has a cut-off, and a plausible call to an API that changed six months ago costs more time than writing it from the docs.
---
Already written up here
Three of these are the boring prerequisites nobody explains, written up after doing them wrong:
- Setting Up a Development Environment From Scratch — what to install and in what order, before any of the above is reachable.
- Git: The Commands That Matter, and the One to Never Run — stage 4 above depends entirely on being able to undo; this is that.
- What a Software Engineer Does, and Where to Start — if the answer to "should I learn to code at all" is still open.
---
Next: Building your own tools picks up where stage 5 leaves off. Or back to all the tracks.