How do you know you're building the right thing?
Traditionally, organisations have tried to answer that question through discovery workshops, requirements documents, architecture diagrams, user stories and detailed specifications. All have value. But they share an inherent limitation. Eventually, somebody has to build something.
And it is often only when users can see and interact with that something that the real learning begins.
We recently sat down with Ben Whorwood, Senior Architect at Flowmoco, to discuss how generative AI is changing that process.
Ben's experience suggests that one of the most valuable applications of AI in enterprise software development may not be replacing software engineers. It may be helping engineers and customers discover what should be built before they spend most of the budget building it.
The expensive way to discover what you really wanted
Ben describes a familiar moment in custom software development. A development team works against the initial requirements. Then the customer gets something tangible to use. And that's when some of the most useful feedback starts:
"I don't need that."
"I do need this."
"Now I've seen it, could it work like this instead?"
There's nothing wrong with that. In fact, it's a completely normal consequence of an iterative, agile approach to software development. Software development has always involved building, testing, learning and adapting. Requirements evolve because understanding evolves. Once people can interact with a system, they see possibilities, constraints and needs that were difficult to articulate when the product existed only as an idea, user story or process diagram.
Ben describes this as the point at which customers often really start understanding what they need.
The problem isn't iteration. The problem is how much of the budget you have already consumed before you reach the most valuable iterations.
Historically, you could burn a significant proportion of the customer's development budget getting to the first meaningful version. By the time users experience the software and their understanding moves forward, considerable time and money may already have been committed to the assumptions that came before it.
That creates friction. But when budgets are tight, it can create a more fundamental problem. The team has learned something valuable, but there may no longer be enough budget available to properly act on that learning.
Changes get deferred. Useful ideas become "phase two". Teams compromise on what they now know would create greater value because too much of the available investment has already been committed.
And that can directly affect return on investment. The organisation has spent the money required to discover what users really need, but can't release enough additional budget to continue exploring and turn those insights into the solution that will deliver the intended business value.
In other words: the project can run out of capacity to iterate just as the most valuable learning begins.
AI-assisted prototyping potentially changes those economics.
From three months to a couple of weeks
Ben saw this firsthand while working on a data integration platform for a large fintech organisation. The organisation had grown through acquisitions. As a result, its technology estate contained multiple systems with different data structures, authentication mechanisms and integration points.
Flowmoco was helping create a unified interface over those fragmented systems. Part of the project required a user interface for configuring the platform. Ben decided to experiment with generative AI to produce the initial implementation, using technologies the team already knew and used in production.
His estimate for developing it conventionally? Approximately three months. The initial AI-assisted version was produced in around one or two weeks.
The obvious conclusion would be that AI makes software development dramatically cheaper. But that isn't the most interesting lesson. The real opportunity is that it makes learning cheaper.
Build enough to have the conversation
Imagine spending several months documenting and discussing a proposed enterprise application. Now imagine spending a fraction of that time creating something stakeholders can actually experience.
It doesn't need to be the finished product. It doesn't need production infrastructure. It doesn't necessarily need live customer data. It needs to be good enough to make an abstract conversation concrete.
Instead of:
"Imagine there was a screen where you could..."
you can say:
"Click here."
Instead of debating whether a workflow makes sense on a process diagram, somebody can try completing it. Instead of asking users what features they might want six months from now, you can watch what happens when they interact with an approximation today.
That means the valuable agile feedback loop begins earlier.
Describe → Prototype → Experience → Learn
And because those first iterations are cheaper, you can potentially run more of them. Try something. Reject it. Try another approach. Put it in front of users. Change it again.
The objective isn't to eliminate discovery. It's to make discovery more tangible, faster and more capital-efficient.
Show the vision rather than describe it
This is particularly interesting from an architecture perspective.
Ben describes himself as a hands-on architect. He still builds things. And that has changed how he communicates technical ideas.
Architects can spend enormous amounts of time producing detailed technical explanations that many stakeholders will never read in full.
Ben increasingly prefers another approach. Build something that represents the vision. Show it from the top down. Then explain the architecture, decisions and engineering underneath it as the stakeholder's understanding develops.
A working representation can convey an idea much more effectively than pages of technical explanation. Generative AI makes producing those representations dramatically faster.
For enterprise development, that could change the starting point from:
Specify → Estimate → Build → Experience → Learn
to:
Describe → Prototype → Experience → Learn → Engineer
That distinction matters.
But what happens to story points?
There's another consequence that is less obvious. AI is making some traditional measures of software development productivity harder to interpret.
Ben has seen this in metrics such as story points and sprint burndown. If a task that previously represented weeks of implementation can suddenly be accelerated dramatically using AI, how should the team estimate it?
Simply increasing the expected number of story points completed per sprint misses what's happening. Because AI isn't necessarily just allowing teams to produce more features. Ben sees an opportunity to produce more rounded deliveries. The time saved generating initial code can be reinvested into things engineering teams often wish they had more time to do properly: documentation, testing, error handling, hardening and handover.
That means the apparent productivity gain isn't necessarily:
10 story points becomes 30 story points.
It might be:
10 story points still takes the sprint — but what gets delivered at the end is substantially more complete.
Ben says estimating story points is becoming more difficult because teams are still adapting to this new way of working. Different parts of the development process accelerate at different rates, while the risk associated with those parts can also be very different.
The familiar burndown chart may therefore tell only part of the story.
Perhaps we should measure learning as well as output
That raises an interesting question for CTOs and technology leaders. If AI dramatically accelerates prototyping, should we continue measuring the early stages of a project primarily through development output?
Perhaps the more valuable question is: how quickly are we reducing uncertainty?
A prototype that takes a week and proves that a proposed workflow is wrong could be considerably more valuable than a beautifully engineered feature that takes six weeks and proves the same thing. Because you haven't wasted five additional weeks. More importantly, you haven't consumed the budget associated with them. That budget remains available to explore the next hypothesis and ultimately engineer the solution that produces the return.
This is where the economics become interesting. We're making the early iterations dramatically cheaper, so there is more budget left to act on what we learn.
The objective during discovery shouldn't be to produce as much software as possible. It should be to learn as cheaply and quickly as possible what software is worth producing.
Vibe coding isn't production engineering
There is an important boundary. Ben isn't suggesting enterprises should vibe code business-critical applications and push them straight into production. Quite the opposite.
Different parts of a system have very different risk characteristics. A user interface created to explore an idea is fundamentally different from a backend transaction-processing system handling financial data.
AI-generated code can also miss the thousands of small feedback loops experienced developers naturally encounter while building systems: edge cases, unexpected responses, error conditions and the "unhappy paths" that gradually harden production software.
That's why the distinction between prototype and product matters. AI can help us reach the prototype remarkably quickly. Experienced engineering judgement determines what happens next.
Use AI to discover the right thing to build
At Flowmoco, we think this points towards a better way to approach enterprise software projects.
Use AI to discover the right thing to build. Then use experienced engineers to build it properly.
The goal isn't to replace agile discovery with vibe coding. It's to make working software a much earlier part of that iterative process.
Prototype the workflow. Test the assumption. Put it in front of users. Find out what they actually need. Change direction while changing direction is still cheap.
And preserve more of the available investment for building the thing that will ultimately create the return.
Once there is greater confidence that you're solving the right problem, apply the architecture, security, testing, data engineering, integration and production disciplines needed to turn that prototype into business-critical software.
The biggest saving may not ultimately be the number of developer hours required to write the code. It could be the money you don't spend building the wrong thing — and the additional budget you preserve to build the right thing properly.
Continue the conversation with Ben
This is still an evolving area of software engineering. If this article has prompted you to think differently about discovery, prototyping, story points, development budgets or how AI could change the economics of your next software project, get in touch with Ben Whorwood, Senior Architect at Flowmoco.
Ben would be interested to hear how other technology leaders are approaching the shift, compare perspectives, or talk through what AI-assisted prototyping could mean within your own enterprise context.
Because before asking how quickly AI can help you build something, there may be a more valuable question: how quickly can it help you discover whether you're building the right thing — while there's still enough budget left to act on what you learn?