Tips and tricks

This page is a companion to the chapters rather than a chapter in its own right. Nothing here is examined on its own, and you do not need to read it in one sitting. Dip into it when you are stuck on a prompt, when you are about to write about something you generated, or when a deadline is a week away.

Prompt craft that transfers¶

Prompting is not a set of magic words. The tools change every few months, and any list of phrases that works today will be stale by the time you graduate. What does transfer is the habit of writing a brief: saying who is doing the work, what the work is, and what would count as a good result. The structure below survives most tools, so keep it in a text file and adapt it rather than starting from a blank box each time.

ROLE: You are a [role with relevant expertise].
TASK: [What you want done, in one sentence.]
CONSTRAINTS:
- [Length, style, format]
- [What to avoid]
- [Audience]
CONTEXT:
[Any background the model needs.]
OUTPUT:
[The exact shape you want, with placeholders or an example.]

Be specific, and show rather than tell. “Write it in an academic style” gives the model almost nothing to work with, because every model has its own idea of what that means. A short sample of the voice you want, or one worked example of the output, does more than a paragraph of adjectives. If you can paste in a passage and say “match this register”, do that.

Constrain the form. Say how long, in what format, with what sections, and what must not appear. A model that is told to produce four bullet points of at most fifteen words each will usually comply, whereas one that is asked for “a short summary” will drift towards its own default length. Constraints also make it much easier to compare two attempts, because they differ in content rather than in shape.

Iterate on what is wrong, not on the whole prompt. When a result disappoints, name the specific defect and ask for that one thing to change: “keep the structure, but the second paragraph asserts something the source does not say, so cut it”. Rewriting the entire prompt from scratch throws away the parts that were working and makes it impossible to learn which change helped.

Generate three and veto. Ask for three distinct options rather than one, then reject two. Choosing is faster than correcting, the spread between the three tells you how strongly your prompt constrained the model, and the act of rejecting forces you to say what you actually wanted. This is a good habit for text, and close to essential for images.

For images, the order in which you state things matters, because most systems weight the beginning of a prompt more heavily. A workable default order is [Subject] | [composition] | [style] | [medium] | [lighting] | [mood] | [extra refs]. For video, add the camera angle and its movement, and say what moves within the scene, since a video model otherwise has to guess whether the world or the camera is in motion. Whatever kind of data you are working with, change one knob at a time. If you alter the prompt, the seed, the guidance value, and the model in a single step, you have learned nothing about which of them mattered. Fix everything except the variable you are studying, run it, note the result, then move on. This is slower for one image and much faster over a semester.

Keeping a decisions and prompt log¶

Every piece of work you hand in this semester comes with a log. It is not busywork or bureaucracy. It is the only record of how the thing was made, and without it neither you nor anyone else can say what came from the model and what came from you.

Record enough that a stranger could get close to your result. For each attempt that mattered, note:

• Brief. The one sentence you were trying to satisfy.
• Tool and model. The name, and the version or the date you used it.
• Prompt. The exact text, not a paraphrase of it.
• Seed and settings. The seed if there was one, and anything you changed from the defaults.
• Result. What you got, what you expected, and the gap between them.
• Human edits. What you cut, rewrote, retouched, re-recorded, or rearranged.

Keep one log file per project rather than one per week or one per tool. A project log reads as a narrative, and when you come to write your reflection you will find the argument already half made in your own notes. Scattered fragments in a chat history are not a log, because chat histories are edited, truncated, and occasionally deleted by the provider.

The log protects you. If someone questions whether the work is yours, a dated trail of prompts, rejected outputs, and edits is the strongest answer you can give. It also protects you from yourself, because it is remarkably easy to misremember, three weeks later, that a phrase you are proud of was in fact the model’s first suggestion.

It is also simply honest. Claiming a generated image as a drawing, or a model’s argument as your own reasoning, is misconduct whatever the tool. Logging as you go makes the honest version effortless, and it turns a rule you have to obey into a description of what you did.

Use the practice log template as your starting point. The three headings, Explore, Reflect, and Create, are the same three movements as the weekly lab, so the log fills itself in as the week goes along.

Writing about AI-made work¶

Describe before you interpret. Say what is there in terms a reader could verify by looking or listening, and only then say what you think it means. “The figure’s left hand has six fingers, and the reflection in the window shows a different room” earns a conclusion about the model’s handling of consistency. “The image feels uncanny” does not, because there is nothing in it to check.

Give addresses. A reader cannot follow you to “the one where the colours went strange”. They can follow you to “the third variation at guidance 9”, or “at 0:42, where the camera pans left”, or “the second paragraph of the model’s first reply”. Generations are cheap and numerous, so being able to point at one of them precisely is most of what makes writing about them possible.

Name the tool, the model, its version or the date you used it, and the seed if you have one. A model called by the same commercial name in March and in October is not the same model, and a claim about its behaviour without a date is not checkable. Nobody expects you to reproduce a result exactly. They do expect to know what you were looking at. Chapter 2 explains why the tool and the model are recorded as two separate things.

Separate what the model did from what you did. Write it as two things: this was generated, then I cropped it, colour-graded it, and replaced the sky. Readers, and markers, are interested in both, and blurring them is the fastest way to make a good piece of work look evasive.

Keep your terminology fixed for the length of a text. Decide what you mean by model, tool, prompt, sample, and generation, and stay with it. In this book, a model is the trained artefact, a tool is the interface you reach it through, a prompt is the input you wrote, a sample or a generation is one output. Drifting between these, so that “the AI” sometimes means the model and sometimes the company that made it, makes an argument impossible to follow even when it is right.

Citing models, datasets and generated material¶

Cite a model the way you cite anything else, from its own documentation rather than from a news article about it. A model card or technical report gives you the author or organisation, the year, the model name, the version, and a URL. Use those. If the developers publish a recommended citation, follow it.

Cite a dataset the same way, from its data card, its documentation page, or the paper that introduced it. Datasets get revised, so the version or the release date matters at least as much as the name. Where a dataset has a licence that restricts use, say so, because the licence is often the point you are making.

For generated material, state in the caption or the accompanying note which tool and version produced it, on what date, and that it was generated at all. That last part is not optional. A reader who has not been told will reasonably assume that a photograph is a photograph.

Use a reference manager. Zotero is free, works with the university’s resources, and will save you many hours over a degree. Beyond the citations themselves, it becomes the start of a research library you keep after the course ends.

There is no single reference style required in this course. Choose one, whether that is APA, Chicago, or Harvard, and apply it consistently. Consistency is what is actually assessed. When you are unsure how to cite something unusual, and generated material is still unusual, follow the guidance from the university library rather than inventing a format.

Figures and captions for generated images¶

A figure has to work on its own. Assume a reader who skims the images before reading a word, which is what most readers do, and write for that person.

Every figure needs a caption that says what the reader is looking at and what to notice. “Generated portrait” is a label, not a caption. “Generated portrait, showing the smooth skin texture and symmetrical framing typical of the default style” tells the reader where to look and why the figure is in your text at all.

The caption must state that the material is generated and by what. Give the tool and the model with its version or the date. If a seed and a guidance value are relevant to the point you are making, put them in too. Do this even when it seems obvious from context, because figures get reused, screenshotted, and pulled out of their context almost immediately.

Credit your reference images. If you fed the model a photograph, a drawing, or a piece of someone’s work as a reference or a style source, say whose it was and where it came from. This applies to your own earlier work as well, where it is a matter of clarity rather than permission.

Screenshots of tools need the tool name and the date you took them. Interfaces are redesigned constantly, and an undated screenshot of a settings panel is worth very little a year later.

Refer to each figure in your text, so the reader knows when to look at it, and keep the labelling consistent across a document.

Privacy, accounts and UiO¶

Start from the university’s own guidance. The AI at UiO pages set out which services are approved for which kinds of material, and what the institution’s position is on the use of AI in coursework. That page changes as agreements change, so check it rather than relying on what a friend told you last year.

In the week before teaching starts, students are usually asked to complete a short AI-literacy onboarding. It covers account setup for the term’s tools, a privacy briefing, and the AI at UiO guidelines for student use of AI. It takes well under an hour, and it exists so that nobody spends week 1 discovering they cannot log in.

Never paste personal data into a commercial tool. That includes other people’s names, contact details, health or student records, interview transcripts, and anything else that identifies a living person. The same applies to unpublished research, whether it is yours, your supervisor’s, or a group you are collaborating with, and to other people’s copyrighted work where you do not have a licence covering this use.

When the material is sensitive, prefer the university service or a model running on your own machine. A local model sends nothing anywhere, which makes it the right default for interview material, drafts of unpublished work, and anything covered by a data agreement. This is a practical reason to learn the local route, not only a philosophical one.

Get consent before cloning any voice or face, including a friend’s, a family member’s, and your own if it will end up somewhere public. Ask in writing, say what the clone will be used for and for how long, and record the answer in your log. A person who agreed to appear in a coursework exercise has not thereby agreed to appear in a public gallery, so ask again if the scope changes.

Running models locally¶

There are four good reasons to run a model on your own machine. Privacy, because nothing leaves the laptop. Reproducibility, because the weights on your disk do not silently change under you the way a hosted service does. Cost, because there is no meter running. And learning, because the moment you have to choose a model size and watch it fill your memory, the abstractions in this book turn into something physical.

A recent laptop in 2026 can do more than most people expect. Small open-weight language models in the few-billion-parameter range run comfortably and are genuinely useful for drafting, summarising, and rewriting. Distilled image models generate at modest resolutions in seconds rather than minutes. Speech recognition runs faster than real time on a laptop CPU, and well on any recent GPU.

What a laptop will not do is match the largest hosted models on hard reasoning, long context, or the polish of the newest image and video systems. That is a real limitation and worth stating plainly. It is also less relevant than it sounds for most coursework, where the constraint is usually your own attention rather than the model’s capability.

The tools page lists current runners and models by category. It is updated more often than this page, so start there for names and links.

your-runner pull <a small open-weight instruct model>
your-runner run <a small open-weight instruct model>

Preparing for the gallery¶

The course has two kinds of deliverable. The semester project is the exam: you perform or install it at the Synthetic Gallery in the exam period, and you hand in a reflection of 1 000 to 1 500 words with your full prompt log. Everything else is an obligatory activity, assessed pass or fail, and all of it must be approved before you can present.

The obligatory activities form a ladder, and each rung is meant to make the next one easier. The weekly log runs all semester. A1, a self-introduction, is due in week 2. A2, a text in your own discipline, is due in week 5. The ethics essay follows in week 7, and A3, a multimodal mini-piece, in week 8. The project proposal is due in week 10, which is where you say whether your project will be a performance or an installation. The project is rehearsed in week 12 and shown at the gallery in the exam period. If you keep the logs, most of the writing for the later rungs already exists in draft.

Performances and installations¶

Performances are five minutes, which is shorter than it sounds. A structure that fits: the brief in one sentence, one artefact shown rather than described, one surprise, one act of your own creative will, and one open question. That is five moves in five minutes, roughly a minute each, and it leaves the audience with something to ask about.

Installations have the opposite problem. Nobody arrives at the start, so the piece has to explain itself from any point. Write a short label, put it where a visitor stands, and prepare a two-minute version of the same five moves for when the panel reaches you.

Prepare the surprise and the act of will before the day. “Where did the AI surprise you?” and “Where did you exert your own creative will?” are the two questions the course keeps returning to, and a vague answer to either is the most common weakness. Point at a specific moment in a specific artefact.

A rehearsal checklist¶

Rehearse in week 12 with the real timings, and check the same list again on the day.

For a performance:

• Run it once against a timer, all five minutes, out loud, without stopping to fix things.
• Test with the projector and the room speakers, not with your laptop screen and headphones. Colours shift, contrast collapses, small text disappears, and a mix that sat well in headphones can lose its bass entirely.
• Do a sound check at the volume you will actually use, and agree who touches the mixer.
• Bring your own cables and adapters, and one spare of whatever connects your machine to the room.
• Have a fallback for every tool that needs the network. A rendered video, a local copy, or an exported audio file will save you when a service is down or the wifi is not.
• Know what you say while something loads. Silence at the two-minute mark is the thing people remember.

For an installation:

• Set it up and walk through it as a visitor would, from where they enter, not from where you stand.
• Check power: how many sockets, how far from the wall, and whether anything crosses a walkway. Tape down every cable that does.
• Test the sound at the level the room will be at when it is full, and use headphones if the piece needs quiet.
• Decide what happens when it is left alone. Does it loop, reset, or need a nudge? A piece that dies after the third visitor did not survive its own exhibition.
• Have a fallback for every tool that needs the network, and a plan for restarting the piece in under a minute.
• Bring signage: a title, the makers, and a provenance card saying which AI tools were used and how, in the form chapter 7 introduced. The card is the part visitors read most carefully.
• Ask how long you have to set up, and arrive with time to spare.

Check every link before you submit. Broken links to a hosted artefact are the single most common failure in gallery pages, usually because a file was shared with the wrong permissions or moved after the page was written. Open each one in a private browser window, where you are not logged in, which is how a visitor will see it.

Build the gallery page from the gallery page template. It asks for the makers, the format, the data types, the tools with versions, your technical needs, the work itself, the brief, the surprise and the will, the provenance, and your consent choice for the public archive. Filling it in early tells you what is still missing from the project, and the technical needs field is what the people setting up the room work from.

Study technique for a flipped course¶

This course is flipped, which means the reading comes before the meeting rather than after it. Read the chapter first, and arrive with one question written down. One is enough. A seminar where fifteen people each brought a real question is a completely different event from one where nobody did.

Work in blocks of about thirty minutes with actual breaks between them, rather than in long unbroken sessions. Reading a chapter of this book twice in two focused blocks will get you further than three hours with a phone nearby, and it is easier to start.

After reading, close the book and explain a concept aloud as if to someone who has never met it. The places where you stumble are exactly the places you did not understand, and they are invisible while the text is still in front of you.

Turn the section headings into questions before you reread. “Diffusion models” becomes “how does a diffusion model turn noise into an image, and why does it work backwards?”. Then answer from memory, and reread only to check.

Use an AI assistant to quiz you on the chapter, then check its answers against the text. It is good at generating questions, and equally confident whether or not it is right, so the checking is not optional. Doing that checking is itself the exercise, since noticing where a fluent answer departs from the source is most of what this course is trying to teach you.