29 AI: Practical use
A short, tool-light guide to using the assistant in the browser for this course. Shared by weeks four and five.
You now know what the assistant is doing under the hood, and you have practiced predicting, explaining, and confirming with it a few times. This note is smaller than those and more useful in the moment: some ordinary habits for actually typing at the thing, so that the answers you get back are worth the checking you are about to give them. None of this is about which button to click. Buttons change every few months; the habits below do not.
Say what you want, not what you are thinking about. “Something about DNA sequences” is not a request, it is a mood. “A function that takes a DNA string and returns the count of each base as a dictionary” is a request. The assistant fills gaps you leave with a plausible guess, not a clarifying question, so a vague prompt does not get you a cautious answer, it gets you a confident answer to a question you did not quite ask. The fix costs you nothing but a few extra words: name the input, name the output, and if there is an edge case you already care about, such as lowercase letters or an empty string, say so up front.
Give it the context it actually needs, and no more. If you want help with one function inside a larger project, paste that function and the one or two things it depends on, not the whole file. Too little context and the assistant guesses at conventions you already decided; too much and it starts guessing at which of forty things you actually meant, which is its own kind of vagueness. A good rule of thumb: give it what a classmate would need to help you, no more, no less.
Read the reply before you trust the tone. An assistant’s reply is fluent and confident whether it is right or wrong, so confidence is not evidence of anything and you should stop letting it feel like evidence. Read a reply the way you would read a claim from a classmate who is occasionally brilliant and occasionally makes things up with total sincerity: interesting, worth considering, not yet worth acting on.
Ask for the reasoning, but do not mistake it for proof. You can ask the assistant to explain a line, walk through an example, or justify a choice, and doing so often surfaces a mistake that a bare answer would have hidden. But remember what an explanation is: another plausible-sounding piece of text, generated the same way the original answer was. It can make a wrong answer sound more convincing just as easily as it can reveal that the answer was wrong. Treat an explanation as a second thing to check, never as the checking itself.
Tell helpful apart from merely fluent. A helpful answer is one you can act on because you have verified it, by running it, testing it, or checking it against something you already know. A merely fluent answer is one that reads well and that you have not yet checked. The two are indistinguishable by feel, which is the entire point of this course, and distinguishable only by the running, testing, or checking you actually do.
Exercise 29-1
Ask the assistant the same underspecified question two different ways: first as something thoroughly vague, such as “write me something to look at a DNA sequence,” and then as a specific request naming the input, the output, and one edge case you care about. Compare the two replies. Which one would you have had to guess at least, and which one can you actually check against what you asked for?
Ask for what you can check
Underneath every habit in this note sits one rule that has not yet been said out loud, so say it now: never ask for something you have no way to check. Everything this course has built, the badges, the tests, the widgets that run a line and show you what actually happened, exists to give you a way to check an answer, and none of it can help you if the thing you asked for is too large or too vague to be checked at all. A single function with a stated input and output can be checked: you can test it, read it in full, run it on a case you already know the answer to. A whole program, or “something that analyzes my data,” resists checking for a different reason: there is no small, stated claim inside it to check against. This is why the second habit follows directly from the first: ask for one thing at a time. A function you can test beats a program you cannot, because a wrong function fails its test and tells you so, while a wrong program full of untested pieces simply runs and produces something, with nothing to tell you whether that something is right. When a task is bigger than one function, treat that as a reason to break it into functions first, the same decomposition this course teaches you to do in Python, and ask for one piece at a time, each one small enough that checking it is actually possible.
Before you run anything
Two more checkpoints sit inside the same exchange: one before the assistant answers, one before you run what it gives you. Before it answers, you can ask it to state its assumptions, or to ask you a clarifying question rather than silently guessing at what you meant. This does not remove the gap-filling described at the start of this note; it makes the gap visible instead of invisible, which is a large difference. An assistant that says “I assumed lowercase input, since you did not specify” has told you exactly where to look if the answer turns out to be wrong. An assistant that made the same assumption silently has hidden it inside code that looks no different from code that checked. After it answers, and before you run anything it produced, do one more pass with only your eyes. Ask yourself a sharper question than whether it looks plausible, which every line from this tool does by default: can you say, in your own words, what each line actually does? A line you cannot explain is not a line to run and see what happens; it is your next question, back to the assistant or to the documentation, before the code touches anything.
When the answer is wrong
The first answer from the assistant is rarely the last one, and the conversation that follows a wrong answer is where a beginner loses a whole afternoon without noticing it happening. Two habits keep that from happening to you. Name the specific symptom rather than the general complaint: that it raises a KeyError on line 4 when the dictionary has no entry for 'N', which input produced which wrong output, the exact line if you can point to it. A vague report gets a vague repair, for the same reason a vague request got a vague answer in the first place. And watch for the tell that the conversation itself has gone bad rather than the code: the assistant apologizes, states with total confidence that it has now found the problem, and hands back code that fails the same way it failed two turns ago. Once is ordinary. Twice means whatever is actually wrong sits outside whatever the conversation has been circling. At that point, restart: open a fresh conversation and restate the problem from the beginning, including whatever you now understand about it that the last few replies clearly did not, rather than layering one more correction onto a conversation that has already shown you it is stuck.
Say what shape you want back
You are allowed to ask for less. Left to its own habits, the assistant tends to over-answer: a paragraph of setup, the code, a paragraph of summary, a list of possible extensions nobody asked for. None of that breaks any rule, and some of it is useful, but a wall of text is easy to accept without reading closely, which is the opposite of what this course wants from you. Ask directly for the shape you actually need: code only, no explanation, when you already know what the function should do and just want to see it; explanation only, no code, when you are trying to understand something and do not want to be tempted to paste an answer you have not earned yet; the shortest version that works, when you want to compare it against your own attempt. Controlling the shape of the reply is not a minor convenience. It is the same habit as asking for one thing at a time, aimed at the reply instead of the request.
Point it at your own code, not only new code
Every habit so far has been about asking for something new: a function, an explanation of someone else’s error, a second opinion on a choice you have not made yet. The single highest-value and lowest-risk use of the assistant is also the one beginners think of last, which is turning it on code you already wrote yourself. Paste in a function you finished for an earlier exercise and ask what it does, whether anything in it looks fragile, or what would happen if you called it with an empty string or a lowercase sequence. You already know what you meant the function to do, so you are in the best position anyone could be in to judge whether the assistant’s account of it is right, and there is no new code in the exchange to distrust, only a second pair of eyes on code you can already run yourself to settle any disagreement. Try it on a function from this week’s own exercises before you try it on anything else.
Closing the tab on purpose
Not every habit in this note is about how to prompt. The most reliable one is sometimes not to. Roughly three out of four exercises in this book carry no assistant badge at all, marked SOLO instead, and the reason is not caution for its own sake. Fluency with Python only comes from typing it yourself often enough that the shape of it stops being unfamiliar, and the assistant is very good at letting you skip exactly that practice while still producing a working answer, which feels like progress and is not quite the same thing. Nobody is checking whether you actually closed the tab on a SOLO exercise. What you lose by not closing it is not a point or a grade; it is the one piece of evidence you would otherwise have had about whether you can do the thing alone, and that evidence is the entire reason the exercise existed.
Prompting in Danish
Many of you will find it more natural to type a question in Danish than in English, and nothing about this course requires you not to. Python itself does not become Danish: its keywords, its built-in error messages, and almost every example you will ever read online are in English, so a function drafted from a Danish prompt still comes back with English names and English comments, because that is overwhelmingly what the assistant has seen written about code, regardless of what language you asked in. What changes is invisible rather than absent: the assistant is translating your Danish request into the same kind of answer it would have given an English request, and translation is one more step where meaning can slip, unnoticed, between what you meant and what it answered. That is not a reason to prompt only in English. It is a reason to give a Danish prompt exactly the same checking you would give an English one, rather than less.
Write it down when it happens
The logbook only works if it is honest, and honesty about a specific exchange fades fast. The moment you catch the assistant being wrong, or catch yourself accepting an answer too quickly, is the moment to write one sentence about it somewhere you will find again, not a mental note to remember later. An exchange that felt worth keeping on Tuesday is, by the time you sit down to write the week’s entry, only a vague sense that something happened rather than the sentence you actually need. Keep the logbook file open, or a scratch note nearby, while you work through the exercises below, and copy the moment in as it happens rather than trying to reconstruct your week from memory once the week has already passed.
Exercise 29-2
Take a function from one of this week’s exercises that is not working right, or write a short one with a deliberate bug if nothing is currently broken. Report the problem to the assistant twice, in two separate conversations. In the first, say only “this doesn’t work” and paste the code. In the second, name the specific symptom: the exact error, or the exact wrong output for a specific input. Compare how many turns each conversation takes to reach a real fix, and note whether the vague conversation shows you the tell described above, the assistant apologizing and handing back code that fails the same way.
Exercise 29-3
Ask the assistant for a function that returns the reverse complement of a DNA string, and ask it, in the same message, to state any assumption it made about the input before you read a line of the code itself. Read the function anyway, in full, before running anything: could you have explained every line yourself even if it had not told you its assumption? Then test it on a sequence containing a lowercase letter or a base other than A, T, G, C, and see whether the code’s behavior actually matches the assumption it stated, or only matches what it assumed for the cases you did not think to try.
For your logbook this week, write the single worst prompt you have given the assistant so far in this course, in your own memory or your prompt history, and rewrite it as it should have been.