EODHD Academy
‹ Build Your First Tool Lesson 5 of 16
Contents Lesson 5 of 16

6 min read · foundations

The loop — plan, prompt, diff, read, verify, commit

Everything else in this course is an application of the six steps below. They are what separates building with an assistant from being driven by one.

plan  →  prompt  →  diff  →  READ  →  verify  →  commit small
   ↑                                                  │
   └──────────────────────────────────────────────────┘

Two rules hold the whole thing up:

Never commit code you do not understand. Secrets never enter code.

Everything below is machinery for keeping those two true while still moving fast.

plan — the smallest next thing

You wrote the project plan in unit 1. This one covers the next twenty minutes. "Add a remove button to each watchlist row, updating the same state the add form writes to." One outcome, one place, something you could check by looking.

Vague requests produce sprawling diffs. Sprawling diffs do not get read. Unread diffs are how you end up owning code you cannot change.

prompt — say the constraints, not just the goal

A good prompt carries the goal and the boundaries the assistant cannot infer:

Add a remove button to each row in Watchlist.tsx. Use the existing symbols state in page.tsx — do not add a store. The server component stays server-only; if this needs client state, tell me before writing it rather than converting the file.

That last clause is the important one. You have asked it to surface an architectural decision instead of quietly making one. Assistants convert server components to client components all the time to make something work, and that is exactly the change that could drag your API key into the browser.

diff — never let it write straight to the file unseen

Whatever your cockpit, insist on seeing the change as a diff before it lands. In a terminal agent that is the approval prompt; in an IDE it is the inline review; in chat it is you pasting deliberately.

If your assistant is configured to edit files without showing you, turn that off. Speed you cannot inspect is not speed.

READ — the step everyone skips

This is the one that makes you a programmer rather than a requester. Four questions, every diff, in this order:

  1. Did it change anything I did not ask about? Extra files, a new dependency, a reformatted function, a "while I was here" refactor. Every one of those is scope you did not choose.
  2. Does it touch data fetching? If yes, the key rule is in play. Where is the fetch happening, server or client? Did a "use client" appear at the top of a file that reads the environment?
  3. What happens when it fails? Generated code is reliably optimistic. Empty list, network error, a field that is null this morning: pick one and find the line that handles it. Often there is no line.
  4. Can I explain this to someone else? If the answer is no, you have a choice: ask the assistant to explain it, or throw it away. What you may not do is commit it.

A useful habit: ask for the explanation before you accept, not after. "Explain what this code does line by line, and tell me what happens if the API returns an empty array." The answer is often where the bug is.

verify — run it, and run the failure

Load the page. Then break it on purpose: an empty list, a ticker that does not exist, the dev server with the key removed. The happy path proves the code compiles; the failure path proves someone thought about it.

commit small — the undo button you get for free

One logical change per commit, with a message saying why rather than what.

git add src/components/Watchlist.tsx
git commit -m "Remove a row without a full refetch - the list is already in state"

Not "update Watchlist.tsx". The diff already says what changed; only you can say why.

This matters more with an assistant than without one. When a change three prompts ago turns out to be wrong, small commits let you take out exactly that one. One giant commit called "add watchlist" means your only undo is deleting a day.

And the second absolute rule lands here: git add . is how keys get committed. Stage the files you meant to change. The starter has a pre-commit hook that refuses key-shaped strings, and it is a seatbelt, not a substitute for looking.

What this costs and what it buys

It is slower per change. Genuinely: reading a diff properly takes a few minutes.

It is much faster per project, because the alternative is not "fast", it is "fast until the first thing you cannot explain, then stuck". The loop is what keeps every line in your repository either understood or deliberately borrowed.

Try it now

Run one full turn of the loop on the smallest thing you can find in the starter: change the page heading. Overkill on purpose, because you are practising the motion rather than the change. Write the one-line plan, prompt, look at the diff, ask the assistant what would happen if the value were empty, run it, and commit with a message that explains why. Time it. That is your baseline cost per turn.