An update goes out to leadership. A small in-house team, working with AI tools, has just delivered in days what earlier efforts couldn’t finish in months.
Everyone reads that as a story about AI. It isn’t—or at least, it isn’t only.
The months of requirements work that already existed are what made those days possible, and that part rarely makes the slide.
I want to be careful here, because I’m not writing this to argue that AI didn’t help. It did. I use these tools everywhere I’m allowed to, and I advocate for using them more.
The problem isn’t the tool. It’s the story we tell about the tool.
The setup
There was a project that had been in flight for a while and had changed hands more than once. Previous attempts hadn’t landed it, for a mix of reasons that are rarely entirely one party’s fault.
Eventually, someone said: bring it in-house, use AI, and keep the team small.
It worked—and fast.
I’ve been on both sides of this: delivering as part of a small, fast-moving team and watching one work from close by. The pattern is remarkably consistent.
The update to stakeholders was that the team had accomplished in days what previous efforts had been unable to finish in months.
Even if we accept the accomplishment exactly as described, the update still leaves out the work that made it possible.
What the update didn’t say
Before that team ever opened an AI tool, there were months of requirements work sitting behind them.
Business analysts and subject-matter experts had spent time working out what the solution actually needed to do. Architects had produced diagrams and data flows. Technical teams had documented how existing systems behaved. Vendors had surfaced constraints nobody knew about at the beginning. Stakeholders had reacted to earlier versions and clarified what they did—and did not—want.
Even the unsuccessful attempts created knowledge.
All of that became context. It became the raw material the new team and its AI tools could work from.
- Business SMEswhat the work actually involves
- Business analyststurning that into stated requirements
- Architectsdiagrams, data flows, target state
- Technical teamshow the existing systems really behave
- Vendorsconstraints nobody knew at the start
Requirements, diagrams, data flows and documented system behavior — the raw material fed into the tools.
AI-assisted build
the part that made the update.
Strip that away and hand the same team the same tools on day one, and they do not move in days. They move at the speed of figuring out what to build—which is the speed everyone was already moving at.
The AI didn’t compress a year of work into a week. It compressed the last stretch, because someone else had already done the first.
That is still valuable. Compressing the final stretch can save enormous amounts of time and money. It can turn an idea that has been stalled for months into something people can finally see, test, and use.
But it is not the same as eliminating everything that came before it.
Why the omission matters
The obvious reason is fairness.
People did months of difficult work and then watched the credit land somewhere else. Their work may not have resulted in the final product, but it helped create the understanding that made the final product possible.
That is a real cost, and it is the one most people notice.
But there is a more expensive one.
When leadership hears, “AI did in days what took months,” the reasonable inference is that the months were waste. The discovery was unnecessary. The earlier teams were inefficient. AI has now solved the slow part, so the next project should be able to skip ahead.
Then the next project does skip ahead. It starts with the tooling instead of the understanding. The organization puts together a small team, gives it access to AI, and expects the same result.
The team produces something quickly, confidently, and wrong—because nobody did the work of deciding what right meant.
Then the conclusion becomes, “AI didn’t work for us.”
The tool takes the blame for a missing input.
That is how an incomplete success story turns into a failed project two quarters later.
Requirements are not just documents
It is easy to talk about requirements as though they are simply a list of instructions waiting for someone to write them down.
They aren’t.
Requirements work means discovering what people forgot to mention. It means surfacing assumptions that have become so familiar nobody thinks to explain them. It means identifying when two stakeholders expect different outcomes from the same process.
It also means forcing decisions.
What happens when the business wants speed, compliance wants another control, and operations says that control will make the process unusable? Which system owns a particular piece of data? What does “real time” actually mean? What is required for the first release, and what can wait? What does “done” mean?
Those questions are not answered by better transcription.
I keep hearing about teams using AI interviewers to gather requirements, and I genuinely like the idea. It is a good use of the technology, and it can scale an activity that has always been a bottleneck.
But notice what it confirms.
Even the AI-native version of requirements gathering is still asking people what they know.
The bottleneck was never the transcription. It was the knowing.
AI can accelerate that work. It cannot make an organization agree with itself.
AI needs someone to tell it the truth
AI tools are extraordinary at working with the context you give them. They are also completely indifferent to whether that context is correct.
Feed an AI a confident misunderstanding of the business and it can give you a fast, well-structured, thoroughly wrong implementation.
Picture how that happens.
One category of customer gets billed on a different cycle. Everyone in the department has known this for a decade, so nobody thinks to write it down. It never comes up in the requirements sessions. The tool doesn’t ask about it because it has no way of knowing there is something to ask.
What comes back is clean, well-organized, and quietly wrong for a portion of the customer base.
Nobody catches it during review because the code does exactly what the documented requirements said.
You find out from the customers.
That gap was always there. What has changed is how fast we can build on top of it before anyone notices.
AI may even make the problem harder to spot. A rough or incomplete solution invites scrutiny. A polished solution creates confidence. When the screens look finished, the workflows run smoothly, and the documentation reads well, people naturally assume the underlying understanding must be equally complete.
It may not be.
Accurate information going in is not a preliminary step we get to automate away. It is the part that determines whether any of the speed is worth having.
What I’d ask
Two things, and neither is complicated.
When you give the update, tell the whole story.
“We delivered this in days, building on the requirements and discovery work completed over the previous months.”
It costs one clause.
It is more accurate. It recognizes the people who created the foundation. It also prevents leadership from drawing a conclusion that could cost the organization on the next project.
Giving credit to the earlier work does not diminish the accomplishment of the team that delivered. If anything, it makes the accomplishment more useful because it explains the conditions that made it possible.
When you hear the update, ask what the result was built on.
Not to challenge the team or minimize what it accomplished, but to understand whether the result is repeatable.
How much discovery had already occurred? What requirements already existed? Were there earlier designs, prototypes, or failed attempts? Was the problem already well understood? Which parts did AI actually accelerate?
A team moving quickly on a well-understood problem tells you something important about AI-assisted delivery.
It does not tell you how quickly that same team can solve a poorly understood problem from scratch.
Those are different capabilities, and leadership needs to know which one it is seeing.
None of this is an argument for slowing down.
Use the tools. Push for more access to them. Use AI to interview stakeholders, organize requirements, identify contradictions, generate prototypes, write code, create tests, and accelerate delivery. I do.
But speed does not eliminate the need to understand the destination. It only allows us to travel much faster once we think we know where we are going.
Just don’t confuse the sprint at the end with the distance actually covered—and don’t dismiss the people who covered it.
Somebody still has to think hard about the problem.