Asking well · for software engineers
Asking well in software engineering
A request like "fix this function" leaves the model to guess what is broken, what correct behavior looks like, and what it may change. It will often rewrite more than it should. It may also fix a problem you do not have.
Asking well means stating what a careful reviewer would want to know before touching the code. What is the expected behavior? What is the observed behavior? Which files and interfaces must stay unchanged? How will you know the change is correct?
Where it comes up
A bug fix from a failing report
A user reports that dates near midnight show the wrong day. A strong request gives the input, the expected output, the actual output, and the time zone. It also asks for a diagnosis before any code change.
A narrow refactor
You want to extract a validation block into its own function. The request names the function, says the public signature must not change, and asks the model to leave unrelated formatting alone.
Edge cases for a parser
Before writing tests for a CSV import, ask for a list of input cases the parser could mishandle. Ask for the list first and the tests second, so you can choose which cases matter.
What it looks like at each band
E1 · Foundational
Gets working code for small, familiar tasks with short requests. Requests usually name the task but leave out the constraints and the expected behavior. When the output is wrong, edits the code by hand rather than improving the request.
E2 · Proficient
States the goal, the inputs and outputs, the language version, and what must not change. Asks for an explanation of the change along with the code. When a first answer misses, adds the missing facts to the request instead of retrying the same words.
E3 · Distinguished
Splits larger work into steps: diagnose, propose options, then implement the chosen one. Asks the model to state its assumptions and to flag anything it could not determine from the code given. Uses the model to question a design before building it.
E4 · Exceptional
Writes request patterns the team reuses for recurring work, such as reviews, migrations, and test generation. Knows which jobs need one precise request and which need a short exchange. Other engineers improve their results by copying how this person asks.
Common mistakes
Asking for "clean" or "better" code
These words give the model nothing to act on. Name the property you want instead, such as fewer database calls, no shared mutable state, or a function under a set length.
No definition of done
Without a test, an expected output, or an acceptance check, the model decides when it is finished. State how you will judge the result before you ask.
Asking for code before a diagnosis
A fix requested before the cause is known often treats a symptom. Ask the model to explain what it thinks is wrong and why, then decide whether to proceed.
A worked example
An API endpoint that lists orders has become slow for customers with many orders.
This endpoint is slow. Make it faster.
The model does not know the data size, the database, the query, or what "slow" means. It may add caching that serves stale data or rewrite the handler in a way that changes the response shape.
This handler lists a customer’s orders. For customers with about 5,000 orders it takes several seconds. Here is the handler, the ORM query it runs, and the table schema with its indexes. First, explain the likely cause and how I could confirm it. Do not change the response format or add caching. If an index or a query change would help, show the migration and the new query separately.
The request gives the scale, the code, the schema, and two firm limits. It asks for a diagnosis and a way to confirm it before any change, which keeps the engineer in control of the decision.
The full study guide for this skill, for every role, is Asking well. The other five skills for software engineers are on the AI skills for software engineers page. A one-page summary is in the AI prompt checklist.
See where you stand
The free check grades asking well and the other five skills in about fifteen minutes. Nobody sees the grade but you.
Then build the skills and prove it. The three steps for software engineers list the courses and templates that fit the work.