Phase 1 · Execute
Pair on the problem. Let AI execute.
Turn a real ticket into shared, testable intent and a bounded change your team can accept.
The program at a glance
One shared practice. Five phases.
- Phase 0 · Suggested week 0
Prepare
Pod, backlog, access, baselines, tools, and structure.
Explore phase - Phase 1 · Suggested week 1
Execute
Agree the design together before generating a change.
Current phase - Phase 2 · Suggested week 2
Guardrails
Keep changes reviewable and run the quality gates.
Explore phase - Phase 3 · Suggested week 3
Trust
Use AI to understand, explain, and debug the code.
Explore phase - Phase 4 · Suggested week 4
Scale
Transfer the playbook with coaches and rollout waves.
Explore phase
Your destination
What success looks like at the end of this phase
The pair has completed multiple real tickets and can confidently take a new ticket through shared design and code generation. Repository notes and early reusable skills are emerging. Engineers enjoy the increased pace and can identify the quality concerns that Guardrails must address next.
The performance step
Spend less time on avoidable rework.
- What improves
- Agreeing intent before generation reduces late behavior decisions. The pair spends more of its time moving a specified change toward acceptance.
- What to measure
- Compare review revisions, time waiting for clarification, and start-to-acceptance time for representative tickets. Record ticket complexity alongside the result.
- Build on it
- Take the repeated sources of rework into Guardrails and turn them into shared checks.
Where you are now
Code arrives quickly, but the team spends time correcting assumptions or deciding what a ticket meant after implementation has started.
What you will learn: Plan, generate, inspect, and validate a representative change with your pair.
What to do in this phase
Step 01
Establish ground truth in the repository
Before asking AI to change code, have it analyze and document the repository structure. Verify the description against the source and actual behavior. Reuse or update README.md for workflows, ARCHITECTURE.md for architecture and data flows, AGENTS.md for AI instructions, SECURITY.md for boundaries, and architecture decision records (ADRs) for key decisions. Useful, accurate context matters more than creating empty documents.
Step 02
Receive → Pair → Discuss → Document → Generate
Work in pairs. Receive the ticket, discuss the solution, and document the agreement before generation. Use the daily deep standup to resolve the problem and assumptions, security and authorization, edge cases and errors, tests, observability, and rollback. Product resolves intended behavior; QA helps define the checks. Humans make the key decisions before AI accelerates implementation.
Step 03
Keep each task bounded and testable
Give each prompt one clear task. Break a large ticket into useful, testable subtasks before implementation. A ticket may take several focused prompts and iterations; success is accepted work, not finishing in one prompt. Record what is included, excluded, and still undecided.
Step 04
Plan, generate, inspect, and grow
Use an explicit plan before generation. Start with a small change, inspect it with your partner, run the agreed checks, and compare behavior with the specification. Resolve missing intent when the output drifts. Expand only as you understand and validate the work; keep review and release safeguards active from the first change.
Step 05
Repeat on more tickets and capture what works
Rotate who leads planning and checking. Complete multiple tickets, then save useful Markdown context and early skill workflows. Bring both the progress and the worries to the coach: review load or quality anxiety is a reason to strengthen controls, not to ignore the concern or keep generating larger changes.
Your working session
Try this with your team
Write a specification for a real ticket in your team’s working document. Have your partner explain the intended behavior back before generation. Produce a small increment, review it, and carry the representative ticket through acceptance. Rotate the planning and checking roles on the next cycle.
Make this: A reviewed specification, verified context note, accepted change with validation, and a record of corrected assumptions.
See it on the page The invitation specification →
Use a practice guide when you reach this step:
A worked example
For “invite a colleague to a workspace,” first agree who may invite, which workspace owns the invitation, and how existing members, expired invites, and delivery failures behave. A first increment can validate the inviter and record the invitation using existing patterns. Explicitly defer external email delivery to a specified increment. This partial implementation does not prove the full invitation journey works.
How success feels
- We can take a ticket, agree on the problem, and generate useful code.
- The pace feels exciting; we are also asking whether our quality checks can keep up.
- Pairing and shared context help us steer the work when the first output is wrong.
Use the signals below to check your progress with the team.
Signals of success
- Multiple representative tickets have been completed with agreed acceptance checks.
- Both engineers can lead the ticket-to-generation workflow, using several focused prompts where needed.
- Pairing is part of the actual working routine.
- Verified Markdown context and reusable skill drafts are being created and used.
- The pod can name specific quality or review concerns to address in Guardrails.
If you are stuck
- Prompts keep expanding. Stop generation and resolve the missing decision in the specification.
- The diff is hard to review. Split it by behavior or risk and validate each useful increment.
- One person does everything. Rotate who plans, operates, and checks.
Coach checkpoint
Before you move on
Bring multiple completed tickets, their specifications and checks, and the emerging repository notes and skills to the coach. Both engineers should be able to explain the shared design and guide code generation. Carry the quality concerns into Guardrails; if this workflow is still inconsistent, repeat a smaller ticket with the pair.
Your next action: Show the coach your completed tickets, the prompts and decisions that shaped them, and the quality concerns to work on next.
Reading independently? Use these questions for self-review. Discuss participation and artifact feedback with a coach through a cohort enquiry.