You're Not a User. You're a Cron Job.

"It's not a bug, it's a feature."
— Every engineer who shipped a human dependency and moved on

That quote became a joke. But somewhere along the way, we started applying it to people.

The feature is you.

Your tribal knowledge. Your daily check-ins. Your judgment about whether the output is trustworthy. Your muscle memory for which edge case to manually catch before it hits prod. Your Slack message at 9am that effectively is the monitoring.

We built systems that look automated. We just forgot to tell them to run without us.

🏗️ Self-Service (Terms and Conditions Apply)

I spent time on a team building self-service provisioning workflows. The pitch was solid: users submit a request, the system handles the rest, no tickets, no waiting on ops. Autonomy at scale. Good story.

The reality: the workflow would start, hit a wall, wait for a human to intervene, resume, hit another wall, wait again. Not always obviously — sometimes it was a bug. Sometimes a hard constraint we hadn't abstracted away yet. Sometimes tech debt we'd rationalized as "we'll come back to this." The happy path worked maybe 60% of the time without someone poking it.

We shipped it anyway. Called it done. Put it in the release notes.

And here's the part that sucked: nobody was lying. We genuinely believed the workarounds were temporary. We genuinely thought the happy path coverage was good enough to call it self-service. We'd just quietly absorbed the gap into headcount and habits and called it operational overhead.

The system wasn't self-service. The humans were.

In other words: the software didn't work for the user. The user worked for the software. We just never put it in the design doc that way.

💀 What Happens When the Load-Bearer Leaves

At a startup I was at, we had a daily batch job. Ran every morning. Had been running for months without incident. No alerts firing, no complaints, no drama — the kind of thing you stop thinking about because it's boring and boring is good.

Then the engineer who built it left the company.

No code changes. No deploys. No config drift. The job started failing within two weeks.

Turned out the job's "reliability" wasn't reliability. It was maintenance — quiet, invisible, absorbed into one person's morning routine. He knew which environment variable occasionally needed a nudge. He knew when the upstream data source would be weird on the first Monday of the month. He knew what "success" actually looked like versus what the exit code said. When he left, the job didn't lose a maintainer. It lost its runtime.

That wasn't the only one. Our search implementation had docs. Good docs, even — clear, detailed, confident. The problem was the actual implementation looked nothing like them. It never had. The person who built it had carried the delta in his head for the entire time he worked there. The docs described the system he'd intended to build. His memory was the patch between intention and reality. When he left, both were gone.

Two systems. Two different failure modes. Same root cause.

People as documentation. People as config. People as the invisible layer between what the system claims to do and what it actually does.

We don't put that in the architecture diagram. We should.

🤖 AI Is Just the Latest Version of This

I want to be careful here, because I'm not making a doomer argument about AI. I think AI is genuinely useful and I use it constantly. But I do think we're actively choosing not to look at something.

Most AI capability in production today is load-bearing human in a trench coat.

Think about what it actually takes to run AI effectively:

• The prompts you write and refine and rewrite when the output drifts
• The context you have to explicitly construct because the model doesn't have it
• The skills and tools you define so it can do anything useful beyond text
• The system instructions you have to think through and maintain
• The judgment calls about when the output is good enough to use
• The PR review on AI-generated code, because you still have to catch what it gets wrong
• The correction loops when it confidently hallucinates a dependency or a schema
• The agentic scaffolding someone has to build, deploy, monitor, and update
• The human empathy baked into every prompt so it doesn't produce something technically correct and completely wrong for the actual user

That's not a knock on the technology. That's just an honest accounting of the labor.

And I know the roadmap argument: this is temporary, the models will get better, the scaffolding requirements will drop, eventually it's fully autonomous. Maybe. But I've been watching that horizon move for long enough to be skeptical of when. And I think there's a version of this conversation we're not having publicly because the industry is too invested in the current narrative.

Right now, in 2025, most production AI systems are self-service provisioning that requires heavy human intervention to complete the overall intent of the workflow. We're calling them done. We're shipping them to release notes. We're absorbing the gap into habits and operations and daily rituals and calling it "human in the loop" like that's a feature instead of a load-bearing wall.

I've started asking a different question before we ship anything AI-powered: what happens when the person who set this up leaves?

Because I've seen that movie. I know how it ends.

🔍 How to Know If You're a Dependency

A few diagnostic questions. If you're honest with yourself, you'll know:

1. Could someone else run this cold? Not a senior person, not someone with institutional context — a capable engineer with only the docs. If the answer is no, you're load-bearing.
2. What happens if the person who built it disappears? Not "what's the runbook" — what actually happens, in practice, given the gap between your runbook and your implementation?
3. How often does the "automated" workflow require a human action to complete? If the answer is "sometimes" and you haven't defined and bounded that, the answer is effectively "always."
4. Is your AI setup documented to the point where someone could pick it up and maintain it? Or is the system prompt living in one engineer's head, the context strategy assumed rather than written, and the evals nonexistent?
5. Are you monitoring the system, or are you being the monitoring?

The difference between automation and theater is whether the system can tell you when something's wrong, or whether you're the one who notices.

🧱 Build for the Person, Not the Workflow

Here's the honest version of what I've come to believe:

Good systems reduce the amount of human knowledge required to operate them. Not to zero — that's a fantasy — but directionally, over time, the knowledge required should be in the system, not in the people.

That means:

• Error messages that explain what actually happened and what to do about it
• Workflows that either complete the intent or fail loudly and specifically, not silently or partially
• AI setups treated like production software: documented, versioned, monitored, with defined failure modes
• Honest labeling — if it requires human intervention, it's not self-service, it's assisted service, and that's fine, just say so
• Runbooks that are actually tested, not aspirational prose

The compromise move — shipping the human dependency and planning to fix it later — almost never resolves. It calcifies. It becomes the system. And then someone leaves, and you find out what the system actually was.

I'm not saying don't ship until it's perfect. Ship early. Ship often. Just be honest about what you're shipping. If the human is a dependency, make them a documented dependency with a plan, not an invisible structural member you discover is missing when the floor caves.

UI will always be more human than AI. That's not a limitation to route around — it's the point. Build for that person.

Final Thought 💭

Every system eventually gets tested by the people who weren't there when it was built.

The question isn't whether the system works with you in the room. You'll always make it work with you in the room. The question is whether it works when you're not.

If the system only runs because you showed up today, you're not operating software. You're doing standup for it.

Build the kind of system that can survive your absence. That's not a heroic standard. That's just engineering.