Company as Code

An org chart was always a program. We just used to run it on people. The Vibe Coding Guide.

One morning I opened my laptop and a corner of the company had already done a night's work without me. The overnight numbers were pulled and turned into a briefing. The next moves were drafted. A small stack of them sat in a queue, waiting for the one thing the night couldn't supply: a yes or a no from a human. It wasn't the whole company — it was one function, marketing, the first one I'd taught to run itself. But it was enough to rearrange how I think about companies. I hadn't hired a team for that corner. I'd compiled one.

It took me a while to see what I'd actually done, and when I did it rearranged how I think about companies. An org chart is already a program. It always was. Every company is a set of rules for turning inputs into decisions: who does what, who hands off to whom, who has to sign before the money moves, what escalates and to whom. We just never called it code, because the computer running it was made of people. The boxes and lines are function signatures. The approval chain is control flow. The this is how we do things here that every company hauls around is a program — executed by humans, slowly, unevenly, with half the instructions living in someone's head and the other half in a policy nobody's read since onboarding.

That gap is the whole thing company-as-code closes. In a normal company, process exists but doesn't reliably run. There's a rule that two people must approve a refund, and most days two people do, and on the busy day someone waves it through and you find out three weeks later. The process was real on paper and optional in practice — which is the same as not existing, right up until it hurts you. Encode the org instead, and the process stops existing and starts executing. The refund cannot happen without the second approval, because the approval is a step in the program now, not a habit you're hoping people keep. It's the hard no from the last chapter, pointed at the company instead of the code: a rule made of architecture instead of words.

There's a grim old word for this that I've come to love. Bureaucracy. A German named Max Weber described it a century ago as the great administrative machine — rules applied impersonally and identically, the same way every time, no matter who's in the chair. People hear bureaucracy and picture the DMV, but Weber was describing an ideal we had never once reached, because the machine was always built out of moody, forgetful, self-interested humans who applied the rules unconsciously and bent them for friends. Company-as-code is the first time the dream is actually available. The rules don't describe the company. They are the company, and they run exactly as written, every time, for everyone. We finally built the bureaucracy that works — and the joke is that it took a machine to make a bureaucracy humane, because now no person has to be the cog that grinds it out.

So what's left for me, in the parts the machine has taken over? The gates. The thing the overnight machine couldn't supply was the yes or the no, and that wasn't an accident — I put those there. The whole system is built to run every routine thing on its own and then to stop, cold, at the handful of moments that need a human: the spend over a line, the hire, the thing we can't take back, the call that's about judgment instead of procedure. Routine executes. Judgment escalates. My job stopped being to do the work, or even to watch the work. It became to sit at the small number of gates where being a human is still the entire point, and decide.

I want to be careful here, because the easy version of this story is that the whole company already runs this way. It doesn't, not yet, and the truth is the more useful thing to tell you. I'm compiling the org chart one box at a time, slowly, on purpose — and the method is the same for every box. I take a routine that's eating someone's day, and first I give it to an intern to run by hand, because the fastest way to learn what a job actually is — the real steps, the real judgment calls, the places it quietly goes wrong — is to watch a person do it before you try to encode it. Then I automate the rote middle and leave the intern at the controls, supervising the machine instead of grinding through the work. Then, only once it's gone boringly reliable, I widen what the machine is trusted to do on its own. Run it by hand, automate, supervise, widen — and only then move to the next box. Marketing is the one I've taken all the way through that loop, which is exactly why every example I'm about to give you comes from there. The rest of the chart is still mostly people. But I've done it once now, end to end, and doing it once is how you learn that it generalizes — that the seats which used to need a salaried person were mostly routine wearing a job title, and the judgment that's actually irreducible is a far smaller thing than the old org chart pretended.

So let me show you marketing, the box I've run all the way through — the two pieces of it that are mostly machine now, and the clearest picture I can give you of what a box on the org chart is code really means. The first is the part of marketing that never sleeps: finding where people are already talking about the problem you solve, and showing up in the conversation. A scanner reads a live feed of public posts, filters the noise down to the few that are genuinely a fit, and for each survivor the machine scores it — real match or not, what's the pain, what are they actually asking for — and drafts a reply in our voice. None of it goes anywhere on its own. Each draft lands in a queue with a status on it, and a person — an intern, the cheapest and most valuable seat in the building — works that queue: read, approve, rewrite, skip. Only when a human chooses to post does a single word reach the world, and they're free to bin the machine's draft and write their own. The machine did the watching and the first pass — the tireless, attention-shredding part that used to eat a junior marketer's entire day. The human did the part that was always the actual job: deciding what's worth saying, and being the one who said it. That's a social team that's mostly software, with a person standing exactly where the judgment and the answerability live.

The second seat is stranger, because the work writes a version of itself. The same pipeline that turns a recorded class into lessons also spins those transcripts into search-built articles — shaped to a strict template, answer-first, structured the way a reader and a search engine both want, cross-linked into a web of related pieces. And then the part I find quietly beautiful: a small checker reads every published article and fails on the things that actually matter — a missing FAQ, a headline too long to display, a summary that won't render right — and tells me exactly which pieces are broken, exit-coding clean-or-not like any other test. I'll be honest about how far it's come: it isn't wired into the build yet, so for now it's a check I run on demand rather than a wall every change has to clear. But the bones are the payment guard from a few chapters back — a standard I used to carry in my head, turned into a thing that carries itself, so the knowledge doesn't walk out the door when the person who had it gets tired or moves on.

There's a famous line in software — Conway's Law — that whatever you build comes out shaped like the organization that built it, because the system mirrors how the people talk to each other. My whole career that was a warning: mind your messy org, it'll leak into your messy product. When the org and the software are the same machine, the warning flips into a tool. I don't have a company and, beside it, software that mirrors the company. I have one system. When I want to change how the company works, I change the code; when the code teaches me a better way to work, I change the company. The mirror became a single pane of glass.

Now the warning, and this is the most dangerous idea in the series if you take it one step too far. Encoding the company does not mean automating the decisions. It means automating the coordination around the decisions — the fetching, the routing, the handoffs, the enforcement — so the decisions themselves land on a human's desk clean, in context, and on time. The failure mode is seductive, and I've felt it pull: once the machine runs the org this well, why not let it make the calls too? Let it approve its own spend, set its own strategy, decide what ships? That is how you build the genuinely frightening thing — a bureaucracy running at machine speed, making confident, wrong, irreversible decisions faster than any human can catch them. Kafka with a GPU. The point of company-as-code was never to take the human out of the loop. It was to take the human out of the toil, and leave them exactly where they belong: at the gates, holding the decisions, finally with the time and the context to make them well.

On the good mornings it feels like this. I'm not buried in that part of the org anymore — not chasing status, not nagging for the handoff, not the bottleneck a hundred small things wait on. The routine ran without me. And when I sit down, the only things in front of me are the ones that were always really mine: the few real decisions, made with a clear head, by the one part of the work a machine can't fill. The function I've automated runs itself right up to the edge of judgment, then stops and waits for me. That isn't a smaller job than running a company. Done box by box, it might turn out to be the first time I've actually been doing the job at all.

Next: the knowledge engine — how I'm trying to make myself replaceable on purpose, so the thing survives me, and one day lets me leave.