The cover is the talk in one picture: a change an agent wrote, AI-0142, earning its way to production. In the HTML deck its checks complete one by one: the spec is agreed, the tests pass, a person approves the review, and the rollout widens from the team to 1%, 10%, and everyone before it reads Landed. The visual language is the release tooling you already use: checks, pull requests, boards, and deployment rings. Every change, board, and number in this deck is illustrative. No real model, repository, pipeline, or production traffic is connected.

Agents draft fast. Approvals still take evidence, and evidence still takes people. In the HTML deck the drafts pour into their queue in under a second; the shipped changes arrive slowly, one at a time. Seven drafted and two shipped is illustrative, not measured data. Kent Beck draws the line between vibe coding and augmented coding: in augmented coding "you care about the code, its complexity, the tests, & their coverage." Source: https://tidyfirst.substack.com/p/augmented-coding-beyond-the-vibes

Three ways a change turns into regret, each one the question someone asks after the incident. - Can't explain it: fixed by standing instructions, a spec, and a read-back (next slides). - Can't verify it: fixed by tests as the contract and a human approval. - Can't undo it: fixed by rings and a rehearsed rollback.

An instructions file is the context every session starts from, so it stops getting lost between sessions. Nobody should have to repeat the build command or the hard rules. What goes in: build and test commands, conventions, hard rules ("never edit a test to make it pass"), when to ask first, and links to decisions instead of pasting them. Check it in and review it like code. Keep it short: link to docs, and load procedures on demand. File names: AGENTS.md is the cross-tool convention. GitHub Copilot reads .github/copilot-instructions.md, path-specific .github/instructions/*.instructions.md, and AGENTS.md. Claude Code reads CLAUDE.md, and reads AGENTS.md when a project has no CLAUDE.md. Keep it lean: encode what a new teammate would be told on day one, commit the agent's configuration folder, and restart sessions at a stopping point instead of letting the context window fill up.

Every model has a fixed context window, and long sessions full of irrelevant context perform worse. Chroma's context rot research: "model performance degrades as input length increases, often in surprising and non-uniform ways." A session that has tried and failed three times is full of failed attempts. What fills it: the system prompt and tools, instructions files, MCP tool lists, every file the agent reads, and every command's output. - Check usage often. Claude Code: /context. Copilot CLI: /context and /usage. VS Code: the context window control in the chat input shows how full the chat is. - Stop at a natural break. Have the agent write its progress and next steps to a file (progress.md, or ticks in tasks.md), commit, and start a fresh session from it: /clear in Claude Code, a new chat in VS Code. Compaction (/compact, or automatic when the window fills) summarizes instead; a fresh start from your own notes keeps what you chose to keep. - Keep the baseline small: short instructions, few MCP servers, and skills, which load only a name and description until they're used. The meter is illustrative; the segment sizes are not measured. Sources: https://code.claude.com/docs/en/best-practices https://code.visualstudio.com/docs/copilot/chat/chat-sessions https://www.trychroma.com/research/context-rot

One long session that gathers requirements, designs, codes, and reviews mixes all of it in one context. Split the job into roles. Each role is a fresh session with its own prompt, and files carry the work from one to the next: - Analyst: interviews you until nothing is ambiguous, then writes requirements.md. - Architect: reads requirements.md, designs the solution, and writes a spec and small tasks (spec.md and tasks.md, or an OpenSpec change, shown after the agents-and-skills examples). - Worker: one task at a time, tests first, on its own branch. - Reviewer: a fresh session reads the diff and the tests and writes comments.md. The worker addresses them, and the loop repeats until the build is clean and every test passes. You approve every handoff: nothing moves to the next role until you've read the file. Have the model draft each role's prompt for this project, then edit it. Role prompts can live in GitHub Copilot custom agents (.github/agents/), Claude Code subagents (.claude/agents/), or a plain Markdown file any agent can be pointed at.

Turn a recurring role into a checked-in custom agent instead of repeating the same prompt. Give it a purpose, the inputs it needs, a useful output, and a stopping point. "Be a senior engineer" is not a task contract. This is an illustrative VS Code custom agent. Save it under .github/agents/, select Reviewer, and give it the agreed spec, the diff, and existing test results. Its read and search tools let it inspect evidence, not run tests, edit code, or merge. Ask it to identify missing evidence rather than claiming checks it could not perform. Review the findings yourself. The prose guides behavior; the configured tool list and host permissions limit actions. Tool names and agent configuration differ by client. A custom agent is not automatically a fresh context: switching roles in the same chat can retain history. Use a new session or a separate subagent when you want the independent review described in the role relay. Source: https://code.visualstudio.com/docs/agent-customization/custom-agents

A skill packages a repeatable procedure, not another autonomous worker. Its folder contains SKILL.md with YAML name and description fields, followed by Markdown instructions. The name matches the folder. The description says both what the skill does and when to use it. This illustrative release-readiness skill turns the same review into a repeatable checklist. Create references/rollback.md alongside it with the team's rollback checks; the link is an example, not a runbook supplied by this deck. Copilot discovers repository skills under .github/skills/; Claude Code uses .claude/skills/. The core format is shared across clients that support Agent Skills, but discovery paths and tool support vary. Try it with "Review this change for release readiness" and check that the intended skill was selected. Name the skill explicitly if needed. Test both prompts that should trigger it and ones that should not, then refine the description. The Reviewer can use this skill to inspect evidence without gaining edit or shell access. Optional scripts run only if the agent has the tools and permission. Skills do not grant permissions or replace human approval. Review third-party instructions and scripts before use, just as you would any other dependency. Keep stable, always-needed rules in the instructions file. Put task-specific procedures in skills, and review and version them with the repository. Sources: https://agentskills.io https://agentskills.io/specification

Progressive disclosure is the loading model described by the Agent Skills specification: 1. Discovery: the agent starts with the names and descriptions of available skills, so it can decide what is relevant without loading every procedure. 2. Activation: a matching task causes the full SKILL.md instructions for the selected skill to enter context. A description is a routing hint, so write a specific trigger. 3. Execution: the agent reads referenced files or runs bundled scripts only as needed. Activating a skill does not eagerly load every reference, asset, or script. Running a script is not the same as pasting its source into context; its output can still consume it. For the release-readiness example, the metadata helps select the skill, SKILL.md supplies the review steps, and references/rollback.md supplies the detailed rollback checks when needed. A task can use several skills, but each is selected individually, not loaded as one library. Keep SKILL.md focused and link directly to supporting files. Do not hide essential steps in an unreferenced document. Metadata is still a baseline cost, so a giant catalog is not free. This reduces irrelevant context; it does not guarantee correct selection or correct results. Exact discovery and invocation behavior depends on the host. Source: https://agentskills.io/specification#progressive-disclosure

A change is a folder in the repository, not a chat. OpenSpec keeps each one under openspec/changes/<name>/: - proposal.md: why, and what changes - design.md: the technical approach - tasks.md: the implementation checklist - specs/: spec deltas, requirements with WHEN/THEN scenarios marked ADDED, MODIFIED, or REMOVED The loop: /opsx:explore to think it through, /opsx:propose to write the folder, /opsx:apply to work the tasks, and /opsx:archive to move the change into openspec/changes/archive/ and update the living specs in openspec/specs/. GitHub Copilot spells the commands /opsx-propose and so on. Review the folder before any code exists: a wrong requirement is cheaper to fix in the spec than in the diff. GitHub Spec Kit runs the same loop with its own commands: specify, plan, tasks, implement. Sources: https://github.com/Fission-AI/OpenSpec https://github.com/github/spec-kit

Spec-driven development: agree on a written, reviewable spec with the agent before any code exists. Vibe coding loses requirements between sessions; a spec keeps them in the repo. Tool-neutral options: OpenSpec (explore, propose, apply, archive) and GitHub Spec Kit (constitution, specify, plan, tasks, implement). Both install into many agents, including GitHub Copilot and Claude Code; the "Same practices" and "Same guardrails" slides show where each piece lives. A plain spec.md and tasks.md in the repo works too. Try it as two personas: an analyst that interviews you until nothing is ambiguous (requirements.md), then an architect that writes the spec and breaks it into phases and tasks. Read-back: ask the agent to restate the plan, and correct it before code exists, while mistakes are still cheap. The Spec, Build, and Review board slides follow one change, AI-0142. Its card moves from column to column as you advance, and one more check completes on each slide.

Kent Beck's augmented-coding prompt: find the next test, implement it, then "implement only enough code to make that test pass." Red, green, refactor, with a person reading each step. His warning signs that the agent is off track: loops, functionality he didn't ask for, and "any indication that the genie was cheating, for example by disabling or deleting tests." Source: https://tidyfirst.substack.com/p/augmented-coding-beyond-the-vibes Work in the smallest increments you can review like a colleague's pull request: one task, one branch. If the agent makes a mess, reset the branch and start a fresh session. Treat the existing tests as the contract. A change to an assertion is a change to the requirements, so it needs its own review.

Whoever wrote a change shouldn't be the one who checks it. Give the agent the same split. The worker implements one task with tests on its own branch. A reviewer with a fresh context (a new session or a separate reviewer agent) reads the diff, the code and the tests, and writes findings to a comments.md file. The worker addresses them. Repeat until the build is clean and every test passes. Then a person approves it, after checking the four boxes on the slide: the intent matches the diff, the tests prove behavior rather than just pass, the blast radius is known, and the rollback is ready. In tools with custom agents or subagents, a main session can orchestrate the crew: you as product owner, an orchestrator, a worker, and a reviewer, with nothing committed until you say so. GitHub Copilot custom agents and Claude Code subagents can both hold these role prompts. When a repository requires approvals, your approval of a pull request from the Copilot cloud agent (formerly the coding agent) does not count: someone else must approve. Explaining a change out loud, to a person, a rubber duck, or an AI, is how you find out whether you understand it. Source: https://chris-ayers.com/posts/copilot-or-rubber-ducky/

Course-correct early. The warning signs: the agent loops on the same error, edits files nobody asked about, adds packages you didn't ask for, or weakens a test to get to green. Don't argue with a confused session; its context is full of failed attempts. Anthropic's advice for Claude Code: if you've corrected it more than twice on the same issue, clear the session and start fresh with a better prompt that includes what you learned. 1. Stop at the first warning sign. 2. Reset the branch to the last green commit. Here, git reset --hard HEAD~2 drops the two WIP commits. 3. Start a fresh session from the spec and the tasks. 4. Fix the cause: a missing rule in AGENTS.md, an ambiguous spec, or a task that was too big. Small commits make this cheap. Checkpoints help too: /rewind (or Esc twice) in Claude Code, and checkpoints in VS Code, roll back to an earlier point. Git stays the source of truth. The session and the commits are illustrative. Source: https://code.claude.com/docs/en/best-practices

Agents finish in parallel; you review one change at a time. Review becomes the bottleneck, so run only as many agents as you can review well. - Give each agent its own git worktree or cloud session, so no two edit the same checkout. Claude Code: claude --worktree <name>. Copilot CLI: /delegate hands a task to the cloud agent, which works on its own copilot/ branch, and /fleet splits a task across parallel subagents. - Split work that touches different files: independent features, docs, tests for existing code. - Keep changes to the same files, shared interfaces, and migrations in one lane, in order. - Within one session, a subagent can search the codebase or read docs in its own context window and return only a summary, so the main session stays small. The lanes, pull requests, and queue are illustrative. Sources: https://code.claude.com/docs/en/common-workflows https://code.claude.com/docs/en/sub-agents

Interactive in the HTML deck, in the audience window. Nothing autoplays. 1. Run. Tests pass on all three changes, but AI-0157 only passes because the agent edited an assertion. 2. The board stops at review. Click Approve: AI-0142 and PR-0161 are approved, and AI-0157 is held before any user sees it. 3. Rings widen exposure: team, 1%, 10%, everyone. PR-0161 raises errors at 1% and the health gate rolls it back. AI-0142 lands. 4. Switch the scenario to Vibe shipping and run again: review is a rubber stamp, rings are skipped, and two changes become incidents at 100%. Step advances one stage but never skips the approval. 2x doubles the speed. Changes, timings, and percentages are fictional and illustrative. The PDF shows the Evidence first outcome, with a one-line Vibe shipping comparison underneath.

Make rollback boring: feature flags, immutable artifacts so the last good build is one step back, health gates that trigger automatically, and a path you have rehearsed. A rollback is a routine release step, not a failure to explain in a meeting. PR-0161 is the same fictional change from the release board. The error rate and the 1% exposure are illustrative.

An agent acts with whatever access you give it: your shell, your tokens, your network. Give it the least that does the job. - Branches: its own branch, never main. GitHub's Copilot cloud agent can push only to the copilot/ branch it creates and can't approve or merge its own pull request, and the person who asked for the pull request can't approve it either. - Secrets: keep production secrets out of the agent's environment. - Network: allowlist what it may reach. The Copilot cloud agent's internet access is restricted by a firewall. - Ask first before new packages and shell commands: permission modes in Claude Code, tool approvals in Copilot. Untrusted text: anything the agent reads (issues, web pages, docs, tool output) can carry instructions. OWASP ranks prompt injection first among LLM risks (LLM01:2025), including indirect injection through external content. Treat it as data, and block the actions with permissions and hooks, not with a polite instruction. New packages: models invent package names. A study of 576,000 generated code samples found that at least 5.2% of the packages commercial models suggested, and 21.7% of those open-source models suggested, did not exist: 205,474 unique fake names that attackers can register. Check that a package exists, who publishes it, and that it's the one you meant. The permissions and the issue are illustrative. Sources: https://docs.github.com/en/copilot/concepts/agents/coding-agent/risks-and-mitigations https://genai.owasp.org/llmrisk/llm01-prompt-injection/ https://arxiv.org/abs/2406.10279

Each extension point trades reliability against context. - Instructions (AGENTS.md, .github/copilot-instructions.md, CLAUDE.md) load into every session. The model reads them and usually follows them, but nothing enforces them. - Skills (SKILL.md folders) load only their name and description up front. Activation loads the full SKILL.md; referenced files and scripts are read or run only as needed. - MCP servers give the model live tools, and their tool list sits in context every session. Claude Code defers full tool definitions until they're needed (tool search), but every server still adds to the list, so load few. - Prompt files (.github/prompts/*.prompt.md) run only when you type /name in Copilot Chat. In Claude Code, a skill with disable-model-invocation: true works the same way. - Hooks are commands that run at fixed points, such as before a tool call, every time, outside the model. A hook can block the call: in Claude Code, a PreToolUse hook that exits with code 2 stops it. Only what the hook reports back reaches the model. So if something must happen every time (formatting, secret scanning, blocking pushes to main), make it a hook, not a sentence in the instructions. The "Same practices" and "Same guardrails" slides show where each one lives. Sources: https://agentskills.io/specification https://code.claude.com/docs/en/hooks https://code.claude.com/docs/en/mcp https://code.visualstudio.com/docs/copilot/customization/prompt-files

The practices are the point; the file names are just where each tool keeps them. Several tools read each other's files: Copilot CLI and the cloud agent also accept CLAUDE.md, Copilot reads .claude/skills, and Claude Code reads AGENTS.md when a project has no CLAUDE.md. - Instructions: AGENTS.md is the cross-tool convention. Copilot adds path-specific .github/instructions/*.instructions.md files. - Specs: OpenSpec runs explore, propose, apply, archive; the command spelling differs by tool (/opsx:propose in Claude Code, /opsx-propose in Copilot). Spec Kit installs skills such as /speckit-specify, /speckit-plan, /speckit-tasks, and /speckit-implement for both tools. - Roles: Copilot custom agents live in .github/agents/ (VS Code uses .agent.md files); Claude Code subagents live in .claude/agents/. - Skills: SKILL.md folders follow the Agent Skills specification in both tools. Sources are listed on the next slide's notes.

- Tools: MCP is the open protocol. Copilot's cloud agent and code review take MCP servers from repository settings on GitHub; Copilot CLI keeps user-level servers in ~/.copilot/mcp-config.json. Load few servers: each one spends context. - Hooks: Copilot hooks run in the CLI and the cloud agent; Claude Code hooks live in settings files. - Approval: when a repository requires approvals, your approval of a Copilot pull request does not count; another reviewer must approve it. Claude Code permission modes range from plan mode (read only) to asking before each edit. Check current vendor docs before presenting: https://docs.github.com/en/copilot/reference/customization-cheat-sheet https://code.claude.com/docs/en/overview

Typing speed isn't the outcome; delivery is. DORA's five software delivery metrics: - Throughput: change lead time, deployment frequency, and failed deployment recovery time. - Instability: change fail rate and deployment rework rate. DORA's 2025 State of AI-assisted Software Development report finds that AI's primary role is as an amplifier of an organization's existing strengths and weaknesses. Google's summary of it: without strong automated testing, mature version control, and fast feedback loops, more change volume leads to instability. So watch the instability metrics as AI raises volume. If change fail rate or rework climbs, slow down and invest in the practices in this talk. DORA names smaller batches as a common way to improve all five metrics. Sources: https://dora.dev/guides/dora-metrics/ https://dora.dev/research/2025/dora-report/ https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report

A challenge-and-response checklist: one person reads the item, the other confirms the state. In the HTML deck, click each line to check it; all seven marks the change ready to ship. The PDF prints a blank list people can keep. Recap: current instructions, an agreed spec, small steps, tests that prove behavior, a human approval, staged exposure, and a rehearsed rollback.