You will be able to give an assistant what it needs to fix a bug, and recognise when to stop and step back.
Priya's results table worked on her laptop. When she pasted feedback copied from an email, some rows came back empty. She typed into her assistant: "The table is broken, some rows are empty, please fix." It rewrote the table code, which changed nothing, so she said "still broken" and it rewrote the server route. After that, nothing worked at all. She said "that made it worse", and the assistant apologised and changed a third thing. Forty minutes in, she was further from working code than when she started.
Every developer has been in this loop. The way out is to give the assistant better information and to know when to stop asking.
"It's broken" gives the assistant nothing to work with, so it guesses. And it guesses confidently, which is worse than not guessing.
Give it what you would give a colleague sitting next to you, starting with the full error message copied exactly, file names and line numbers included. Error messages often run to many lines, and the useful part is not always the first line, so paste all of it. For a web app, look in two places: the browser's developer tools console for errors on the page, and the terminal running your server for errors on the server.
Then the steps to reproduce it. What you did, in order, with the input you used: "I pasted these three lines, copied from an email, and pressed submit. The first row shows correctly. Rows two and three are empty. No error in the browser console. The server log shows a validation failure on items two and three."
And what you expected instead. "I expected three filled rows."
With that, the assistant has evidence instead of a vibe. Priya's version of that message got a useful answer on the first try.
Now the important habit. Do not ask for a fix yet. Ask: "What is the most likely cause of this? Do not change any code yet."
This does two things. It makes the assistant reason about the problem rather than jump to a patch, and it lets you check the reasoning before anything changes. If the explanation makes sense and fits the evidence, ask for the fix. If it does not, you have saved yourself a bad change.
Priya's assistant explained that text copied from email often contains non-breaking spaces and invisible formatting characters. Her server split items on line breaks, so some items arrived with stray characters that made the model's output fail her schema check. That matched the evidence, since only the copied lines failed. The fix was to clean the text before splitting. One change, and it worked.
Sometimes the first fix does not work. Give it one more try, with the new error message. If the second fix fails too, 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. Each new fix builds on that mess.
So step back. Revert to your last working commit, the one from lesson 6.3, Work in small steps and read every change, which throws away every change since then. Then start a new conversation with the assistant and describe the problem fresh, with everything you have learned: the error, the steps to reproduce, and what you now know does not cause it. A clean start with better information beats a tenth attempt in a tangled one.
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, and find exactly where it goes wrong.
When a bug is fixed, make sure it stays fixed. Ask the assistant to add a small test or check that would have caught it. For Priya, that was a test that 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, and if any future change brings the bug back, the test fails and says so.
You do not need a large test suite for a small app. One small test per bug you fix adds up quickly, and those tests protect exactly the places that have already gone wrong once. In module 7 you will do the same thing for the model's output, with an eval set.
Keep a record as you go. Every bug, what caused it and how you fixed it. Over a few weeks that record shows you your own patterns, and the final project asks for it, so the activity below gets it started now.
Keep a bug log while you build, recording the error, the cause and the fix for each bug you hit.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).