# AI as a student Where a language model moves you forward, where it wrecks your learning, and what you have to say about it. Multimedia & Creative Technology · 0.0 General · Self-study · version 1.0.0 · 2026-09-20 Tags: ai Slides: Speaker notes: ## Agenda 1. What it is: Guessing the next word, very well 2. Where it fails: Invented certainty 3. Learning or copying: The difference that counts 4. Prompting: Context in, something usable out 5. Checking: Anything you take over is yours 6. Being honest: What you say and what you share ## Self-study: How to work through this *30 minutes, On your own* Count on half an hour. Keep a chat window open, half of this deck puts you to the test straight away. 1. The prompt lab and the drill sit in the second half 2. The rules of your course or your exam always outrank this deck 3. Finish with one assignment you approach as a tutor instead of an answer machine ## 1. What it is *Not a search engine, not a database, not a colleague who thinks.* **It guesses the next word.** The model calculates which word is likely to follow what is already there. That the answer is right follows from good training, it is not a guarantee of the system. ### Why that matters *Everything you read about mistakes below follows from this one mechanism.* 1. **It always sounds good**: Fluent phrasing is exactly what the model was trained on. That says nothing about whether it is right. 2. **It does not know what it does not know**: There is no bell ringing at a gap in its knowledge. It fills that gap with whatever sounds likely. 3. **It does not know your project**: Only what you paste into the window. The rest of your codebase does not exist for the model. > [!NOTE] > Models that search or read your files do pull in real information. Even then it is the text around it that gets predicted. ## 2. Where it fails *Four kinds of mistakes you learn to recognise.* ### Hallucinations *Invented things that look completely real, because they are written in the same tone as the truth.* | What you get | Why it goes wrong | | --- | --- | | A function that does not exist | It fits the pattern of the library, so it sounds logical | | An npm package that never existed | Attackers register those invented names, with malicious code inside | | A source with title, author and year | The format is right, the publication does not exist | | A quote from somebody famous | In that person's style, but never said | > [!WARNING] > Never install a package you copied from an answer without looking it up on npm itself. That is a real attack route, not a theory. ### Good and less good *The same model, two kinds of task.* #### Works well - Explaining what an error message means - Boilerplate, regex, test data, conversion work - Rewriting or translating a text - Asking follow up questions until a concept clicks #### Works badly - Versions and APIs from the last few months - Numbers, dates and sources that have to be right - Choices inside your project, with your context - Anything you cannot judge for correctness yourself ### The version trap *The model was trained on years of old code. Your framework was not.* - You get the way it worked three versions ago - That code sometimes still runs, with a warning you do not see - Sometimes it does not run and you spend an hour on a function that got removed - The official documentation of your version always beats the answer > [!TIP] > Put your version numbers in the question. That is the cheapest correction there is. ## 3. Learning or copying *The same tool, two completely different outcomes.* **Following along is not the same as knowing.** You read an answer, it is clear, you nod. That feeling of understanding is real. It disappears the moment you turn the page and have to do it yourself. ### Two ways to use the same window #### As a tutor - "Explain why my approach does not work" - "Give me a hint, not the solution yet" - "Ask me three questions about this code" - "What should I have noticed in this error?" #### As an answer machine - "Write the whole assignment for me" - Pasting until it runs and moving on - Skipping the explanation because it works - Generating your report and putting your name under it ### Who you are cheating *The effort you skip is exactly the effort you learn from.* 1. **Struggling works**: Twenty minutes of searching sticks better than an answer you get in ten seconds. Annoying, and true. 2. **The exam is alone**: In a test you sit there without a window. Whoever let it type for four months finds out right there. 3. **Internships settle it**: A company sees within a week whether you can explain what you wrote. That is the skill they hire. > The honest test: close the window and type it again. If that fails, you did not learn it, you only fetched it. ### The ground rules *These hold in this course. Other courses and exams can be stricter, and then those count.* - **What is fine**: Asking for explanation, unpacking error messages, generating boilerplate, having your text proofread, listing alternatives. - **What always holds**: Explaining every line you hand in. If you cannot, it is not your work and it does not count. - **What is not fine**: Having a whole assignment made, an exam or a test, and anything a course explicitly says no to. - **What you say**: Mention where you used it when the course asks for it. Hiding it turns a tool into a problem. ## 4. Prompting *The same ingredients as a good question to a human.* ### Prompt lab *The same question, once as a cry for help and once with everything the model needs.* ### Four handles that make a difference *On top of the context, these are what you can turn.* | What you add | What you get back | | --- | --- | | The versions of your tools | Code that matches what you actually run | | "Explain before you give code" | Something you learn from instead of something to paste | | "Give three approaches with their downsides" | A choice instead of an opinion | | "What is wrong with my solution?" | Criticism of your own work, far more useful than a rewrite | ### What you do not paste in *Everything you type leaves your machine and can be stored or used.* - Passwords, API keys and tokens, not even "just to test" - Personal data of real people: names, mail addresses, files - Code or documents from your internship or a client, unless it is explicitly allowed - Exam questions, and anything under a confidentiality agreement > [!WARNING] > Many companies have a policy for this. Ask on your first day of internship, not after you pasted their code. ## 5. Checking *Everything you take over becomes yours. Mistakes included.* ### The check in five steps - Does it run, and does it do what you asked? - Can you explain every line to somebody else? - Do the functions and packages really exist, according to the official docs? - Does it fit the rest of your project, or is it a strange island? - Is there anything in there you do not need, or that does too much? > [!TIP] > **The explain test** > > If you cannot explain it, it is not finished. Not because it is forbidden, but because you cannot repair it when it breaks. ### Sources you get handed *Links from an answer get opened, every time.* - A url can be invented and still look perfect - A title can exist while the content says something else - Official documentation is one click away, and that click is the entire check - For numbers and dates: find the original source, not the summary > [!NOTE] > This counts double for a report with references. An invented source in your bibliography is a mistake your lecturer spots immediately. ## 6. Being honest *To your lecturer, to your client and to yourself.* ### Drill: smart or not *Six situations from an ordinary week of classes.* **1. You are stuck on an error and ask the model to explain what it means.** - **Fine use** ✓ - Better not - Only outside class This is what a model is good at and what you learn from. You get an explanation, not a finished solution, and you can still check whether it holds. **2. You have your whole report written and put your name under it.** - Fine, you wrote the prompt - **That is plagiarism, and it shows** ✓ - Fine if you reread it You hand in work that is not yours. Rules aside: your lecturer recognises the tone, and the first question about it leaves you speechless. **3. The model suggests an npm package you have never seen. You install it straight away.** - Fine, npm checks that - **Look it up on npm and GitHub first** ✓ - Only with sudo Invented package names get registered by attackers. Check downloads, last update and the repo before you install something that ends up in your build. **4. You paste code from your internship company into a chat to have it cleaned up.** - Fine, it is only one function - **Check the policy of the company first** ✓ - Fine if you change the names That code is theirs, not yours. Many companies forbid this or run their own environment. Ask on day one and you are set for the rest of your internship. **5. You use the model to list three ways you could build a feature.** - **Useful, you choose afterwards** ✓ - Pointless, it knows nothing about your project - Only if you take all of it Getting alternatives side by side is one of the better uses. The choice and the reasoning stay yours, and that reasoning is what your lecturer wants to hear. **6. For an exercise that explicitly has to be done without tools, you use it anyway.** - Nobody notices - **Do not, the exercise is the training** ✓ - Fine if you check it afterwards Such an exercise exists precisely to make you do the work. Skipping it means you find out during an exam or an internship that something is missing, and then it is too late. ### What you say about it *Transparency costs you nothing and clears up a lot afterwards.* ```md ## Use of AI - Claude used to unpack the error in Weather.jsx - First version of the regex for postcodes, adjusted by hand afterwards - README text checked for language - All code in src/ written and tested by me ``` > [!TIP] > Four lines in your README or your report. Even when your course does not ask for it, it is a good habit for later. ### And the rights *Briefly, because the deck about rights and licences covers it fully.* - Images and text from a model usually get no copyright, yours included - What you may do with the output sits in the terms of the tool - Code from an assistant can hold literal pieces with a licence on them - Asking a client whether AI is allowed belongs in the conversation up front ### What is the best test for code you take from an answer? - A. Whether you can explain every line to somebody else - B. Whether it runs without errors - C. Whether it came from a recent model - D. Whether it has comments **Answer:** A. Whether you can explain every line to somebody else Running is the minimum, not proof. If you can explain it, you can also change it when it breaks, and that is exactly what gets asked of you next. ### Cheat sheet *Six habits that separate faster from dumber.* - **Context in**: Goal, versions, code, error message, what you already tried. - **Explanation first**: Ask why, not only what. Hints over solutions. - **Struggle first**: Twenty minutes on your own. That is where the learning sits. - **Check**: Explain every line, look up every package, open every source. - **Nothing secret**: No keys, no personal data, no client code. - **Say what you did**: Four lines in your README and you never have the discussion. ### Task: One assignment as a tutor *25 minutes, On your own* Take an exercise where you would normally ask for the answer, and swap the roles around. 1. Ask for explanation and hints, no code, until you can write it yourself 2. Write the solution yourself, with the window closed 3. Then have your own code criticised and see what of it holds 4. Note in three lines what you learned and what your model got wrong ### Further *Three things worth the trouble, plus the rules that outrank them.* - **The rules of your programme**: What is allowed per course and per exam. In doubt, ask your lecturer, not the model. - **[The docs of your framework](https://developer.mozilla.org)**: For every answer about code: one click to the official source for your version. - **The terms of your tool**: What happens to your input and what you may do with the output. Different per tool and per plan. - **The deck about getting help**: The same ingredients work on a human, and you often learn more there. ## Glossary - **Language model**: A model that calculates which word is likely to follow what is already there. It always sounds fluent, but a right answer follows from good training, it is not a guarantee. It only knows what you put in the window. (slide 4) - **Hallucination**: Something invented that looks completely real: a function, an npm package, a source or a quote that does not exist. Attackers register invented package names, so look up every package on npm first. (slide 8) - **Version trap**: The model was trained on older code and hands you the way it worked a few versions ago. Put your version numbers in the question, and the official docs of your version always win. (slide 10) - **Tutor**: Using a model for explanations and hints instead of the solution. The opposite is the answer machine: having it write the assignment and pasting until it runs. (slide 13) - **Prompt**: What you ask the model. A usable prompt gives context: your goal, your versions, your code, the error, what you already tried and how you want the answer. (slide 17) - **Explain test**: Can you explain every line you take over to somebody else? If not, it is not finished, because you cannot repair it when it breaks either. (slide 21) - **Transparency**: Saying where you used AI, for example in a short section in your README or your report. Required when your course asks for it, and a good habit for later. (slide 25) ## Links and sources ### In the deck - [The docs of your framework](https://developer.mozilla.org) (slide 30)