Is this computer ready for the course? GigaLab checks Python and its packages, your settings, the models you can call, Redis and the optional 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 (slide 24).
Everything in one request must fit: system prompt + history + new message + the space reserved for the answer (slides 17–22).
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 (slide 24). 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 (slide 30). 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 GigaLab, Flowise, ChatGPT or a classmate. Code checks it against the current contract in three layers: syntax, schema, business rules (slides 40, 129). 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 (slide 46).
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 (slides 48–50). Node names and fields can vary by Flowise version.
The same ideas with a different interface (slides 81–87): 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_day4_lab.py in Module 6 → Day 4 lab |
Key terms (slide 86). 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 GigaLab 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 (slides 49 and 77).
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 (slide 90).
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 (slide 89).
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 (slide 96).
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 slide 132 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 (slide 146).
Click Inspect on a live case to see the raw request and response of its first model call.
Slides 147–149, 153 and 155. 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. |
Slide 150. 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.
Slide 154, human decision 2. 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 slide 157 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 GigaLab fills the steps from it.Sections GigaLab 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. GigaLab 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 (slide 152). 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 (slide 152). 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: GigaLab 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 (slide 152). 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 (slide 149). Write examples in plain words. GigaLab 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 (slide 149). GigaLab 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 (slide 155). Write the change you want, then split it into small steps that each end with a test run. GigaLab 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.
Slide 161: 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 GigaLab 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 (slide 105).
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 (slide 115).
A shared counter per scope and window. The slide 122 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 (slides 144–146): 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_day4_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_day4_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_day4_lab.py test
test runs the nine tests with a free stand-in model, so no key is needed. demo runs slide 146's 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 GigaLab tests it on (slide 86: 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 (slide 143: 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 slide 146 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 failing 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 slides' 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 (slides 56–59).
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 (slide 57).
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 (slide 64).
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 (slide 66).
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 GigaLab. 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 (slide 60). The name and description are always visible to the agent; the steps load only when it uses the skill (slide 61).
Run 3–5 sample requests on this skill by itself and check each output. A wrong answer is easier to trace to one skill (slide 62). Each test records the version; change the skill and test again.
Test each skill alone first, then the agent (slide 62).
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 (slide 65).
Record which skills the agent actually used. A right answer from the wrong skills is still a fail (slide 63). Test requests that need 0, 1, 2 and 3 skills (slide 62).
The slide 68 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.
Slide 69. The reflection counts most: it shows that descriptions control when a skill is used.
After (its description now):