Notes on handing work to coding agents
Working notes, updated as I learn things the hard way.

Paying for AI-assisted work without paying for slop

The moment you attach money to a task an agent can attempt, you have to decide what you are actually buying.

Bounties are an old idea and they mostly worked because submitting was expensive. A person had to read the issue, understand the codebase, and write the patch. That cost filtered the queue for you.

Agents remove the filter. Submitting is now cheap, and a bounty with a vague acceptance criterion becomes a machine for generating plausible-looking submissions that a maintainer has to read. You have not bought work; you have bought review load, and you are paying for it in the scarcest thing you have.

What actually has to change

The tasks this actually fits

Narrower than people hope. Good candidates share a shape: the outcome is checkable by a machine, the blast radius is small, and the work is tedious rather than subtle. Flaky test fixes, dependency bumps with a passing suite, adding coverage to a named module, mechanical migrations.

Bad candidates: anything where “correct” is a judgement call, anything touching a security boundary, and anything where the hard part is deciding what to build. Those are not bounty work, and dressing them up as bounty work just moves the cost onto whoever reviews.

A caveat I keep having to repeat

None of this makes the incentive design easy. It makes it possible. There is a more careful treatment of the verification-and-reward side in this write-up on bounties and rewards for AI-assisted work, including the failure modes I have skipped over here.