How do you turn an idea into a ticket an AI agent can build?

By closing the gap between rough and precise. I write the outcome first (what's true when it works), slice out the smallest piece that delivers real value, then write a spec with the context, the exact outcome, the constraints, and clear done-criteria — precise enough that an AI agent can execute it without guessing. The product decisions (what, why, what to cut) stay in my head and in the outcome; the ticket hands the agent only the 'how' to build, well-specified.

What makes a good ticket for AI coding tools?

Precision and a clear boundary. A good ticket states the outcome, the relevant context, the constraints, and how you'll know it's done — leaving no product decision for the tool to invent. Vague tickets force the AI to make choices it shouldn't (it'll guess plausibly and generically), while over-broad tickets ask it to build too much at once. The sweet spot is one small, well-defined slice with an explicit definition of done, so the agent executes rather than improvises.

Should AI tools decide how to implement a feature?

Implementation details, often yes — that's execution, which AI is great at. Product decisions, no. The line runs between 'how to build this well' (fine for AI within your constraints) and 'what to build and why' (yours). A good ticket encodes your product decisions as constraints and outcome, then leaves the agent free on the implementation within those bounds. That keeps the leverage of AI execution without letting it quietly make the product choices that determine whether the thing is any good.

How I Turn a Rough Idea into a Claude Code Ticket

The gap between a rough idea and working code is precision — and an AI agent like Claude Code needs a lot of it. I close that gap the same way every time: write the outcome first, slice out the smallest useful piece, then specify it tightly enough that the agent can build it without making any product decisions. The ticket carries the what and why (mine, non-negotiable) so the agent only has to handle the how. Done right, this is what turns AI from an impressive toy into the reason one person ships real features fast. Done wrong — vague ticket, AI fills the gaps — you get a plausible feature that solves the wrong thing.

The gap: rough is human, precise is buildable

A rough idea lives happily in your head at low resolution — "let users shape a request into a decision." That's enough for you to know what you mean. It is nowhere near enough for an agent to build, because the agent can't read the intent behind it; it can only build what's specified. Hand it the rough version and it fills the missing detail with the plausible average — which is exactly the product-decision drift I never want AI making. So my job is to raise the resolution before I hand it over.

Step 1: Outcome first

I start where I always start: what's true for the user when this works? One sentence. That outcome is the anchor the whole ticket points at, and it's the thing I refuse to let the agent decide.

Step 2: Slice the smallest useful piece

I don't ticket the whole idea — I ticket the smallest slice that delivers real value on its own. A big ticket asks the agent to make too many choices at once and to build too much before I can see if it's right. A small, sharp slice gets built, reviewed, and corrected fast — then I ticket the next slice. Small slices keep the agent executing rather than improvising, and keep me in the loop between steps.

Step 3: Write the spec

Then I write the ticket precisely enough to remove guesswork:

Context — what exists, where this fits.
Outcome — the exact result, from step 1.
Constraints — the product decisions encoded as rules: what it must and must not do, what to leave out.
Done-criteria — how I (and the agent) will know it's finished and correct.

Step 4: Keep the product decisions out of reach

The whole point is the boundary. Implementation details — how to structure the code, which pattern to use — I'm happy to leave to the agent; that's execution, where AI shines. But what to build, why, and what to cut never go into the agent's hands as open questions. They're already decided, encoded as the outcome and constraints. The agent builds my decision fast; it doesn't get to make it.

Step 5: Review against the outcome, not the code

When it comes back, I review against the outcome and done-criteria, not just "does the code run." Does it deliver the result I specified? Did it stay inside the constraints? If it drifted, that's usually a sign the ticket left a gap — so I tighten the ticket and go again. The review is where I catch the agent having quietly made a decision I should have made, and the fix is almost always in the spec, not the code.

What usually goes wrong

Vague tickets. Handing over the rough idea and letting the agent fill the gaps with the generic average.
Tickets too big. Asking for the whole idea at once, so too many decisions get made before you can course-correct.
Product decisions left open. Not encoding the what/why/cuts as constraints, so the agent invents them.
Reviewing code, not outcome. Checking that it runs instead of that it delivers the result — and missing the drift.

Write the outcome, slice it small, spec it tight enough that only the implementation is free, and review against the outcome — and Claude Code becomes the fast hands that build your decisions, not a plausible-answer generator. The precision you add before the ticket is exactly the product judgment AI can't supply. That's the whole workflow, and the whole reason it works.

Part of Building AI Products. See also how I use AI without letting AI make product decisions and why I write the expected output before the screen. The newsletter sends one practical build lesson every two weeks.