AI is speeding up the wrong part of software

We surveyed about 350 engineers with Refactoring.fm on AI adoption. 95% of teams are using it. 80% are using it heavily.

9% are using it to help write product requirements.

The same survey shows requirements are the single largest reported bottleneck – bigger than testing, code review, or deployment. Teams are pointing AI at almost everything except the part of the pipeline slowing them down most.

That's where "almost right" comes from. The spec doesn't say what right looks like, so AI fills in the blanks with whatever's statistically likely. The spec says "support bulk edit" but doesn't define what happens on partial failure. The spec says "show recent activity" but doesn't define recent. Nobody asks during grooming. AI builds it. It looks fine in review. A customer hits the case nobody specified.

AI didn't create the planning problem. It just hid the cost of bad planning.

Bad specs used to surface immediately. Tickets coming back, engineers pushing back on grooming, the same items hitting retros twice. Friction caught ambiguity by accident. Now the ambiguity surfaces three sprints later, when customer support starts asking questions about a feature and nobody connects it to the spec that caused it. Velocity looks fine. The rework just hides in a different column.

If your AI-assisted velocity is up and you don't know how your rework rate has moved alongside it, this is probably what's happening.

I've seen this movie before. Before Atono I built xMatters – 3 million users, 99.99% uptime, sold to Everbridge in 2021. Upstream was always where the expensive problems lived, and almost always the last place anyone aimed a new tool. Apparently still true.

The report digs into what separates teams whose AI ships clean code from teams whose AI ships almost-right code – where their product knowledge lives, how they share AI context, and whether the gap is widening fast enough to matter.

If you keep getting AI output that's almost right, the report's where I'd start.