The rest of this site is about what you have to build around the agent. This page is about what for. Eight jobs on one axis: how cheaply you can check the result, and what it costs you to be wrong.
It is not that AI works or does not work. It works enormously well at some jobs and is dangerous at others, and the difference is not the model: it is how much of what it did you can actually check.
Every job names the disciplines it leans on, how much process it is worth, and how you check the result. If your job is not here, find the one whose verification looks like yours — that is the part that transfers.
No, and saying so matters. A process sold as always-correct gets abandoned the first time somebody applies it to a two-line fix, and it takes the rest of the process down with it. Three rungs, chosen by the cost of being wrong — not by the size of the change.
01 · Process
No ceremony
What lives here
Changes where reading the result costs less than describing what you wanted up front. A typo, a four-line helper, a question about code that already exists.
The rule
Can you tell at a glance whether it is right or wrong? Then write nothing first. Ask for it and look at it.
How it rots
It gets stretched past where it reaches: somebody ships a three-day feature having written nothing down, because the four-line changes had been going fine.
Bounded changes with observable behaviour. A bug, a single-module refactor, a diff review. You know what you want; what you do not know is whether you got it.
The rule
Is there an automatic check that tells right from wrong? Write it first. That is one line of process, not a document.
How it rots
The check gets written after the change and confirms what the change does rather than what it was supposed to do. A test like that does not verify anything: it approves.
Work whose cost of being wrong is not paid by you today. A new feature, a migration, an architectural decision. Things that stay.
The rule
Will someone have to understand this in six months without being able to ask you? Then the specification and the reasoning are part of the deliverable, not paperwork around it.
How it rots
It gets applied to everything by default, people experience it as bureaucracy, and two months later neither the process nor the habit of verifying survives.
Same axis, in order. At the top are the jobs where checking is cheap and being wrong costs you a bad explanation; at the bottom, the ones where neither holds and the mistake stays in production.
01
Understand code
What does this do, and why is it like this?
Having it explain a system you did not write — or one you wrote eight months ago, which by now amounts to the same thing.
Where it earns its keep
This is where it earns the most and risks the least: if it gets it wrong, you pay in a bad explanation, not in broken code. And following a flow end to end is exactly what a human does slowly, late, and with the urge to give up halfway.
Where it fails
It will confidently explain the intent of code that never had any. It reads the result, not the argument that produced it: if that was a rushed Friday patch, it presents it to you as design. Intent does not live in the code, it lives in memory — and if nobody saved it, it will not be found.
How you know it came out right
Ask for the file and line behind every claim. An explanation with no coordinates is a hypothesis with good prose.
Default process
No ceremony
Where it runs
Separate when it gets noisy
What gets read in order to understand goes on taking up room long after it has served. When the sweep spans four files or more, let another agent do it and hand you back the three sentences that matter. For one file you already have open, the handoff costs more than the reading.
02
Find why it breaks
Why does this break, and since when?
Handing it a symptom so it finds the cause, instead of trying fixes until one makes the error go away.
Where it earns its keep
Forming hypotheses from a stack trace and discarding them fast. A human falls in love with the first one and spends two hours defending it; the agent has no ego invested in any of them.
Where it fails
It jumps to fixing before it has reproduced anything. Let it, and you end up with a patch that covers the symptom and leaves the cause fully intact — and those are the bugs that come back in production three weeks later, when nobody remembers the patch.
How you know it came out right
A test that fails before the change and passes after. Without that you did not fix anything: you changed something and the symptom left on its own.
Default process
Light ceremony
Where it runs
Separate when it gets noisy
Tracing the origin can cost many files; fixing it costs three lines. Delegate the tracing, keep the fix.
03
Refactor
How do I change the shape without touching the behaviour?
Moving, renaming, extracting and splitting code that already works, without changing anything it does.
Where it earns its keep
The mechanical change repeated across many files. This is the job where a human tires around file twelve and starts making mistakes exactly when they believe they have got the hang of it.
Where it fails
Looking at the code, it cannot tell “this is equivalent” from “this is nearly equivalent”. And “nearly” in a refactor is a bug nobody will attribute to the refactor, because the refactor did not change anything.
How you know it came out right
The suite green before and after. If you had to change what a test asserts about behaviour, it was not a refactor: it was a behaviour change under another name.
Default process
Light ceremony
Where it runs
Separate when it gets noisy
If the callers have to be mapped first, that goes elsewhere. The editing itself belongs in one thread: these are changes that have to stay coherent across files.
04
Implement
How do I write this without reviewing it line by line?
Writing new code: a feature, an endpoint, a screen. The job everyone thinks of first when they think about AI.
Where it earns its keep
Writing the twentieth variant of a pattern that already exists in your repository. It is not inventing anything there: it is copying well, and copying well is most of the work on any normal day.
Where it fails
The newer the thing you ask for, the more the output resembles an average of the internet. And a large feature in a single request drifts within the hour: the instruction from the beginning ends up competing with two hundred lines of test output, and loses.
How you know it came out right
Acceptance criteria written before it starts writing. If you cannot write down how you will check that it is right, you do not yet know what you are asking for.
Default process
Full ceremony
Where it runs
In the main thread
One coherent unit has one author. That does not contradict splitting into batches: if the feature cuts into pieces that do not overlap, each piece is its own thread with its own single author. What never works is two agents editing the same unit in parallel.
05
Review
What am I missing in this diff?
Having it read a finished change and tell you what is wrong, with the file, the line, and the scenario where it breaks.
Where it earns its keep
Reading a whole diff without skipping the boring file. Its attention does not wear out — which is precisely what happens to a human reviewer from the sixth file onwards.
Where it fails
It approves your own work if the reviewer is the same thread that wrote it. And with no declared budget it finds findings forever: half of them are noise, delivered with the same confidence as the real one.
How you know it came out right
Every finding with a file, a line, and a concrete failing scenario. A finding with no scenario is a style opinion in an urgent tone.
Default process
Light ceremony
Where it runs
Always a separate agent
Not for noise — for independence. The reviewer must not have seen how the code was written: having seen the reasoning, it reviews the reasoning instead of the result.
06
Decide architecture
Which option do we take, and where is the reasoning written down?
Using it to open the range of alternatives and name what each one costs, before somebody — you — chooses.
Where it earns its keep
Listing options you had not thought of and putting a name to the cost of each. As a generator of alternatives it is excellent, and it carries none of the bias of having worked six years with exactly one of them.
Where it fails
As a decider it is outright dangerous, because it pays none of the consequences. And if you tell it which one you prefer, it will bring you reasons for your preference. That is not a second opinion: it is a mirror with good prose.
How you know it came out right
The decision saved together with the alternatives you rejected and why you rejected them. If nobody can reconstruct the reasoning in three months, you will have the whole argument again.
Default process
Full ceremony
Where it runs
In the main thread
Deciding is the one thing that is not delegated. You can delegate the research into each alternative; the choice is signed by a person.
07
Document
How do I write down what already exists without it going stale in a month?
Turning code into prose: a README, an explanation of a module, the changelog nobody wrote.
Where it earns its keep
It can read and it can write, and that combination is rare in someone in a hurry. Documentation is the job everyone postpones, so the floor it competes against is having nothing at all.
Where it fails
It documents what the code does, not what the code is supposed to do. And that difference is the entire value of documentation: what it does, you can already read off the code.
How you know it came out right
Someone who was not involved can follow it without asking you anything. There is no automatic check for this, and pretending there is comes out worse than admitting there is not.
Default process
No ceremony
Where it runs
Separate when it gets noisy
If half the repository has to be read to write two pages, let someone else read it. If you are documenting what you just did, delegating forces the other agent to rediscover it from scratch.
08
Migrate
How do I move up a version without breaking what already worked?
Taking a major dependency up, changing framework, or moving a whole module to a different way of doing things.
Where it earns its keep
The volume. A migration is hundreds of call sites that all change the same way, and that work is mechanical, enormous, and completely unbearable by hand.
Where it fails
It applies the API it learned in training, not the one in the version you are migrating to — which is almost always newer than anything it saw. This is the job where stale documentation does the most damage, because the error only shows up at runtime.
How you know it came out right
The suite green on the new version, and every breaking-change note read by you — not summarised by the same agent that is running the migration.
Default process
Full ceremony
Where it runs
Separate when it gets noisy
The inventory of what has to change goes elsewhere and comes back as a list. The migration itself runs in batches, each one verifiable on its own.
Read the verification column top to bottom and the pattern shows itself: the jobs that go well are the ones where checking the result is cheap. That is the real lever — not asking better, but building the thing that checks.