Imagine sitting in a project review and hearing that a piece of software you expected to take three months has reached something resembling 80% completion in two weeks.
There is an obvious question. "Great. So when can we have it?" It's a perfectly reasonable question.
It's also where some of the most interesting challenges created by AI-assisted software development begin.
In our latest conversation with Ben Whorwood, Senior Architect at Flowmoco, we explored what happens when generative AI dramatically accelerates the visible part of software development.
Ben has experienced this directly. On a fintech project, he used GenAI to create an initial implementation in around one or two weeks for something he estimates would previously have required around three months.
That's a remarkable productivity gain. But it also raises a deceptively difficult question: what does 80% finished actually mean?
The 80% illusion
The screens are there. The workflow works. The API responds. Data appears where it should.
Someone can sit in front of the application, click through it and successfully complete the process. To a stakeholder, that can understandably feel like 80% or even 90% complete. But visible functionality and production readiness aren't the same thing.
Behind what the user sees are error handling, edge cases, permissions, security, logging, monitoring, performance, testing, documentation, deployment, maintainability, backup and recovery.
Ben describes AI as being able to get developers a long way towards that visible 80% extremely quickly. The remaining work, however, can still consume considerable engineering time.
That's because it isn't simply polishing the final few pixels. Much of what remains is the engineering that turns something that works into something the business can depend upon. That distinction matters enormously for enterprise software.
AI is making story points difficult
It also creates a very practical problem for development teams. How do you estimate the work?
Agile teams have historically developed an intuitive understanding of story points and velocity. The team looks at a story and says: "We've built things like this before. That's probably an eight." That judgement incorporates years of experience about complexity, uncertainty and effort.
Then AI arrives.
A developer discovers that something expected to require several days of implementation can be generated in a morning. Does an eight-point story suddenly become a two?
Perhaps. But then the next apparently similar story encounters a complicated integration or unusual edge case and requires substantially more human intervention.
The relationship between complexity and elapsed development time starts becoming less predictable. Ben sees this directly in the difficulty of assessing story points and sprint burndown when AI is accelerating different parts of development at radically different rates. Traditional velocity metrics don't necessarily disappear. But their meaning may need to evolve.
Should AI mean more story points?
There is another question hiding underneath this.
If AI makes a developer significantly faster, should management expect them to complete significantly more stories every sprint? It's tempting. If implementation effort falls by 50%, surely velocity should double?
Ben's perspective suggests something more interesting could happen.
Perhaps the productivity gain shouldn't all be spent on producing more features. Software engineers have always had a list of things they would like to do better.
Improve the documentation. Write another set of tests. Refactor an awkward section of code. Improve error handling. Investigate that unusual edge case. Add better monitoring. Tidy up the handover. Improve the developer experience for whoever comes next.
None of these things are unimportant. But they're often the activities living in the margins of a sprint. The feature works. The deadline is approaching. Another story is waiting. Move on. AI potentially gives developers some of those margins back.
The joy of a more rounded sprint
This may turn out to be one of the less discussed benefits of AI-assisted development.
Instead of measuring the productivity improvement purely as "10 story points becomes 20 story points," perhaps we should sometimes measure it as "10 story points becomes a much more complete 10 story points." The developer still delivers the functionality. But now there is more time for documentation.
More testing. Better error handling. More attention to edge cases. More opportunity to refactor something that doesn't feel right. A cleaner handover. A more maintainable result.
For experienced engineers, there is something genuinely attractive about that. AI can take away some of the repetitive implementation effort and create more space for the parts of engineering that require judgement.
That aligns strongly with Flowmoco's own approach to software engineering: production-ready code, modular and testable architecture, iterative delivery, and documentation and knowledge transfer built into handover rather than treated as an afterthought. (Flowmoco Ltd)
Perhaps AI's biggest contribution to sprint velocity isn't helping engineers do more stories. It's giving them enough space to finish each story properly.
Then we hit the QA problem
There is, however, a problem. If development accelerates dramatically, quality assurance has to keep up.
Imagine an engineer can now generate thousands of lines of apparently working code in the time it previously took to write hundreds.
Someone still needs to establish whether that code: does what was intended; handles unexpected conditions; is secure; integrates correctly; doesn't break existing functionality; performs appropriately; and can be understood and maintained later. AI can help with that too.
It can generate tests. Review code. Identify potential problems. Suggest edge cases. But there is a deeper assurance question: how comfortable should we be asking the same class of technology that generated something to tell us whether what it generated is correct?
Independent engineering judgement still matters. And as code production accelerates, verification can increasingly become the constraint.
Recent research into AI-assisted software engineering is beginning to describe a similar shift: as implementation becomes cheaper and faster, engineering effort increasingly moves towards making the resulting systems inspectable, correctable and maintainable. (arXiv)
Has QA become the new bottleneck?
For years, development teams have tried to optimise delivery pipelines. Requirements move into development. Development moves into testing. Testing moves into deployment.
AI has the potential to radically accelerate one stage of that pipeline without necessarily accelerating everything around it at the same rate. That creates an interesting inversion.
Historically, we might have had: Development → QA, with development frequently acting as the constraint.
Increasingly, we could have: AI-accelerated development → QA, with assurance becoming the constraint.
That isn't necessarily bad. If we're going to have a bottleneck, establishing that software is safe and correct isn't a terrible place to have one.
But organisations need to recognise the change. Simply measuring how quickly developers can generate functionality could become a misleading measure of overall delivery performance.
AI makes "done" more important
Agile teams have long talked about the Definition of Done. AI arguably makes that concept more important.
When something can look finished incredibly quickly, organisations need to be precise about what finished actually means.
Does "done" mean the feature works? Or does it mean the feature works, has been tested, reviewed, secured, documented, integrated, monitored and can be maintained by someone other than the person who created it?
Those are very different definitions. FlowMoCo explicitly distinguishes rapid prototyping from production engineering: prototyping is used to validate assumptions quickly, while production software is engineered for reliability, maintainability and performance. (Flowmoco Ltd)
AI makes the first of those dramatically easier. It doesn't make the distinction disappear.
Code can work without being understood
There is another issue Ben raises that becomes increasingly important as AI generates larger quantities of code.
Software has meaning. An experienced developer doesn't just know what a section of code does. They often understand why it is there.
They remember the awkward integration. The edge case discovered six months ago. The reason an apparently unnecessary validation step exists. The production incident that resulted in a particular architectural decision. Thousands of small pieces of context accumulate as people build and maintain systems.
AI-generated code can work without the humans responsible for the system developing the same depth of understanding. That may not matter during a prototype.
It matters enormously when the original developer leaves, something fails at 2am, the system needs to change three years later, or a prototype quietly becomes business-critical infrastructure.
The question isn't merely: can we generate this code? It's: can we own it afterwards?
Boards should expect the productivity gain
None of this should become an excuse for engineering organisations to claim AI won't change delivery economics. It already is.
Boards, CEOs and CTOs should absolutely challenge technology teams about where AI can make development faster and more efficient. If something that genuinely took three months can safely be delivered in three weeks, the organisation should benefit.
Discovery should become cheaper. Prototypes should arrive faster. Some development estimates should fall. Engineering productivity should improve.
But executives also need to distinguish between speed of generation and speed of assurance. Because AI is dramatically reducing the cost of making software. It isn't necessarily reducing the cost of knowing that software is good. And for business-critical enterprise systems, the second question ultimately matters more.
Vibe code the possibility. Engineer the reality.
At Flowmoco, we believe organisations should use AI to discover the right thing to build, then use experienced engineers to build it properly.
Use AI to explore. Use it to prototype. Use it to remove repetitive implementation work. Use it to make early iterations cheaper.
And use the time it gives back to engineers to do more of the things that traditionally struggled for space inside a sprint.
But when that software starts handling customer data, processing transactions, integrating with critical systems or becoming something the organisation depends upon, "it works" isn't the finish line.
The questions become: can we understand it? Can we test it? Can we secure it? Can we maintain it? Can we monitor it? Can we recover it?
That's where experienced engineers become more valuable in an AI-accelerated environment, not less. Their value increasingly moves from simply producing code towards applying judgement to everything being produced.
AI gives us more speed. Experienced engineering helps us spend that speed wisely.
Continue the conversation with Ben
AI-assisted software development is changing quickly, and teams are still learning what it means for estimation, story points, QA, sprint design and production engineering. If this article has prompted you to think differently about your own development process, get in touch with Ben Whorwood, Senior Architect at Flowmoco.
Ben would be interested to hear how other technology leaders are seeing story points, QA and engineering practices change, compare perspectives, or talk through what AI-assisted development could mean in your own enterprise context.
Because the next time someone says: "If AI built 80% of it in two weeks, surely we're nearly finished?" perhaps the right response is another question: "80% of what?"
Talk to the Flowmoco engineering team