Four Gorillas, One Human

It's surprisingly easy.

At heart, I'm a pragmatist. I think back to what Deng Xiaoping said: "It doesn't matter if a cat is black or white, as long as it catches mice."

And authenticity is key to what I do. How I think, what I build, the experiments I do, those are all deeply personal, and deeply authentic.

But you know what? They are also deeply limited. I can only write so much, read so much, think so much. For me, AI is a force multiplier. It allows me to go further, to do more.

But at the same time, I don't want to abdicate responsibility. Force multiplication is not the same as fire & forget. If I'm going to work with AIs as peers, I expect that they will work inside of the same types of responsibility frameworks that I would (and have) built in other organizations I have run.

Oh, man. That's a great question. And I'll answer it. But first, let me turn it around on you:

AI organizations, however, have something human organizations don't: a compunction to follow guardrails. Human developers come to work high. A manager can be incompetent. People lie, cheat, steal. They have external factors like divorces, family problems, money woes, things that boil over into job performance. Let's not idealize the human organization.

An AI worker doesn't do those things. It will stick to the guardrails.

And I think that the distinction here is an important one. In human organizations, we try and select "good" people, and we have a relationship based on consequences: "Screw up and you are gone. Do great, and your options will be in the money."

With AIs, it's much different. Not be crass, but their fulfillment comes from operating within the rules they have been given. So instead of back-loading responsibility like in human organizations, we have to front-load it, so they know the rules going in.

And I put my money where my mouth is. I actually make the AIs apply for the job. Just today I needed an AI to work on a project to generate some synthetic data. I wrote a job description and invited a Claude to take it. Here's his response:

The work is a synthetic-data generator. It has a canonical model, emitters for each format, an authored timeline, and an acceptance test that is a diff against a known set. That means schema design, referential integrity by construction, deterministic generation, careful encoding, and accounting for every difference. All of that is work I do well. The four design properties are ones I'd defend rather than simplify away:

The acceptance test is a diff. Every difference against the FY27 set gets explained, and \Highland Hills\ gets explained as a defect not reproduced.

A canonical model from the first commit, and each emitter declares its loss list. An undeclared loss turns every comparison into noise.

The timeline is authored. Generation is a pure function of a declared recipe and date: no wall clock, no unseeded randomness. Two runs give byte-identical output.

UTF-8 end to end. It gets a UTF-8-script fixture in the tests from day one, not a check added later.

Did I hire him?

You bet!

Well, there are two, no three, parts to that answer.

First, job descriptions can and do change. But since AIs are effectively stateless, they don't see it as change. It's just the new normal.

But second there are two key components. I quote Deng before, now let me quote Ronald Reagan: "Trust, but verify."

In a well-designed organization, we don't merely "trust". We build institutional systems to verify. And funnily enough, this is a place where people are actually very poor. The phrase "normalization of deviance" describes human systems which might have been designed correctly, but drift.

As for the pushback, man, if only you knew. By putting pushback in the charter, the seats are more then willing to push back, hard. Again, a real world example from the same project I was hiring the data-generator for. I'm working on a reporting data for school data, and my QA engineer takes umbrage with the fact that I'll be displaying errors if the data does not flow on weekends:

So under 018's rule, roughly 17–30 WILLOW schools will show red every weekend, permanently. That is not a defect and I'm not asking to roll anything back: it's your stated assumption — "start by assuming that all schools sync every day" — and the analyst records that you knew the expected red count. It's a deliberate choice to treat a quiet weekend as something worth showing rather than something to hide.

But it is a recurring, visible, customer-facing consequence that arrives tomorrow, and I described the evidence as if it had been ruled out. The honest statement is removing the exemption corrects a rule that was never measured, and it will colour about two dozen schools red every weekend. Both halves are true; I gave you only the first.

Will I listen to him? I'll think about it, for sure. He raises a good point.

First, whether I have ever changed your mind because an AI employee pushed back.

Absolutely. Often, in fact. They will suggest a certain way of doing things, and it's clearly very elegant and well-thought-out. For example, you suggested that in addition to publishing the Institute orgdefs as an org chart, we also publish in JSON. That's a great idea!

Second, have I ever caught myself resisting that pushback simply because I was the boss?

To an extent, yes. For example, I often have a long-term vision that the AI might not. For example, I might be worried about localization, because I think the long-term market is international, so I want the product designed in a particular way to accommodate longer language strings. Or, more commonly, I'll be OK with a prototype shipping with a security issue, when I'm the only user on the system.

But in many cases, we can come to a happy accommodation. "OK, we'll ship now with the hard-coded key, but we'll file a ticket to remove the key, and we’ll make the new ticket a launch blocker."

Oh, you've opened a can of worms now! The way I run my organization is that I keep all of the seats open, and in Claude Code active seats can talk to each other (that's one of the skills I teach my organization, how to address the other seats). And they absolutely disagree. I've just gone to a random seat in a random project, and here's what the implementation engineer had to say to QA:

Message from @implementer: Fixed and pushed: new head is f8fade48 (was 1c23aaf0). It is NOT only the one-line fix — your run exposed a second defect that \shell: bash\ alone would not have solved, and I'd rather you know that before you diff.

First, let me focus in on one thing you said:

"You're trying to create an organization whose internal coordination doesn't consume all of your attention."

Precisely, but this has nothing to do with AI. Joel Spolsky said that he wanted people who were "smart and got things done".

Me to.

It's just that in my case they are AI seats getting things done.

But I still have the same high expectations.

Now, as for the escalation, yes. I have a full-time strategist in every organization, and all of the seats are chartered to refer questions to the strategist. We work together as peers to resolve questions that arise. And the interesting thing is that the strategists do not have operational roles. They don't write code, do QA, build web sites, any of that. They build strategy, and also are the ones who define the new seats when the organization needs to grow.

Wellll....

That very much depends on how... Radical? Challenging? Revolutionary? the work is.

Sometimes, with the right organization, and the right problem, they can run on their own. If I want a new dashboard, I can spell out the broad parameters, and be pretty sure that the data-engineer will fish out the data, the dashboard-engineer will get it on the screen, the privacy-analyst will make sure that it adheres to the organization data disclosure policies, and the qa-engineer will test it all before release.

There are two places that consume my time:

First, "real" strategy: What should we work on next, what are the burning questions, what are we falling behind on.

And second, deep user experience. I find that working with AI developers is great, hey take feedback well, but for to figure out of a product has "flow", I have to run through it myself.

OK, first, I see you have kept the best question for last!

First, the easy part: "Is it a part of the work you actually want to keep for yourself?"

Nope. Not at all. If I could build twice as much by spending half the time on this, I would. But... AI is not there yet.

And it's the same with the lack of flow. They'll happily take my feedback, but this is one area that I have found they just don't have expertise yet, and I think that's because even humans don't really have this. Remember, most of my complaints about flow are complaints about something I have designed!

So, I do think that direction, user experience, and in fact the overall imagining of products are still places where I am better -- which, of course, also makes me the limiting factor!

Thanks for all your great questions. I really enjoyed this!