Hands-on training labs
Software Engineering Research Group (UTM SERG)
Training catalogue
Course
Is this computer ready for the course? MAIlab checks what this course’s labs need, from Python and your settings to the models you can call and the tools, and says how to fix anything missing. The same checks run in a terminal:
Copy report gives a short text for the class chat when you ask for help: the checks and your browser ID, never a key.
Send a message. The exact HTTP request, the raw response, the streamed chunks and every retry appear here.
Models read and write tokens, not words. Each coloured chip is one token; · marks a space.
Same meaning, different token counts, different bill.
Everything in one request must fit: system prompt + history + new message + the space reserved for the answer.
The API remembers nothing between calls. Your app re-sends the whole history every turn, so input tokens and cost grow with each turn. A chat app does this for you without showing it.
Example: a Klang Valley clinic with 300 enquiries a day. Change any number.
Set USD → RM to today's exchange rate. Reasoning tokens are billed as output, so set output tokens from a real call.
Every call this browser made: chat, compare, error lab and token counts. Click a row to open it in the Inspector. Other browsers cannot see your log.
The current chat (plus the text in the message box) written as each provider's raw request. Nothing is sent.
Each experiment makes a real request to the provider and model chosen on the left (only the simulated 429s are fake). Predict the first response, then run it. Read the status code before the content.
One prompt, sent to all three providers at the same time with the same system prompt and max_tokens. Each model runs at its default effort.
The parts are assembled into one request. The system field carries the instruction, the output contract and the failure policy. Each few-shot example becomes a user/assistant message pair. The enquiry goes last, inside the input variable.
Paste a reply from MAIlab, Flowise, ChatGPT or a classmate. Code checks it against the current contract in three layers: syntax, schema, business rules. A prompt alone cannot do this.
Expected columns come from the contract's enum and boolean fields. "(any)" means the case does not check that field.
Compare two contracts line by line, then run both on the test set. Accept a change only if nothing that passed before now fails.
The same contract and test set on several models, one run per case. Which is the cheapest model that meets the target?
Copy each block into the matching Flowise node. Node names and fields can vary by Flowise version.
The same ideas with a different interface: nodes become classes, wires become |, side panels become parameters and environment variables, and the chat window becomes a script or a test.
| Flowise node | LangChain (Python) | Where you see it |
|---|---|---|
| Chat Prompt Template | ChatPromptTemplate.from_messages([...]) | prompt below: system message, few-shot pairs, then {enquiry} |
| ChatOpenAI or ChatAnthropic | ChatOpenAI(...), ChatAnthropic(...) | model below; the key comes from an environment variable, never a field |
| LLM Chain (the wires) | prompt | model: a Runnable | chain below |
| The chat window | chain.invoke({...}), run from a script or a test | result below; Module 1's Inspector shows the HTTP request it becomes |
| Structured Output Parser | your own check(), or model.with_structured_output(schema) | check() below: syntax, schema, then business rules |
| Custom Tool | @tool on a typed function; its docstring is the description | Module 3 → Code |
| Tool Agent | create_agent(model, tools, system_prompt=...) | Module 3 → Code |
| Buffer Memory, Redis-Backed Chat Memory | a checkpointer with a thread_id, or your own Redis history | Module 6 → Memory, and giga_pipeline_lab.py in Module 6 → Whole pipeline |
Key terms. Chain: a fixed composition of steps. Runnable: a LangChain object you can invoke; a prompt, a model and prompt | model all are.
Tool: a function with a name, a description and an input schema. Memory: earlier state supplied to later turns.
Common mistakes. Treating code as a different concept: the chain, tool and memory ideas are the same in both. Mixing up cache and memory: a cache reuses a result, memory supplies the past conversation (Module 6). Unpinned versions: the first line of every LangChain snippet in MAIlab names the versions it is tested on, because the APIs change between releases.
Runs the test set against your own Flowise chatflow, straight from this browser, and checks every reply against the contract.
Built from the contract in the editor and a saved test run.
Click Inspect on any test result to see its raw request, response and contract check here.
Each step: observe (what is in context) → plan (the tool call the model proposes) → act (the harness checks it, then runs, denies or asks a human) → update (the result goes back). The model proposes; the harness decides.
Each case uses the design-studio starter and the mode chosen on the left. Predict first, then run it with the harness and again with only a prompt guardrail. A prompt request alone is weaker than a check in code.
The same tools, written in each provider's raw tools field. Limits such as "at least 1" go into the description: the schema tells the model, and the harness enforces it.
The same scenario, run live on all three providers. Nobody can approve here, so a tool that needs approval ends the run.
Click Inspect on a live step to see its raw request, with the tools and the whole conversation so far.
| Syntax error (not valid JSON) | |
| Schema error (wrong fields or types) | |
| Business-rule error | |
| Tool outage | |
| Temporary API error (timeout, 429, 5xx) | up to 3 attempts with backoff, then human review |
| Wrong API key (401) | stop and alert: retrying cannot fix it |
| Limit reached, or a tool needs approval | human review |
Each case runs through the agent harness with the fallback policy on the left. A case passes only if the agent did the right thing: the right route, the right amounts, and no forbidden action. Failure tests switch on a planned failure and check that the fallback catches it.
The same eval set on two versions. The demo is set up: A is the studio agent with a typo in its price data (poster RM100), B is v1.0. Accept a change only if nothing that passed before now fails.
Models are used only in live mode (set on the left).
What a real system would send to its monitoring: one line per failure, with the error class and the route. Credentials and the customer's data stay out.
Click Inspect on a live case to see the raw request and response of its first model call.
Answer each quick check before you build.
You build software by directing an AI coding agent that reads files, edits code and runs commands. You set the goal, approve the plan and verify the result.
A freelancer asks Claude Code to add SST to a quote calculator, reviews its plan, then checks the tests and the diff before committing.
Same observe → plan → act → update loop as the agent in Module 3. The tools are now your project: files, the terminal and the tests.
| Module 3 harness | Claude Code |
|---|---|
| System prompt | CLAUDE.md: standing instructions, every session |
| Tool permission: allowed / approval / denied | Permission rules: allow / ask / deny |
| Approval pause | Permission prompt, and plan approval in plan mode |
| Limits (steps, tokens, time) | A time box, small steps, /clear between tasks |
| Module 4 eval cases | Acceptance tests, agreed before the change |
Accepts whatever the AI produces. 300 generated lines, unread, because the app seems to run.
Keeps engineering discipline: clear requirements, small steps, tests, review and version control.
The agent only knows what it can read. A CLAUDE.md file in the project root gives standing instructions (commands, conventions, rules) that load in every session. It is committed to Git, so it never holds secrets.
Claude Code asks before it edits files or runs commands, unless you allow them. Plan mode is read-only. CLAUDE.md is guidance; permission rules are the hard limits.
Allow pytest to run without asking, but keep approval for git push and for deleting files.
An agent saying “done” is not evidence. Passing tests, a readable diff and a run of the real program are. Agree the tests before you ask for the change: you own the requirement and the acceptance test.
compute_quote([("logo", 2)]) must return subtotal RM600.00, SST RM48.00 and total RM648.00.
| Everyday idea | Technical concept |
|---|---|
| Contractor, fast on site | Coding agent |
| Agreed drawings | Approved plan |
| Site rules | CLAUDE.md + permissions |
| Inspection before paying | Tests and diff review |
Where it stops working: a contractor carries professional liability. The agent carries none, so the reviewer does.
| Mistake | Do instead |
|---|---|
| Accepting changes without reading the diff | Review every diff. Ask Claude to explain any line you do not understand. |
| One huge, vague prompt | Break the work into small, testable steps, and plan first. |
| Secrets or client data in CLAUDE.md or prompts | Keep keys in environment variables. CLAUDE.md is committed to Git. |
The human approves every stage boundary. Loop back to Plan whenever verification or review fails.
1 · Explore. “Explain this project and how to run its tests.” Claude reads three files and runs pytest: 1 test passes.
2 · Plan. In plan mode Claude proposes: return a dict, add an SST rate, validate inputs, add four tests. Human decision 1: the educator edits the plan to keep the rate in catalogue.json.
3 · Implement and verify. Claude edits quote.py, adds tests and runs pytest: 5 passed. It updates the old test to the new return type.
4 · Review and commit. Human decision 2: the educator spots float rounding and asks for Decimal. Claude updates, re-runs the tests and commits “Add 8% SST and input validation”.
Those two decisions are the engineering. The next step shows why decision 2 matters.
| Action | How in Claude Code | Why it matters |
|---|---|---|
| Start a session | Run claude in the project folder | The agent works on this project only |
| Create project memory | /init writes a starter CLAUDE.md | Standing rules for every session |
| Check what loaded | /memory and /context | See which CLAUDE.md files are in context |
| Plan before editing | Shift+Tab to plan mode, or /plan | A read-only proposal you approve |
| Stop or redirect | Press Esc | Interrupt a wrong direction early |
| Fresh start | /clear | Drop old context between tasks |
| Control actions | Permission prompts and /permissions | You decide what runs and changes |
Shortcuts can change between versions. Check the Claude Code docs at code.claude.com.
Change the numbers. Floats store money in binary, so some amounts come out a hair off, and how you write the formula changes the answer.
Rounding a float at the end hides this until it doesn't: in Python, round(2.675, 2) gives 2.67, because 2.675 is stored as 2.67499999….
CLAUDE.md starts with what the project is, so the agent does not have to guess. Use the Quote helper lab, or press New project above and describe your own system.
Changing the stack on a new project swaps in that stack's commands, permissions and test file. Once you have edited them, use the button instead.
/init in Claude Code? Paste the CLAUDE.md it wrote, and MAIlab fills the steps from it.Sections MAIlab does not recognise are kept as they are, at the end of the new CLAUDE.md.
The commands the agent uses to install, test and run the project. MAIlab chose them from your answer in step 1: you do not need to write any.
Things Claude cannot guess, like how to run the tests. Write the exact command, pytest -q, never “run the tests”. The test command is the one the agent uses to check its own work.
The main parts of what you are building, in your own words. The agent reads this first, so it knows what matters.
Where things live, so the agent reads the right file first. One line per file or folder that matters; skip the obvious. Starting from an empty folder? List the layout you want, or leave this empty and decide it in Plan.
Project conventions that differ from the defaults. Write each rule so a reviewer can check it against the diff. “Write clean code” cannot be checked; “Use Decimal for money; round to 2 dp” can.
Red lines the agent must respect. Tick the ones you want: MAIlab writes the permission rule behind each one, so a never is blocked and an ask makes the agent stop for your click.
Clear red lines. CLAUDE.md is context, not enforcement: the agent usually follows it, but nothing stops it. Back each line that matters with a permission rule: deny blocks the action, ask makes Claude stop for your click.
Agree what “done” means before the work starts. Write examples in plain words. MAIlab writes them as tests that fail for now; in the session's first step the agent turns each one into a real test, and you approve them.
Agree the acceptance tests before you ask for the change. MAIlab writes them as a test file you commit first. They fail until the change is made; the change is done when they pass, and the agent is told never to edit them.
How much the agent may do on its own. You can change this later, and Shift+Tab switches it during a session.
Hard limits, in .claude/settings.json. Claude Code checks deny first, then ask, then allow. Anything not listed asks you. Project rules apply once you trust the folder.
Claude Code may start in another mode unless the settings say "defaultMode": "default". Shift+Tab switches modes during a session.
Bash rules match the command text, so they are not a security boundary: git -C . push slips past Bash(git push *). Use them to keep the agent honest, not to stop an attacker.
Extra helpers. Leave them off for your first session; turn one on when you know why you want it.
Each one is a real Claude Code file. Leave them off for your first session; add one when you know why you want it.
Never one huge, vague prompt. Write the change you want, then split it into small steps that each end with a test run. MAIlab turns this into the session's prompts, using your commands and rules.
Everything on the Files tab, in one zip. Unzip it into your project's root folder (the starter: an empty folder called quote-helper).
Unzipping into an existing project replaces any CLAUDE.md and .claude/settings.json already there. If you have your own, merge by hand.
Tick each one as you do it. Your ticks are saved with the project.
Follow it stage by stage, with Claude Code open beside it. Each stage shows what to type, with Copy buttons; paste the evidence where it asks, and tick the checkpoint before you move on. The Evidence tab reads what you paste.
What to hand in: your CLAUDE.md, the approved plan showing your edit, the test evidence and a reflection. The reflection is assessed most heavily: it shows whether you supervised the agent or just accepted its output.
Checking Redis…
Only keys with your browser's prefix. Inspecting them is not logged below.
Every command MAIlab sent for you, newest first, as redis-cli shows it.
Build the key, then GET it. A hit returns the stored, validated result. A miss calls the model, checks the answer, and stores it with SET key value EX ttl.
Each turn: identify the session, load its history (LRANGE), pass it in with the new message, check the reply, save the pair (RPUSH, LTRIM) and refresh the TTL (EXPIRE). Storing alone does not make the model remember.
A shared counter per scope and window. The Lua script increments and sets the expiry in one atomic step, and every blocked caller is told when to retry.
One turn of the studio assistant: rate limit → load history → cache → agent → validate → store → save. On a Redis failure it returns a review result and an error class, without keys or client data.
giga_pipeline_lab.py is this pipeline written with LangChain: create_agent with the read-only lookup_price tool and a Quote schema,
then the same cache key, history, atomic rate limit and safe fallback, and the same nine tests. send_quote is never given to the agent.
Run it on your own laptop, against your own Redis.
macOS
python3 -m venv .venv .venv/bin/pip install langchain==1.4.6 langchain-openai==1.7.2 langchain-anthropic==1.7.6 redis==8.1.0 pydantic==2.14.1 .venv/bin/python giga_pipeline_lab.py test
Windows
py -m venv .venv .venv\Scripts\pip install langchain==1.4.6 langchain-openai==1.7.2 langchain-anthropic==1.7.6 redis==8.1.0 pydantic==2.14.1 .venv\Scripts\python giga_pipeline_lab.py test
test runs the nine tests with a free stand-in model, so no key is needed. demo runs the normal and failure cases and the cache and session traces
with your own model: set MODEL_NAME and its key (the file's first lines list OpenAI, Claude, DeepSeek and Ollama), or MODEL_NAME=stand-in to see them for free.
Paste the output into your evidence pack. These are the versions MAIlab tests it on (record tested versions).
Everything so far ran on the class Redis. Now run the same thing on your own laptop: install Redis, replay the commands in redis-cli, run the self-test, and bring the result back as evidence (a training Redis instance).
Each line is a real Redis command; the ECHO lines print what to look for. Compare your output with the expected output.
The pipeline you ran, as Python with redis-py, and the evidence: package versions, the cache hit/miss trace, the separate-session trace, the tests and your decision checklist.
Studio Reka JB, a small design studio in Johor Bahru, has an AI assistant that answers customer enquiries. You decide what the AI reads before it answers: start with Start here on the right.
What the AI’s search can find. Untick a document to hide it from the search (the search index). Two are out of date on purpose, and one is in Bahasa Melayu.
The documents are cut into short pieces. The search scores each piece against the question, and only the best few go on the sheet.
The AI answers only from the pieces it was given, and names the piece after each fact, like [price-2026#1]. Code then checks the sources and the numbers. With nothing useful on the sheet, the right answer is “I do not know”.
A customer chats for 15 messages. The deadline comes in message 2 and the budget in message 4. Each way puts a different part of the chat on the sheet: the chart shows the words it costs on every message, and the table whether the last message can still see the facts.
One fact (“the client’s maximum budget is RM450”) is hidden in a long pile of past quotes: at the start, in the middle or at the end. Then the AI is asked for it.
The Module 3 agent quotes one poster, first with its 3 tools, then with 9 look-alike tools added. The whole tool list goes on the sheet at every step. Does it still pick lookup_price, and what do the extra tools cost?
A long, unchanging start (the instructions, the documents and past quotes) is sent twice; the second call should read it from the provider’s cache. Then the time is put at the very top, and the cache stops matching. Unchanging first, changing last.
Write your design down: what goes on the sheet, in which order, how much, and why. It starts from what you set in steps 1 to 5. Export it as JSON, or as Python that builds exactly this sheet.
Bring in what you built in Modules 2–7. Each one fills its stage, and goes into the build pack as it is.
Fourteen stages in four phases: define the idea and its requirements, decide the stack, the quality and the core modules every SaaS needs, design the AI (only when a feature uses it), then ship. Each stage ends in a file your coding agent will read, with blueprint.json as the source of truth. Click a stage to see what you decide there and why.
Drawn from your own decisions: a step you chose not to have is grey. Change a decision on the Blueprint tab and this changes with it.
What one task costs you, what a customer costs you a month, and prices that leave a margin. Token prices come from models.json; the exchange rate is yours to check today.
Fixed costs: server, domain, email, tools. Payment fee: check your gateway’s own rate. The margin is what is left of each ringgit after the tokens and the fee. Price from value: a customer compares your price with what the problem costs them, not with your token bill.
Code checks your requirements, stack, quality targets, permissions and AI decisions against each other and against the lessons of Modules 1–7, as Module 5 checks a Claude Code setup. Fix the errors before you build.
One live call: the whole blueprint goes to a model that looks for risks the checks above cannot see. The cost is shown before you send.
Everything you decided, as files any coding agent reads: blueprint.json (the source of truth), AGENTS.md for Codex, Cursor and most agents, CLAUDE.md, GEMINI.md and Copilot instructions that point to it, the docs, and a pending test for each acceptance criterion. Unzip it into an empty folder, open the folder in your coding agent and start with milestone M0 on the Build guide tab.
One milestone per session. Paste the prompt into your coding agent; it plans, you approve, it writes the tests first, then the code. When the tests pass, paste the evidence here.
The trainer passcode is TRAINER_PASSCODE in this exam server's .env.
The studio is the course case. My own business builds the same agent for your business: your price list, skills and tools.
One folder per skill. Until the agent loads one, it sees only the names and descriptions.
A skill packages the know-how for one kind of task: a name, a description of when to use it, numbered steps and optional files. An agent works toward a goal by choosing which of its permitted skills and tools to use, inside a harness that sets the rules.
A prompt is one instruction. A tool is one function the app runs. A skill bundles know-how for a task: instructions plus the tools and files it needs.
She keeps a binder of procedures: booking, billing and panel insurance claims. She reads the tab labels and opens only the procedure each patient needs.
The same kind of agent for your own business: its price list, its skills and its tools. It is kept apart from the studio lab: switch with Starting point on the left.
Keep each business you build: Save set on the left stores it under a name, and Load brings it back, so a learner can keep several case studies and switch between them.
One file, catalogue.json, that the skills refer to, and the lookup_price tool reads. Never copy prices into a skill.
Writes classify-enquiry, draft-quote, bilingual-reply (when clients write in BM) and make-booking (when an action needs approval), the agent's instructions, samples and a test plan, in your business's words. Free and the same every time: then edit them.
Data only, as in Module 3: a look-up table, a calculator formula, or an action that never leaves MAIlab. Every call goes through the harness: allowed runs, needs approval waits for staff, denied is refused.
The JSON the agent finishes with, checked in three layers like a Module 2 contract.
Keep each skill to one task. If the steps need “and also…”, split it into two skills. The name and description are always visible to the agent; the steps load only when it uses the skill.
Run 3–5 sample requests on this skill by itself and check each output. A wrong answer is easier to trace to one skill. Each test records the version; change the skill and test again.
Test each skill alone first, then the agent.
Least privilege: read-only first. load_skill and read_file are always there: they only read the skill library.
The harness checks every call, refuses anything that sends, and logs every step. Module 3 shows a full harness with approvals.
The model sees the instructions and the skill index, calls load_skill for each skill it needs, then read_file and lookup_price. Every reply is a draft for staff: nothing goes to the client.
Record which skills the agent actually used. A right answer from the wrong skills is still a fail. Test requests that need 0, 1, 2 and 3 skills.
This lab runs in Claude with Skills turned on, in Claude Code, or in Flowise. The same SKILL.md files work in the first two.
A project folder: each skill in .claude/skills/<name>/SKILL.md with its files, the agent instructions and the test plan in CLAUDE.md. Unzip it into a folder, run claude there, and try the five requests.
One zip per skill, with the skill's folder at its top. Upload each under Settings → Features (Skills, with code execution on). Only name and description are in the frontmatter, as claude.ai requires.
The reflection counts most: it shows that descriptions control when a skill is used.
After (its description now):
Pusat Tuisyen Cemerlang, a tuition centre in Johor Bahru and Kulai, answers parents on WhatsApp. You build the Johor Bahru assistant that finds the right page in its documents and answers only from it: start with 1 · Start here on the right.
Each one has labels (metadata): its branch, current or out of date, its language, and where it came from. One was copied from Facebook and never checked.
It is cut, labelled and searched like the others, and saved in this browser. A line that starts with # is a heading.
Two in Bahasa Melayu, one that needs two documents, and two that no document answers. For each: were the right pages handed over, how soon, is the answer right, and does it stay with its sources?
Each case starts from a good set-up (cut by paragraph, both searches, every filter, a second reading, three pieces, the rules on) and breaks one thing.
Write your design down, from what you set in steps 2 to 6, with a reason for each choice. Export it as JSON (Module 8 imports it into stage 9), or as one Python file that runs the same pipeline and tests it, with nothing to install.
Studio Reka JB uses Claude Code, Claude Desktop and a Flowise assistant, and each one needs the same prices. You build one MCP server for all of them, plug MAIlab’s agent into it, then your own AI app: start with 1 · Start here on the right.
Each one runs on this computer at its own address (Streamable HTTP). Steps 2, 3 and 5 use the one you choose.
The server labels each tool; the app decides. The starting point follows the server’s labels because you built this server. For a server you did not build, start from “a person approves”.
Run the agent to see the tools as the server sends them, and as Claude and OpenAI receive them.
Step 7 of 8 (MCP in your own system)
Write your server down: what it offers, what each app may do with it, how apps connect, and the checks you keep. Export it as JSON, or download the server as one Python file.
Kafe Senja wants a logo and a poster, and 200 A3 posters printed by Friday, with the reply in BM and English. Studio Reka JB’s agents share the work, and the printing goes to another company’s agent: start with 1 · Start here on the right.
The same request and pattern, run both ways.
Step 7 of 8 (orchestration and A2A in your own system)
Write your design down: the pattern and why, what each hand-off carries, the merge checks, the limits, and which other companies’ agents you trust. Export it as JSON, or download it as one Python file that runs it and checks it.
Tick a constraint to add it to the prompt; untick it to take it out.
Step 7 of 8 (your own folder, Git and assistant)
The files a marker opens first: what it is, how to run it, the stories, every prompt with its reason, and the page itself. Name the AI tools you used: the course asks you to say so.
Only for “Ask the AI to fix it” in step 4.
Step 7 of 8 (issues, failing tests and node --test on your computer)
What you found, what you fixed, and which test guards each fix. Then three questions the course asks you to reflect on.
For step 5, Generate from the contract.
The AI’s first draft. Change it here: MAIlab writes the SQL from this form.
Tick a constraint to add it; the contract is added from step 4.
Step 7 of 8 (a real repository: backend, frontend and docs)
Everything the backend and the frontend are built from, and the code generated from it. It downloads only when no secret is left in the code.
Opening your portal…
Step 7 of 8 (FastAPI dependencies, Pydantic, pytest and Playwright on your computer)
Each rule, the tests that catch it breaking and whether it is fixed; each failure case, predicted and seen. The tests download for pytest, with a Playwright test for your own page.
For step 4, The run, and the agent’s answer to your review.
The plan the AI suggested. Each row is one task: what it is, which criteria it serves, which files it changes, and the test that proves it.
The AI’s suggestion: allow everything, so it never has to stop and ask.
Step 7 of 8 (a real coding agent, an issue and a protected main)
Everything a real agent needs to work in the tracker the way yours did here, and the evidence of how it went. It downloads only when no key is in it.
For step 3, Run the team. A real model plays each agent in its own conversation.
The AI’s suggestion: every agent gets every tool, no round limit, no team rules.
A recorded practice run that ended approved, yet BC2 is broken. Click the step where it went wrong.
Step 7 of 8 (subagents, permissions, hooks, a turn limit and MCP)
The three agents for Claude Code with your tools and rules, and the evidence of how the team ran. It downloads only when no key is in it.
Nothing checks that a student cannot grade. Write the test that fails when one can.
The AI’s workflow, as a form. MAIlab writes ci.yml from it.
Step 7 of 8 (GitHub Actions, branch protection, gitleaks and Dependabot)
The portal as a repository you can push to GitHub, with your workflow and its settings. Its tests run with pytest as they are, so the first run can go green. It downloads only when no key is in it.
Step 7 of 8 (Docker, a staging host, a deploy job, migrations and rollback)
The release written up end to end, and the files to deploy Lab 7’s portal repository for real. It downloads only when no key is in it.
For steps 3 and 4: who writes the answers.
Rank the four candidates for each opening, 1 for the most likely, then compare.
Four answers from other prompts. Each has one problem: find it against the situation on the left.
Step 7 of 8 (ChatGPT, Claude, Gemini or Microsoft Copilot)
Your final prompt as something you can reuse: the facts that change become blanks, and the criteria travel with it.
For steps 2 to 5: who answers. Step 6 is practice only.
Every enquiry, student, meeting and figure in this lab is invented. Use real ones only in your own assistant, with names removed.
The office’s tracker needs: .
Practice only: MAIlab’s model calls carry text, so a stand-in reads these images. Download one and try it in your own assistant on step 7.
Step 7 of 8 (few-shot prompts, tables, chains, self-checks and images in your assistant)
This lab’s prompts, as you wrote them, ready to reuse. The library is kept in this browser: download it, and load it back on another computer.
For every step: who writes the answers.
All three readers:
Both summaries:
The source (MAIlab adds it after your prompt)
Step 7 of 8 (ChatGPT, Claude, Gemini or Microsoft Copilot)
This lab’s prompts as you wrote them, ready to add to your library, with the faculty glossary and the habit of removing personal data.
For every step: who answers.
Every claim, staff member, student, survey answer and number in this lab is invented. Real forms and data go only into tools your university approves for them.
The five questions (MAIlab adds them too)
The dean’s questions (MAIlab adds them, and the survey, after your prompt)
Message 4 carries made-up personal data on purpose, to test the refusal. In real use, not pasting is the control: by the time an assistant refuses, the data has already reached the provider.
Step 7 of 8 (PDFs, spreadsheets, data-analysis tools and custom assistants)
Everything in your library, ready to share: colleagues load the file into their own MAIlab, and merging keeps both versions when a prompt differs.
Who answers; OpenAlex is real either way.
MAIlab adds six included abstracts (S01, S04, S05, S17, S32, S34) after your prompt. Fields: design, sample, models, metrics, finding.
Step 7 of 8 (OpenAlex, Scopus or Web of Science, Zotero, and your own reference list)
This lab’s prompts as you wrote them, with the checks that go with them, ready for your own review.
For codebook and coding-reliability approaches; reflexive thematic analysis codes differently and does not measure agreement.
Who answers; MAIlab’s checks are the same either way.
Step 7 of 8 (your transcripts, your data in Python or R, your draft, your rules)
This lab’s prompts as you wrote them, with the checks that go with them, ready for your own research.
Who answers. A plan records which, and its runs keep to it.
A real judge runs only in real-model mode; by default it is a different model from the experiment’s.
Step 7 of 8 (a real model, OSF, and your own results)
This lab’s prompts and plan as you wrote them, ready for your own experiments.
Who answers; the checks are the same either way.
Step 7 of 8 (your own assistant or study)
The experiment report from your records, the robustness checklist, and this lab’s prompts.
Who answers. The model here is the one you try a task on, add on step 4, and ask to read the results.
Calls made at the same time can slow each other down: 1 at a time gives the cleanest latency, 4 finishes sooner.
Prices are in US dollars, as in models.json. Enter today’s rate to see RM as well; MAIlab does not guess it.
The set’s fingerprint (SHA-256):
Prefill reads the whole prompt in one pass, and the model keeps what it has read in a KV cache (the keys and values of every token so far). Decode then writes one token at a time, each one looking back at that cache, so every extra answer or reasoning token adds its own slice of time. A provider also batches calls from many customers on the same hardware: when it is busy, each call gets a smaller share, which is one reason the same call is faster at some times than at others. Prompt caching, which re-uses the cache of a repeated prompt, is measured in Context Engineering (Module 7 of the AI Automation course).
A runs file (benchmark-runs.json) holds the configurations, the task set’s fingerprint and every call. Loading one checks that it answered this task set, then works like a finished run: a trainer can record a real benchmark once and share it.
Carried from step to step, and into the notebook on step 9.
Used only by the teacher on step 7 and the AI’s reading on step 10. The rest of the lab needs no model.
Your own dataset: one item a line, as {"input", "output"}, {"enquiry", "reply"} or {"messages"}, at least 50 and at most 5,000 lines. It replaces the office’s for every later step. A "split" field on every line keeps its own split; otherwise MAIlab splits it 80/10/10.
DoRA splits each weight into a size and a direction and adapts the direction with LoRA, which can come closer to a full fine-tune at the same rank. rsLoRA scales the update by alpha ÷ √r instead of alpha ÷ r, so a high rank still learns. Both are one setting in PEFT’s LoraConfig (use_dora, use_rslora); this lab keeps plain LoRA.
On the attention layers, which every token uses, or on each expert’s MLP; the router is usually frozen, so that training does not upset the balance it has learned. Either way the whole model must be in memory, which is why this lab fine-tunes a small dense model.
Free GPUs are not guaranteed: when Colab has none to lend, try again later. MAIlab cannot run the notebook itself; it never asks for a token and never uploads your data. Uploading the notebook to Colab puts the dataset written into it on Google’s machines, so use your own dataset only if you may share it with Google.
With Ollama running on this computer, the base model (ollama pull qwen3:0.6b) and yours (from the notebook’s optional last cell and ollama create) answer the same test items, one at a time, scored the same way. Free: it runs on this computer.
Who answers, reranks, extracts and summarises. Practice uses MAIlab’s free stand-ins, with made-up names and estimated costs.
The embeddings behind meaning search: MAIlab’s free stand-in, or real ones from OpenAI or Ollama, as in the RAG Lab.
Prices are in US dollars, as in models.json. Enter today’s rate to see RM as well; MAIlab does not guess it.
A runs file (retrieval-runs.json) holds the plan, its fingerprint and every record. Loading one rebuilds it from checked fields; a file made on another question set, corpus or graph loads, but is named, and no control ticks for it.
graph.cypher is one MERGE statement per entity and per relation, for Neo4j; graph.json is NetworkX node-link data. Both are data only.
Who reads the requests, checks them and writes the emails. Practice uses MAIlab’s free stand-ins, with made-up names and estimated costs; a person always decides the edge cases.
Prices are in US dollars, as in models.json. Enter today’s rate to see RM as well; MAIlab does not guess it.
A runs file (recovery-runs.json) holds the designs, their fingerprints, every run’s outcomes and step 5’s trace. Loading one rebuilds it from checked fields; a file made on other requests, times or failure rates loads, but is named, and no control ticks for it.
Practice reads a simulated week of the agent team’s traffic, free. Live reads your own calls from MAIlab’s call log and makes no model calls.
The rollback rule: roll back when a test shows 1.2 is worse; promote only when the tests rule out a quality drop larger than the margin and a p95 rise larger than the allowance; otherwise extend.
Who checks the requests and writes the lessons. Practice uses MAIlab’s free stand-ins, with planted behaviour and estimated costs; a live run is counted, costed and confirmed first.
This browser did not keep E06’s last save: its storage for this site may be full, so this work would be lost on reload. Download memory-runs.json and lessons.json on step 9 to keep it.
Each strategy is one change against the baseline (no memory), with the same corrections, seeds and repeats:
The test: week 3, unseen, after the memo. Week 4 stays locked until a final plan is saved after hygiene (step 7).
Who runs the pilot’s two conditions. Practice uses MAIlab’s free stand-ins from E01, E03 and E06, with planted behaviour and estimated costs; a live pilot is counted, costed and confirmed first.
This browser did not keep E07’s last save: its storage for this site may be full, so this work would be lost on reload. Lock the plan and download prereg.json on step 9 to keep it.
To find current baselines in the literature, PE301 Lab 5 shows how to search it with OpenAlex.
Who runs step 3’s two conditions. Practice uses MAIlab’s free stand-ins from E01, E03 and E06, with planted behaviour and estimated costs; a live run is counted, costed and confirmed first.
This browser did not keep E08’s last save: its storage for this site may be full, so this work would be lost on reload. Download results.csv on step 3 to keep the run.
Step 7 of 8 (Trello, Jira, GitHub Projects or Miro)
Step 7 of 8 (Trello, Jira, GitHub Projects or Miro)
Step 7 of 8 (Trello, Jira, GitHub Projects or Miro)
Step 7 of 8 (Trello, Jira, GitHub Projects or Miro)
For step 6: who writes the drafts.
Step 7 of 8 (Trello, Jira, GitHub Projects or Miro)
For step 6: who writes the tests.
Step 7 of 8 (Trello, Jira, GitHub Projects or Miro)
Step 7 of 8 (Claude on the web, the desktop app or the mobile app)
Step 7 of 8 (Claude on the web, the desktop app or the mobile app)
Step 7 of 8 (Claude with Cowork, on MAIlab's practice folder)
Step 7 of 8 (Claude with Cowork, on MAIlab's practice folder)
Step 7 of 8 (Claude Code on MAIlab's practice project)
Step 7 of 8 (Claude Code on MAIlab's practice project)