Chapter 7 - Scaling Beyond the Solo Practitioner

The empirical findings in this book - the ~4-session ceiling, the specific review fatigue curve, the single Merge/Integration Authority - are calibrated to one practitioner working alone. That's not a limitation of the discipline; it's an honest account of where it's been tested. This chapter addresses what likely changes and what likely stays the same when the team grows.

What probably stays desk-level

The core practices are engineering practices, not coordination practices. TDD, Spec-First Prompting, Executive Code Review, Domain Gap Surfacing, Perception-Gated Work - these operate at the level of a single developer's session. They don't require team agreement to implement; they don't change shape when a second or third practitioner is added. XP's own history is relevant here: its individual practices (TDD especially) were adopted widely by engineers working in organizations that never called themselves XP shops, with no coordination required. The same is true here.

What becomes shared infrastructure

Context Stewardship is the practice most obviously affected by scale. A CLAUDE.md maintained by one person becomes a team artifact maintained by several. The same properties that make it valuable - it's version-controlled, it's read every session, it has to be kept accurate or it misleads - make it amenable to shared ownership. The discipline required is the same as for any shared documentation: treat accuracy as a first-class responsibility, not a nice-to-have. The risk at scale is that no one person feels accountable for it and it drifts.

Agent Role Topology at team scale means decisions about which sessions hold review authority, which are implementation-only, and which hold full architectural context. At n=1, this is a session-by-session judgment call. At n>1, the topology has to be explicit - otherwise concurrent sessions from different practitioners can contradict each other's review authority without either party realizing it. This is probably the practice most in need of formalization before it can be taught at team scale.

What breaks

Velocity estimation. Story points and sprint velocity assume roughly uniform throughput among practitioners for a given complexity of work. Two developers on the same task, one with a mature agent topology and maintained context, one without, can have throughput differences that dwarf the usual variance between human developers. Traditional time-based velocity estimation becomes unreliable in this condition. The right measure shifts toward complexity and risk (how uncertain is this change, how wide is the blast radius) rather than time - which is arguably where it should have been anyway.

The Merge/Integration Authority bottleneck. A single human holding final authority over all merges works at n=1 because merge volume is constrained to what one person generates. At n>1, a single-authority model becomes an operational bottleneck. The practical resolution is explicit risk-tiering: low-risk, well-scoped, well-tested changes can be approved by any practitioner; high-risk or cross-cutting changes require a designated authority. This mirrors how review authority operates in high-performing engineering teams, but it requires risk-tiering criteria to be codified in repository context rather than held in one person's head.

The aiXP-to-org interface

The likely shape at scale: aiXP stays the desk-level engineering discipline (the way XP itself does today), while team coordination runs through whatever macro-process the org already uses - Scrum, Kanban, or something else. The interface between the two layers is the artifact: a PR, a ticket update, a demo. This matches the Anthropic Applied AI team's own "committed artifact" model, where each stage of the workflow produces a document that triggers the next stage. The artifact is the handoff, regardless of whether the next stage is another session, another person, or a CI pipeline.