How to Present Your Framework: 5, 15, and 30 Minute Versions

Updated Aug 2026

The 5-Minute Elevator Pitch

Use this for initial screens, hallway conversations, or when the interviewer says "tell me about your approach."

"I've built an AI-augmented test automation framework that uses a coding agent (Claude Code) driving the browser through the Playwright CLI, taught via an agent skill.

The core idea: Instead of writing brittle scripts, we define tests as natural-language plans and let an AI agent execute them through a CLI that drives the Playwright engine. Page state lands on disk as compact YAML snapshots; the agent reads it on demand and interacts with elements by reference.

Why this works: The agent can reason about failures, rediscover elements when the UI changes, and adapt to unexpected states. Traditional tests break when a button ID changes. Our agent re-snapshots the page, finds the button by role and name, and keeps going.

Key numbers: Roughly 4x cheaper in tokens than MCP-based approaches — that's Microsoft's own benchmark (~27k vs ~114k per task), and it's why they now recommend the CLI over their own MCP server for coding agents. Full Playwright actionability and auto-waiting underneath, so reliability isn't traded away.

The trade-off: Non-deterministic execution, but we mitigate this with command logging, archived Playwright traces, and a self-healing strategy where every healer patch is code-reviewed."

The 15-Minute Technical Overview

Use this for technical interviews or architecture discussions.

Part 1: Problem Statement (2 min)

"Traditional browser test automation has three problems:

1. Maintenance burden — When the UI changes, every affected test breaks. Teams spend 40-60% of their time maintaining tests, not writing new ones.

2. Brittleness — Tests depend on exact CSS selectors. A simple HTML restructuring breaks dozens of tests.

3. No reasoning — When something unexpected happens (a modal appears, a redirect occurs, a loading spinner takes longer), traditional tests just fail. A human tester would handle it.

AI agents solve all three — they can reason about the UI, adapt to changes, and handle unexpected states."

Part 2: Architecture (5 min)

"Three layers, each with a clear responsibility:

Test Definitions (Markdown plans — specs/):

## Scenario: Login with valid credentials
1. Navigate to the login page
2. Enter valid email and password
3. Submit the form
Expected: dashboard loads with the user's name visible

Agent Layer (coding agent + browser skill):

• The skill is a ~100-line SKILL.md generated by playwright-cli install --skills
• Loaded once into context; commands run through the shell
• The agent reads the plan, executes, verifies against fresh snapshots

Browser Layer (playwright-cli → Playwright engine):

• Snapshots and screenshots saved to .playwright-cli/ on disk — not streamed into context
• Element refs from YAML snapshots (fill e8 "text"), no selector authoring
• Full Playwright auto-wait and actionability underneath
• Named sessions (-s=admin, -s=customer) for parallel isolated contexts

Why CLI skills over MCP:

• ~4x lower token cost per task (Microsoft's benchmark: ~27k vs ~114k), up to 10x on long sessions
• The agent reads page state on demand instead of receiving it on every action
• Composable with other CLI tools in shell pipelines
• Microsoft now recommends this path over their own MCP server for coding agents"

Part 3: Self-Healing (3 min)

"When an interaction fails:

Tier 1 — Re-snapshot and rediscover: the agent takes a fresh snapshot and matches the element by role and accessible name. Cheap; handles most failures.

Tier 2 — Screenshot + state reasoning: catches loading issues, redirects, unexpected modals.

Tier 3 — Playwright's healer agent: replays the failing step against the live app, patches locators/waits/data, reruns until green — or concludes the app itself is broken. That verdict is the difference between self-healing and bug-hiding.

We track healing events. High healing on one test = stale assumptions (update the plan). Frequent healing across tests = a UI refactor happened. Every healer patch goes through code review."

Part 4: CI/CD (3 min)

"GitHub Actions with matrix strategy:

• Headless browsers, fresh isolated sessions per test group
• 4-5 parallel test groups
• Failure artifacts: screenshots, snapshots, command log, and the full Playwright trace with network capture — the audit trail of what the agent did
• JUnit XML for dashboard integration
• Healer runs as a follow-up job on failures; its patches arrive as PRs, not silent fixes"

Part 5: Results (2 min)

"Key outcomes:

• Test maintenance time reduced dramatically (agent adapts instead of breaking)
• Test reliability >98% (actionability checks eliminate most flakiness)
• New tests written as natural-language plans a product owner can review
• Failure debugging time reduced (trace + agent reasoning vs stack traces)"

The 30-Minute Deep Dive

Use this for final-round technical interviews or architecture review boards.

Expand the 15-minute version with:

Additional Section: Token Economics (5 min)

Walk through the numbers from 03-skills-vs-mcp/02-token-budget-analysis.md. Explain the disk-first mechanism, the naive-vs-measured gap (per-step arithmetic looks like 50x+; measured end-to-end is ~4x because the agent still reads snapshots on demand), and why 4x still decides the architecture at scale.

Additional Section: WebDriver BiDi (5 min)

Cover the protocol evolution (Selenium → WebDriver → CDP → BiDi). BiDi is the present: ~70% CDP surface coverage, WebdriverIO v9 default, Selenium 5's forthcoming headline. Show the message flow diagram.

Additional Section: Competitive Landscape (5 min)

Compare Playwright CLI/Agents, Playwright MCP, Stagehand, browser-use, and Vibium as the standards-native case study. Explain your decision framework. Show the decision matrix.

Additional Section: Live Demo or Walkthrough (remaining time)

If possible, show:

1. Installing the skill: playwright-cli install --skills
2. Running a simple flow: agent opens a page, snapshots, fills by ref, verifies
3. Showing the command log and a YAML snapshot
4. Showing a failure with trace + recovery

Common Follow-Up Questions (Be Ready)

Body Language & Delivery Tips

1. Draw diagrams — The three-layer architecture diagram sells the framework better than words
2. Use concrete, sourced numbers — "4x fewer tokens, Microsoft's own benchmark" beats an inflated estimate you can't defend
3. Name-drop thoughtfully — "Microsoft now recommends the CLI over their own MCP server" is the credibility line; "Jason Huggins, who created Selenium, is rebuilding for the agent era with Vibium" shows you track the field
4. Acknowledge trade-offs first — "The trade-off is non-determinism, and here's how we handle it" shows maturity
5. Have opinions — "CLI skills became the standard interface for agent browser control in 2026, and here's why" — architects respect conviction backed by evidence