What we are making: a working method. Not “ask it things” —
a repeatable way of getting real value out of it without being misled.
The rule: it drafts, you verify
A chatbot is a fast, fluent, unreliable colleague who has read a great deal and remembers none
of it precisely. That is a genuinely useful colleague, provided you never sign off their work
unread.
The second prompt gets an answer worth acting on, and a test that could disprove it.
What made the second one work
The exact symptom, including the actual error text.
The timing. Forty minutes, not 'sometimes'.
Your own evidence. The boot counter — a number you collected.
The hardware context it could not otherwise know.
A request for a test, not just a cause. This is the important one.
💡 Tip
Always ask for the test, not just the answer. “What is the smallest experiment that would confirm or rule this out?” turns a guess into something you can check, and it is the single most valuable prompt in this book.
Do it — the disciplined debug
Your teacher gives each team a deployed device with a genuine intermittent fault.
Fifteen minutes with no chatbot. Read the log. Form a hypothesis. Write it down.
Write a prompt containing all five things from the list opposite, and ask for the smallest confirming test.
Read the answer. Write in your notebook whether you agree, and why.
Run the test, not the fix. Find out whether the hypothesis is right first.
Only then make the change, by typing it yourself.
Record: your hypothesis, its hypothesis, what the test showed, what you did.
⚠ Careful
Notice this is the same loop as Session 16. Observe, hypothesise, design the smallest test, run it, record it. The chatbot is a source of hypotheses. It is not a source of conclusions.
Where it genuinely earns its place
Task
How well it does
Note
Explaining an error message
Very good
Especially compiler and linker errors
Translating between languages
Very good
“what is this Python doing?”
Boilerplate you could write but slowly
Good
Still read every line before using it
Suggesting what to test next
Good
Its best use in this subject
Writing code you do not understand
Actively harmful
You cannot maintain or defend it
Deciding a threshold for you
Actively harmful
It has never seen your data
⚠ Careful
That last row matters for your project. A chatbot cannot choose your threshold, because your threshold comes from your deployment, on your roof, with your sensor. Anything it suggests is a plausible number with no evidence behind it.
The honesty line
The test: can you defend every line, to somebody who asks why?
Declare it
From now on, every use goes in your notebook: what you asked, what it said, what you did
about it.
This is not a school rule invented to catch you out. Professional engineers now do exactly
this, because a design decision whose reasoning cannot be reconstructed is a liability. Your
notebook is the reconstruction.
💡 Tip
At the May panel somebody will ask whether AI wrote your project. The strongest possible answer is to open the notebook and show precisely where it helped and where it did not. That reads as confidence. A denial reads as a denial.
What you learned
It drafts, you verify. Never the other way round.
Give it symptoms, numbers, context, expected-vs-actual, and what you tried.
Ask for the smallest confirming test, not just the cause.
Work on it yourself first, or you cannot judge the answer.
It cannot choose your threshold. It has not seen your data.
Record every use.
Challenge optional — only if you finish early
Use a chatbot to debug something, then find the answer yourself. Which was faster?