Sit in on a requirements meeting sometime and watch for the moment it happens.
You ask the person who knows the process best, the one who has done the job for fifteen years, to walk you through how it actually works. They start strong.
Three steps in, they slow down: "Well, it depends." A few steps later: "Oh, except for the corporate accounts, we skip that part." And then: "I do not really think about it. I just do it."
That person is not being difficult. They are the single most valuable source of truth in the building, and they still cannot fully tell you what they know. Across the table, the team taking notes has never processed a claim, shipped a freight order, or closed a month-end in their lives.
The gap between those two sides is where most software quietly goes wrong. And we keep believing that gap is a tooling problem. It is not.
The comfortable lie about hard problems
The comfortable lie is that better tools will close that gap. Faster languages, better frameworks, and now AI that writes working code from a single sentence. The story goes that once building gets easy enough, the problem solves itself.
Yes, talking to computers has been getting easier for seventy years. We went from punch cards to assembly, from assembly to high-level languages, and now from languages to plain English. Talking to humans about what they actually need has not gotten easier at all.
If anything, it is getting harder to do well, because the faster we can build, the more tempting it is to skip the part where we figure out what to build.
Two different costs we keep confusing
Every technology project carries two costs, and we treat them as if they are one.
The first is the cost of translation: turning a clear intent into working software. Syntax, plumbing, and typing. This is the cost AI is driving toward zero, and that is genuinely good news.
The second is the cost of understanding: figuring out what the intent should even be. The real problem, the actual need, the thing the business expert cannot quite put into words. AI does almost nothing for this one.
Fred Brooks made this point decades ago, long before anyone typed a prompt. He argued that the hardest single part of building a software system is deciding precisely what to build. The code was never the hard part. Deciding what the code should do was, and it still is.
Why understanding stays stubbornly human
Three things make this cost so hard to pay, and all three are about people, not machines.
The people who own the problem carry it as tacit knowledge. They live the process, so they have stopped noticing it. Ask them to narrate it, and you get "well, it depends," because the exceptions live in their hands, not their words.
Requirements are discovered, not collected. People learn what they actually need by using something and reacting to it. There is a grand myth that if you write requirements down, people get what they want; in practice, they get what was written down, which is rarely the same thing.
The people building the solution rarely have the domain expertise to fill the gaps on their own. Someone has to bridge the business and technical sides, and that bridge is built on conversation, not documentation.
How to get good at the part that stays hard
You cannot automate your way out of this, but you can get much better at it. A few things that I have seen work.
Treat working software as a question, not an answer. Ship the smallest real slice you can and watch the reaction. The moment a stakeholder says, "that is exactly what I asked for, but now I see it is not what I need," is not a failure. That sentence is the most valuable thing you will hear all month, and you bought it cheap.
Replace "tell me the requirements" with "show me you doing it." Sit next to the person and watch the actual work, including the tabs they switch between and the exceptions they never mention. Tacit knowledge surfaces in action, almost never in an interview. We made a similar case for AI tools in why your AI works in the demo but dies in the workflow; the real work is never quite the documented work.
Make the conversation the unit of understanding, not the document. A written spec looks precise, which is exactly what makes it dangerous; it hides the gaps behind clean formatting. A good user story was always just a placeholder for a conversation, not a contract.
And make it safe to say "I do not know yet" and "that is wrong." If the business expert feels they must have every answer in the room, they will invent one, and you will dutifully build it.
Common traps
A few ways smart teams make this worse, especially now.
Mistaking "it runs" for "it is right." AI makes code run almost instantly, and that tells you nothing about whether it solves the problem. A precise, working answer to the wrong question is still wrong.
Treating the spec as the truth. A spec is a snapshot of one conversation on one day, and it started going out of date the moment the meeting ended.
Optimizing only for build speed. If understanding is your real bottleneck, building faster just gets you to the wrong place sooner, with more confidence and a bigger bill.
Outsourcing the thinking to the tool. The AI will cheerfully build whatever you describe, including a beautiful version of a thing nobody needed. The judgment about what to ask for is still yours, and it is the scarce skill most teams have not trained for.
Try this next week
Pick one feature on your backlog that everyone agrees they understand. Before anyone builds it, ask the person who owns the problem to perform the task in front of you and narrate it aloud. Write down every "it depends" and every "except when." Those exceptions are the actual requirements, and you will probably find that the thing everyone understood was understood three different ways.
Then ship the smallest slice that lets them react to something real. Treat the first "that is not quite it" as a win, because you just turned a vague assumption into a concrete requirement while it was still cheap to change.
If you want a structured way to build this discipline of problem discovery into how your teams work, it is a lot of what we do in our coaching engagements.
Where this is heading
Here is the part that keeps me up, in a good way. Business people talking directly to the computer and interacting with it is coming, and probably sooner than most of us expect. The translation layer between the business and technical sides is going to get very thin.
But that does not solve the problem of understanding. It relocates it. Even talking straight to the machine, a person still cannot articulate everything up front, still discovers what they need by using it, and still knows more than they can say. The computer becomes a faster sparring partner, which is genuinely good, but only for someone who can frame a problem and recognize when the answer is wrong.
So the scarce skill stops being coding, and it never really becomes prompting. It becomes knowing what you actually need and being able to say it. Communication does not get easier; it just changes who is on the other side of it. The people who can do that clearly, with a machine or with a room full of humans, are the ones who will still matter when the building is free.
So knowledge is still power, and we still have to find a way to "know". I am going to show my age, but I recall a famous cartoon I watched as a kid, saying:
"now you know, and knowing is half the battle." - G.I. Joe