The doom loop
It goes like this. Something errors. You paste the error. The model changes three files. A different error appears. You paste that. It changes five files. The original feature stops working. You paste more. Two hours later the app does not start, you cannot remember what it looked like when it worked, and the model is now suggesting you reinstall your dependencies.
Everyone building this way hits it. The way out is not a better prompt. It is a procedure.
Stop after two
Hard rule: if two attempts at the same error both fail, stop asking. The third attempt is where damage starts, because the model is now working on a codebase that contains its own failed guesses.
Go back to the last state that worked. Lesson 5 covers how. If you have no save point, this is the moment you learn why you need one.
Read the error yourself
Errors look like noise. They are not. You need three pieces from them.
TypeError: Cannot read properties of undefined (reading 'name')
at BookingCard (/app/components/BookingCard.tsx:23:31)
at renderWithHooks (/node_modules/react-dom/cjs/react-dom.js:14985:18)
at mountIndeterminateComponent (/node_modules/react-dom/cjs/react-dom.js:17811:13)Line one is the what. Something was undefined and the code asked it for .name. Almost certainly a booking that was expected and was not there.
The first line mentioning your own files is the where. BookingCard.tsx, line 23. The node_modules lines below are the library's internals; you can ignore them nearly always.
What you did just before is the when. Did it break on page load, or after you clicked something?
With those three you can write a request worth sending. Without them you are forwarding noise and hoping.
Reproduce it before you fix it
Can you make it happen on purpose, every time? If yes, you can tell when it is fixed. If no, you cannot, and any fix you accept is a guess that happened to coincide with the bug not appearing.
Write the steps down in one line: "Log in, go to /bookings, click any row for a cancelled booking. Blank page." That sentence is worth more to the model than the stack trace.
Change one thing
When you do ask for a fix, constrain it:
This error happens every time I click a cancelled booking:
[paste the first three lines]
Reproduce: log in, /bookings, click a cancelled row.
I already tried adding a null check in BookingRow — no change.
Fix only BookingCard.tsx. Do not change the database schema,
do not touch the API route, do not refactor anything.
Explain the cause before you write code.The restrictions matter as much as the description. Left unbounded, an agent asked to fix a display bug will sometimes rewrite your data layer because it noticed something it did not like.
"Explain the cause before you write code" is the highest-value sentence in that prompt. If the explanation is vague — "there may be a state issue" — the fix will be vague too, and you should not accept it.
When the fix works, find out why
Sometimes an error disappears and you have no idea what changed. That is not fixed. That is postponed. Ask: "which line caused the error, and which line prevents it now?" If the answer is a wrapped try/catch that hides the failure, the bug is still there and now it is silent.
Delete and redo is a legitimate move
After several rounds of patching, a feature can end up as sediment: layers of half-applied fixes, dead branches, two functions doing similar things. Repairing that costs more than rebuilding it.
Revert to before the feature existed. Write a better description than the one you used the first time, now that you know what went wrong. Build it again in one clean pass. This often takes fifteen minutes and feels like a failure. It is not. It is the cheapest option on the table.
The thing that makes all of this possible
Every instruction in this lesson assumes you can get back to a working version. If you cannot, none of it applies and you are just hoping. That is the next lesson.
Before you move on