ai curriculum

A plain explanation of tokens, probability and why the same question can produce different answers on different days.

The group deliberately causes the model to invent facts, miscount and agree with a statement that is wrong.

Participants classify real internal documents and decide what may and may not be entered into a prompt.

Each participant picks three tasks from their own week and plans how to approach them.

The parts of a working prompt, applied to tasks participants bring from their own roles.

Participants bring a prompt that is not working. The group rewrites it and compares results side by side.

What to include in the context window, in what order, and what is better left out.

Chaining and reasoning budgets, then building a shared prompt library with owners assigned.

Engineers complete timed tasks on their own repository before any AI tooling is introduced.

Claude Code, GitHub Copilot and Cursor configured against the real codebase and its conventions.

A small ticket worked through live, with failure modes pointed out as they appear.

How to brief a model so that it produces correct code on the first attempt.

Generating tests, then using mutation testing to check the tests actually catch defects.

What to look for in code you did not write, including invented APIs and unstated assumptions.

Each engineer takes a genuine backlog item through to a pull request ready for review.

The team writes its own rules for AI use, including the work it will not use AI for.

Define the feature, then write forty test cases describing what good output looks like.

Build the feature to a first working version, including structured output and tool use.

Test for prompt injection, define refusal behaviour, handle errors and set a cost ceiling.

Deploy behind a feature flag with monitoring in place, then demonstrate it to the group.

Participants examine their own document set and identify the problems it will cause.

Splitting documents sensibly, adding metadata, and building the first index.

Connecting retrieval to a model to produce answers that cite their sources.

Adding keyword search and a reranker, measuring the improvement at each step.

Building a scorecard that separates retrieval problems from generation problems.

Teaching the system to say it does not know, and treating that as correct behaviour.

Building the loop by hand without a framework, covering tools, termination and error handling.

Making an agent resume correctly after being interrupted partway through a task.

Connecting to existing MCP servers and diagnosing integration problems.

Each participant exposes one internal system as a set of tools.

Limiting what an agent can reach, and gating actions that cannot be undone.

Tracing a run, reconstructing a failure from the logs, and capping spend.

Each agent runs against a task chosen by the group rather than by its author.

Turning a vague expectation into written criteria that can actually be tested.

Collecting one hundred real cases, including the ones the system currently gets wrong.

Running the test set for the first time and reviewing the result honestly.

Using a model to grade output, then checking that it agrees with human reviewers.

Wiring the test set into the pipeline so that a drop in quality blocks a release.

Mapping assets, attackers and entry points for one of the organisation's live systems.

Attacking a system the participants built, using both direct and indirect injection.

Combining private data, untrusted content and an outbound channel to extract information.

Permission escalation, tool misuse, and driving up cost through repeated calls.

Reviewing external MCP servers, skills and models as potential routes in.

Documenting findings with severity ratings, owners and agreed fix dates.

One route for every model call, with keys, quotas, logging and provider switching.

Examining participants' own telemetry and reducing cost and response time in the room.

Moving to a new model version using shadow traffic and a staged rollout.

The group works through a scenario in which the model is confidently wrong at scale.

Scoring a real backlog on error tolerance and whether correct answers can be checked.

How variable output affects estimates, testing, support and release planning.

Writing a specification in which acceptance criteria are expressed as test cases.

Reviewing how real products handle citations, consent and letting users edit output.

Defining metrics that show whether people accept the output, not just open the feature.

Planning the rollout and agreeing in advance what would cause the feature to be withdrawn.

Designing for confident, uncertain and incorrect output rather than assuming success.

Reviewing real AI products for how they handle trust, disclosure and recovery.

Showing progress, allowing interruption, requesting approval and supporting undo.

Building a prototype and putting it in front of real users before the session ends.

A direct assessment of current AI capability, separating evidence from vendor claims.

Every live and proposed AI initiative laid out on one wall, scored and ranked.

Working through the real decisions using switching cost, differentiation and time to value.

Selecting three initiatives with named owners, dates and agreed stopping conditions.

Finding and recording the AI already in use, including tools adopted without approval.

Applying EU AI Act risk categories to the organisation's actual use cases.

Reviewing current practice against ISO 42001 and ranking the gaps by effort to close.

Writing an acceptable use policy short enough to read and specific enough to apply.

Configuring projects, artifacts, memory and connectors as a proper working environment.

Working with large amounts of context, then producing finished business documents.

Installation, permissions, memory files, and a real ticket taken through to review.

Writing, packaging and distributing a skill the rest of the team can install.

Connecting internal systems, then running work in parallel across a large task.

Building a production agent, and configuring seats, data controls and audit logs.

Participants map a routine they own and identify the step AI can take over.

Trigger, condition, action and output, built and running before the session ends.

Error paths, retries, approvals, and what happens when it runs unattended overnight.

Documenting the automation, assigning an owner and defining how success is measured.

Using AI to write queries against the warehouse, and the guardrails this needs.

How an incorrect figure reaches a board report, and the checks that prevent it.

Turning analysis into a written argument without the model inventing the reasoning.

Rebuilding a monthly report with AI, keeping a human review step in place.

Using AI for account and prospect research that is genuinely better, not only faster.

Where personalisation at scale becomes misleading, agreed as a team standard.

Running content from brief to publication at volume, with brand and accuracy checks.

Deciding what AI answers directly and when a customer must reach a person.

Extracting, comparing and reconciling information across the organisation's own files.

Designing the checks an auditor will expect, before the process goes anywhere near live.

Extracting clauses, flagging risk and producing first drafts, with review requirements set.

Audit trails, retention periods, and handling privileged or confidential material.

Rebuilding job descriptions, screening and interview design with AI support.

Running a fairness test on the workflow the group has just built.

Creating personalised onboarding and learning content that is genuinely useful.

Designing an assistant for staff questions, with escalation and confidentiality rules.

The group maps its current lifecycle honestly, marking which phases have already changed and which are unchanged from three years ago.

Why agents produce most of a feature quickly then stall, and what that means for how work is split.

Moving from writing software to designing the system that produces it, and what that changes about the job.

Rewriting a real ticket as a specification precise enough for an agent to complete without coming back for clarification.

Keeping code review meaningful when most code is generated, and deciding what to read closely versus automate.

Which checks must pass before work moves on, and which of them a person still has to hold.

Redesigning QA around owning the evaluation system, and moving release decisions to automated gates.

The team writes down the lifecycle it will actually run, names owners for each gate, and sets a date to review it.

Why an agent is a model plus everything around it, and which of those parts your team already owns without realising.

Writing the instruction file for a real repository, then testing whether the agent actually follows it.

Separating deterministic constraints from organisational requirements such as data handling and approvals.

Turning an existing team practice into a packaged skill, then installing it for someone else to use.

Putting specifications, rules and skills under version control, and linting them against each other.

Writing code that runs at fixed points in the agent lifecycle, for the standards agents keep forgetting.

Limiting what an agent can reach, and testing whether those limits actually hold.

Building evaluation across four layers, from checking skills for conflicts through to measuring whether real tasks succeed.

Tracing agent runs, spotting quiet drift, and attributing token spend to the work that caused it.

Building perceive, plan, act and observe without a framework, so the mechanics are visible rather than hidden.

Deciding when an agent stops, and what happens when it will not.

Wiring compilers, tests and linters in as feedback, so the agent corrects itself before a person has to.

Detecting when a run is going wrong early, and pushing it back on track without restarting.

Rebuilding the same work as nodes and edges, with branching, joins and shared state.

Running branches at once and synchronising the results, then measuring whether it was actually faster.

Running planning, implementation, testing and review as a chain, with clarifications flowing through a person.

Deciding when a person intervenes, based on confidence, ambiguity, risk and policy, and automating what is left.

Running several agents at once and coordinating them through shared context rather than through you.

The practical tooling for seeing many runs at once, and the failure modes that only appear at that scale.

Mapping your current pipeline and marking every stage where security is manual, late or absent.

Secret scanning and code scanning in the editor and at commit time, tuned to keep false positives low.

Scanning Terraform and Helm for misconfiguration, and separating deliberate overrides from real mistakes.

Auditing container images continuously, and keeping base images current without stalling releases.

Behavioural baselines for running workloads, and detection that finds problems without burying the team in alerts.

Assembling the stages into one pipeline, then measuring what each stage catches that the previous one missed.

Building a picture of normal behaviour for workloads, and detecting deviation from it at runtime.

Generating policies from observed traffic rather than writing them from scratch, then tightening them safely.

Expressing policy as code and enforcing it before workloads reach the cluster.

Tuning enforcement so that security stops being the reason deployments are delayed.

Deciding what is standardised centrally and what teams choose for themselves, and where that line usually sits wrong.

Making the supported route faster than working around it, because adoption follows convenience rather than mandates.

Setting up a sandbox where people can try things safely, and choosing the first projects to run in it.

Embedding champions in teams, shipping ready made templates, and measuring uptake honestly.

Building a network and training it, covering gradients, loss, optimisation and the failures that look like bugs.

The same model built in both PyTorch and Keras, so the differences are visible rather than theoretical.

Convolutional networks and transfer learning, applied to a real image set the group brings.

Handling ordered data, and why transformers replaced recurrent networks for most tasks.

Multiple GPUs, mixed precision and checkpointing, with the cost of each measured.

Recording every run so that results can be compared, reproduced and defended later.

The governance and cost arguments for running AI inside the warehouse rather than exporting data to it.

Running embeddings and inference in SQL, on the group's own tables.

Building an agent that queries warehouse data, with access controls the data team accepts.

Controlling spend, auditing access, and deciding what should never be queried this way.

Working through fairness, consent, transparency and displacement using cases from the organisation rather than the news.

Tracing how a reasonable decision produces an unfair outcome, and where in the process it could have been caught.

Running a fairness check on a workflow the organisation already uses.

Turning the discussion into positions and guidance specific enough for teams to apply without asking.