AI-DLC Workshop: Zero to Prototype in Two Days
Learn how to take cross-functional teams from blank page to working prototype using AI-DLC. Includes the facilitation model, metrics, and lessons learned from multi-team workshops
Introduction
Last month, I facilitated an AI-DLC workshop with an enterprise software company. Twenty-five engineers, product managers, and designers walked into a room on Monday morning with three separate product ideas — one per team. By Tuesday afternoon, all three teams had working prototypes — architecture decisions documented, user stories validated, code committed to feature branches, and one app deployed to a non-prod AWS account. Each team demoed what they built to engineering leadership right after.
In a typical sprint-based workflow, you'd spend weeks refining stories, planning sprints, and aligning stakeholders before a single line of code gets written. Then development takes another 6–8 weeks. We did all of it — from blank page to live stakeholder demo — in two days.
This isn't a post about what AI-DLC is — you can read about the methodology's origins from AWS leadership or explore the open-source workflow rules on GitHub . This is the post I wish I'd had before I ran my first workshop: a field guide for solutions architects, engineering managers, and technical leads who want to take cross-functional teams from zero to working prototype using AI-DLC with agentic coding tools — AI assistants that can plan, write, and execute code within your IDE.
I'll share the facilitation model that worked, the anti-patterns I discovered the hard way, and the decisions that made the difference between teams that shipped and teams that stalled.
What Makes AI-DLC Different from "Vibe Coding"
You might be thinking: "Isn't this just a fancy wrapper around letting AI write code?"
No. And here's why that distinction matters.
Unstructured AI coding — what some call "vibe coding" — works fine for solo developers building throwaway prototypes. But it falls apart the moment you have multiple people, shared interfaces, or production-quality requirements. AI-DLC solves this by imposing a phased workflow:
- Inception forces alignment before anyone writes code. AI generates artifacts (requirements, user stories, architecture), but humans validate every output through collaborative mob elaboration.
- Construction scales horizontally because the Inception artifacts become the contract. Multiple developers work in parallel referencing the same agreed-upon functional design.
- Operations validates the build through deployment, testing, and monitoring — ensuring what you built actually works end-to-end.
- Human approval gates sit between every phase transition. Nothing auto-commits. Nothing auto-deploys. The human reviews the plan, approves it, then reviews the generated code.
The key insight: AI-DLC doesn't remove humans from the loop — it restructures the loop so AI handles the generative work while humans handle the judgment work.
Important: AI-DLC is IDE and agentic coding tool agnostic. Teams can use any IDE and any agentic coding tool — Claude Code, GitHub Copilot, Cursor, Kiro, or Codex. The methodology is about the process, not the tooling.
The Workshop Model: Two Days, Zero to Demo
After running multiple workshops across different verticals — EdTech, biotech, developer platforms — I've converged on a model that consistently delivers results.
Important: The two-day format I describe here is what has worked for me, but it's not rigid. You can customize this methodology to fit your organization — some teams may need three days, others might compress further. The phases matter more than the exact timebox.
How teams operate: fully independent, end-to-end
If you have three use cases, you have three teams — and each team runs all phases independently: Inception, Construction, and Operations. They are fully self-contained units with 5 to 9 people per use case — typically a product owner, a few engineers, and optionally a manager. What matters is that the team has enough domain knowledge during Inception and enough engineering capacity during Construction.
Each team is cross-functional and owns their use case from ideation to demo. No shared dependencies between teams. No waiting on another team's output.
After all teams complete their cycle, they come together for a joint stakeholder demo.
Prerequisites checklist
Before Day 1, make sure you have:
- Use cases scoped and assigned to teams
- Teams formed (cross-functional, 5–9 people each)
- IDE + agentic coding tool installed on all dev machines
- AI-DLC workflow rules installed and configured
- AWS sandbox account provisioned (if deploying)
- Room booked with screen-sharing capability per team
Phase 1: inception (Day 1 morning → afternoon)
Within each team, one person drives (shares their screen with the agentic coding tool), while the rest contribute domain knowledge in a focused mob elaboration format.
The phase begins with the team providing an intent — a high-level description of what they want to build. The AI then asks clarifying questions to fill gaps in understanding: "Who are the target users?" "What's the expected scale?" "Are there existing APIs to integrate with?" As a team, you answer these questions collaboratively, and this back-and-forth shapes the requirements.
From there, each team follows this sequence:
- Workspace detection — The AI scans the existing codebase (brownfield) or project scaffold (greenfield) to build initial context.
- Reverse engineering (brownfield only) — AI documents existing patterns, APIs, and component structures. Engineers correct and augment.
- Requirements elaboration — The product owner describes what they need. AI generates
requirements.md. The team reviews, challenges, and refines. - User story generation — AI produces INVEST-format stories (Independent, Negotiable, Valuable, Estimable, Small, Testable). The product owner validates priority and acceptance criteria.
- Architecture design — AI proposes the application architecture (
app-design.md) and functional design (functional-design.md). Engineers review and adjust.
By afternoon, each team has a committed
aidlc-docs/ directory containing the complete design contract their developers will reference during Construction. Some teams finish by early afternoon, others by later afternoon — the pace depends on the complexity of the use case and the team's familiarity with the domain.Important: The approval gate at the end of Inception is non-negotiable. Every team member must confirm: "I know which stories I own, I understand the API contracts, and I can start generating code now."
Phase 2: construction (Day 1 afternoon → Day 2 afternoon)
Once a team's Inception wraps and the approval gate passes, their engineers fan out and begin building individually. Teams that finish Inception early start Construction early — there's no requirement for all teams to transition at the same time.
Each person opens their IDE, launches their agentic coding tool, and begins the plan-execute loop:
- Prompt the AI with a task, referencing the shared design docs
- AI produces a plan (markdown)
- Human reviews the plan, adjusts if needed
- AI generates code
- Human reviews code, accepts or refines
- Commit to feature branch
- Repeat
Within each team, engineers work on separate feature branches — no merge conflicts during Construction. Construction continues through Day 2. Some teams wrap up by early afternoon; others need more time depending on scope and complexity. The key is that teams move at their own pace.
Phase 3: operations (Day 2)
Once Construction is complete, teams shift to Operations: integrating branches, deploying, and validating end-to-end functionality. During the workshop, Operations typically looks like:
- Merge feature branches and resolve conflicts
- Deploy to a non-prod AWS account
- Run smoke tests to validate end-to-end flows
- If time permits, set up a basic CI/CD pipeline
Most teams treat full Operations — monitoring, hardening, production readiness — as a post-workshop activity in the days that follow. The
aidlc-docs/ artifacts and the code generated during Construction make that follow-up work significantly faster regardless of when it happens.Stakeholder demo (Day 2 afternoon)
All teams come together. Each gets 10–15 minutes to show stakeholders:
- What they set out to build (the user stories they tackled)
- A live demo of the working prototype
- Key architecture decisions and trade-offs
- What's remaining for post-workshop completion
The demo creates accountability and gives stakeholders immediate visibility into what AI-DLC delivers. Every workshop I've run, the reaction from leadership has been some version of: "Wait, you built this in two days?"
Sync points within each team
Without deliberate sync points, parallel engineers will drift. I recommend two:
- Day 1 end of day — Quick standup within each team. Surface blockers, verify interface assumptions. Each engineer pushes their branch.
- Day 2 morning — Integration check. Merge branches, verify end-to-end flow, identify blockers before the final push.
Anti-Patterns I Learned the Hard Way
Anti-pattern 1: the "watching paint dry" problem
During Inception, when the AI is processing a complex prompt, there are natural pauses — sometimes 30–60 seconds. Even with a team watching one screen, dead time is noticeable.
What I do now: I deploy activity prompts while the AI processes. While AI generates requirements, I ask the team: "What edge cases are we missing?" "What happens when this fails?" "Who's the most frustrated user in this flow?" This turns dead time into validation time.
Anti-pattern 2: training vs. doing
In my early workshops, I jumped straight into execution assuming the methodology would be self-evident. It wasn't. One team's feedback was blunt: "I didn't really feel like I was taught how this should work."
What I do now: I run a 10-minute AI-DLC micro-briefing at the start and at each phase transition. I frame the why before the how — why we do Inception before Construction, why the approval gate exists, why parallel branches matter. By the time we start, everyone understands the framework — the workshop is purely about applying it.
Anti-pattern 3: scope creep during inception
AI is really good at generating comprehensive requirements. Too good. Left unchecked, a morning session can produce 40 user stories when the team can realistically tackle 12.
What I do now: I set a hard cap before Inception begins: "If AI produces more than 15 stories, we ruthlessly prioritize and defer." This forces scope decisions early rather than discovering at demo time that you're only 30% done.
The Metrics That Matter
Across my workshops, here are the consistent patterns:
| Metric | Traditional approach | AI-DLC workshop |
|---|---|---|
| Time from kickoff to first stakeholder-visible prototype | 8–12 weeks (planning + development) | 2 days (planning, development, and demo) |
| Boilerplate/scaffolding effort | ~15% of total | Near zero |
| Requirements alignment | 2–3 weeks of meetings | Half a day (Inception) |
| Stakeholder visibility | End of sprint (2+ weeks) | Day 2 afternoon demo |
The last metric surprises stakeholders most. One engineering leader told me the Inception phase produced alignment that "would have taken weeks of back-and-forth emails and meetings."
What Happens After the Workshop
The workshop isn't the end — it's the launchpad:
- The
aidlc-docs/directory remains the living design reference. New stories get added. The functional design evolves as the team learns. - Each developer continues the plan-execute loop independently. No mob session needed for familiar patterns.
- Sprint planning uses the generated backlog. User stories from Inception become the sprint backlog — already prioritized and linked to design docs.
- Code review + hardening is Week 1 priority. AI-generated code needs human scrutiny for security, error handling, and edge cases before new feature work begins.
When to Use (and Not Use) AI-DLC Workshops
Works best when:
- You have cross-functional teams that need alignment (not just coders)
- The project has both design ambiguity and implementation complexity
- You're starting a new initiative (greenfield) or replacing a major component (brownfield with clear boundaries)
- You have multiple use cases that can run in parallel
- Stakeholders are available for the Day 2 demo
Less effective when:
- The work is purely maintenance, bug fixes, or small UI changes
- The team already has a complete, agreed-upon design
- Only one developer is available
Getting Started
If you're interested in running an AI-DLC workshop for your organization, here's how to get started:
- Reach out to your AWS account team. Contact your Account Manager or Solutions Architect — they can coordinate with AI-DLC specialists to evaluate your use case and plan the workshop.
- Scope and fit assessment (~2 weeks before). An AI-DLC specialist will discuss your project or use case to determine if it's a good fit. They'll work with you to define a realistic scope for the two-day workshop — we can't complete months of work in two days, so the specialist helps identify what's achievable and impactful within the timebox.
- Prerequisites. Your team should be following an Agile methodology (or a structured SDLC). The workshop builds on existing Agile ceremonies — sprints, user stories, backlogs — and accelerates them with AI. If your team doesn't have these fundamentals, the specialist will work with you on readiness.
- Install the workflow rules. The open-source AI-DLC workflow rules configure your agentic coding tool with the phased workflow, approval gates, and document generation patterns. Remember — this works with any IDE and any agentic coding tool.
Conclusion
AI-DLC isn't about replacing developers with AI. It's about restructuring how teams collaborate so AI handles the generative grunt work — scaffolding, boilerplate, documentation — while humans focus on judgment: validating requirements, reviewing architecture, and approving code quality.
Each team independently runs Inception, Construction, and Operations before demoing their working prototype. The format has consistently compressed what traditionally takes 8–12 weeks from kickoff to stakeholder-visible prototype into 2 days across multiple enterprise customers.
The teams that succeed aren't the ones with the best AI prompts. They're the ones that do the pre-work, respect the approval gates, and treat generated artifacts as a starting point for human judgment — not a finished product.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article