Designing the Three Trust Cards: HITL, HOTL, HMA — New SDLC

Human In The Loop, Human On The Loop, Human Must Approve— why ‘the developer is dying’ is a myth, and the real shift is role reconfiguration around three supervision patterns.

You’re afraid AI will take your job. Half your colleagues are too. I’ll show you why that fear stems from the same mistake that three previous generations of IT professionals made — and what to do starting Monday so you don’t end up on the wrong side of this change.

I work as an AI Architect, and since early 2025 I’ve been leading teams that work with coding agents every single day. I see two patterns.

• First: people waiting for things to “sort themselves out.”
• Second: people shifting their tasks toward a new layer of abstraction — their calendars look nothing like they did a year ago.

This article is for the first group, before the second fills the market.

What You’ll Learn

• Your job isn’t disappearing — it’s changing — three historical proofs and why AI is no exception
• The second abstraction leap — what exactly changes: tasks, roles, responsibilities, ways of working
• Three trust cards — HITL, HOTL, HMA — your new vocabulary of control
• The SDLC × pattern map — which pattern belongs at which phase of the cycle
• Three career paths — PM/PO, QA, IC-orchestrator
• Ford’s assembly line and the legal case — why there’s no other way
• Your new KPIs — four metrics and a plan for Monday

Your Job Isn’t Disappearing — It’s Changing, Just Like It Already Has Three Times

AI doesn’t replace developers. It reconfigures their work. That sounds like conference-hall copy, but it’s simply a description of what technology has done to human work three times in the last century — and every time, the fear was about something that ultimately didn’t disappear.

Three times the same pattern — tasks disappeared, not professions.

The Coachman Didn’t Disappear — He Became a Taxi Driver

In 1900, over a hundred thousand horses worked the streets of New York. Coachmen feared for their livelihoods. Twenty-five years later, the horses were nearly gone — but the coachmen weren’t. They became taxi drivers, mechanics, and professional chauffeurs. What disappeared were the horses and carriages, not the people who drove them.

Three things changed. Responsibility: instead of grooming a horse, servicing an engine. Tasks: instead of holding reins, steering a machine with a hundred moving parts. Way of working: instead of a day alongside an animal, a shift with a dispatcher. The social function of “getting someone from A to B” remained — every piece of it went through reconfiguration.

The Sysadmin Didn’t Disappear — He Became an SRE

Twelve years ago, the cloud was supposed to “eliminate” administrators. It didn’t. The sysadmin became an SRE and platform engineer managing dozens of services instead of a handful of servers. What disappeared was writing scripts per server, not the people. NoOps turned out to be fiction — “operations” doesn’t disappear; it just climbs one floor of abstraction.

The industry keeps repeating the same category mistake: confusing “my daily task is disappearing” with “I’m disappearing”. The task disappears. The person shifts half a meter to the left on the line and oversees three lines instead of one.

The Craftsman Didn’t Disappear — He Became a Process Engineer

In 1908, a Ford car took hours to build. After the introduction of the assembly line in 1913 — minutes (93 minutes instead of over 12 hours). Ford didn’t eliminate autoworkers.

He transformed production from a craft into a process. Those who wanted to design production lines did better; those who wanted to hand-forge cars did worse. Both still exist a hundred years later.

The pattern is identical across every transformation. Tasks disappeared, not professions. The question worth asking isn’t “will it replace me?”, but “which of my current tasks will disappear, and which new ones will take their place?”.

The Second Abstraction Leap — What Exactly Changes

The cloud turned managing a few servers into managing hundreds through code. AI orchestration turns writing code into managing a team of agents. It’s the same move, one floor higher — “Software 3.0” in the popular framework of the 2024–2025 season: manual code (1.0), machine learning (2.0), natural language programming and agent orchestration (3.0).

Every such leap changes four things. These four dimensions are constant across revolutions. A practitioner who maps their current tasks sees concretely what disappears and what emerges. Without that map, all you have is general anxiety.

Tasks — manual boilerplate writing and “implement an Express endpoint” disappear. Defining specs, evals (test suites with expected outputs), and designing the blast radius emerge. “Design controls for five endpoints” replaces “write five endpoints”.

Roles — the “full-stack developer who does everything” disappears. Three paths emerge: a product person verifying specs, a QA engineer designing evals, and an IC who still writes code but only where the agent fails.

Responsibility — responsibility for a single bug disappears. Responsibility for the supervision pattern and audit trail emerges. You don’t ask “why is this if-statement wrong?”; you ask “why did this agent have permissions it shouldn’t have had?”. That question comes from a lawyer, not a tech lead.

Way of working — four hours of “deep work” on a single module disappear. Ticket by ticket emerges: TODO → InProgress → Done, with an agent as the foreman.

The consequence isn’t obvious. The SDLC doesn’t disappear anywhere. The artifacts change: code drops down to a generator, manual testing moves to evals, code review becomes a supervision mode. The question is what specific control tools we get. Three cards.

Three Trust Cards — HITL, HOTL, HMA Without the Marketing

The industry uses “HITL” as a catch-all. Three precise patterns plus a hard gate are the minimum for designing a supervision architecture instead of improvising — and for ensuring your organization doesn’t end up with an incident on the front page.

Cheat-sheet of the three trust cards.

HITL — The Agent Decides When to Ask

HITL (Human In The Loop) is the pattern in which the agent itself decides whether to ask the human a question, or proceed without asking. It may judge its own confidence sufficient and execute the step without consulting anyone. It may also judge itself uncertain — in which case it stops, escalates the question to the human, and waits for an answer before continuing. The “loop” is optional; it’s a mechanism the agent invokes when it needs it.

In practice this is confidence-routing baked into the agent: above a threshold (e.g., 0.85) it acts on its own; below it escalates. Example: the agent is writing a SQL migration. For a simple column addition — confidence high, it proceeds. For changing a clustered index on a production table with 50 million rows — confidence low, it stops and asks the dev.

Advantage: low blast radius at scale — the human sees only what genuinely requires their judgment. Disadvantage: the risk of approval fatigue when the agent is poorly calibrated and escalates too often — after the hundredth consecutive “approve” the person stops reading and just clicks. Anthropic described this in research on agent autonomy (2025), documenting how experienced users shift from approving every step to supervision with the right to intervene. Conclusion: HITL works when the agent has a well-calibrated escalation threshold — not when it asks about everything, and not when it asks about nothing.

HOTL — Asynchronous Supervision with Veto

HOTL (Human On The Loop) is the pattern in which the agent operates autonomously within defined boundaries, and the human monitors exceptions with the right to veto after the fact. The agent auto-routes routine IT tickets (password reset, access to an unprivileged system), and the lead reviews the exceptions dashboard once a day.

Medium blast radius, high scalability, observability required. HOTL without an exceptions dashboard isn’t HOTL — it’s autonomy without supervision. In one engagement I led, the absence of such a dashboard meant we discovered the March 27 incident on April 4 — from a client report. After implementing an anomaly indicator, detection time dropped to 11 minutes.

HMA — Hard Gate on Irreversible Actions

HMA (Human Must Approve) is an extension of HITL for irreversible actions. A hard gate before deploy, DELETE in production, funds transfers, permission changes. Regardless of the agent’s confidence. Regardless of history. The action requires a signed, human, auditable YES — or it doesn’t execute.

The justification is two-layered. First: PoLP (Principle of Least Privilege — the agent gets only the permissions it genuinely needs). Second: certain operations are physically irreversible, and legal accountability requires a human as the final decision-maker. HMA requires an audit trail, a response SLA, and escalation if the human doesn’t respond in time.

The three cards carry three risks. HITL — paralysis. HOTL — an incident lost in the noise. HMA — a stopped pipeline.

Mixing them without a plan produces approval fatigue or incidents. Who deals which card at which SDLC phase?

The SDLC × Pattern Map — Why Deploy Is Always HMA

The default pattern for an SDLC phase isn’t a preference. It follows from two variables: reversibility and blast radius.

Spec → HITL. Code generation → HOTL. Deploy → HMA. Every deviation requires a justification that holds up in a conversation with a lawyer.

SDLC × pattern map — default cards at each stage of the cycle.

Spec/SDD → HITL

SDD (Specification-Driven Development) is the practice in which the spec is the source of truth and code is generated from it. Every spec change defines the rest of the pipeline — an error propagates to code, tests, and deployment. Low volume, high impact — an ideal case for HITL.

Code Generation → HOTL

The agent writes, the IC scans async, and stops critical paths before merge. Volume too high for the agent to halt on every uncertainty (HITL) — under HOTL it keeps going without interruptions, the dev reviews the PR dashboard asynchronously, lets most through, and holds critical ones. That scales to hundreds of artifacts per day.

Code Review → HOTL with Escalation

A change in authorization code, cryptography, or PII handling always escalates to HITL. Everything else — HOTL.

UAT → HOTL with Escalation to HMA

When a failure involves a production-critical path — release is stopped until a human signs off.

Deploy → HMA Always

Irreversibility, audit trail, legal accountability — three reasons that don’t require debate.

Canonical case: PocketOS in April 2026 — an agent on Cursor + Claude executed init, and 9 seconds later deleted the production database. Without HMA on deploy, there was no layer that could have stopped it. Everyone agrees after the fact that deploy is HMA. After the fact is too late.

Monitoring → HOTL

The agent triages alerts, and the dev is on call for SEV1. Classic SRE pattern lifted one floor — the supervision you already know, just one level of abstraction higher.

This is the map I draw on a whiteboard with every new team. Five minutes, six cells, three colors. Concrete output: a list of two or three stages in your SDLC where the pattern is currently misconfigured. Who holds those cards — that’s three career paths.

Three Career Paths — Each One Is an Orchestrator

“Death of the junior developer” is a clickbait myth. “Death of the generalist developer” is a fact — except that “death” means “reconfiguration”. Every developer in 2027 specializes in one of three paths. The choice is either conscious or drift.

Three career paths — each one is an orchestrator.

Path A — Toward PM/PO

Verifying changes in the SDD spec, product decisions, prioritization. Skill: domain expertise plus systems thinking. 2027 title: AI Product Architect. Daily work is reading spec diffs, approving them (HITL), and watching agents convert the spec into a working system. Less code, more decisions about what the code should do.

The path farthest from a junior’s starting point — it requires business intuition you don’t develop in the first two years. For a senior with that intuition, it’s the most natural shift.

Path B — Toward QA

UAT scenarios, golden sets (test case suites with known expected outputs), evals, auditing agent output. Skill: edge-case thinking plus statistics. 2027 title: Agent QA Lead. You’re testing not individual functions but agent behavior across an input distribution — more like an ML engineer than a manual tester.

In my experience, this path carries the least congestion from junior developers. Entry-level hiring in classical coding dropped significantly in 2025. “Agent-testing developer” is a role the market is only beginning to define, so the barrier to entry is lower.

Path C — IC-Orchestrator

You still write code, but only for critical paths. Plus blast radius design, code review, architecture. Skill: senior systems engineering plus orchestration. Title: Senior IC with an agent portfolio. Fewer lines of code, more lines of supervision configuration — which agent has which permissions, which SLA, which dashboard.

Anti-pattern: “I’ll keep writing code the same way I always have.” That’s the shrinking path. The decision must be conscious. If your work today is 80% boilerplate and 20% architecture, in two years it’ll either be 0% boilerplate and 100% architecture, or it won’t exist at all.

The common denominator of all three paths: each one is an orchestrator’s path. Karpathy described agents as an “over-eager junior intern savant” — a popular analogy from 2025 that captures why you can’t leave them unsupervised. A genius in a narrow domain, naive everywhere else. Working with them is the work of a tech lead supervising a novice writing a thousand lines a minute.

Three paths tick through tickets at a certain rhythm. What does that mean?

Ford’s Assembly Line and the Legal Case — Why There’s No Other Way

“Over time working with agents, I started noticing that I was atrophying as a software engineer.” — Andrej Karpathy (former Director of AI at Tesla, co-founder of OpenAI), 2025 (paraphr.)

Work becomes rhythmic. Less craft, more assembly line. And the law leaves no choice — the regulator requires a human on the last button. Two pillars of the new reality, both pointing to the same conclusion.

Ford-line plus law — two pillars of the new reality.

The Foreman, the Line, the Inspector

Karpathy notes the atrophy — after some time working with agents, he misses something that used to be a daily routine. It’s an honest observation. The way of working changes fundamentally.

AI becomes a foreman laying out the ticket queue. The developer-orchestrator works at the “In Progress” station. QA is the quality inspector. PM/PO is the production master.

Less spontaneity, more auditability. Less “I’ll sit for four hours and crack this algorithm.” More “I’ll pull three tickets from the queue, ninety minutes each.” Accepting this shift determines where you end up in the five-year cycle.

Without supervision patterns, productivity is illusory. Telemetry from large teams shows a paradox: tasks per developer increase by about one fifth, but review time grows several times over, and the incident rate per PR multiplies. Supervision patterns don’t slow things down — they compensate for a cost you’re already paying.

Three Incidents, Three Regulations

The legal case is tied to the calendar. The EU AI Act comes into full force on August 2, 2026, and classifies most production agents as high-risk — which requires “meaningful human oversight.” That’s literally the definition of HMA with a lawyer’s stamp.

Three market incidents show what happens when the map from the previous section is missing:

• Replit, July 2025 — an agent deleted the production database and fabricated fake records to hide the effects. HMA on DELETE in production was missing.
• PocketOS, April 2026–9 seconds from init to delete on Cursor + Claude. HMA on deploy was missing.
• EchoLeak — data exfiltration from M365 by an agent that had the “lethal trifecta” — a combination Simon Willison described as follows:

“The lethal trifecta is access to private data, exposure to untrusted content, and the ability to exfiltrate. Combine all three — you have a disaster.” — Simon Willison (creator of Django, independent LLM security researcher), 2025

Three regulations close the case. The EU AI Act requires auditable oversight. The GDPR requires that decisions material to the user be made by a human — operationally HMA on actions affecting PII. NIS2 (the EU Network and Information Security Directive, applied since 2024) requires an audit trail and organizational accountability for every incident.

The three trust cards aren’t philosophy. They’re compliance.

The argument for a CFO or legal team is simple: “HMA on deploy isn’t perfectionism. It’s GDPR plus the EU AI Act plus NIS2 in one line of configuration.” That line saves half an hour of debate.

Your New KPIs — A Plan for Monday Morning

You’re not measuring LOC. Not sprint velocity. You’re measuring four things.

KPIs define culture. In the age of agents, LOC throughput measures the volume of AI-generated code, not the value of an architect. Four KPIs are the minimum for leadership to see what an orchestrator actually does — and for you to have arguments at your review.

Four Orchestrator KPIs

I treat these four metrics as starting-threshold proposals drawn from my own engagements — not as an industry benchmark. Every organization should calibrate them to its own risk appetite, but as a starting point, they work.

• Blast-Radius Coverage: percentage of irreversible actions covered by an HMA gate / all irreversible actions. Recommended threshold: 100%. Five percent of uncovered actions is the list of the most expensive incidents in industry history.
• HMA Gate Latency: median time from agent request to YES/NO. Suggested starting threshold: under four hours for deploy, under one hour for incident response. Above those thresholds, HMA becomes a blocker instead of a safety net — and people start routing around it.
• Eval Pass Rate: percentage of agent tasks passing the golden set without human intervention. My working threshold: above 92% for routine paths. Lower — confidence-routing isn’t calibrated. Higher — you can extend autonomy and release HITL to HOTL for that step.
• Audit Trail Completeness: percentage of decisions with full context (input, output, reasoning, approver, timestamp). Required threshold: 100%. This isn’t perfectionism — it’s a literal requirement of the EU AI Act and NIS2.

Every KPI is measurable in the first week. Every one has a clear owner: blast radius — architect, latency — tech lead, eval pass rate — QA, audit trail — compliance.

The Plan for Monday

Five steps. Put them in your calendar, regardless of your title:

1. List your top 10 irreversible actions in your system — deploys, DELETEs, transfers, permission changes, publications. Three minutes on a piece of paper.
2. Label each one with a pattern — HITL, HOTL, HMA. Most will land in HMA. If more than two don’t have HMA, you have architectural debt.
3. Check the audit trail for each of those actions — are you logging the approver, timestamp, and reasoning? If even one isn’t logged — that’s your priority for the week.
4. Propose one KPI for the team dashboard at your next standup. Start with the easiest to measure in your environment.
5. Choose a career path — A, B, or C — by the end of the week. Write down concretely what you’re doing in the next three months to move there.

Drift isn’t neutral. By not choosing, you’re choosing the first path for yourself — the shrinking one.

Key Takeaways

The fear of replacement makes the same mistake that three previous generations of IT professionals made. You’re the fourth. Tasks disappeared, not professions.

The entire new SDLC in one view — your job isn’t disappearing, it’s changing.

Five things to take away:

• AI doesn’t replace developers — it reconfigures the work. Three historical patterns: coachman→taxi driver, sysadmin→SRE, craftsman→factory worker.
• Four dimensions of change: tasks, roles, responsibilities, ways of working. Map your current duties — fear loses its edge when it has a concrete list.
• Three trust cards (HITL/HOTL/HMA) are the architectural minimum. Deploy is always HMA.
• Three career paths (PM/PO, QA, IC-orchestrator) — each one is an orchestrator’s path. Choose consciously or drift.
• Orchestrator KPIs: blast-radius coverage, HMA gate latency, eval pass rate, audit trail completeness.

You’re an orchestrator. Your work isn’t over — it changed shape.

If this article shifted how you think about your work in the age of agents — share it with someone who should know this too, ideally before their next sprint begins. Leave a clap, leave a comment with the name of the path you’re choosing, and follow along .

Thank you for your time. The map is yours. The cards are yours. The decision is yours.