"We use AI to write code" can mean accepting the next line an editor suggests, or letting ship changes no person ever reads. The gap between the two is like the gap between cruise control and a car with nobody in the driver's seat. Both are useful; they need very different safeguards.

So the real question is how much autonomy to give AI for each kind of work, and what replaces a person's as autonomy grows. This lesson covers four ideas: the spectrum of autonomy, and where it belongs, specs and tests as the contract an agent works against, and the "" at the far end. It closes with where Tack and docket sit, including what they don't do.

The autonomy spectrum

Two questions place any AI coding practice: who writes the code, and who checks it before it counts.

Level	Who writes	Who checks	Minimum it needs
1. Autocomplete	the person, with suggestions	the person, while typing	nothing new
2. Chat	the model, in snippets	the person, when pasting	judgment
3. Vibe coding	the model, everything	nobody	a throwaway environment
4. Agent with review	an agent, in the codebase	the person, every change	automated tests
5. Spec-driven	an agent, from a written spec	the person, spec and change	versioned specs
6. Background agents	an agent, unwatched	the person, at the end	isolation, budgets, a record
7. Lights-out factory	agents	other agents and scenarios	all of the above, measured

Follow the "who checks" column. At level 3 nobody reads the code. From 4 to 6 a person reads it again. At level 7 automated checks take the person's place. Each step up adds its own controls, such as isolation, cost , approvals and a record of every action; Sandboxing and agent security and Governance and human-in-the-loop cover them in depth.

Vibe coding

Andrej Karpathy coined the term in February 2025 for programming where you accept whatever the model produces without reading the changes and, in his words, "forget that the code even exists" (context and quote via Simon Willison). He presented it as fine for throwaway weekend projects.

That is what it is good for: prototypes, demos and one-off tools. Willison draws a helpful line: if you reviewed the code, tested it and can explain what it does, it is no longer vibe coding but AI-assisted development.

Specs and tests as the contract

Nobody builds a house from a chat over coffee: there are plans, and an inspector checks the result against them. applies that idea. The source of truth is a written, versioned document, the spec, saying what to build, why, and how the result will be accepted. The agent builds from it, and the person reviews the spec before the code.

A spec only helps if someone can check it was met. That is why, at this level, tests are the contract: each acceptance criterion should map to an automated test the agent can't edit to make it pass. See Testing and evals for agents.

Specwhat to build, why, how it is accepted
Person reviewsthe spec, before any code exists
Agent buildsworking from the spec
Teststhe contract, out of the agent's reach
Person reviewsthe change itself

In spec-driven development the person checks twice: the plan before the work, and the result against tests the agent could not rewrite.

Background agents and the lights-out factory

A takes a task, such as an issue or a board item, works with nobody watching and hands back something reviewable, usually a pull request (a proposed change awaiting approval). Copilot's works this way (Coding agents: harnesses and skills).

The lights-out factory takes the idea to its end. In manufacturing, the term means plants that run with nobody on the floor, lights off. The most cited example is FANUC in Japan, where robots build robots and, by published accounts, can run unsupervised for weeks.

In software, Dan Shapiro proposed a five-level scale in January 2026, modeled on the levels for self-driving cars, and called the top rung the dark factory: nobody reviews the code agents produce. The best-documented public case is StrongDM's AI team, whose rule is that humans neither write nor review code. In place of review, they run end-to-end scenarios kept outside the codebase, so agents can't tune them in their favor, and test at volume against imitations of the outside services they depend on.

Tack and docket on the spectrum

In Tack

Tack covers background work (level 6). A board item becomes a run that a worker machine executes with a coding agent, and each is recorded with its events, decisions, outputs and measured cost (Introduction). A policy per request sets the agent's tools and network access, plus a spending cap (Agent Runners & Fleet Execution). What it doesn't do: it writes no specs, and in the 's code we found no step that runs your tests, reviews the change or merges it; that stays with the agent, your CI or a person. The fleet is not in a tagged release.

In docket

Leadplans, never edits code
Implementerwrites the code
- Automatic checkan optional command that must pass
Revieweroptional, approves or sends it back
Testeroptional, pass or fail
Youreview the change and commit

docket's built-in pipeline. A budget check runs before every step and stops the task when the cap is reached; the final commit stays with a person. Source: Agent Teams (Pods) · Complete Workflow Guide

Neither promises level 7. Both provide controls that level would require.

Common mistakes

Putting it into practice

Choose the level by kind of work, not by team:

Prototypes and exploration: level 3, in throwaway environments with no real data.
Products with users: level 4 or 5, so someone understands every line that reaches production.
Bounded, repeatable maintenance such as dependency updates or missing tests: level 6, with isolation, a budget and a reviewed pull request.
Level 7: only with scenarios and that have already caught real regressions, failures that can be undone, and cost measured from day one.

Sources

Go deeper

Tack's and docket's own documentation shows these controls in more detail:

Agent Runners & Fleet Execution covers how a Tack board item becomes a recorded run, the policy that limits the agent, and what a runner can and cannot promise.
Agent Teams (Pods) explains docket's roles, how the pipeline hands a task from one role to the next, and the checks between them.
Complete Workflow Guide follows one task from the queue to a commit, including the budget stop and custom pipelines that end in a human sign-off.

Key takeaways

Autonomy runs from autocomplete to the lights-out factory, and each level needs its own controls.
Vibe coding is for prototypes; taking one to production means moving to a level with review and tests.
In spec-driven development the spec is the source of truth and tests are its contract.
Removing human review is only defensible when measured scenarios, evals and checkpoints replace it.
Tack and docket provide recorded execution and governed pipelines, not a factory without people.

Check yourself

What turns vibe coding into AI-assisted development?

Someone reviewing, testing and understanding the generated code. Once you can explain it and have tested it, it is no longer vibe coding.

Why shouldn't an agent be able to edit the tests that judge its work?

It could change the tests until they pass instead of meeting the requirement. That is also why StrongDM keeps its scenarios outside the codebase.

A team wants to stop reviewing agent code by hand. What must be in place first?

Measured replacements for that review: scenarios and evals that have already caught real regressions, checkpoints before changes land, reversible failures and cost tracking. Without them, it is vibe coding at scale.