Most advice about working with AI is a collection of tips. Tips help with individual requests; they do not tell you what to do next.
What tends to be missing is an order of operations — something you can follow on Monday and again on Thursday, that produces a comparable result both times, and that tells you when a piece of work is finished rather than merely stopped.
The workflow below is one such order. It is worth following once in full on something small before deciding whether it earns its place.
The shape of it
Every piece of work goes through the same sequence: decide why it exists, describe what should happen, resolve the questions you have not answered, state what must not change, build it, check it against what you described, and preserve the result before starting the next thing.
The order matters more than it looks. Each step produces something the next step needs, and skipping one does not save time so much as move the cost later — usually to the point where it is most expensive.
Walking one change through
Take something small and real: letting a user change the email address on their account.
Why it exists. People change jobs and lose access to old addresses, and at the moment they have to ask an administrator. One sentence, and it already rules things out — this is not about profile editing generally.
What should happen. From the outside: the user opens their account page, sees their current email, enters a new one, confirms their password, and is told the change has been saved. Afterwards the new address is shown, and signing in uses it.
Note that this describes what someone would see, not how it is stored or validated. Those are implementation choices, and the point of leaving them open is that this is the part AI genuinely handles well.
The questions you have not answered. Reading that description back, several things are unresolved. What if the address is already used by another account? What if it is not a valid address? Should the old address be notified? Does the change take effect immediately or need confirming from the new address? What if the password is wrong — how many attempts?
Answer them now, as decisions: an address already in use is rejected with a message; invalid formats are rejected before saving; the old address is notified; the change takes effect immediately for now; three password attempts then a lockout consistent with the existing login.
Those five answers took a minute. Left unanswered, each would have been decided silently, and you would have discovered the choices later by accident.
What must not change. Do not alter the login flow, the password rules or the existing account page layout. No new dependencies. The user table structure stays as it is apart from the email value itself.
Build it. Now the request is worth making, because it contains the outcome, the behaviour, the decisions and the boundaries. This is a single message, not a conversation — and it is noticeably longer than "add email changing", which is the point.
This is also the step that changes most if you let an agent carry out the whole sequence unattended. What that changes and what it does not is covered in agents still need someone to decide what "done" means.
Check it. Against the description, item by item. Change an address successfully. Try one already in use. Try an invalid one. Enter the wrong password. Confirm the notification to the old address. Then sign out and sign back in with the new address, because that was part of what you said should happen.
Then check what you did not change: can existing users still sign in, does the account page still show everything it did before, is the password rule unchanged.
Preserve it. With the behaviour verified, mark this version as one you have actually checked, before starting the next thing. What makes that different from an ordinary commit — and why the difference matters more as changes arrive faster — is set out in always have something that works to go back to.
If you would rather work from something than remember the order, the planning checklist is this sequence as a single pass you can tick through.
Where people skip, and what it costs
Two steps get dropped more than the others, and both are dropped because they feel like overhead at the moment they are needed.
The questions step gets skipped because the work seems obvious. It is obvious to you; the ambiguity is invisible precisely because you have already resolved it in your head without noticing. The cost arrives as a series of small corrections, each reasonable, which together take longer than the minute you saved.
The preserve step gets skipped because nothing appears to depend on it. Nothing does, until something goes wrong three changes later and there is no verified version to fall back to. That is the moment a manageable problem becomes an expensive one.
Adapting it without losing the point
This is a shape, not a ritual. For a two-line change to a personal tool, the whole cycle can happen in your head in thirty seconds, and writing it down would be theatre.
What should not flex is the relationship between the steps. Describing behaviour before requesting the work, and checking against that description afterwards, are the two that carry the method — the description is what makes the check possible. Drop either and you are back to evaluating results by whether they look plausible.
For work with real consequences — personal data, payments, access control — the cycle is a floor rather than a complete answer. Everything above still applies, and so does automated testing and review by someone who understands the specific risk.
Where it comes from
This sequence is the practical form of a method called PDAID — Prompt-Driven AI Development — which sets out the same cycle as seven named phases, with more detail on each and on the division of responsibility between you and the assistant. The PDAID page is the fuller explanation; this article is one pass through it on a single change.
If you want to go deeper on individual steps, the two that repay the most attention are describing the work: how to plan an app before you ask AI to build it, and checking the result: how to test code you didn't write.