Chapter 06 · Section I · 9 min read
6.1 The two things that stay human: intent and accountability
The loop takes over the work. It does not take over the responsibility for what the work was supposed to be, or who's answerable when it goes wrong.
Everything in this course is about moving work from your hands into a machine. Chapter 5 shows what that looks like end-to-end. But two things never move: the intent behind the work, and the accountability for the outcome. When the loop ships wrong output at 3am, the loop does not answer for it. You do. This section is about what that means in practice.
Why these two stay human
Intent. The loop cannot decide what you’re trying to accomplish. It can decide how to do the thing you asked for, sometimes brilliantly, but the framing — “we care about this, not that; this trade-off, not that one; this audience, not that one” — comes from you. A loop with no intent produces impressive output at speed and it is the wrong impressive output. That’s the worst of both worlds.
Accountability. When something goes wrong, someone owns it. Regulators want a name. Customers want an apology. Your team wants to know what changed and who’s fixing it. “The loop did it” is not a valid answer. The loop is a machine you designed and deployed; you are the answer.
These two responsibilities scale with what the loop can do. A loop that drafts internal Slack summaries carries small intent + small accountability. A loop that files tax documents carries big + big. The math never changes: whatever the loop’s blast radius is, you own it.
How to hold intent explicitly
Not in your head. Written down, alongside the loop:
- A one-paragraph statement of what the loop is for. In plain language. Read it every time you change the loop; if the change is inconsistent with the paragraph, rewrite the paragraph or don’t ship the change.
- A short list of what it must NOT do. “Never respond directly to customer complaints — always route to a human.” “Never edit files under
apps/legacy.” “Never spend more than $10 per cycle.” Whichever things, if the loop did them, would be a real problem. - A named owner. Not a team. A person. Someone who reviews the loop’s outputs regularly, who gets the alerts, who is the answer to “who runs this?” Every loop needs one. Loops without owners rot.
How to hold accountability structurally
Accountability doesn’t stay held by force of will. It needs structure:
- Observability, real observability. You must be able to answer “what did the loop do yesterday?” without opening a debugger. If you can’t, you’re not accountable — you’re just hoping.
- A kill switch. A one-command way to stop the loop, right now. If your loop can only be stopped by editing a config and waiting for a deployment, you don’t have a kill switch — you have a wish.
- A rollback path. For anything the loop writes, updates, or ships: how do you undo it? A loop that files 500 tickets you can’t recall is a liability, not a tool.
- A regular review. Even scheduled loops that run cleanly should be sampled — maybe weekly, maybe monthly — by the owner. Not to look for bugs; to check that “correct output” still matches “what we want.” Intent drifts over quarters. Loops don’t notice.
The delegation illusion
The seductive framing is: “the loop handles this now, so I can focus on higher-leverage work.” Sometimes true. But it goes wrong when the leverage-gain is real and the accountability-transfer is imagined.
Concrete: you set up a loop to auto-approve small vendor invoices under $500. You save five hours a week. Three months in, the loop approves a fraudulent invoice, and when finance asks who signed off, the answer is either you (accountable, because you built the loop) or nobody (a compliance problem). Either way, the “leverage gain” now costs you a week of investigation and a policy rewrite.
The delegation illusion is thinking a loop makes something someone else’s problem. It doesn’t. It just moves the problem from the doing to the designing.
Roles the loop cannot fill
Regardless of how capable the models get:
- Deciding what the work is worth. A loop can produce ten drafts; you decide which one ships. A loop can flag ten anomalies; you decide which one is real.
- Owning the relationship on the other side. A customer who’s been talking to a loop is talking to you, whether they know it or not. When something goes wrong, they will expect you.
- Being the last human check on a high-stakes action. Payments, hires, fires, legal filings, medical decisions. The loop can prepare, draft, review. The last look is human by design, not by fallback.
The loop compresses the cost of everything that isn’t these. That’s the actual leverage, and it’s real. But these stay yours.
What “staying the engineer” looks like in a week
For any serious loop in production, budget an hour a week for the owner to:
- Read the loop’s summaries from the past 7 days.
- Look at any escalations and ask whether they were routed correctly.
- Spot-check three or four outputs the loop shipped without escalation.
- Ask “does the loop still match its intent statement, or has one of them drifted?”
An hour a week is nothing compared to the time the loop saves. Skip that hour for three months and you’ll pay for it in one bad week.
Check your understanding
Quick check
—