I've asked AI coding tools to add small features to things I was building.
The request made perfect sense to me. It was only a few sentences, but I knew how the feature should work, where it fitted and what shouldn't change.
The AI didn't know any of that.
It built what I asked for, filled in the missing parts and gave me something that looked finished. Only when I tried to use it did I realise how much of the request had never left my head.
The code worked.
It just wasn't what I meant.
AI can move so quickly that an unclear idea becomes working software before you notice the idea was unclear.
AI can't see what you meant
A request can feel clear because you already know the story behind it.
You know who complained about the current system, which awkward case matters and why the obvious solution won't work. None of that needs explaining when you're talking to yourself.
AI only has what you give it.
If something is missing, it has to make a choice. It will use a common pattern, follow the code it can see and pick an answer that seems reasonable.
Often the answer is reasonable. It's just reasonable for a problem that may not be yours.
A human engineer is more likely to stop and ask a question. They may have seen the same feature fail before, know something about the customer or wonder whether the work needs doing at all.
AI can ask those questions too, but it is also very willing to carry on without them.
The danger isn't that it always makes bad choices. It's that it can make sensible choices without telling you which parts of the problem it had to invent.
Working code feels like progress
Once code exists, the conversation changes.
People stop asking what should be built and start talking about how to improve what's already there. The button should move. The page needs another field. The loading state could be better.
Those may all be useful changes, but they assume the first version is heading in the right direction.
Before these tools, a feature might take long enough that somebody would question it before much had been built. The delay was frustrating, but it created time for the gaps to appear.
Now a vague request can become a polished starting point in an afternoon. Something that began as a quick experiment quietly becomes part of the product.
The code may have been cheap to write, but it still takes time to understand, test, maintain and remove.
Fast wrong work is still wrong.
There is simply more of it by the time you notice.
A clear problem leaves room for answers
The answer isn't to describe every button, table and line of code before AI can begin.
That can be just as limiting. If you describe the whole solution, AI has no room to find a better one.
The important part is being clear about the problem.
"Build a customer dashboard" says what kind of thing you expect, but almost nothing about why it should exist.
"Support needs to see a customer's recent failed payments while speaking to them" is more useful. Add that it must be read-only, use the current permissions and help support find an answer within a minute, and the work has a clear shape.
It doesn't say where every field belongs. It says who needs help, what they are trying to do and which boundaries matter. AI can still suggest the design and work out how to build it.
A clear request doesn't have to be long. It needs to explain the reason for the work, the result you want and anything important that must not change.
That gives AI enough direction without pretending you already know every answer.
Ask for questions before code
The easiest way to find the gaps is to ask AI to look for them.
Before asking it to build, ask it to explain the request back to you. Ask what it is assuming, what could be understood in two different ways and what it would want to know before starting.
This can be slightly humbling.
A sentence that seemed obvious can produce a page of perfectly fair questions. Better to see them now than after the feature has been built.
Answer the questions that could change the direction. Decide which ones can wait.
Then ask for the smallest useful part and check whether it behaves the way you expected. If it doesn't, you have a small misunderstanding to fix rather than a complete system to unpick.
AI can challenge the request, find the missing context and show you where your own thinking is vague. That work is less impressive than watching it produce an entire feature, but it is often more valuable.
We've spent years treating the building as the expensive part of software.
AI is changing that.
It can build an answer remarkably quickly. The difficult part is making sure it is answering the right question.
AI doesn't make ambiguity disappear.
It makes ambiguity expensive by letting us build before we've decided what we're building.
