The Autonomy Slider¶
The Spectrum¶
Autonomy isn't binary — "human does it" vs. "AI does it." It's a slider with positions between those extremes. Andrej Karpathy calls this one of the defining mechanisms of effective AI applications: "Build Iron Man suits, not Iron Man robots." The suit augments — the human stays in the loop, making decisions. The robot operates independently. In 2026, the suit is the right model.
The slider has five practical positions:
| Position | Human Role | AI Role | Example in Your System |
|---|---|---|---|
| Operator | Directs every action | Executes what you say | You write the analysis logic line by line |
| Collaborator | Works alongside AI | Co-produces with guidance | You and AI pair on the analysis engine |
| Approver | Reviews before execution | Proposes actions, waits for approval | AI drafts an alert; you review before it sends |
| Monitor | Watches for problems | Acts autonomously within constraints | Data ingestion runs on its own; you check logs |
| Observer | Reviews after the fact | Fully autonomous | Dashboard refreshes automatically; you audit periodically |
You've already been moving along this slider. In Lift 1, you were the Collaborator — working alongside AI to build features. In Lift 2, you added evals that let the Monitor position work safely. In Lift 3, worktrees and quality gates moved more work to the Monitor and Observer positions. This lift is about making those positions deliberate rather than accidental.
The Reversibility Principle¶
The single most important factor for where you set the slider: can you undo it?
Reversible actions — reading data, running analysis, generating draft reports, modifying code in a branch — are safe for higher autonomy. If the system gets it wrong, you fix it. No permanent damage.
Irreversible actions — sending an alert to field teams, deploying to production, deleting data, notifying stakeholders — need lower autonomy. Once an alert goes out, you can't un-alert the field team. Once a wrong danger assessment reaches an operations manager's dashboard during a storm cycle, the consequences are real.
The reversibility principle maps cleanly to your system:
| Component | Reversible? | Slider Position | Rationale |
|---|---|---|---|
| Data ingestion | Yes — re-fetch if wrong | Monitor | Bad data is caught by analysis or evals |
| Analysis engine | Yes — re-run with corrections | Monitor/Approver | Wrong assessments are caught by evals before they leave the system |
| Alert: "Extreme" danger | Partially — field teams are notified | Approver or Collaborator | High-stakes, real-world consequences; human reviews before dispatch |
| Alert: "Low" danger | Yes — low consequence if wrong | Monitor | Low risk; auto-send with logging |
| Dashboard update | Yes — refresh corrects it | Observer | Self-correcting on next data cycle |
| Analysis model change | No — affects all future outputs | Approver | Changing how the system thinks requires human judgment |
| Golden dataset update | No — changes the standard of truth | Collaborator | The answer key itself should never be modified autonomously |
Notice that different components of the same system sit at different positions. That's the point — the slider isn't one setting for the whole system. It's a per-component decision based on reversibility and consequence.
Human-in-the-Loop vs. Human-on-the-Loop¶
Two patterns for how humans relate to autonomous systems:
Human-in-the-loop: The human approves before execution. The system proposes; the human decides. This is the Approver position — safe, but it doesn't scale. If every alert requires human approval, you're back to being the bottleneck. And at high volume, approval becomes rubber-stamping — meaningless clicks that don't actually catch problems.
Human-on-the-loop: The system acts autonomously within defined constraints. The human monitors and intervenes only when something is anomalous. This is the Monitor position — scalable, but it requires trust. That trust comes from the infrastructure you've built: evals that catch wrong answers, structured logging that shows what happened, quality gates that block deployment on regression.
The risk of human-on-the-loop is that "monitoring" degrades into "not watching." The risk of human-in-the-loop is that "approving" degrades into "rubber-stamping." Neither pattern is safe without the measurement infrastructure from Lift 2.
Team Activity: Map Your System¶
Format: Mob Session Time: ~3 minutes Setup: One person drives, everyone contributes.
On a whiteboard or in a shared doc, list every component of your system: data ingestion (UAC, NWS, SNOTEL), analysis engine, alert generator (by danger level), dashboard, golden dataset management, skill updates, deployment pipeline.
For each component, place it on the autonomy slider and state why: - What position? (Operator / Collaborator / Approver / Monitor / Observer) - What's the reversibility? (Fully reversible, partially, irreversible) - What's the consequence of a wrong output? - What infrastructure supports this position? (Evals, logging, quality gates)
Discuss: Did you agree on every position? Where did the team disagree? What does disagreement tell you about where the line should be?
Key Insight¶
The autonomy slider is a per-component design decision, not a system-wide setting. The reversibility principle determines where each component should sit: reversible actions with low consequences can run at higher autonomy; irreversible actions with real-world impact need human approval. The infrastructure from Lifts 2 and 3 — evals, structured logging, quality gates — is what makes the Monitor and Observer positions safe. Without that infrastructure, high autonomy is high risk. With it, you can deliberately choose where to trust the system and where to stay in the loop.