Checklist

AI-Assisted Development Planning Checklist

One pass through one piece of work: what to settle before you ask, what to put in the request, what to check when the result arrives, and what to do before starting the next thing. Work through it in order. Most items take a sentence.

To keep a copy, use your browser's print option — the page is formatted to print without the site navigation.

1. Before you ask

  • I can say in one sentence what useful outcome this piece of work produces.
  • I have described what should visibly happen, from the point of view of someone using the software.
  • My description could be checked by someone else without asking me questions.
  • I have listed the decisions I would otherwise be leaving to the AI — empty states, duplicates, ordering, limits, what happens when something fails.
  • I have answered those decisions, rather than written them as open questions.
  • I know what this change must not alter.
  • The piece is small enough to check in a couple of minutes, and still does something observable.
  • I know what I will look at to decide whether it worked.

2. In the request

  • The outcome, in one sentence.
  • The behaviour, in plain terms — what happens, and what is then visible.
  • The decisions I have already made, stated as decisions.
  • The relevant existing state: which files or areas this belongs to.
  • The boundaries: which files, behaviour and dependencies must be left alone.
  • Nothing about implementation that I do not actually care about.

3. When the result arrives

  • I have checked the described behaviour, point by point, rather than reading the code and forming an impression.
  • I have checked each decision from step 1 — the empty case, the duplicate case, the failure case.
  • I have checked two or three things nearby that were working before, and they still work.
  • I have looked at which files changed, and it is the set I expected.
  • Anything changed beyond the request is either genuinely necessary, or rejected.
  • I have not accepted "it runs" as evidence that it works.
  • I have not accepted the AI's own description of the work as evidence that it works.

4. If something is wrong

  • I have written down what actually happened, and what I expected instead.
  • I am asking for the smallest correction that addresses that difference — not a rewrite.
  • I have re-run the same checks afterwards, including the neighbouring ones.
  • If the correction has grown larger than the original change, I have stopped and gone back to my last good version instead.

5. Before starting the next piece

  • The behaviour I accepted has actually been verified, not assumed.
  • The boundaries I set still hold.
  • This version is preserved somewhere I can return to.
  • I could answer, right now, the question: what is the last version I know was correct?

A note on proportion

Not every project needs every line of this. A throwaway tool needs the first section and little else. Software handling personal data, payments, access control or anything with real consequences needs more than this checklist provides — automated tests, and review by someone who genuinely understands the area. Use the checklist as a floor for work you intend to keep, not as a ceiling.

This checklist follows the shape of the PDAID method. For the reasoning behind each step, see how to plan an app before you ask AI to build it and how to test code you didn't write.