13 August 2026
I've been working with a SaaS team that routes almost its entire delivery pipeline through AI: specs, design, architecture, ticket creation, code generation. On paper it should have been the best-documented backlog I'd ever seen, and it was, impressively so. Every ticket read like it had been written by a senior engineer who'd already solved the problem: clear structure, exact class names, a defined implementation path from the first line.
That confidence should have been a green flag. It wasn't. The uncomfortable truth is that this team was enforcing technical debt before a single line of code had been written.
AI-generated specs read as confident because they are precise. They name the class. They name the method. They describe the exact pattern to follow. That precision reads like expertise, like someone who has already thought the problem through and is now just documenting the answer.
It isn't. It's specification without thinking. The model has pattern-matched onto something plausible and written it down as if it were a decision. Nobody actually worked out why the behaviour matters, what happens when it goes wrong, or whether "implement X in class Y" is even the right shape for the problem. The confidence is real. The thinking behind it isn't.
When a ticket says implement X in class Y, developers stop thinking about the problem and start executing instructions. Coding agents do the same thing, only more literally: they don't own the outcome, they follow the ticket. The codebase drifts toward whatever the AI was told to build, not toward what the system actually needs to be.
That's the real cost. Ownership doesn't just disappear from a single ticket, it disappears from the codebase as a habit. Once developers get used to executing rather than deciding, they stop noticing when the next ticket contradicts the last one.
Here's what it looks like in practice. One ticket says implement X in class Y. A few sprints later, a similar ticket says implement X in class Z. Any senior engineer reading this already knows what happens next: now the same behaviour lives in two places. The bug that gets fixed in Y quietly survives in Z. SOLID principles are gone. And because nobody questioned the first instance, the coding agent, and the developers around it, treat the duplication as an established pattern. The next AI-generated ticket copies it again.
The teams getting real value from AI aren't skipping refinement to move faster. They're doing more of it, not less. Before a ticket is anywhere near "ready for AI", they're asking:
That's the whole difference. Refinement forces someone to think through what's being built before AI is allowed to decide how. Skip that step and you've handed the "how" to a system that has no stake in the codebase's future.
None of this is an argument against AI. The issue was never the tool. It's treating AI output as a final decision instead of a first draft that still needs scrutiny.
Proper refinement before AI touches a ticket prevents technical debt from being baked in on day one. Developers keep ownership of what they're building. Coding agents get handed real problems to solve instead of instructions to execute. The codebase stays something a team can reason about months later, not just something that compiles.
It doesn't matter whether your team runs Scrum, Kanban, or something in between. The mechanism that matters is the room: the point in the process where the whole team looks at a ticket together and someone is allowed to say "I don't understand this part." That single sentence does two things at once. It catches ambiguity before it becomes a bug, and it teaches everyone in the room what a well-written ticket actually looks like, versus one that just sounds confident.
Your refinement process isn't old-fashioned. In an AI-assisted pipeline, it's the only thing standing between you and technical debt that was baked in before anyone typed a line of code.← All posts