Phase 9: Team Workflows & AI-Native Process · 50 min · Claude Code · Python

Process Design for Your Product

A team operating model that only exists as tribal knowledge in the founding engineer's head isn't a process, it's a single point of failure waiting for its first vacation.

Hiring signal: Producing a concrete, reusable operating-model document for a real system — not just following an existing team's process — is exactly the artifact that distinguishes someone who can set up AI-native engineering practice for a new team, not just work inside one someone else built.

What you will learn

Synthesize this phase's practices (spec governance, drift enforcement, AI code review, context/knowledge management) into one written operating model
Write a team workflow playbook that a new engineer could follow without asking a founding member to explain it verbally
Validate a playbook for completeness against the required sections a real AI-native team operating model needs
Apply the phase's principles to your own course-long product rather than a hypothetical team

Introduction

Process Design for Your Product

The founding engineer who set up a team's entire AI-native workflow takes a two-week vacation. In their absence, a spec conflict comes up between two contributors, nobody's sure who's supposed to resolve it. A PR touching the harness config sits unreviewed because nobody knows the harness maintainer is supposed to be a required reviewer — that was something the founding engineer just knew and enforced by habit, never wrote down. A new hire joins mid-vacation and gets pointed at "ask around, people will help you figure it out." None of this is because the team's process was bad. It's because the process only existed as one person's tacit knowledge, which means it wasn't really a team process at all — it was one engineer's process that the rest of the team happened to be borrowing.

What a real operating-model playbook contains

This phase built four pieces of a team's operating model, one lesson at a time: who owns what and which rituals apply (c12-09-1), how spec conflicts get detected and resolved (c12-09-2), how AI code review is configured and read with judgment (c12-09-3), and what a new hire's agent needs to be productive on day one (c12-09-4). A playbook is what makes these four pieces something the team actually has, rather than something that happened to work while one person was paying attention to all of it. It should be specific enough that a new engineer, reading it cold with no verbal explanation, could correctly answer: who reviews a spec change in this domain, what happens when two contributors edit the same criterion, which automated reviewer is primary and what its checklist covers, and where the agent-readable context lives.

The playbook is itself a spec — for how the team works, not just what the code does
Everything this course has said about specs (specific over vague, reviewed like code, kept current, treated as the source of truth) applies just as much to a document describing the team's own process as it does to a document describing a feature's behavior. A vague playbook ("we try to review specs carefully") fails the same way a vague feature spec does — it can't actually be followed or checked against, it just gestures at good intentions.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Specificity is what makes a playbook usable, not aspirational, Writing this for your own product, not a hypothetical team, Why this playbook matters beyond this lesson, Build It — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.