Practice guide
Run a deep standup
Agree on one bounded change before generation: intent, risks, checks, and ownership.
Bring one decision worth making
Use this guide in Execute when a ticket is ready for shared design. A deep standup is protected working time to settle intent before generating code. Bring the ticket, relevant repository context, current behavior, and a place to record decisions. Both engineers participate; involve product and QA in the decisions that need their input.
Choose one useful increment. If the ticket contains several independent behaviors, decide which one the pair will specify today. Carry unresolved questions forward with an owner instead of silently filling in assumptions.
A proposed 60-minute agenda
- 0–10 minutes · Agree on the outcome. Product explains the user need. State the current behavior, intended behavior, and explicit exclusions. Have the other engineer explain the task back.
- 10–25 minutes · Draw the change. Trace the request through the existing code and data. Discuss authorization, ownership, dependencies, and the smallest useful implementation. Record decisions and their reasons.
- 25–40 minutes · Challenge the design. Walk through invalid inputs, retries, permission failures, and partial failures. Decide the acceptance tests, review checks, and evidence needed. QA helps expose missed cases.
- 40–50 minutes · Make delivery observable. Agree how failures will be detected, what operators need to see, and how to reverse or disable the change. Reuse the repository’s existing release controls.
- 50–60 minutes · Commit the plan. Read back the specification. Assign implementation and checking roles, resolve remaining blockers, and write the first bounded generation task. Defer generation when an essential decision is still missing.
Use these suggested time allocations as a starting agenda and adjust them to the work.
Worked example: record a workspace invitation
Intent: an authorized workspace administrator can create an invitation for that workspace. The first increment checks authorization and records the invitation using existing patterns.
Checks: an administrator succeeds; a non-administrator is rejected; an administrator from another workspace cannot invite into this one; a retry follows the agreed duplicate-invitation rule. Record the exact expected response for each case before generation.
Boundary: external email delivery is a separate increment. An unresolved duplicate rule goes to product. An unclear authorization boundary goes to the responsible engineer. Neither is a reason for the AI to invent behavior.
First task: implement the agreed authorization and persistence behavior with the specified tests. Review the diff and results together before adding delivery.
Leave with shared intent
Your output is a short specification with acceptance checks, exclusions, decisions, open questions, owners, and the next implementation task. You are ready when both engineers can explain what will change and how they will know it works. Return to Execute and repeat the routine on the next ticket.
A working document to compare with yoursThe invitation specification →