Skip to main content

Production-Ready Approach With Labs That Actually Ship

Your lab manual becomes the mentor, and your rubric becomes the marker.

CS3042 · Cloud Computing LabWeek 07
Due Fri 23:59

Assignment

Summarise the daily sales drop

A campus store drops a daily sales CSV into object storage.

The finance team wants one JSON summary per day: total revenue,

units sold, and the three best-selling items.

Write a function that runs when the file lands and writes the summary back.

Deliverables

  • A handler triggered by the upload, not a script you run yourself
  • Totals computed from the file, with rows that fail to parse skipped
  • The summary written back to storage as JSON
  • One test that proves a malformed row does not break the run

The checks on the right are published with the assignment, so nobody is guessing what the bar is.

Evaluation checks

0/4 ruled

Handler is triggered by the upload

30
reading the repository…

Totals match the source file

30
reading the repository…

Malformed rows are skipped, not fatal

25
reading the repository…

Summary written back as JSON

15
reading the repository…

Attainment so far

0 of 100 weight settled

0/100

The surface that runs every week, not once a year.

Your lab manual becomes the mentor and the marker

You bring the assignment you already set. We index the manual, the SDK docs and the reference repos into a knowledge graph the mentor agent draws on to answer students' questions well, and every submitted repo comes back scored against your rubric, not ours.

Runs inside
Your existing course
Owned by
The department
Leaves behind
Attainment evidence

How it runs

The manual becomes teachable and the bar gets written down before the session starts.

  1. 1

    Your manual becomes a knowledge graph

    We index the lab manual, the SDK documentation and the sample repos exactly as they are. No new wiki to write, no bespoke course content.

  2. 2

    The graph becomes the teaching assistant

    It answers students in their editor and the browser, grounded in your sources, so a cohort of 300 is not waiting on one demonstrator.

  3. 3

    Your rubric becomes the checks

    Each check carries a weight, where in the code the answer lives, what makes it a pass and what makes it a fail. Students see them, so the bar is stated rather than guessed at.

CS3042 · Cloud Computing LabNew assignment
Week 07
Deliverables0/4
  • Add a deliverable

Drafting. Nothing is visible to students yet.

Publish to cohort
The paperwork

The records are ready when you need them

Marks alone do not say what a student could and could not do, so someone ends up rebuilding that from memory months later. Here every check is recorded as the work is marked, so the record is written while it is still true.

One line per check

You get a result for each check you wrote, not one mark for the whole lab. It is clear which part a student got right and which they did not.

Every score points at the code

Each result names the line that earned it. Anyone reviewing the work later can open the repository and see for themselves.

Yours as a spreadsheet

One file per cohort with every submission, check and result. Download it, keep it, share it with whoever asks.

What they graduate into

The roles hiring right now

These titles barely existed when most syllabi were written. What each one needs is teachable, but only where students integrate, direct agents and ship.

01

Forward-deployed engineer

Sits with the customer and makes it work on their stack.

  • Read an unfamiliar SDK fast
  • Integrate against someone else's API
  • Ship under a customer's constraints

Built by

Labs set on a real SDK, judged on integration rather than output

02

Full-stack product engineer

Owns a feature from the database to the button.

  • Wire services together end to end
  • Make something that runs for someone else
  • Decide the trade-offs alone

Built by

Challenges and hackathons: a repo that works, not a slide that claims it

03

AI integration engineer

Builds with agents, and catches them when they are wrong.

  • Direct an agent to a useful result
  • Review code they did not write
  • Spot a confidently wrong answer

Built by

The mentor in the student's editor, plus a judge that catches confident nonsense

How it starts

One course, one section, one semester

No curriculum committee, no migration, nothing to rip out. A pilot is small enough for one faculty member to run and honest enough to judge on the results.

You bring

  • One lab course, one section, one semester
  • The manual, SDK docs and reference repos you already publish
  • Your rubric, as the checks the judge must rule on

We set up

  • The knowledge graph and the Skill students install in one command
  • Assignment deadlines on the scheduler, reminders included
  • Faculty, HoD and coordinator access, each scoped to what they need

You leave with

  • A scorecard per student, cited to specific lines of code
  • One cohort workbook, exportable, with per-criterion attainment
  • A ranked view of who is actually production-ready