Our co-founder Dr Hank Du has been thinking through why release cycles slip when features involve AI. Here's some of what he shared with us this week: "The easy part of feature planning is knowing what you want to build. Having gone through many release cycles now, anyone can come up with what to build, and even how to build it.
The hard part comes before you start building: how will you know it works, what has to be tested, and when do you call it finished? If you can't answer those questions, the cycle will slip.
AI features make this harder because they stack several sources of complexity at once. Traditional software behaves deterministically: same input, same output. AI features don't. Outputs are probabilistic. Users often have to verify results in the loop, which branches the journey. And there is usually data migration from the systems that came before, which changes how the application behaves. Any one of these would complicate a release cycle on its own.
The realisation we keep coming back to is that testing, even for a small team, cannot be treated as leftover capacity. It has to be a capacity of its own: planned, staffed, and defended in the schedule the same way building is. Shipped is not the same as client-ready, and the distance between the two is testing.
The other lesson is that complex features fail in dimensions that feature planning rarely names up front: how the user journey branches, how permissions cascade, how historical data migrates, how failures surface, and what evidence proves it works. Naming those dimensions before you build is what tells you how much testing capacity to reserve. You won't catch every unknown that way, but you'll catch most of them early, and you'll have capacity held back for the rest.
None of this is a reason not to ship AI features. It's a reason to plan them better."
