Almost every AI mistake starts in the ticket

Almost every mistake AI made during our hackathon with the One Go development team was in the ticket, in what nobody had written down. A small share was in the code itself. If you want to move faster with AI, better specs are where you gain the most, and that asks something of developers and product owners alike.

Too vague or too bloated

A ticket can fall short in two ways. It's too vague, or it has been filled out with AI and has become hugely bloated. Either way, whoever builds it doesn't know exactly what needs to happen. At One Go, both were happening.

That was what the hackathon was about: how do you get from an idea to a plan you can actually carry out? We tried spec-driven development, loosely based on a blog post by Anthropic: first the intent, then the spec, then the plan. Three mixed hackathon teams of developers and non-developers worked with it for a day, on real tickets from the backlog.

Not in the room

By the One Go development team's estimate, only 1 to 2% of AI's mistakes are genuinely badly written code. The rest starts in the spec. Wherever the spec leaves something open, the AI fills in an assumption of its own.

An example from the project shows this isn't only true for AI. A versioning API was built differently than intended. The developer who built it joined the team later and hadn't been part of the earlier conversations. The details weren't in the ticket, so there was no way to know them. An AI agent is in exactly that position, only on every ticket.

That puts work on the product owner. Edge cases belong in the ticket before there's a plan, even for a small ticket. What you can skip for a bug or a small addition are the separate intent and plan steps. There, they cost more than they deliver. For a whole feature, they pay for themselves.

What's in someone's head, the AI doesn't know

One of the hackathon teams gave the same prompt on different machines and got different results. The difference was in the rules each person had given Claude over time. That's team knowledge, but it lived on a single laptop.

The same thing happened with design. For a small feature, such as a settings page, the design system is enough, as long as the AI is explicitly told to use it. Give it a Figma design and the AI follows it very literally, restyling existing components the moment they deviate even slightly. When a design is needed and when the design system will do is currently a judgment call in someone's head.

Both belong somewhere the whole team can find them. That's spec too: what isn't written down, the AI fills in itself.

Review sets the pace

At One Go, most of the codebase is written by hand. The team has AI write most new features, and that code is reviewed in full. It's closer to pair programming than to an AI going its own way. The rule is simple: you're responsible for the code in your pull request, however you got there.

That full review is needed because AI makes mistakes. And that's where the bottleneck is: AI produces far more text and code than anyone can review. Every hackathon team ran into this. Agent Teams, a Claude Code feature where several agents work on one task at the same time, each with its own context, did good work. But because each agent builds up that context itself, a single ticket burned through so many tokens that it isn't efficient yet.

Claude reviews first and catches real mistakes. It also raises a lot of matters of taste, which the team often sets aside. What developers still find after that is about domain knowledge, and about mistakes that come from an unclear or incomplete spec. So what's left for review mostly started in the ticket.

The team could produce more than it does now, but deliberately keeps to the pace it can review. The craft is increasingly in the spec, and in judging what comes out.

Next time, we turn it around

At the next hackathon, we won't add AI to the process that already exists. We'll look at which processes need to change now that AI is here. One important goal: setting up review so the team dares to hand it off, for example with automated UI tests that compare the old and the new situation.

Intent, spec and plan belong in the ticket. That's where people and the business see what's happening, and where an agent, or a developer who joins later, finds what was discussed.

Further ahead, we expect systems that keep working day and night, with people answering the questions left open through a dashboard each morning. At heart, those are questions about the spec too.

To be honest, this is bleeding edge, and half of what we try may come to nothing. With AI, the backlog has shrunk from about three years of work to one, but One Go has ideas for years. So time to experiment doesn't appear by itself. You have to make it deliberately, and that's what this hackathon is for.

In practice, that means edge cases are in the ticket before there's a plan, team rules and design trade-offs live in one place everyone can find, and in review you also look at what was missing from the spec.

A year from now, we'll have this conversation again, to see where we stand.

Take your next feature ticket and give it to someone who wasn't in the room. Ask them what they would build. Every difference from what you meant is something an agent will fill in by itself, so it still belongs in the ticket.