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 pitch for AI coding tools is that you describe what you want and they build it. In practice the gap between a rough idea and working code is precision, and Claude Code needs far more of it than the pitch admits. I close that gap the same way every time: write the outcome first, cut out the smallest useful slice, then specify it tightly enough that the agent can build it without making a single product decision. The ticket carries the what and the why — mine, non-negotiable — so the agent is left with only the how. Done right, this is what turns AI from an impressive toy into the reason one person ships real features quickly. Done wrong — vague ticket, agent left to fill 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 at low resolution in your head — "let a user shape a vague request into a clear delivery decision." That's plenty 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 underneath the words; it can only build what's on the page. Hand over the rough version and it fills the missing detail with the plausible average — which is exactly the product-decision drift I never want an agent making. So the job is to raise the resolution before it changes hands.

Step 1: Outcome first

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

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 tell whether any of it is right. A small, sharp slice gets built, reviewed and corrected fast — and then I write the next one. Small slices keep the agent executing instead of improvising, and keep me in the loop between steps.

Step 3: Write the spec

Then I write the ticket precisely enough to leave no guesswork:

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

Step 4: Keep the product decisions out of reach

The whole thing turns on one boundary. Implementation details — how to structure the code, which interaction pattern to reach for — I'm glad to hand off; that's execution, where AI is genuinely strong. But what to build, why, and what to cut never reach the agent as open questions. They're already settled, encoded as the outcome and the 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 the done-criteria, not "does the code run." Does it deliver the result I specified? Did it stay inside the constraints? When it drifts, that's almost always the ticket leaving a gap — so I tighten the ticket and run it again. The review is where I catch the agent having quietly made a call I should have made, and the fix is nearly always in the spec, not the code.

What usually goes wrong

Vague tickets. Handing over the rough idea and letting the agent backfill it with the generic average.
Tickets too big. Asking for the whole idea at once, so too many decisions get made before I can course-correct.
Product decisions left open. Not encoding the what, the why and the 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 rather than a plausible-answer generator. The precision you add before the ticket is precisely the product judgment AI can't supply. That's the whole workflow, and the whole reason it holds.

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.