Give an assistant what it needs to fix a bug, and tell when it is time to stop and step back.
Next time your app breaks, copy the full error message exactly as it appears before you type anything to your AI coding assistant. Take every line, including the file names and line numbers. Error messages often run to many lines, and the useful part is not always the first line, so paste all of it.
A report like "it's broken" gives the assistant nothing to work with, so it guesses. It guesses confidently, which is worse than not guessing at all.
Priya was building an app with a results table, using an AI coding assistant. The table worked on Priya's laptop. Then Priya pasted in feedback copied from an email, and some rows came back empty. Priya told the assistant: the table is broken, some rows are empty, please fix. The assistant rewrote the table code, and nothing changed. Priya said "still broken". The assistant then rewrote the server route, and after that nothing worked at all. Priya said "that made it worse", and the assistant apologised and changed a third thing. After forty minutes, Priya was further from working code than at the start.
Every developer has been in this loop. If you keep saying "still broken" or "that made it worse", the assistant keeps making unrelated changes, and each one moves the code further from working. To get out of the loop, give the assistant better information and know when to stop asking.
Give the assistant what you would give a colleague sitting next to you. That means the full error, the steps to reproduce (what you did, in order, with the input you used) and what you expected to happen instead.
For a web app, check two places for errors. The browser's developer tools console shows errors on the page. The terminal running the server shows errors on the server.
Priya's second report gave all of this. Priya pasted three lines copied from an email and pressed submit. The first row showed correctly, and rows two and three were empty. There was no error in the browser console. The server log showed a validation failure on items two and three. Priya expected three filled rows. With the error, the steps and the expected result, the assistant had evidence to work from instead of a vibe, and Priya got a useful answer on the first try.
Before you ask for a fix, ask: "What is the most likely cause of this? Do not change any code yet." This makes the assistant reason about the problem before it writes a patch. It also lets you check the reasoning before anything changes.
When Priya asked this, the assistant explained that text copied from email often contains non-breaking spaces and invisible formatting characters. Priya's server split items on line breaks, so some items arrived with stray characters. Those characters made the model's output fail Priya's schema check. The explanation matched the evidence, since only the copied lines failed. The fix was to clean the text before splitting. It was one change, and it worked.
If the explanation makes sense and fits the evidence, ask for the fix. If it doesn't, don't go ahead with that change. You have avoided a bad change before it was made.
If the first fix fails, try once more and give the assistant the new error message. If the second fix also fails, stop asking for fixes.
After two failures the conversation itself is often the problem. It is full of wrong guesses, half-applied changes and code that has drifted, and each new fix builds on that mess. Revert to the last working commit from Lesson 6.3, "Work in small steps and read every change". Reverting throws away every change since that commit. Then start a new conversation and describe the problem fresh. Give it the error, the steps to reproduce, and what you now know does not cause the bug. A clean start with better information beats a tenth attempt in a tangled conversation.
If the fresh attempt also fails twice, the step was probably too big. Split it into smaller steps. Or ask the assistant to add logging that shows what the data looks like at each stage, so you can find exactly where it goes wrong.
Once a bug is fixed, ask the assistant to add a small test or check that would have caught it. If a later change brings the bug back, the test fails and tells you. Priya's test feeds the splitting function a line containing a non-breaking space and checks that the cleaned item comes out right. It runs in under a second.
A small app does not need a large test suite. One small test per fixed bug adds up quickly, and those tests protect exactly the places that have already gone wrong once. In module 7 you will do the same kind of checking on the model's output, using an eval set.
Keep a record of every bug as well: what it was, what caused it, and how you fixed it. Over a few weeks the record shows you your own patterns. The final project asks for this bug record.
Start your bug record now with the most recent bug you hit. Write down the bug, its cause and the fix, and add an entry for each bug you fix from now on.
Keep a bug log as you build. For each bug, write down the error, the cause and the fix.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).