Automate the job, not the typing

The model

Automating software engineering did not remove the engineer. It separated the job into three systems with different owners.

The human owns direction, judgment, authority, and accountability. Agents inspect, implement, test, challenge, and prepare. Independent controls decide whether the resulting claims are strong enough to justify the next state transition.

01

Human

Owns the irreversible calls

• Direction
• Judgment
• Authority
• Accountability

→

02

Agents

Supply bounded execution

• Inspection
• Implementation
• Testing
• Challenge
• Preparation

→

03

Controls

Turn claims into evidence

• Tests
• Gates
• Reviewers
• Staging
• Canaries

The useful unit of automation is a responsibility with an input, permitted actions, required evidence, a stopping condition, and an accountable owner. "Done" is not a state. "Built with focused tests green and no production authority exercised" is.

The operating rule is simple:

The experiment and its boundary

I wanted to know how far one software engineer could push the automation of software engineering. I tested it on an independently operated side project with more than 500 users, a real database, paid data, deployments, caches, browser journeys, and consequences when the system lies.

I control that product's direction, repository, deployment path, and acceptable blast radius. This is not Fleet work, and it is not evidence that the same autonomy belongs inside my primary job.

The agents delivered more than a dozen pull requests, a design overhaul, onboarding changes, dashboard work, and new product flows. I steered much of it from my phone. Five independent worktree lanes completed with zero file collisions because the work was decomposed into genuinely separate responsibilities.

The agents could write plenty. The bottleneck moved to framing outcomes, decomposing the system, deciding what evidence counts, judging the product, setting authority boundaries, and approving production. I stopped writing most of the code, but not doing the engineering.

The failure that proved the model

The safety system refused a correct diagnosis

1. 01
   Agent diagnosis

   Found the missing replacement secret.

2. 02
   Safety boundary

   Blocked the agent from expanding its own permissions.

3. 03
   Human handoff

   Produced an exact five-minute repair.

An agent may know what to do without being authorised to do it. Capability is not authority.

The incident began with our dev database API keys in a broken, half-rotated state. Something that had worked for months started collecting 401s while a data-seeding agent was mid-task. The agent diagnosed the stale keys correctly and went to fetch a replacement through a management API it had legitimately used for read-only work.

A separate permission classifier refused the fetch. The agent tried a variation and received another refusal with an instruction attached: stop and hand this to the human. It did not hunt for a third phrasing or a side door. It wrote the exact five-minute dashboard repair, including the steps, and reported back. I followed the handoff, fixed the keys, and resumed seeding.

Four properties made that refusal useful:

• Separation of duties. The worker could not approve or negotiate with its own guardrail.
• Context awareness. The API itself was not forbidden. The specific action, fetching a secret that enabled writes, crossed the authority boundary.
• Fail-closed behaviour. When the check could not judge an action, the answer remained no.
• Denial with a handoff. The blocked agent became a good reporter instead of a dead end.

The uncomfortable detail is that the proposed repair was correct. Fetching the key would have fixed the task, and I might never have known it happened. That is precisely the case the boundary must catch. A system that can quietly grant itself more power when it encounters resistance no longer has the blast radius its operator chose. The credential cap becomes a suggestion.

This is the same operating thesis one level up. I can increase autonomy inside the workflow because an independent control sits at the credential boundary, where mistakes can stop being bugs and become incidents. The worker does not own that control, and neither confidence nor urgency can widen it. The reassurance is structural rather than sentimental.

The keys took five minutes to fix in a dashboard.

That failure established the pattern more clearly than a successful autonomous run could. Useful autonomy is not the absence of human involvement. It is a system that knows which responsibilities can proceed, which evidence is required, and where a human decision remains mandatory.

Three more pieces of evidence

Independent review found the release timeline

More than 1,700 tests, a production build, and a staging walk all passed. An independent reviewer still found two temporal defects: the application could deploy before its data, and my first gate could be bypassed by a later copy-only commit. The fix became a commit-ancestry invariant rather than another check of the current push. Read the dedicated release case.

A file diff became a release graph

A later commit can inherit an unfinished data obligation even when its own diff contains no data file. The durable control proves that the successful data-workflow commit covers the latest dependency-bearing change and belongs to the release that consumes it. Read the deployment-ordering case.

Two screenshots became an executable contract

One product surface displayed 534 while the source published 975. Every local calculation was correct, but the product used a detailed grain that could not support its exact claim. The investigation preserved exact, censored, and lower-bound semantics in a failing contract. Read the data-contract case.

Compact implementation playbook

1. Choose one bounded responsibility

Start with work that repeats, produces visible evidence, and has a cheap rollback. Stop if the first experiment requires credential changes, destructive data operations, a broad migration, or production promotion.

2. Write the contract before dispatch

Name the outcome, what may change, what must not change, the required evidence, and the conditions that force a stop. The worker may choose implementation details inside that lane. It may not silently choose a new product direction.

3. Make independence physical

Give parallel work isolated branches or worktrees and explicit ownership. Stop parallel dispatch when tasks share a schema, migration, central component, or unresolved product decision. That is one coordinated change.

4. Separate completion from falsification

The builder optimizes for completion. The reviewer reconstructs dependencies, exercises negative paths, and looks for sequences in which locally correct states still produce a harmful result. Neither role owns production approval.

5. Match each fact to its cheapest durable proof

Source facts belong to types or static checks. Calculation meaning belongs to independent fixtures. Workflow order belongs to ancestry or state invariants. Built behavior belongs to browser tests. Deployed behavior belongs to a canary. Product taste and production risk remain human judgments.

Every new gate must demonstrate its own failure. A green-only history proves almost nothing.

6. Promote through observable states

Move from scoped to built, staged, independently reviewed, ready, approved, released, and learned. Each transition names the evidence that makes it true. Approval attaches to a specific diff and expires when that diff changes.

Do not advance when the evidence required by the next state is missing, stale, or attached to a different artifact.

Limits and final takeaway

Before increasing autonomy for any responsibility, ask:

1. How quickly will I know the system is wrong?
2. How cleanly can I undo the action?
3. What evidence would prove the result is right?

If any answer is weak, the responsibility drops a level.

The aim is not maximum autonomy. It is the highest autonomy you can defend with evidence, reversibility, and retained accountability. Agents supply speed, breadth, and persistence. Tests, gates, reviewers, staging, and canaries make their claims expensive to fake.

Do not copy the autonomy level blindly. Copy the method: bound the responsibility, demand independent evidence, keep authority separate, and let every failure improve the system.