Listen to this article
When I give AI a development task, I want to tell it how to approach the work as well as what to build. Asking for a feature leaves a lot open to interpretation. It might make the change, see that the application starts and come back with a confident message saying everything is finished.
I think we need to be more specific about what finished means. The request should include a process: understand the change, protect the existing work, implement and test it, provide evidence, then compare the result with what was agreed. This gives me something I can review before accepting the job.
These are the five steps I would put alongside a request. The detail should fit the task, but the expectation is the same: AI should leave a clear account of what it changed and how it knows the result works.
1. Agree what will change
Start by asking AI to inspect the relevant part of the application and explain the change it intends to make. It should identify the files or data involved, the behaviour we want and anything that needs to stay intact. This is the point to resolve a missing requirement, before it becomes an assumption in the code.
For a permissions change, for example, I would spell out which users should have access, which should not and what should happen to existing records. For a form, I would describe a successful submission, the validation failures and what happens to someone’s progress. A request becomes much easier to check when it describes observable behaviour.
I also want the scope to be clear. Tell AI which environment it can work in, where the code should be committed and whether deployment is part of the request. A preview release and a production release are different actions. The instructions should make that distinction before the work starts.
2. Take the backup first
Ask AI to identify what needs protecting and take the relevant backup before changing it. That could be an export of the affected records, a database backup or a recoverable copy of existing files. The backup needs to match what the task could alter. A code commit will not recover customer records changed in a database.
The handover should record when the backup was taken, where it is stored and what it contains. If it holds sensitive information, it needs appropriate protection. I also want a clear explanation of how it could be restored. Saying a backup exists is less useful if nobody knows which change it would undo.
This does not need to become an elaborate exercise for every small edit. Ask for a recovery method proportionate to the work. The important part is deciding how to recover before making a change that we might need to reverse.
3. Implement the change and test the behaviour
Tell AI to keep the implementation within the agreed scope and make the code available for review. I want to see what changed, with a branch, commit or pull request where the project uses them. Unrelated improvements can be discussed separately rather than quietly becoming part of the same job.
Then ask for tests tied to the requirements. A passing total is useful context, but I want to know which checks demonstrate the new behaviour and which protect existing functionality. For a bug fix, ask it to show that the relevant test fails without the fix and passes with it, using an isolated test setup. That is a more useful explanation than simply saying the tests are green.
It should also run the existing checks relevant to the affected area and report failures honestly. If a check could not run, it needs to say why. AI can write tests that agree with its own mistaken implementation, so the assertions still need reviewing against the original requirement.
4. Provide proof from the right environment
Ask for evidence that someone can follow. Depending on the task, that might include test output, screenshots, a browser walkthrough or the response returned by a request. Each item should explain which requirement it supports and where it was checked. A screenshot of the interface does not demonstrate everything happening behind it.
For permissions work, I would ask it to check the data reaching the browser as well as the buttons on the screen. For a reset flow, I would ask it to try the old value and the replacement. For a form, I would want to see the error state and the successful path. The evidence should cover the behaviour we asked for, including the cases where an action should be refused.
Use test accounts and test data for checks that change state. Tell AI to identify what it changed during testing and clean up any temporary access afterwards. The report should make clear whether it checked a local build, a deployed preview or production. I need that context to understand what the evidence actually tells me.
5. Confirm against the original request
The final response should come back to the agreement at the start. Ask AI to list the requirements, state what was delivered for each one and link to the supporting evidence. It should also identify anything incomplete, any remaining uncertainty and whether a deployment still needs to happen.
I find this much easier to review than a long account of every action the AI took. I want the code reference, the backup details, the test results, the browser evidence and a clear statement of the outcome. That structure also helps when I return to the job later and need to understand what was actually done.
The report itself still needs scrutiny. AI saying that something was checked is a claim I can follow up, and the supporting material needs to be available. The process is useful because it makes the work reviewable. It does not remove my responsibility to decide whether the implementation and the checks are good enough.
An instruction to add to your requests
You can put the process directly underneath the task. I would use something along these lines, then adjust the testing and backup requirements to suit the project:
Follow this process for the request above:
1. Inspect the relevant code and data. Set out the intended change, the acceptance criteria, what must remain unchanged and the environment you will work in. Resolve material ambiguities before implementing.
2. Before making changes, take the relevant backup or recovery snapshot. Record its location, time, contents and restoration method. Protect sensitive exports appropriately.
3. Implement within the agreed scope and provide the code reference. Test each acceptance criterion and relevant existing behaviour. For a bug fix, demonstrate that the relevant test detects the original problem. Report failed or unavailable checks.
4. Provide reviewable evidence from the agreed environment. Include relevant test output and browser screenshots or observations. Use test accounts for actions that change data, record their effects and remove temporary test access afterwards.
5. Finish with a requirement-by-requirement confirmation, links to the evidence, backup details and anything still unverified or outstanding. State where the change is running. Deploy to production only if that deployment is explicitly included in my request.
This is the part I want to make routine. The feature request tells AI what I need. The process tells it what I expect before I will consider the work complete. If I am going to rely on AI to do more, I want the work it hands back to become easier to inspect and understand.