Ask the coding assistant what it needs before it codes
A coding assistant asked to implement a feature will often choose an approach before the product question is settled. Use it first to map unknowns, constraints and the cheapest useful test.
On this page 6 sections
- Ask for unknowns and assumptions before asking for implementation.
- Give the assistant a bounded context and a verifiable question.
- Treat generated code as evidence only after running the relevant check.
The fastest way to get code from an AI assistant is to ask it to build something. That is not always the fastest way to learn whether the thing should exist. A polished first draft can make an unsettled product decision feel settled because there is now something concrete to react to.
I get more value when the first request is not “implement this.” It is “tell me what you would need to know before implementing it.”
Separate the question from the solution#
A feature request usually bundles an outcome, a possible design and a set of hidden assumptions. For example: “Add a comparison view so a manager can spot unusual changes.” The outcome might be faster review. The proposed design is a comparison view. The assumptions may include that the manager has a stable baseline, can identify what counts as unusual, and has permission to see both records.
Ask the coding assistant to inspect the relevant code and return four things before it edits anything:
- The current behavior, with file and function references.
- The smallest product assumption that could make the proposed feature unnecessary or unsafe.
- Two implementation shapes and what each would require.
- A cheap test that would change the decision to build.
This does not make the assistant a product strategist. It gives the PM a structured way to use the tool’s code-reading ability without letting its first implementation become the default answer.
Bound the context, not just the prompt#
A long prompt can still produce a weak answer if the tool is pointed at an entire repository with no boundary. The model may spend its context on unrelated files, infer behavior from stale documentation, or edit a shared component when the task is local.
Name the files or folders it may inspect, the files it may change, and the paths it must not touch. If the relevant area is unknown, ask for a read-only map first. Then review the map and widen the boundary deliberately. The instruction “do not modify files” is more reliable than assuming an assistant will know that exploration should remain read-only.
A useful task brief fits in a small template:
| Field | Example |
|---|---|
| User outcome | A reviewer can find the changed field quickly |
| Known current behavior | The list shows only the latest value |
| Allowed context | The list page, its data adapter, and its tests |
| Forbidden changes | No API contract or shared navigation changes |
| Question to answer | Can a local view expose the old and new values? |
| Evidence required | Existing tests plus one focused regression test |
The examples are hypothetical. The point is to make the boundary observable: if the diff changes a forbidden area, it is easy to reject before debating code quality.
Ask for alternatives with costs#
When the assistant finds more than one plausible approach, ask it to compare them against the same constraints. “List alternatives” is too loose; it invites a list of implementation patterns with no decision relevance.
Ask for the smallest reversible option, the option that best preserves future flexibility, and the risk each introduces. For the comparison example, a temporary side-by-side view might answer the review question without changing the underlying record model. A persisted history feature could support more workflows but would introduce retention, access and migration decisions.
Do not ask for arbitrary scores unless the inputs mean something. A table with “what this makes easier,” “what it makes harder,” and “what we still need to learn” is often more useful than a synthetic ranking.
Make the prototype answer one question#
A prototype is valuable when its result can change a decision. Before letting the assistant build it, finish this sentence: “If the prototype shows , we will ; if it shows , we will .” If neither branch changes what the team does, the prototype is probably a demo rather than a test.
Keep the prototype narrow enough to inspect. A small script that compares two representative records may be more informative than a fully integrated screen. Use synthetic or approved sample data. If the task depends on real user information, do not paste it into a tool unless the data handling is explicitly permitted.
The assistant can produce the test harness, but the PM still chooses the input cases and the success condition. Ask it to explain which cases are missing and why. Then add the cases that represent a realistic failure: no baseline, a deleted field, a permission boundary, or conflicting values.
Treat the diff as a claim#
Generated code is a claim that a particular change solves the stated problem. Review the claim against the task, not against how plausible the code looks.
A compact review has four passes:
- Scope: Did it touch only allowed files?
- Behavior: Does the change match the user outcome rather than merely the requested UI?
- Evidence: Did the focused test run, and does it fail without the change?
- Risk: Does the change alter data access, persistence, or a shared contract?
If a test cannot run, the output is not verified. If a result depends on a manual judgment, record who made it and what they saw. “The assistant said the tests pass” is not a substitute for seeing the test result.
A better first prompt#
Try this before asking a coding assistant to implement a new product idea:
Read only the listed files and do not edit. Summarize the current behavior with code references. List the assumptions that must be true for this feature to help the user. Give two bounded implementation options, their risks, and one reversible test that could change whether we build it. Stop after the analysis.
After reviewing that output, decide whether the problem is understood. Then give the assistant a small implementation task with allowed files and a test condition. The tool may still write the code; it just no longer gets to decide what the code is evidence for.
Before the next AI-assisted build, write down the product question, the allowed context, and the result that would change your mind. If any of those is missing, ask for the map before the patch.