Hand it over, or do it yourself

You spend forty minutes prompting an agent to nudge an icon two pixels to the left. It moves it three, then one, then somewhere else entirely. Later the same afternoon, you hand-write a date picker you could have described in two sentences.

Both mistakes have the same cause. You picked the wrong tool for each job, and the tool in one case was you.

The rule

An agent, the AI that reads, writes and runs code for you, is brilliant at work with lots of code and a clear finish line. It's clumsy at work where the quality lives in how something looks or feels, because each round trip through a prompt costs more than just doing it.

So ask two things about any task. Is it a lot of code? Can you say what done looks like? If yes, hand it over. If the quality lives in your eye, or you'd be faster by hand, keep it.

Practise on twelve

The rule is easy to say and surprisingly easy to get wrong in the moment. Here are twelve real tasks. Sort each one, then read why.

A pattern shows up quickly. The things you hand over (a CSV import, a prop renamed across sixty components, retry logic for a failed save) are big but describable. The things you keep (the bounce on a drawer, an icon centred by eye, the crop of a screenshot) are small but felt. For the in-between ones, split them: let the agent propose five accent greens, then pick one yourself.

Work with it like a colleague

The worst way to use an agent is like a vending machine: put a request in, take whatever falls out, put another request in. The best way is closer to working with a capable new colleague.

1. Read the context yourself first

   Open the files, skim the doc, look at the screen. You can't judge a proposal about something you haven't looked at.

2. Ask for an approach before code

   Three sentences on how it would do it. That's cheap to read and cheap to correct.

3. Add the one thing you know

   Most of the time you know something the agent doesn't: a constraint, a better primitive, a reason. Say it.

That last step is where most of the value is. Say you want dots to travel along the wires of a diagram. The agent might reach for a timeline of hand-placed positions. You happen to know each wire is already an SVG path, and SVG can move a shape along a path on its own.

Read docs/sync.md, then propose how to animate the sync diagram so it explains the idea in the article.
Keep it to three sentences before writing code.
Constraint I know matters: each wire is an SVG path, so moving dots can follow it with <animateMotion>.

Papercuts

A papercut is a small flaw that's easy to live with once and wearing after a hundred times, like a menu that closes the dialog behind it. Every product collects them. The ones that feel cared for are the ones where someone fixes them steadily.

Agents are great at papercuts, as long as you don't stop what you're doing to fix each one. Spot it, write it down, hand it over, carry on. The writing-down part is what makes or breaks it, and the rule is simple: evidence beats adjectives. "The dropdown feels weird" sends the agent guessing. A screenshot with an arrow on it, or for motion the actual numbers from the frame where it goes wrong, sends it to the cause. If you think you know the cause, name it.

A good papercut report fits in five lines: what happens, what should happen, your best guess at why, the evidence, and how far the fix may reach. That last line stops a two-line bug fix from turning into a redesign.

What to remember

• Lots of describable code: hand it over. Quality judged by eye, or faster by hand: keep it.
• Read the context, ask for an approach in a few sentences, then add the one thing you know.
• Log papercuts as you go with evidence (a screenshot, a recording, the numbers) and a limit on the fix.

Go deeper: Briefs that work · Tools that check the work