Start free trial

Phase 3 · Trust

Understand and own what you ship.

Use AI to investigate unfamiliar behavior while retaining the ability to trace, test, and challenge its explanations.

The program at a glance

One shared practice. Five phases.

  1. Phase 0 · Suggested week 0

    Prepare

    Pod, backlog, access, baselines, tools, and structure.

    Explore phase
  2. Phase 1 · Suggested week 1

    Execute

    Agree the design together before generating a change.

    Explore phase
  3. Phase 2 · Suggested week 2

    Guardrails

    Keep changes reviewable and run the quality gates.

    Explore phase
  4. Phase 3 · Suggested week 3

    Trust

    Use AI to understand, explain, and debug the code.

    Current phase
  5. Phase 4 · Suggested week 4

    Scale

    Transfer the playbook with coaches and rollout waves.

    Explore phase
Follow a flexible coached cadence: weeks 0–4 are a suggested rhythm, not a guaranteed completion schedule. Guardrails and Trust can be combined with your coach when the pod is ready.

Your destination

What success looks like at the end of this phase

AI-assisted engineering is the team’s normal way of working. The pod can deliver substantial product outcomes, investigate unfamiliar behavior, and confidently use its approved release path. It has specific guardrails for agentic work and can explain how AI, a partner, tests, and controls support its understanding.

The performance step

Investigate faster. Keep ownership.

What improves
Verified shared context helps engineers navigate unfamiliar code, explain a change, and test a diagnosis without waiting for the original author.
What to measure
Record time to a verified explanation or diagnosis, how often another engineer can teach the behavior back, and the resulting fix and validation evidence.
Build on it
Transfer that understanding in Scale so a receiving pod can repeat the work with less dependence on the original pair.

Where you are now

The team produces more changes than anyone can hold in memory. Explanations may sound convincing before anyone has checked the execution path.

What you will learn: Build a sourced explanation and use evidence to test a debugging hypothesis.

What to do in this phase

  1. Step 01

    Change the way you build understanding

    Shift from needing to remember every line to knowing how to understand the relevant code. Treat AI as help with organizational memory: searchable context, sourced explanations, and investigation support. Engineers keep accountability by tracing, testing, and validating what the system explains.

  2. Step 02

    Ask → Trace → Verify → Act

    Ask AI to explain a feature. Trace the authorization and data path to actual source locations. Verify the explanation with evidence and appropriate tests. Only then act on the result or debug the behavior. Keep unknown external-service or environment behavior visible instead of allowing a plausible explanation to stand in for proof.

  3. Step 03

    Use a partner and tests to challenge the explanation

    Investigate code unfamiliar to the engineer leading the exercise. Record a hypothesis and the evidence that would disprove it. Run a bounded check, update the explanation, and have the partner teach the behavior back. Add verified findings to the repository’s shared context.

  4. Step 04

    Define guardrails for agentic development

    When agents take on more work, make their permitted scope, tool use, access, stop conditions, validation, and human approval boundaries explicit. Test those boundaries on a bounded task. Increase autonomy only within a process the team can review, understand, and control.

  5. Step 05

    Apply the method to meaningful product work

    Use the workflow on representative features or changes, not only demonstrations. Show the intended product outcome, validation, system understanding, and approved release evidence. Compare the work with the starting baseline while retaining complexity, quality, and context. AI should fit into everyday engineering decisions.

Your working session

Try this with your team

Choose an unfamiliar behavior in the representative ticket. Complete the investigation record in your team’s working document: source path, hypothesis, disconfirming evidence, bounded check, result, and remaining uncertainty. Have your partner repeat the explanation before the coach review.

Make this: A verified walkthrough, at least one tested hypothesis, and an updated context note.

See it on the page A reusable authorization skill →

Use a practice guide when you reach this step:

A worked example

An invitation appears pending after a simulated delivery failure. The engineer hypothesizes that invitation creation failed. Tracing the state transition and running a local fixture reveals that the invitation was recorded while delivery remained unresolved. The revised explanation separates stored state from provider acceptance; provider behavior still needs its own evidence.

How success feels

  • AI is part of how we normally work, and we know when to question it.
  • I know how to understand code I did not write and investigate failures.
  • We can deliver meaningful product changes while retaining ownership of their behavior.

Use the signals below to check your progress with the team.

Signals of success

  • The pod routinely uses AI for planning, implementation, comprehension, and debugging where appropriate.
  • Engineers can take a representative ticket through the approved production path with evidence.
  • Product outcomes, rather than code volume alone, are visible in the demonstration.
  • A sourced walkthrough and tested hypothesis show how the team understands unfamiliar behavior.
  • Custom guardrails for agentic work are documented, exercised, and owned.

If you are stuck

  • The answer has no source support. Ask for evidence and test the highest-impact assumption.
  • Repeated prompts disagree. Investigate the actual execution path instead of voting among answers.
  • A fix arrives before a diagnosis. Isolate the failure and write the hypothesis first.

Coach checkpoint

Before you move on

Demonstrate meaningful product work, its release and validation evidence, a sourced explanation, and an agentic task with explicit controls. The coach checks that AI-assisted work is becoming a repeatable default and that engineers can still challenge explanations and own the resulting system. Resolve understanding or control gaps before transferring the practice.

Your next action: Bring a product-outcome demonstration, verified system explanation, and agentic-work guardrails to the coach review.

Reading independently? Use these questions for self-review. Discuss participation and artifact feedback with a coach through a cohort enquiry.