What you will learn
- A focused request makes a change easier to review.
- Running the program matters more than code that merely looks correct.
- Check suggested libraries and APIs against their documentation.
1. Describe current and expected behavior
Before asking for a change, explain which input or action triggers the problem and what should happen instead. Include relevant error text and enough context to reproduce it. Remove connection details, keys and private content from the example.
Choose a small task, such as fixing form validation or explaining a function’s execution path. Asking for an interface rewrite, architectural changes and a new feature at once makes it harder to identify the cause of a failure and assess the result.
2. Set the scope and explain the project
Identify relevant files, the language and the tools already in use. State which areas must remain unchanged. Ask the assistant to explain the path it will inspect and what information is missing before it starts editing.
Do not accept a new package or API suggestion without checking it. Find its name and version in official documentation and confirm compatibility with your runtime. A generated example that looks simple is not sufficient reason to add another dependency.
Problem: [incorrect behavior and reproduction steps] Expected behavior: [a result we can check] Project and constraints: [language, tools and permitted files] Inspect the relevant path and state your assumptions first. Propose the smallest coherent change. Keep unrelated architecture, dependencies and files unchanged. Explain what changed and how we can verify it.
3. Review the diff
Read the changes and ask what each one affects. Has an earlier condition been removed? Does the error path still give a useful message? Could generated code expose information in output or logs that should stay private?
If you do not understand a part, ask for an explanation of that specific code. The explanation should match the implementation. Compare it with actual execution and documentation rather than treating the assistant’s description as proof of correctness.
4. Exercise normal and edge cases
Test more than one successful input. Try empty and invalid form values, an empty list and a failed request where relevant. Existing project tools such as TypeScript and linting are useful checks, but they do not replace exercising the behavior in a browser or appropriate runtime.
A test should measure the expected outcome. A test that merely repeats the implementation’s steps may pass with the same mistaken assumption. Write down an example input and the correct output independently of the proposed change.
5. Keep the result explainable and reversible
Record small, focused changes separately and explain why they were needed. When handing work to a teammate, include reproduction steps and how to verify the fix. A statement that something was tested is less useful than the actual scenarios checked.
An AI coding assistant can speed up exploration and drafting, while the project team remains responsible for accepting a change. Sensitive operations and code involving access or financial workflows need review appropriate to that domain.
Your next-step checklist
Review each item before using the result.
Further reading
This guide suggests a workflow. Check the official source and the specific product page for current features and terms.
Cursor
Replit
ChatGPT