The art of asking in the age of AI

Three years ago, when I started building seriously with these models, the failure mode was obvious. They invented APIs that did not exist. They cited libraries nobody had written. You spent half your time fact-checking a confident liar.

That problem has quietly shrunk. Agentic reasoning models re-read the file, run the test, catch themselves mid-sentence. Real progress, and it happened faster than most of us expected.

The problem that replaced it is harder, because it does not live in the model. It lives in the person typing.

Everyone learned to prompt. Almost nobody learned to think.

There is a lot of advice out there about asking the model for clarification. Useful, but small. That is not what I am talking about.

Asking the right question is now the primary way you see the frontier. It is the interface. Not the IDE, not the agent harness — the question.

And a question carries more than information. It carries a frame.

Come to a model with "this codebase is a mess, just patch it somehow" and you will get something back that inherits that posture. Not on the first reply. But three turns down, the output has absorbed it — timid code, defensive workarounds, a solution shaped exactly like the low expectation you handed it. You will get, somewhere down the line, the negative impact your framing carried.

Reverse the frame and the same mechanism runs the other way. Ask as though a clean answer exists. Describe what good looks like. You are far more likely to land there.

None of this is mystical. The model is continuing the trajectory you opened. Your first paragraph picks which distribution it samples from. That is a real lever, and most people pull it without knowing it exists.

Every word is a branch

Think of the conversation as a decision tree. Every question you ask picks a branch, and every branch you take closes off the ones beside it.

The unnerving part is how small the branching factor can be. A single keyword changes everything downstream:

• "Fix this" → you get a patch. Narrow, local, at the site of the symptom.
• "Why is this failing?" → you get an investigation, and often a different culprit than the one you pointed at.
• "Refactor this" → you get new structure, whether or not the structure was the problem.
• "Is this the right design?" → you get pushback, sometimes on the premise of your own question.

Same file. Same bug. Four different afternoons.

Say "quick" and you have quietly authorized a shortcut. Say "temporary" and you will get code that is, in every sense, temporary. Say "handle the edge cases" without naming them and you will get someone else's idea of which edges matter. Name three, and you get those three — and the fourth one, the one that actually bites you in production, goes unwritten because you never mentioned it.

None of these words feel like decisions when you type them. They feel like phrasing. But you are not phrasing, you are choosing a branch, and ten turns later you are somewhere far from where the neighbouring branch would have put you. By then the cost of walking back is real — code exists, tests exist, the shape has set.

Which is why the expensive thinking belongs at the top of the tree, not the bottom. Thirty seconds spent on what am I actually asking routinely saves an hour of steering a conversation that started three degrees off course. Three degrees compounds.

But tone is the shallow version

I want to be careful, because "be positive with the model" is a trivial reading and it will not get you a product.

The real variable is steering, and steering is a property of the person, not the prompt. Two things make it work:

Clarity of thought. You have to hold the architecture in your own head. What are the boundaries. What owns what. Where does state live. What breaks at ten times the load. If you do not know, the model will fill the gap with something plausible, and plausible is the dangerous kind of wrong — you will not notice for two weeks, by which point it is load-bearing.

Perseverance. The first output is almost never the one you ship. Neither is the second. The people getting real leverage out of these tools are the ones willing to say "closer, but the retry logic belongs in the client, not here" for the fifteenth time without losing interest. The conversation is the work. Impatience is now the expensive failure mode — more expensive than a skill gap.

Where the models still need a human

Here is what I run into constantly, and it happens with the best models available. Fable, Opus, all of them.

They write redundant code.

At small scale you never see it. One file, one feature, fine. At product scale — a service layer, a worker, a UI that all need the same validation rule — you start finding the same function reimplemented four times under four slightly different names. A helper that already existed, rewritten from scratch because nothing prompted the model to go look for it.

As a senior engineer, you stare at that and think: this is a dumb mistake. It is a dumb mistake. It is also entirely predictable. The model is reasoning from what is in its context window. You are reasoning from what is in your head — the whole system, the thing you designed, the specific reason those two modules must never both own that logic.

That gap does not close with a bigger model. It closes when you notice and say: we already have this. Use what is there. Do not write another one.

I have said that sentence hundreds of times across free products and open source ones. I expect to keep saying it for a while.

"Everything is a form of art"

My dad used to say something I have never been able to shake:

It's an art. Everything you do, everything you say, everything you talk is an art, is a form of art.

As a child I was fascinated by that line. I would take a plain fact and turn it over, trying to work out what it actually meant for me and my life. Decades later I think he was simply right.

Because what I have been describing — the framing, the steering, the patience — is not a technique. It is taste.

There is a beauty in a thought process, and you can develop a taste for it the same way you develop a taste for food, or music, or a well-cut piece of code. You learn to feel when a design is clean before you can fully justify why. You learn to wince at a duplicated helper the way you wince at a sour note. That wince is not documented anywhere. It is not in the model's weights. It is the thing you spent twenty years earning.

And it is exactly what the model needs from you. It can produce ten plausible architectures in a minute. Choosing the one that is right — not merely correct, but right for this system, this team, this next year — is an act of taste. So is knowing when to stop. So is knowing which of your own questions is worth asking.

Everything you say to the model is a form of art too. It is worth doing it well.

Creativity, and the curiosity that feeds it

If I had to name one tool that matters most — for an AI developer, for anyone — it is creativity. Not as decoration. As the actual instrument.

Everything above depends on it. The decision tree only helps you if you can imagine branches that are not obvious. Steering only works if you have somewhere original to steer toward. Taste tells you which of ten options is right; creativity is what put an eleventh on the table, the one the model would never have proposed because nobody has written it down yet.

And creativity does not run on its own. It runs on curiosity — the reflex to pull the thread, to ask what happens if, to open the thing up and look inside when nothing was forcing you to. Curiosity is what generates candidate questions. Creativity is what turns them into something worth building.

Curiosity alone makes you well-read. Creativity alone burns out fast, with nothing new coming in. Put them together and you get something genuinely rare: a person who keeps finding new questions and keeps making new things out of the answers. Pair that person with a frontier model and the leverage is absurd. That is the superpower — not the model, the pairing.

The models are extraordinary at answering. They are not the ones deciding what is worth asking about. That part is still ours, and I do not think we should be in a hurry to hand it over.

The bottleneck moved

The scarce skill is no longer typing speed, or holding a framework's API in memory. The model has that, cheaply, forever.

What it does not have is your intent. It cannot infer the shape of the system you are trying to build unless you can describe it — precisely, patiently, and more than once. The bottleneck moved from can you write it to do you know what you want, clearly enough to say out loud.

Most people cannot. That is the whole game now.

So ask better questions. Not politer ones. Not longer ones. Clearer ones. Come in holding the architecture. Steer with intent. Push back on redundancy. Stay in the conversation past the first plausible answer.

The frontier model is extraordinary. It is still a mirror. What you get out of it is mostly a measure of how clearly you were thinking when you asked.

Which brings me back to my dad. It is an art — the asking, the steering, the knowing when to stop. It always was.