Before I ask AI to change a feature, I want to write down what must keep working. Otherwise I can judge the answer by how neat it looks and miss what it changed around the edges.
A few plain sentences give me something to check.
Describe the behavior I need
For a hypothetical profile-editing form, I could write:
- Existing information stays unless the person changes it.
- A rejected submission explains what needs attention.
- Success means the save completed.
- Reloading shows the saved result.
- Editing one profile cannot change another person's profile.
These are expectations for the example, not a claim that I have tested a particular product. They tell me what evidence I would need before accepting the change.
Keep the request small enough to review
If I ask for a form improvement and receive unrelated changes to navigation, authentication and project structure, I have a much larger review.
I ask for the assumptions and affected files to be explained. Then I inspect them. An assistant's explanation can guide me to the relevant code; it does not prove the behavior is correct.
If a library or service is involved, I check its official documentation for the version in use.
Try the important paths
Using test data, I try a normal save, invalid input, a cancelled edit and a failed request where the test environment allows it. I reload after saving and check an adjacent field.
For private data, I check the authorization boundary with another test account. The right screen appearing is not enough if the underlying request can reach the wrong record.
The checks should fit the change. A few examples do not cover every security or reliability question.
Record what I know
I finish with what I verified and what remains uncertain. If I cannot explain an important part, I investigate before relying on it.
Writing the expectations first helps me review the solution against the product's needs. I want reasons to accept the code beyond “it looks like the feature is there.”