The Art of Asking (AI)
Why the most powerful feature of your AI coding agent isn't writing code: it's reading it. A guide for senior engineers on using 'Ask' mode to navigate complexity.
Loading content...
Why the most powerful feature of your AI coding agent isn't writing code: it's reading it. A guide for senior engineers on using 'Ask' mode to navigate complexity.
The highest-leverage way to use an AI coding agent is often in "Ask" mode rather than having it write code. By using the AI to rapidly explore legacy systems, audit documentation drift, and red-team your architectural plans, you build the required mental model to make critical engineering decisions in a fraction of the time.
There is a misconception that to get value out of an AI coding agent, you have to let it write code.
I see this in code reviews constantly. Engineers (smart ones) will accept a slightly suboptimal implementation because "that's what the agent outputted." They treat the AI as a junior contractor: you give it a task, it gives you a PR, and you merge it.
But if you look at how the most effective Staff and Principal engineers are using these tools, you'll notice a different pattern. They aren't just using the AI to write; they are using it to read.
They are leveraging "Ask" mode.
At a certain level of seniority, your primary value isn't the number of lines you modify; it's the number of poor architectural decisions you prevent.
An AI agent running in "Ask" mode (read-only) is the ultimate force multiplier for this. It allows you to build a mental model of a system 10x faster than traditional grepping and clicking through definitions. You can gain the context needed to make a high-leverage decision without ever touching the Edit button.
Here is how to use it effectively.
We have all been there: you get dropped into a massive legacy codebase (or even a messy corner of a modern one) that looks like it was written by three different teams who hated each other.
Traditionally, you would spend days manually tracing execution paths.
With an agent, you can perform instant archeology. Instead of searching for string literals, you can query intent:
"Explain how the
BatchPrunerclass interacts with theRetentionPolicy. Specifically, does it soft-delete records immediately, or does it wait for a separate cron job. Please trace the execution flow starting from therun()method."
The agent acts as a dynamic documentation generator. It reads the code (the ultimate source of truth) and synthesizes a narrative for you. It turns "exploring a new codebase" from a week-long slog into an afternoon reading session.
One of the most powerful uses of Ask mode is helping specialists cross the stack boundary.
If you are a frontend engineer, the backend can often feel like a black box. You see an API response, but you don't know why data is formatted that way.
Instead of pinging a backend engineer and waiting 4 hours for a reply, you can point your agent at the backend repository and ask:
"I'm seeing the
user_statusfield return 'pending' even after payment. Look at thePaymentControllerand theUserStateMachine. What conditions could cause this state mismatch?"
Suddenly, you aren't just filing a ticket saying "API broken." You are filing a ticket saying, "The PaymentController doesn't await the UserStateMachine transition before returning code 200."
You have bridged the gap without needing to be an expert in the other side of the stack.
Drafting a Design Doc or an Entity Relationship Diagram (ERD) is easy. Keeping it up to date is impossible.
By the time a feature ships, the implementation has almost certainly drifted from the spec. This "drift" is where bugs hide.
Ask mode is an incredible tool for auditing this drift. I often paste a section of a Design Doc or an ERD into the chat and ask:
"Here is our intended design for the Notification System. Look at the current implementation in
services/notifications. Where does the code diverge from this design? Are there any edge cases handled in code that aren't in this spec?"
It acts as a relentless auditor, highlighting the difference between what you thought you built and what is actually running in production.
Before I write a single line of code for a complex feature, I use the agent to red-team my plan.
I will describe my proposed approach: I plan to add a new column to the Orders table to track shipping provider.
Then I ask the agent to find the risks:
"I want to add a
shipping_providercolumn toOrders. Scan all references to theOrderstable in the codebase. Which raw SQL queries, reporting jobs, or legacy services might break if I change the schema here?"
It might find a hardcoded SQL report in a forgotten cron job that SELECT * and maps by index, which your change would have silently broken. Finding that risk cost you 30 seconds of asking; finding it in production would have cost you a weekend.
The "Agent" part of AI Agent implies action. We want it to do things. But sometimes, the most agentic thing you can do is stop, look, and ask.
By separating the "understanding" phase from the "coding" phase, you ensure that when you finally do switch to generic code generation, you are steering it with the confidence of someone who truly understands the system.
Stop trying to get it to write your code. Start asking it to teach you your system.