AI-assisted coding becomes harder to review when one sentence mixes several targets, exceptions, and intended behaviors. In my solo iOS work, I find that separating those pieces makes the conversation easier to correct.
This is a practical workflow from my experience, not a benchmark showing that clause count determines accuracy. The example below is a hypothetical profile editor, not a claim about a production defect.
Start with a request that is hard to verify
Fix the name field and the Save button so empty names are rejected and errors are red, but keep the normal flow and show a confirmation when it works.
What exactly should turn red? Does “empty” include whitespace? Does a failed save still show confirmation? A reviewer must supply missing decisions before even checking the code.
Five changes to the instruction
1. Number the requirements
Give every independently checkable behavior its own item. This provides a stable reference for implementation and review: “R3 is missing” is more useful than “the form still feels wrong.”
2. Put short clarifications in parentheses
Write “Save button (the checkmark in the top-right corner)” instead of leaving the target implicit. Keep parentheses short. A separate condition deserves a separate requirement.
3. State the goal and your current understanding
Goal: prevent accidentally saving a blank display name.
Current understanding: the form allows an empty value. Ask the coding assistant to verify that assumption against the actual implementation before editing. Do not present an untested guess as a confirmed bug.
4. Restate current and intended behavior on every revision
For the feature being changed, say what it does now and what it should do afterward. Include behavior that must be preserved. This is especially useful after several revisions, when an earlier message may describe an older implementation.
5. Separate combined requests without losing logical conditions
“A and B” can hide two separate changes or a shared condition. Write one rule per target when scope is ambiguous. However, preserve genuine conjunctions: “signed in AND has edit permission” requires both predicates. Splitting the prose must not change that logic.
A reviewable replacement prompt
Target: profile editor, display-name validation and Save action.
Goal: prevent blank display names from being persisted.
Current behavior (my understanding; verify first):
An empty name can be submitted.
Required behavior:
R1. Treat a name as blank if trimming whitespace and newlines
produces an empty string.
R2. For a blank name, show “Enter a name” below the field.
R3. For a blank name, do not call the persistence operation.
R4. Render the validation message in red (the message itself).
R5. For a valid name, preserve the existing persistence behavior.
R6. Show a success confirmation only after persistence succeeds.
R7. Preserve the existing handling of persistence failures.
Before editing:
Check the implementation and identify any incorrect assumption
or conflict in these requirements.
After editing:
Report the change and verification result for each R-number.
Mark unverified items explicitly.
The prompt is longer, but the conditions are easier to locate. It also avoids accidentally requesting a red button when only the message should be red.
Turn the requirements into checks
| Input or event | Expected observation | Requirements |
|---|---|---|
| Empty string | Validation message; no persistence call | R1–R4 |
| Spaces and a newline | Same as empty input | R1–R4 |
| Valid name, save succeeds | Existing save behavior; confirmation after success | R5–R6 |
| Valid name, save fails | Existing failure handling; no success confirmation | R6–R7 |
These are suggested checks for the example, not tests I ran against an app in this article. In a real change, verify both the visible UI and the side effect: a warning alone does not prove that persistence was skipped.
Keep the next revision equally explicit
If R2 needs different wording, restate its current message and replacement message. If the save flow has changed since the previous prompt, update that baseline. Requirement numbers help only if their meaning stays current.
My next step is to review AI-assisted changes item by item as implemented, incorrect, or unverified. That makes the result easier to inspect and gives the next prompt a concrete starting point.
Disclosure: I am an independent developer of Wacha, an iOS party-game collection. This post was drafted and organized with AI assistance from my development experiences and notes.
Top comments (0)