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. Understanding, verification, integration, and safe release still take work. The answer is not an approval meeting for every step: automate repeatable checks and reserve human judgment for intent, uncertainty, and risk. AI can help gather that evidence before a single production-code change is made. 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. The other drafts are checkout totals, a flaky date test, config-key names, and audit-log pagination. The exact titles are not the point: drafting has outpaced the evidence to ship. 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: gather source-backed requirements, research the unknowns, and agree on intent. - Can't verify it: collect observed evidence, test the behavior, and review the change. - Can't recover: limit exposure and rehearse a recovery path. These are the three questions that organize the talk. Shipping to everyone at once increases blast radius; it does not by itself make a change irreversible. A deployment rollback also cannot undo every data change or external side effect.

AI is useful for preparation, not just code generation. Before a planning meeting or a coding session, have it gather the relevant tickets, documentation, code paths, previous decisions, and known failures. Ask for links and questions, not a solution disguised as a summary. Illustrative research brief: "Prepare for the search keyboard-navigation discussion. Find the current behavior, related bugs, accessibility guidance, and constraints. Cite the sources, separate facts from assumptions, and list the decisions we need. Do not implement anything." Use the smallest relevant context packet. The next examples show how to retain standing instructions and keep the session focused; setting up every extension is not a prerequisite. The keyboard-navigation change is the running example from preparation through release.

The questions you ask steer the agent; the questions you do not know to ask can leave the most important constraints unstated. Research and domain knowledge improve the question, not just the answer. This is not a promise that better wording alone guarantees good results. The leading question already assumes that DOM focus should move. In this search example, that could satisfy the request while breaking the requirement that the user can keep typing. Questions we might have missed: should focus stay in the input, how is the active result announced to a screen reader, and what happens when there are no results? Ask the agent to surface assumptions, missing constraints, alternatives, and evidence that would disprove the plan. Then check those suggestions against code, primary documentation, stakeholders, and observed behavior. Asking the same agent "what did we miss?" is useful, but is not independent validation that nothing is missing. An agent can answer our incomplete question very well. Two worktree experiments can also optimize the same wrong problem if they inherit the same unexamined assumptions.

Introduce the running case here: a meeting requested keyboard navigation for search, but important behavior is still undecided. The next slide is a proposed ticket update, not an approved implementation. Use prepared, reviewed input for this introduction; configure the access boundaries before actually running connected tools or applying changes. Use Microsoft 365 Copilot in Teams to query the available meeting chat and recap. For spoken meeting content after the meeting, a retained transcript must be available; chat-only access cannot reconstruct an untranscribed discussion. Availability also depends on licensing, organization policies, meeting settings, and access to the source. Example prompt: "From this meeting, draft the agreed requirements, proposed ideas, action items, and unresolved questions as separate sections. Cite the supporting transcript or chat. Include owners and dates only when explicitly stated. Do not create tickets yet." Check the cited passages, then confirm ambiguous requirements with the participants. An AI summary is not an approval, and an action item is not automatically an acceptance criterion. GitHub Copilot is a separate product. Give the coding session a reviewed recap or connect an approved tool such as Work IQ to retrieve accessible Microsoft 365 context. This is not an automatic handoff built into every Copilot experience. Work IQ is public preview and tenant access requires the appropriate administrative consent; respect source access and sensitivity restrictions, and do not copy restricted meeting content into a public repository or ticket. Sources: https://support.microsoft.com/en-us/teams/copilot/catch-up-on-meetings-with-microsoft-365-copilot-in-teams https://github.com/microsoft/work-iq

Turn the confirmed meeting follow-up into a proposed new ticket or a patch to an existing one. At this point it remains a draft. Research and experiments may change the proposal; close the open questions and agree the implementation plan before treating it as a commitment. With configured Azure DevOps or GitHub tools, a coding agent can do ticket upkeep as well as read tickets: draft descriptions and acceptance criteria, create child tasks, link related work, and attach the research or experiment results. Example prompt: "Read the current work item and the reviewed meeting follow-up. Propose changes to the description and acceptance criteria, suggest child tasks and relevant links, and keep unanswered questions explicit. Preserve owner, priority, and dates unless a confirmed decision changes them. Show the field-by-field changes; wait for approval before applying them." For Azure DevOps, the MCP server exposes work-item create/update, child-item, comment, and link operations. The exact tools depend on the configured server and the caller's permissions. Research can stay read-only; writing needs an enabled write tool and an approved change. After approval, reread the item for concurrent edits, apply only the approved fields, verify the saved values, and return the work-item link. Do not silently overwrite a teammate's edits, close unrelated tickets, or manufacture commitments that were never agreed. No meeting or ticket is connected to this deck. These are workflow examples, not live actions. Sources: https://learn.microsoft.com/en-us/azure/devops/mcp-server/remote-mcp-server?view=azure-devops https://github.com/microsoft/azure-devops-mcp

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 weaken a test to hide a failure"), 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. Also record the working practice: tests first, the smallest change that passes, and "read docs/adr before redesigning." Those details do not need a second panel on the slide. 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

An agent acts with whatever access you give it: your shell, your tokens, your network. Give it the least that does the job. Set those boundaries before research or implementation. Begin evidence gathering with read-only access where possible, and approve the specific write operations needed for ticket updates. - 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. The permissions are illustrative. Standing instructions describe the policy; permissions, repository protections, and supported hooks enforce it. The next example makes that distinction concrete. The boundary matters regardless of which client you use. Source: https://docs.github.com/en/copilot/concepts/agents/coding-agent/risks-and-mitigations

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. Keep repository protections and least privilege in place as well. The cross-tool reference later in the implementation flow shows where the configuration lives. Source: https://code.claude.com/docs/en/hooks

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. This applies during research too: a meeting transcript, ticket, or retrieved document is source material, not permission to send messages, change work items, or use credentials. 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 issue and blocked action 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

The meeting and ticket examples use connected tools. This is the implementation distinction: MCP supplies callable operations, while a prompt file supplies a repeatable request that you start. Neither gives the agent permission to invent requirements or make unapproved changes. Each extension point also trades reliability against context. - Instructions load into every session. The model reads them and usually follows them, but nothing in the text enforces them. - Skills load only a name and description up front, then detail on demand. - MCP servers give the model live tools, and their tool list spends context. Claude Code defers full tool definitions until needed (tool search), but every server still adds to the list, so load few. - Prompt files (.github/prompts/*.prompt.md) run when you type /name in Copilot Chat. In Claude Code, a skill with disable-model-invocation: true works the same way. The prompt's content enters context when you invoke it. Sources: https://agentskills.io/specification https://code.claude.com/docs/en/mcp https://code.visualstudio.com/docs/copilot/customization/prompt-files

Ask the agent to investigate before proposing an implementation. For the search example: where is keyboard input handled, what do existing tests establish, what accessibility behavior is required, and which earlier decisions constrain the change? Have it cite code locations, issue history, and the relevant version of primary documentation. Check the cited material yourself: a citation can be real while failing to support the claim. Record conflicting sources, missing access, and unknowns instead of filling them with guesses. Research should end with a decision, an unanswered question, or a testable hypothesis. Use what you learn to revise the question and its constraints, not only to justify the plan you started with. An evidence packet is more useful than an enormous transcript of the research. Keep the sources and reasoning that the implementer or reviewer will actually need. Source: https://martinfowler.com/articles/exploring-gen-ai/context-engineering-coding-agents.html

"Known" here means a stakeholder-confirmed requirement linked to the reviewed ticket, not a fact inferred from an AI summary. "Assumed" is a design hypothesis, not a conclusion. "To check" names the observation that could change the decision. For each important claim, keep the source, its relevant version or date, what was actually observed, and what remains uncertain. A model saying "the tests pass" is not test output. Ask it to attach the command and result when it can run a check; otherwise mark it not run. This is evidence gathering before production implementation, not a demand for a large document. An issue comment or a short research.md can carry the packet.

Four named agents, four documents, and approval meetings are not the minimum viable workflow. Scale the effort to uncertainty, blast radius, and reversibility. A small, reversible change does not need the same process as an authentication change or a data migration. Even small changes need the agreed behavior and relevant verification; access boundaries and repository-required reviews still apply. Extra roles and tools are optional ways to organize the work, not evidence by themselves. The implementation examples in the talk show choices you can apply at each stage, not a mandatory toolchain for every change.

Use multiple git worktrees for competing experiments, not just parallel feature delivery. Start each from the same recorded base commit, on a different branch, with its own Copilot session and a bounded research question. Here the question is how to add keyboard navigation while preserving input focus and existing behavior. The same acceptance checks apply to both. Time-box the spike. It may contain disposable code, but it is not production implementation or permission to merge. Do not expand either candidate into a whole feature just because the agent can. No winner or measured improvement is claimed in this illustration. Worktrees isolate checkout files, not the whole environment. Git history and repository configuration are shared; ports, databases, credentials, and external services may still collide. Give experiments separate runtime resources or safe fixtures where necessary. Never use production data or secrets just to make an experiment convenient. Source: https://git-scm.com/docs/git-worktree

Collect observed behavior, test output, relevant measurements, and the actual diffs, not two persuasive agent summaries. Use the same inputs and environment where comparison requires it. A candidate failing a check does not prove the other is safe. Choose an approach, explain the tradeoff and the rejected alternative, and attach that evidence to the work item. Revisit the proposed requirements if the research exposed a missing decision. Then agree on the implementation plan. Bring only the reviewed changes into the implementation branch and rerun its checks; do not merge every experiment or treat prototype code as finished. Exploration can be parallel while integration remains deliberate. Limit experiments to what you can evaluate. Preserve useful findings before cleaning up disposable worktrees. Later, distinguish these competing experiments from parallel delivery of independent changes: those PRs need coordinated integration and enough review capacity. Source: https://git-scm.com/docs/git-worktree

For a larger change, splitting the job into roles can keep each context focused. This is one optional workflow, not four mandatory agents. Each role here is a fresh session with its own prompt, and files carry the work from one to the next: - Analyst: records confirmed requirements and unresolved questions in requirements.md. - Architect: reads requirements.md, designs the solution, and writes a spec and small tasks (spec.md and tasks.md, or the OpenSpec change shown next). In this workflow, review the handoff before moving to the next role. For a smaller change, one short brief and a focused session may be enough. 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.

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 Review the folder before production implementation begins: the earlier spikes explored uncertainty, while this folder records the proposed plan we are about to agree. Source: https://github.com/Fission-AI/OpenSpec

This is the lifecycle overview, not a claim that the example is already finished. We have reached Propose; Apply and Archive follow the agreed plan and completed implementation. 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. GitHub Spec Kit runs the same loop with its own commands: specify, plan, tasks, implement. The keyboard-navigation example has four reviewable tasks. Archive the change after those tasks are complete, rather than leaving the only record of what changed in a chat. Sources: https://github.com/Fission-AI/OpenSpec https://github.com/github/spec-kit

Agree on a written, reviewable implementation contract, using the confirmed requirements and the research or experiment results. Disposable spikes answered questions; this is the boundary for production work. Make the intended behavior, constraints, non-goals, and open decisions clear. Changing result ranking is out of scope for this keyboard-navigation change. 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. Different file names." reference and its notes show where each piece lives. A plain spec.md and tasks.md in the repo works too. Use the requirements, plan, and experiment evidence prepared in the preceding examples. Read-back: ask the agent to restate the agreed behavior and constraints before implementation. Resolve the final-result boundary behavior in the ticket rather than letting the code quietly decide it. Apply only the reviewed ticket changes and carry the agreed spec into the worker. The Spec, Build, and Review board slides follow one change, AI-0142. The examples between those stages show how to implement the practice, rather than starting a different workflow.

After you approve the architect's plan, the worker starts from the spec and tasks in a fresh session. It implements one task at a time, tests first, on its own branch. A separate reviewer reads the diff, code, and tests, then writes comments.md. The worker addresses the findings; repeat until the build is clean and every test passes. An agent review does not replace human approval. The branch name is illustrative. Each handoff is a deliberate checkpoint, not a reason to automatically launch four agents for every small change.

Experiments can deliberately change the same files in separate worktrees to compare alternatives. Parallel delivery is different: several changes must eventually coexist. Use the following rules for delivery work, rather than treating all experimental branches as changes to merge. - 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. Sources: https://code.claude.com/docs/en/common-workflows https://code.claude.com/docs/en/sub-agents

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. In this illustration, three worktree agents and one cloud agent each opened a pull request. Two are approved; two are still waiting. These are fictional pull requests, not measured data. Use this example to set concurrency before launching delivery workers, not as another approval of the running keyboard-navigation change.

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. Review changes to the tests as carefully as changes to the implementation. Tests can and should change when agreed requirements change; weakening an assertion just to hide a defect is different. Preserve the relevant regression coverage and link changed expectations to the reviewed requirement. A passing status alone is not the evidence.

Use this with the agreed keyboard-navigation behavior, not as a general prohibition on a particular matcher. A handler that leaves the first result active could pass the weak check. A handler that selects the next result but steals focus could still break typing. The stronger assertions check the intended result and retained input focus. In a real test, set up the initial selection, fire ArrowDown, and derive nextResult from the agreed behavior. The example omits that fixture for clarity; screen-reader behavior needs suitable additional verification, not just a DOM assertion. An agent can write implementation and tests that share the same wrong assumption. Anchor the checks to the reviewed requirements and show that they fail against the relevant broken behavior. A fresh reviewer context is useful, but is not an independent source of truth.

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. In the illustrative keyboard-navigation task, Task 2 was green. Task 3, close on Escape, has gone off track. The next slide shows the recovery, separately from these warning signs. Source: https://code.claude.com/docs/en/best-practices

1. Stop at the first warning sign. 2. Preserve anything needed, then return your disposable local branch to the last green commit. In this specific illustration, git reset --hard HEAD~2 drops the two WIP commits and any uncommitted tracked changes. Do not copy that command blindly or rewrite a shared branch. 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

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. Agent Skills is an open format at https://agentskills.io. Optional companions are references/ for runbooks and detail, scripts/ for repeatable checks, and assets/ for templates and examples. 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

Intentional complexity exception: one take-away configuration reference, replacing two larger comparison tables. Do not read every cell aloud. 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. - 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

Read these as questions, not boxes to tick because a pipeline is green. The blast radius must be known and the rollback ready before approval. 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/

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 relevant checks pass and the findings are resolved. Another agent may share the same mistaken assumptions; ground the review in requirements and observed evidence, not agreement between models. Only now does a person approve it, using the four questions just considered: the intent matches the diff, the tests prove behavior rather than just pass, the blast radius is known, and the recovery plan is ready. Reviewer setup and evidence gathering precede this approval checkpoint. 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.

Introduce the release mechanism before showing the full board. The team goes first, then a small share of users, then more users, then everyone. Promotion needs evidence at every ring. Choose real ring sizes and health gates for the service; these percentages are illustrative. The following slides make the health and recovery conditions explicit before the combined release example. The percentages do not replace a service-specific rollout policy.

"Healthy" must mean something observable. Pick the relevant synthetic checks and telemetry, the baseline, the tolerated regression, the observation window, and the recovery owner before rollout. An absence of errors in a tiny sample is not proof that the change is safe. For search, combine behavioral keyboard checks with appropriate service health signals. Do not collect users' raw keystrokes to verify a focus requirement. The examples here are illustrative; the service owner sets actual thresholds and data-handling requirements. Automate promotion stops and recovery triggers where the signals and procedures support it. Name the person accountable for ambiguous evidence and for verifying recovery.

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.

Containment and recovery are different. Rings limit how many users are exposed; a rollback restores a compatible previous version. Neither automatically reverses a destructive migration, an external payment, a sent notification, or other persistent side effects. For those changes, plan compatibility, backups or compensating actions as appropriate and test the recovery procedure. Sometimes a forward fix is safer than reverting the deployment. Do not promise reversibility that the system does not have.

Intentional complexity exception: the release board brings the earlier ideas together. 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 weakened 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%. 5. Switch back to Evidence first and complete its approved run. Leave the audience on the landed, held, and contained-rollback outcomes, not on Vibe shipping. 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.

PR-0161 is the same fictional change from the release board. The error rate is healthy at ring 0, crosses the health gate at ring 1, and returns to normal after the rollback. Nobody beyond ring 1 sees it. The error-rate story and the 1% exposure are illustrative.

Typing speed isn't the outcome; delivery is. DORA groups three software delivery metrics under throughput: change lead time, deployment frequency, and failed deployment recovery time. Source: https://dora.dev/guides/dora-metrics/

The other two DORA metrics are change fail rate and deployment rework rate. “AI’s primary role is as an amplifier, magnifying an organization’s existing strengths and weaknesses.” DORA, State of AI-assisted Software Development (2025). 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. Run the same list on every change, however experienced the author. 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. On the next AI-assisted PR, link the confirmed ticket and research sources, show the observed verification, and name the exposure and recovery plan. Sources include current standing instructions; intent is the agreed ticket or spec, not an unreviewed meeting summary. Use a rollback or another tested recovery procedure appropriate to the change. The questions are the same throughout: can we explain this change, verify it, and recover safely? The agent can help at every stage, not just write the implementation.

These are the same further-reading links as the original closing slide and the README. Specific claims, examples, and vendor documentation remain cited in the relevant speaker notes.

Close on the supplied event poster and feedback QR code. Keep both images uncropped so the event details and the QR code's white quiet zone remain intact.