demo

gistfile1.txt

# AI Assisted Development Workflow — 5-Minute Demo Script

**Scope:** Phase 0 (AI Knowledge Bootstrap) through Phase 1 (Planning + PRD)
**Duration:** 5 minutes
**Audience:** UBS engineering leadership / team leads

---

## Slide-by-Slide Script

### Slide 0 — Title (30s)

> "This is a structured workflow we've developed at Thoughtworks for AI-assisted feature development. The core idea: AI tools are only as useful as the context you give them. Without structured context, you get generic suggestions. With it, you get contributions that actually respect your architecture and constraints."

**Transition:** "Let me walk you through how we set that context up — and then how it flows into planning."

---

### Slide 1 — Overview Pipeline (30s)

> "The full process has five phases. Today I'm going to focus on the first two — the bootstrap and the planning phase — because that's where most of the leverage is. If the AI understands your codebase before it writes a single line, everything downstream gets better."

**Action:** Point to Phase 0 and Phase 1 in the pipeline. Mention that Phases 2-4 (Build, Iterate, Deploy) follow the same structured approach but are out of scope for this demo.

---

### Slide 2 — Phase 0: AI Knowledge Bootstrap (60s)

> "Phase 0 is a one-time investment. We have the AI scan the codebase and generate structured documentation for every module — API surface, dependencies, file structure. That's the easy part."
>
> "The critical part is what happens next: developers review every doc and add what the AI can't infer — architectural decisions, tribal knowledge, the *why* behind the code. 'We chose this library because the other one doesn't support X.' 'This module talks to a legacy system that has a 5-second timeout.' That kind of context."

**Action:** Point to the Module Doc Template table. Highlight the AI-generated vs developer-authored split.

> "We then configure instruction files — claude.md, copilot-instructions — with enforcement rules: the AI must consult these docs before generating any plan."

**Key message:** The AI captures *what*, developers add *why*. Neither alone is sufficient.

---

### Slide 3 — Phase 0: Orchestration (60s)

> "Here's how it works in practice. On the left you see a typical project structure — each module has its own documentation file. On the right, the orchestrator."
>
> "The instruction file at the root acts as a central hub. When the AI starts working on a task, it reads the instruction file first. That file references the relevant module docs. The AI loads that context, then produces a structured plan that respects the architecture and constraints."

**Action:** Walk through the animated diagram — modules feeding into claude.md, which outputs a structured plan.

> "This isn't magic. It's just making sure the AI reads the same documentation a new team member would read — except it does it every time, consistently."

**Key message:** Instruction files are orchestrators, not just configuration. They define what the AI must know before it acts.

---

### Slide 4 — Phase 1: Planning (60s)

> "Once the AI has context, we move into planning. The key discipline here: plan only the first 2-3 tasks in detail, then re-evaluate after each one. We don't try to predict everything upfront."
>
> "The AI consults module docs first and surfaces constraints before the developer even starts writing a plan. Time-boxed spikes handle unknowns. Work gets decomposed into sub-tasks with clear boundaries and success criteria."

**Action:** Point to the Planning Discipline table.

> "Two rules I want to highlight: feature flags for anything user-facing — so we can decouple deploy from release — and short-lived feature branches that merge within days, not weeks. These aren't suggestions, they're part of the process."

**Key message:** Planning is iterative and AI-informed, but the developer makes the call.

---

### Slide 5 — Sample PRD (60s)

> "This is what a real planning artifact looks like. It's a PRD for a lineage radius feature — lets users control how many hops deep a data lineage graph shows."
>
> "Notice the level of specificity: exact file paths, acceptance criteria with checkboxes, implementation tasks broken down by component, and a testing matrix. The AI helped draft this based on the module docs it had already ingested. The developer then reviewed and refined it."

**Action:** Scroll slowly through the PRD. Pause on:
- **Acceptance Criteria** — "These are the pass/fail conditions. No ambiguity."
- **Implementation Tasks** — "Each task maps to a specific file. The AI knows the codebase well enough to suggest where changes go."
- **Dependencies table** — "It flags that the backend API needs to support the radius parameter — that's a cross-team dependency the AI surfaced from the module docs."

> "This PRD becomes the contract for the build phase. Every sub-task traces back to it."

**Key message:** The PRD is concrete, file-level specific, and AI-assisted but human-validated. This is what "AI-assisted planning" looks like in practice — not vague suggestions, but structured artifacts.

---

## Closing (30s)

> "To summarize: Phase 0 gives AI the context it needs — once. Phase 1 uses that context to produce plans that are specific enough to execute against. The AI does the heavy lifting on structure and surface-level analysis; the developer adds judgment, priorities, and domain knowledge."
>
> "The rest of the workflow — build, test, iterate, deploy — follows the same principle: AI assists, humans decide. Happy to go deeper on any of those phases."

---