Developer = agent supervisor (Yegge Stage 6-7)

In Steve Yegge's model of AI adoption stages, Stages 6 and 7 represent a fundamental shift in what a developer does. In the earlier stages (1-4), the developer uses AI as a powerful tool - for autocomplete, for generating code snippets, for answering questions - but remains the primary implementer. In Stage 5, the developer uses a CLI agent like Claude Code in "YOLO mode," delegating multi-step tasks. In Stages 6-7, the role shifts further: the developer becomes a supervisor of agent fleets rather than an implementer of code.

The supervisor role is distinct from the user role in a specific way. A user directs an AI tool and evaluates its output. A supervisor manages a set of agents working in parallel, sets goals and constraints, monitors progress, intervenes when agents go wrong, integrates outputs, and maintains quality and coherence across the whole system. The skill set is different: less "how do I write this code" and more "how do I structure this problem so agents can solve it in parallel, and how do I detect when they're going wrong before too much bad work accumulates."

Yegge describes Stage 6 as having 3-5 agents running in parallel per developer, each working on different aspects of a feature or fix. Stage 7 is the "one-shot unattended agent" model - dispatching an agent with a complete specification and reviewing the output rather than supervising the process. Both stages require a developer who is skilled at decomposing work into agent-sized tasks, writing clear specifications that agents can execute reliably, and reviewing AI-generated output at the speed that makes the whole model economically worthwhile.

The organizational implication is significant. A developer in Stages 6-7 has a different job description than a developer in Stages 1-4. The skills that matter have shifted: toward problem decomposition, specification writing, output review, and system thinking. This has implications for hiring, for onboarding, for performance evaluation, and for what senior engineering looks like in an AI-native organization.

• Represents a step-change in developer throughput - a developer supervising 3-5 parallel agents is not marginally more productive than one using autocomplete; the throughput multiplier is potentially 3-5x on appropriate tasks, which changes what is possible for a team of a given size
• Changes the skill premium in engineering - the most valuable developer skill in a Stages 6-7 organization is not writing code; it is structuring problems clearly, writing effective specifications, and maintaining coherence across agent outputs; organizations that don't recognize this shift will value the wrong things
• Requires new organizational support structures - supervision of agent fleets requires infrastructure that individual tool use does not: fleet management, cost tracking, coordination mechanisms, output review workflows; the organization needs to build these to make the role viable
• Creates a capability gap between adopters and laggards - Gartner's 40% enterprise AI agent projection by end of 2026 implies that organizations at Stages 6-7 will be competing against organizations still at Stages 1-3; the throughput difference is not a marginal competitive advantage
• Changes what "senior engineer" means - in a Stages 6-7 organization, the most senior technical contributors are those who are best at orchestrating agent work effectively; this is a different archetype than the senior engineer who is the best individual coder

1. Identify developers ready for the Stage 6 transition - Not every developer transitions at the same pace. The developers ready for Stage 6 are those who are already proficient at Stage 5 (CLI agent YOLO mode), have developed good judgment about when agent output is trustworthy, and are comfortable with the supervision model of working rather than the implementation model.

2. Build task decomposition skills explicitly - The bottleneck in moving to Stage 6 is usually not agent capability; it is the developer's ability to decompose a problem into clear, well-scoped agent tasks. Run workshops specifically on this skill: here is a feature spec, decompose it into 3-5 parallel agent tasks with clear boundaries and minimal dependencies. This skill is learnable but requires deliberate practice.

3. Develop specification writing standards - Agents work best with well-structured specifications that include: context about the codebase and existing patterns, a clear task definition with explicit scope boundaries, success criteria that can be evaluated objectively, and explicit constraints (what not to do). Build a specification template and use it consistently.

4. Define your output review workflow - Supervising agent output is a skill that needs structure. Build a review workflow: what does the supervisor check first (did the agent understand the task?), what do they check second (is the approach reasonable?), what do they check last (is the implementation correct?). A structured review workflow is faster and more reliable than ad-hoc checking.

5. Start with parallelism on non-critical tasks - The first parallel agent runs should be on tasks where a bad outcome is recoverable and the blast radius is small. Test generation, documentation, refactoring of isolated modules, and exploratory prototype code are good starting points. Don't start parallel agent runs on the authentication system.

6. Measure the throughput change explicitly - Track the output metrics for developers who have transitioned to Stage 6 versus those who haven't. The difference in feature throughput, PR volume, and test coverage will be the data that drives adoption of the supervisor model across the broader team.

Moving to Stage 6 without Stage 5 proficiency. Developers who haven't mastered single-agent task delegation are not ready for multi-agent supervision. The supervision model requires rapid judgment about agent progress and output quality - judgment that develops from experience with individual agents. Skipping Stage 5 produces developers who are overwhelmed by parallel agent management rather than empowered by it.

Writing underspecified tasks. The most common failure mode in agent supervision is a task specification that is clear to a human engineer but ambiguous to an agent. "Add tests for the auth module" is underspecified. "Add unit tests for the five methods in AuthService that currently have zero test coverage, using the patterns established in UserServiceTest.java, targeting 90% branch coverage" is a specification an agent can execute reliably.

Not building the review capacity to match the agent throughput. If each developer supervises 5 parallel agents, the output review workload grows by 5x. Organizations that add agent capacity without adding review capacity end up with large volumes of unreviewed agent output, or review that is perfunctory rather than substantive. Stage 6 requires explicitly accounting for the review time in the developer's workload.

Treating agent supervision as diminished work. Some developers resist the supervisor role because it feels less "real" than writing code themselves. This is a cultural problem that requires addressing directly. The supervisor who structures a complex feature into parallel agent tasks, monitors execution, and integrates the outputs into a coherent whole is doing sophisticated engineering work. Leadership needs to recognize and value this explicitly.

Losing codebase coherence at scale. Multiple agents working on the same codebase in parallel can produce outputs that are individually correct but collectively inconsistent - different naming conventions, incompatible abstractions, conflicting approaches to the same pattern. The supervisor's most important quality-management role is detecting and correcting incoherence before it compounds.