Most advice about AI coding tools is about prompting. That is the least important part.
Here is what actually changes when an agent joins your workflow, in the order the changes hurt.
The bottleneck moves to review#
You used to spend the day producing code and a small slice of it reading other people's. Now a large model produces four hundred lines in ninety seconds and you spend the day reading. The work did not disappear; it moved to the part that was already the least fun and the least practised.
This has a concrete consequence: anything that makes a diff harder to review makes the agent less valuable, even if the code is correct. A change that touches nine files when three would do is a worse outcome than a slower change that touches three, because you have to read all nine.
So the first real skill is bounding. Not "write me a feature" but "change these two files, do not touch the migration, stop when the test passes."
Ambiguity gets resolved silently#
A human colleague who does not know whether deleted users should keep their orders will ask you. An agent will pick one, implement it confidently, and never mention that a decision was made.
This is the single most expensive failure mode, because the code looks finished. The test passes. The PR description is well written. The only way to catch it is to have decided the ambiguous cases yourself before the work started.
Every hour you spend making a request unambiguous saves you more than an hour of review. That ratio is the whole reason specs matter now, and it is why one of the first things we teach is how to write a spec an agent cannot misread.
Context is not the same as access#
Giving the agent your repository is not the same as telling it what the repository is. It can read internal/ledger/entry.go. It cannot infer that every write needs a matching counter-entry in the same transaction unless something says so — a comment, a test name, or a memory file.
An agent with file access and no context will produce code that compiles, passes the tests you happen to have, and quietly breaks the invariant nobody wrote down. The fix is not a better model. The fix is writing down the thing everybody on the team already knows.
This is what CLAUDE.md, AGENTS.md, cursor rules and their equivalents are for. They are not prompt tricks. They are the onboarding document you never wrote.
Confidence stops being a signal#
When a colleague says "I think the bug is in the connection pool", the confidence in that sentence carries information — they have seen the code, they have a hunch, and hunches from experienced people are worth something.
Model confidence carries no such information. An agent will describe a bug it has not reproduced with exactly the same certainty as one it has. If you have been using tone as a proxy for reliability your whole career, this will catch you out repeatedly until you stop.
The practical countermeasure is small and works: make it reproduce before it diagnoses. We will cover the exact wording in the debugging lesson, but the principle is that a theory backed by a failing test you watched run is worth something, and a theory backed by prose is worth nothing.
What does not change#
Your judgement about what should be built. Your knowledge of why the system is shaped the way it is. Your responsibility for what merges.
An agent shifts where the effort goes. It does not move the accountability. When something ships broken, "the agent wrote it" is not a thing you get to say — and more usefully, it is not a thing that helps you find the bug.
Where to go next#
The rest of this track is practical. The next lesson is about the first thing to do on any repository you want an agent to work in: writing down what it is.
If you take one thing from this lesson, take this: the leverage is not in the prompt. It is in what the agent knew before you typed, and in how carefully you read what came back.