Something is off with AI-assisted development. Here is what it usually is.
The code works. The product is drifting.
Five problems we see in teams that adopted AI coding tools, what causes each one, and the one fix they share: what you write down is what the agent keeps.
- The code looks finished and is wrong
The agent returns a confident, coherent, plausibly wrong answer. It passes a surface review because the logic looks sound, and it fails in production.
The cause: Mistakes got cheap to make and stayed expensive to find. Output went up; review capacity did not. There was nothing specific to review against, so the reviewer judged how plausible it looked.
- The same rule lives in five places
A business rule is added wherever it was asked for. When the rule changes, one place gets fixed and the others keep the old version.
The cause: The instruction named locations, not the rule. Say "this is a rule of the order, use it wherever a refund is decided" and the agent builds one place.
- What shipped is not what was meant
The feature works. It is not quite the feature the product needed, and the rework starts after launch.
The cause: Intent was never written down. The build was faster than the deciding, so the why never caught up with the what.
- Nobody can explain the product six months later
Features exist that no one can trace to a decision. The roadmap and the code have quietly parted.
The cause: Going fast without the why is not speed. It is fast chaos. Nothing kept the strategy and the repository in the same picture.
- The team runs out of decided work
Developers are fast and idle. Velocity looks fine on the board until the queue of undecided work empties.
The cause: Only the development work is estimated. Deciding what to build is not on the board, so nobody saw it become the constraint.
One cause under all five
A strong developer used to make up for a thin brief. Months of knowing how things worked filled the gaps, and they asked someone when they could not. An agent cannot do that. It has no memory of your last six months and no sense of what to ask. Whatever you did not write down, it guesses, quickly and with confidence. So the product judgement has to be written before the build: the strategy, the rule, the acceptance criteria. Name the rule, not the locations.
What we saw: a couple of days of written context on a feature, then a junior developer who knew almost nothing about it built an MCP layer in a day, tested end to end, with far fewer product questions from the agent than usual. Same tool. The difference was what was written down first.
The check most teams skip
Does what you built match what you set out to build? Feature1 keeps the strategy as a written narrative, reads the repository to see what the product can actually do, and shows the gap. That gap is the list of what to change next, and it is the same check whether you are planning the next quarter or reviewing last week's pull requests.
Start with what you set out to build.
Thirty minutes to write the direction down. Then the code has something to be checked against. $29, no code access needed.