The material,delivered live.

Buying every engineer a licence is the easy part. This talk is about the rest of it: what actually happens when you try to move an entire engineering department to AI-native practice, and which of the obvious plans fail.

It is the material behind Chapter 10 — shared context, standardised stacks, rational resistance, and metrics that measure capability instead of activity — told from inside a real adoption programme.

The short version of the book. The role shift from implementer to orchestrator, the four pillars the practice rests on, and the honest answer to the question everyone in the room is actually asking.

A lot of teams are working on the same unsolved problem: exposing all of a company's data to an agent. This is the architecture a small team of senior engineers built over almost a year to do it.

Design choices that gave real semantic meaning to OpenSearch fields, how unwritten knowledge from subject-matter experts gets collected and used, how the system is evaluated, and the permission model that keeps it safe. What started as a client project became a harness for very large clusters.

A hands-on session on the part of Chapter 8 that people skip: how you actually know an AI system is getting better instead of just different. Building an eval suite, reading its failures, and wiring it into a pipeline.

Most engineers are using AI the wrong way. They paste code into a chat, accept whatever comes back, and ship it. That works fine, right up until it doesn't. The AI makes things up, the code ends up doing something different from what was asked, and nobody can figure out why.

This talk is about what actually changes when you stop treating AI as a magic box and start treating it like any other tool that needs decent inputs to produce decent outputs: enough context that the agent does not guess, a short spec so there is something to check the result against, and a review you do not skip because a machine wrote the code.

It sounds obvious said out loud. The gap is doing it consistently, and that is what we work through: how spec-driven development, context engineering and verification mechanisms combine to produce production-quality code with AI.

Building an AI agent for a real team is not a prompt problem, it is a systems problem. A practical, production-minded workflow for building an agent using a coding agent, and designing the codebase so the loop stays reliable as complexity grows.

The core pattern is two agents with different jobs: the coding agent is the builder, and the agent you are building is the product. The example that ties it together is self-healing evals, where a failing eval sends the builder agent to the right layer — context, tool contract, or code — and it opens a pull request explaining what changed and what is still missing.

Give an AI access to a real Node.js runtime and things get interesting: it can run code, install packages, generate files, and launch servers on the fly. This talk walks through a Node.js sandbox server powered by the Model Context Protocol.

Fresh Docker containers, npm installs on demand, JavaScript execution, logs and files sent back — all through simple MCP messages. It is the practical companion to Chapter 4.