The Art of Asking (AI)
For senior engineers, the most valuable thing an AI coding agent can do is read the system, not generate code. A guide to using Ask mode to understand complexity.
Loading content...
For senior engineers, the most valuable thing an AI coding agent can do is read the system, not generate code. A guide to using Ask mode to understand complexity.
Most of the value I get from AI coding agents comes from Ask mode, not code generation. I use it to map legacy code, catch spec drift, and pressure-test risky changes before I let the agent write a single line.
I keep seeing the same failure mode in code reviews. Good engineers merge weak implementations because "the agent gave us this and tests pass."
That is backwards. The smartest move is usually reading, not writing.
I spend most of my time in Ask mode. Read-only. No commits. No accidental "while I'm here" refactor.
At a certain level, your main value is not how many lines you changed. It is how many bad architectural calls you prevented.
Ask mode helps me do that faster than bouncing between grep results and symbol definitions for days. I have gone from "new repo confusion" to a usable mental model in one afternoon, still without touching Edit.
You get dropped into a legacy system that looks like three teams built it and none of them agreed on naming, ownership, or boundaries.
The old version of me traced execution paths by hand for two days.
Now I ask for intent and trace in one shot:
"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."
I get a working explanation tied to real code paths. It is not perfect documentation, but it beats a wiki page frozen in 2019.
I am mostly a frontend engineer. Backend behavior can still look like a black box when I hit a weird response.
Example. I see user_status: pending after payment clears. Instead of slacking someone and waiting, I ask:
"I'm seeing the
user_statusfield return 'pending' even after payment. Look at thePaymentControllerand theUserStateMachine. What conditions could cause this state mismatch?"
Now the ticket is specific. "The PaymentController returns 200 before awaiting UserStateMachine transition." I did not need to become a backend expert. I needed fifteen focused minutes.
Writing a design doc is easy. Keeping it honest is hard.
By the time you ship, the code and spec usually drift. That is where quiet bugs sit for months.
I paste a section of the design doc or ERD into Ask mode and ask for gaps:
"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?"
The useful output is simple. A concrete list of "spec says X, code does Y."
Before big changes, I red-team the plan in Ask mode.
I start with the exact change. I want to add a shipping_provider column to Orders.
Then I ask:
"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?"
Last month this surfaced a cron job that used SELECT * and mapped columns by index. That question took thirty seconds. The bug would have taken a weekend.
Everyone wants agents to do things. Fair.
But if I skip understanding, I am just shipping confident guesses faster. Ask mode is how I avoid that trap.