Lights Out, part 3: running the nightshift | Dibran's Blog

4 216 words

Share ↗

Meet Dobby<br>We named our agent Dobby, after the house elf in Harry Potter. It was meant as a joke and turned out to be the most accurate architecture decision we made all year. Dobby is tireless, eager to please, occasionally does the wrong thing with enormous enthusiasm, and, crucially, he is a free elf. He has his own identity, his own set of clothes, and a very short list of things he is actually allowed to do. He works while we sleep.

Dobby. Tireless, eager, and a free elf.

The two previous posts in this series argued that the adoption question is settled and that the discipline you already know is what makes agents useful. This post is the operational one. It is about what it actually takes to have an agent do real work overnight, and about the least glamorous truth of the whole endeavour: the hard part was never the agent.

Let me start with the anti-pattern, because most teams are living in it and calling it adoption.

Stop working the casino floor<br>Walk through most engineering orgs that have gone agentic and you will see the same thing. A developer with three terminals open, an agent running in each, and a human whose entire job has quietly become pressing Enter. Approve this command. Approve that edit. Yes, continue. Yes, continue. Yes, continue.

Engineers are nowadays much like old people in the casino, just slamming the enter button.

I call these the casino developers. They are sitting at three slot machines at once, pulling levers, occasionally getting a payout, mostly feeding the machine. It feels like leverage because there is a lot of motion and the tokens are flying. But look at what the human is doing. They are the bottleneck, the babysitter and the audit trail all at once, and they are doing all three badly, because you cannot supervise three streams of confident output at machine speed. Karpathy’s warning from part 1 lands here. The discrimination muscle is the only one being used, and it is being used past exhaustion.

Synchronous agentic coding is a trap. It caps your throughput at exactly one distracted human’s attention, it turns your best engineers into approval clerks, and it produces the specific brand of plausible garbage that makes people conclude the tools do not work.

The alternative is asynchronous agentic coding. You do not sit next to the agent. You give it a well formed unit of work, a place to do it, an identity to do it with, and a way to hand the result back for review. Then you walk away and do something a human is actually good at. The agent’s output arrives as a pull request, on its own schedule, to be reviewed like any other pull request. Nobody pulls a lever. Nobody hits Enter at 2 a.m.

Dobby working an asynchronous task on its own, producing a pull request without a human pressing Enter.

Everything below is what walking away actually requires. It is more than it sounds.

The sandbox is the workplace<br>You cannot walk away from an agent running on your laptop. You just can’t. Part 2 spent a whole post on why: the laptop holds your SSH keys, your cloud sessions, your .env files, and an agent acting with your identity is one poisoned issue comment away from being an exfiltration tool. Async coding is impossible to do safely on the host, because async means unsupervised, and unsupervised on the host is the Replit story on a timer.

So the first thing Dobby needs is a workplace that is not your machine. You can buy this off the shelf. Coder, Daytona, Firecracker microVMs, Dev Containers and a plain Kubernetes pod farm all get you there. We ended up building our own, for reasons I will come back to at the end, but the plumbing is not the point. The point is that Dobby’s workplace is:

Disposable. Spun up per task, torn down after. A compromised workspace has a lifespan measured in the length of one job, not one laptop’s career.

Reproducible. This is where prebuilt images earn their keep. Dobby does not apt-get his way to a working environment at midnight and hope the network holds. We ship him prebuilt Docker images that contain the entire stack: language runtimes, build tools, linters, the test harness, the database he tests against, the whole lane from part 2 already painted on. When Dobby starts a job, the bumpers are already up. He is not assembling the bowling alley, he is bowling.

Actually able to build the thing. Here is the wrinkle nobody warns you about. Containers are great until you need to build an iOS app, and Apple’s toolchain does not live in a Linux container. So one of Dobby’s workspaces is a Mac Mini sitting on a shelf, enrolled as a build node, running Xcode. Same identity model, same guardrails, same disposability where we can manage it, but real Apple silicon, because you cannot docker run your way to a signed .ipa. If your product touches native mobile, plan for this early. It is the one part of the setup that is physical.

The mental model to hold: you are not...