It was a Tuesday afternoon. I had a task: a filter component for a product list needed to be faster. I knew roughly where the problem was – so I just started.
Three hours later I had a significantly more complex component, a refactored state management layer and a pile of open questions. Was this solved on the frontend or could it have been addressed on the backend? Which filter options should actually be cached? And what was the difference with the mobile view again?
I had been coding without really understanding the problem. The result showed it.
A ticket is not a bureaucratic act
When I use the word "ticket", I sometimes hear a quiet groan. Fairly enough – in many teams, a ticket means: fill out a Jira form, write "N/A" in three fields, add a deadline, assign a sprint. That has about as much to do with what I mean as a doctor's appointment with a spontaneous walk in the park.
A ticket in my sense is simply: a short, clear description of a problem and the expected result. Two paragraphs. Sometimes three bullet points. Done.
The crucial thing is not the ticket itself – it's the act of writing. Whoever has to write a problem down first has to think it through. And that is the real gain.
What a good ticket contains
I keep it simple. Three things are almost always enough:
Goal: What should be better after this change? Not "optimize the filter component" – but "the filter component should respond without visible lag at 500+ entries."
Acceptance criteria: When is the task done? "Filter interaction under 100 ms, tested on a mid-range Android device." No essay – but concrete enough that I know at the end of the day whether I'm finished.
Out of scope: What is explicitly not part of this task? That's the underrated part. When I write down "backend caching is a separate ticket", I'm not suddenly deep in a different problem three hours later.
Why this matters even more with AI
Anyone who read Context engineering: why your prompt is the smallest problem already knows the principle: the AI is only as good as the context it receives. A ticket is the application of that principle at the level of the individual task.
Before, I could start coding with a vague plan and at least trust my own judgment. I know the codebase, I understand the context, I notice when I'm going off track.
An AI model can't do that. It has no context beyond what I give it. If I write "optimize the filter component", I get code that optimizes something – maybe exactly the right thing, maybe something that improves performance but breaks accessibility, maybe a generic solution that doesn't fit the project at all.
The ticket forces me to build that context before I hand it off. After that I can give the AI a precise task – and I get a precise result.
Clean commits as a side effect
Working with tickets comes with a gift: a readable git history.
Every commit references a ticket. fix: GBW-42 – filter response time under 100ms. Three months later I know immediately: what was the problem? Why was this changed? What was the scope?
Without tickets it looks different. fix: performance. update filter. changes. These commits have given me many grey hairs in my career – usually my own.
The connection is direct: whoever has described the problem clearly can also name the solution clearly. And a clearly named solution is a good commit.
The side effect that surprised me most
Sometimes, when I sit down to write the ticket, I realize I can't.
Not because the problem is too complex – but because I can't clearly formulate the goal. I sit down and realize: I don't actually know what I want. Or: the feature doesn't actually make sense in the current state of the project. Or: this isn't a frontend problem at all, it's a data model problem.
That's not a failure of the ticket. That is the point. Writing a ticket costs me ten minutes. Coding in the wrong direction for three hours costs me – well – three hours. Plus the time to undo it.
The ticket is the cheapest mistake I can make. Because when it happens, it happens on paper.
How I handle it today
I use YouTrack for my own project – but the tool doesn't matter. What matters is the moment before the first commit: is there a ticket for this?
For my own projects I write the ticket myself – often in five minutes. For client projects it's usually already there, or I help shape it. And when someone says "this is just a small thing, does it really need a ticket?"
My answer: precisely because it's a small thing, the ticket takes two minutes. And if it turns out not to be a small thing, you just figured that out – without having written a single line of code.
The next post looks at the other side of the same question: what happens when you have a ticket but still start too early – without having defined the architecture first?
Whoever cannot write a ticket has not yet understood their problem. And whoever has not understood their problem should not be writing code yet – neither themselves nor via AI.