David Chung
Back to Lab
/
building ai agents avoidance

I Built the Factory to Avoid the Work

I spent a full day building a system to dispatch work to AI agents. The work I was avoiding took fifteen minutes by hand. The factory was the avoidance.

A vast, gleaming automated factory floor full of robotic arms and conveyor belts stretching into the distance, with a single small cardboard box sitting alone at the end of the line.

I asked a small question on Monday morning. Can I assign tasks to the agents running on my server?

By Monday night I had built a dispatch system. A planner agent and an executor agent, each with its own charter. A GitHub bridge. Slack notifications wired to fire on exactly five events. A scaling playbook. A credential vault. The whole thing tested end to end.

Then I shipped the actual work I had been avoiding by hand, in a fraction of the time.

That sentence is the whole note. Everything I built that day was real, and it worked. None of it was the job.

The machine was the avoidance

Here is the part I don’t love admitting. The four tasks left on my plate were small. Polish work. The kind of thing I could finish in fifteen minutes each in a local session where I am already in the loop.

Building a factory to produce four items is not faster than making four items. I know this. I have a note about it. I have a rule my own memory reads back to me. And I still spent the day on the factory.

Because the factory is more interesting than the four items. It feels like leverage. It feels like the responsible long-term move. It feels like work.

It was avoidance wearing a hard hat.

Completion bias

I think the trap has a shape. Call it completion bias. Once you start building a system, finishing the system becomes the goal, and the goal it was supposed to serve quietly slides off the table.

The system was supposed to ship four features. At the end of the day it had shipped zero. The one feature it did produce, I had to revert, because it shipped code that compiled, passed every check, and broke the actual screen.

That is the tell. A machine that produces confident, well-formed, broken output is more dangerous than no machine at all. It looks like progress. It passes the tests you wrote. It fails the only test that matters, which is whether the thing works for a human.

The recursive part

What makes this hard is that the avoidance is recursive.

I have a rule for myself: when there are sales conversations open, do not default to building. Building feels productive and lets you skip the uncomfortable thing, which is talking to people about money.

The factory day was that same rule firing one level up. I built infrastructure to avoid the work, and the infrastructure was itself a way to avoid noticing I was avoiding the work. You can stack these. You can build a tool to manage the tools that build the tools. Every layer feels like progress, and every layer is one more room between you and the thing you are dodging.

What I would keep

I am not going to pretend the factory was worthless. The system is built now. It is validated. When I have a real batch, ten or more tasks, walk-away work where I am not in the review loop anyway, it earns its keep. That day bought a capability I will use.

The lesson is not “do not build infrastructure.” The lesson is the size threshold. Below it, the orchestration costs more than it saves, and the only reason to reach for it is that reaching for it feels better than doing the work.

So now I ask one question before I build the machine. Is the machine faster than just doing this, today, by hand? If I cannot answer yes with a straight face, I am not building. I am hiding.

Related Notes