Ask Questions, Not Queries
Most engineers talk to AI the way they talk to a search box, and lose answers they could be getting today. Six question patterns worth copying, and how to tell a good answer from a fluent one.
Most engineers talk to AI about their codebase the way they talk to a search box. They have been trained to, by twenty years of tools that only accepted queries. The habit costs them answers they could be getting today, from the assistant they already pay for.
This is a practical guide to asking better. No new tooling required — just a different shape of question, and a way to tell when the answer is worth trusting.
The two shapes
A query describes where to look. A question describes what you want to know.
Query: grep -r "subscription" --include=*.ts Question: What happens to a customer's access when their subscription is paused?
The query is precise about the search and silent about the goal. You get results; you do the reasoning. That was a fair trade when the tool could only match text — you were the reasoning engine and it was the index.
A model is not an index. Give it a query and you have hired a reasoning engine to do lookup work, then done the reasoning yourself anyway. Give it a question and it can at least attempt the part you actually wanted.
The catch is that most people phrase questions as queries out of habit, and then conclude the model is bad at their codebase.
Six patterns worth copying
These work across assistants. Adapt the nouns.
1. The consequence question.
"If we change X, what does a customer experience differently?"
Not "what calls X". The word customer forces the answer up out of the call graph into the product, which is the altitude you were asking at anyway.
2. The failure-path question.
"How can a customer end up in state Y? List every path you can find."
Instead of describing the bug and asking for a fix, ask for the ways the outcome is reachable. You get a set to check rather than one guess to argue with, and the set is auditable.
3. The intent question.
"Why does this behave this way? Is it deliberate or incidental?"
The most valuable thing a codebase knows and never says. Even a partial answer — "there is a guard here that suggests it was deliberate, added alongside the refund handling" — reframes a change from fix to decision.
4. The pre-flight question.
"Before I change this, what should I know?"
Deliberately open. It surfaces things a targeted question would have excluded by construction, which is where surprises hide.
5. The onboarding question.
"Explain this to someone who has never seen this codebase but knows the domain."
Forces product vocabulary over implementation vocabulary. Also a good detector: if the answer is still a tour of files, the assistant does not actually have the product, only the text.
6. The verification question.
"What should I test to be confident this change is safe?"
Turns an answer into a checklist. Also the fastest way to find out whether the assistant understood the change — a bad test plan is a very legible failure.
The rules that make them work
Use your product's nouns, not your codebase's. Customer, plan, refund, invitation, invoice. If your question contains a class name, you have started translating and given away the part you wanted done for you.
Ask for the shape of the answer. "List every path", "give me a test plan", "name what changes for the user". Unstructured questions get essays; structured questions get things you can act on.
Ask for evidence in the same breath. "…and cite the file and line for each claim." Costs you eight words and changes what you receive, because a claim with a citation can be checked in seconds and a claim without one has to be re-derived.
Ask follow-ups. The first answer is a draft. "You mentioned the renewal path — what else touches it?" is where the real content usually appears.
Don't say the answer in the question. "Is it true that pausing breaks renewal?" invites agreement. "What happens to renewal when a subscription is paused?" invites work.
How to tell a good answer from a fluent one
Fluency is free now. These four checks are not.
Is it about the product or about the files? "This touches billing/renew.ts and three others" is a file summary. "A paused subscription still passes the renewal check, so an invoice is generated" is an answer. The second can be wrong, which is what makes it useful.
Can you follow it back? Every claim should name where it came from. Open one at random and check it. If two out of three citations do not say what the answer claimed, you have learned something important about the whole session.
Does it admit an edge? "I could not determine whether the webhook fires on this transition" is a better answer than confident silence on the same point. Systems that never express uncertainty are not more certain; they are just not tracking it.
Does it survive a rephrase? Ask the same thing differently, twenty minutes later. If the answer changes materially, it was reconstructed rather than known, and you should treat both versions as hypotheses.
Fifteen minutes that will tell you where you stand
Take one change your team is actually considering. Ask your current assistant:
- What would this change affect that a person would notice?
- What already depends on the part I am changing?
- What should I verify before shipping it?
- Cite the file and line for each claim.
Then open three citations. Count how many say what the answer claimed.
Whatever that number is, it is your real starting point — not the demo you saw, not the benchmark on the vendor's page. And if it is low, you have not wasted the time: you now know which of your questions the tool can carry and which ones still need a person, which is worth more than another month of assuming.
Put a number on your own workflow
Bring us the recurring workflow where AI still needs expensive people to supervise, review and correct. We baseline what it costs and put the target in writing before we build. Or connect a repository and see it on your own code first — 1,000 credits free, no card.
Build My Business Case → Start free →Frequently asked questions
How should I phrase questions to AI about my codebase?
In the product's vocabulary rather than the codebase's. "What happens to a customer's access when a subscription is paused" gets a usable answer; "grep for subscription" gets results you then have to reason over yourself. If your question contains a class name, you have already started doing the translation you wanted the assistant to do.
How do I know whether an AI answer about my code is trustworthy?
Four checks. Is it about the product or just a summary of files? Does every claim cite a source you can open? Does it admit anything it could not determine? And does it survive being asked again, differently, later? An answer that changes materially on a rephrase was reconstructed, not known.
What is the single most useful thing to add to a prompt about code?
"Cite the file and line for each claim." It costs eight words and changes what you get back, because a claim with a citation can be verified in seconds while a claim without one has to be re-derived from scratch — which is the work you were trying to avoid.
Why does my AI assistant answer general programming questions better than questions about my own code?
General knowledge is in the model's weights and available directly. Knowledge of your product is not — it has to be reconstructed on each request from whatever fragments were retrieved, and reconstruction reliably loses behaviour that spans multiple files. That is most of what people actually ask about.
Related articles
Why AI Gets Your Own Codebase Wrong
Your assistant is excellent at code it has never seen and unreliable about code you wrote yourself. The cause is structural: the distance between the way you asked and the form the tool can compute over.
The Comprehension Economy
Developers spend 58% to 70% of their time understanding code, not writing it. The industry spent three years optimising the smaller half — and increased the load on the constraint.
How to Benchmark AI Coding Tools on Your Own Repository
A practical protocol for testing AI code tools yourself: designing the question set, holding the model constant, blind scoring, and the four things worth measuring.