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

The AI-Native Team Operating Model

Once agents write most of the code, the highest-leverage review moment isn't the diff anymore — it's the spec and the harness that produced it.

Hiring signal: Naming spec owner, harness maintainer, and eval owner as real team roles — not just 'everyone reviews everything' — is the organizational vocabulary that shows you've thought about how a team actually operates at AI-native scale, not just how one engineer does.

What you will learn

Name the three new team roles an AI-native operating model requires: spec owner, harness maintainer, eval owner
Explain why the primary review activity shifts from code review to spec and harness review
Describe the three daily rituals of an AI-native team: spec review, eval review, harness regression check
Route a real PR's changes to the correct owner role based on what actually changed

Introduction

The AI-Native Team Operating Model

A twelve-person engineering team, each now orchestrating agents that generate most of their code, notices something their old org chart never anticipated: nobody actually owns the spec files. Nobody's job is specifically "make sure the harness's approval gates stay coherent as the team adds new tools." Nobody tracks whether the golden-set of past incidents is actually growing as new incidents happen, or just sitting there from the one time someone set it up. These weren't roles the team needed before, because specs, harnesses, and eval suites weren't first-class artifacts anyone had to maintain — they were incidental to "the code," which was the thing the old org chart was built around owning. Once agents write most of the code, the artifacts that actually determine quality shifted upstream, and the team's roles hadn't shifted with them.

Three new roles

An AI-native team needs explicit ownership of three things that didn't used to need a named owner: a spec owner (or several, per domain) who maintains spec quality and governance — ensuring specs stay implementation-agnostic per c12-01-2, that same-commit updates actually happen per c12-01-4's drift gate, that ambiguous specs get clarified before they cause a generation mismatch. A harness maintainer who owns the harness spec, the approval-gate configuration, and the regression suite from c12-04-5 — the person who catches a new skill silently conflicting with an existing rule before it ships, not after. An eval owner who maintains the golden-set from c12-07-4, making sure every real incident's postmortem actually becomes a permanent test case rather than a closed ticket nobody follows up on.

These roles don't replace engineers who write code — they're additive
A spec owner, harness maintainer, or eval owner isn't necessarily a separate person from the engineers generating features with agents — on a small team, one person might hold two or three of these roles simultaneously. What matters isn't a large new headcount; it's that these responsibilities are explicitly assigned to someone, rather than implicitly nobody's job, which is exactly the gap the twelve-person team discovered.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers From code review to spec and harness review, Three daily rituals, Sizing this to your team's actual scale, 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.