In his excellent 2014 talk at YC, “How to Operate”, Keith Rabois gives an analogy for operators: that you should act like an editor.

He’s talking to managers, describing how (if done well), your role should mostly involve actions like redlining work, asking clarifying questions, allocating resources, ensuring consistent “voice,” and delegating. Your job isn’t (mostly) to “write” — it is to edit.

I have a decent amount of practice at this, having been in management roles for a decade or so. I don’t claim to be perfect — and I certainly get into the writing sometimes — but the feeling of being an editor is familiar to me.

And that has made my experience writing AI-assisted code feel totally natural. As I’ve onboarded people to interface0, I’ve realized how stark the difference is between people who are used to being editors and those who aren’t. The former tend to love AI tools and use them very effectively — and the latter tend to struggle.

The reality is, with AI: we’re all the editors now.

When I write code with AI, I find myself acting as:

  • part engineering manager — specifying the approach at the appropriate level given the “engineer’s” (read: agent’s) task-relevant maturity (a key concept mentioned in Rabois’ talk)
  • part product manager / marketer — figuring out what needs to be built in the first place, from the user perspective
  • part QA — aggressively testing the outputted code and thinking hard about edge cases
  • part code reviewer — actually reading the generated code, tweaking it, and getting it production-ready and in line with the “voice” and conventions of the rest of the project

This is familiar to anyone who has led a small startup or team before — you often need to take up all of these roles. Each is the “editor” of its function, and at a small enough company, one person needs to fill all of those.

But there’s a huge difference: at a small company, resource allocation is your hardest decision. What do you have your one or two engineers work on? Going in the wrong direction carries huge velocity penalities.

Now, my engineering workflow often involves sending off several agents to do the exact same work — and then reviewing what comes back from each of them. I even send agents off to give something a shot that I’m not even sure I want!

The cost of doing so — duplicating work or trying something that doesn’t end up shipping — has moved to nearly zero.

Then, it all comes back, and I spend my time reviewing, QA’ing, tweaking, and then shipping. Jordan Singer has it right:

the new bottleneck is no longer doing the work

it’s reviewing the work

With AI — whether in coding or otherwise — perhaps our best use is to be editors, in the Rabois sense of the word. That means allocating resources, redlining, testing, clarifying, keeping the voice of the output consistent, discarding what doesn’t belong, and delegating.

Just as in companies, there are occasions to get into the writing. It happens. And it will continue to. But I’m already seeing the most effective engineers realize that, if their goal is output, their time is better spent playing editor roles than writer ones.

Everyone is talking about how people need to learn how to use AI. Maybe so. But perhaps people just need to learn to manage, with some slight tweaks from the old human-centric way.

The canonical reference materials on managing people — like Andy Grove’s High Output Management (where task-relevant maturity comes from) — mostly still apply. It’s just that more people need to read them now. Instead of 10% of a company being “managers,” it’ll be 100%.

Yes, there are some changes, like recognizing how “cheap” it now is to have different “teammates” try the same thing with different approaches, or even with the same approach. But the principles are otherwise much the same.

This approach rewards people who can “collapse the talent stack,” as Scott Belsky put it:

As I reflect on the teams I’ve led and hundreds of start-ups I’ve worked with, there is a consistent unfair competitive advantage i’ve witnessed when the talent stack was collapsed - when the lead designer was also the product leader, when the front-end engineer was also a designer, when the designer is also a great copywriter, when the product leader was also the founder/ceo, etc. Tighter conduits for decision making and synthesizing information are an incredible advantage when it comes to crafting products

Try it! Next time you have something to do — a piece of code to write, an email to draft, a memo to write — think like an editor or a manager. Craft a request, catered to agents’ current task-relevant maturity. And then send it off to all of them.

For code — ask Codegen, Codex, Claude Code, and Cursor. For writing — ask Claude, GPT-5, o3, Gemini, and Grok. Let them all do their thing.

And then come back, pick the winner, and edit. And while you’re waiting, do some reading about management and see if it resonates.

As Thomas Dohmke, until recently Github’s CEO, wrote:

Developers rarely mentioned “time saved” as the core benefit of working in this new way with agents. They were all about increasing ambition. We believe that means that we should update how we talk about (and measure) success when using these tools, and we should expect that after the initial efficiency gains our focus will be on raising the ceiling of the work and outcomes we can accomplish, which is a very different way of interpreting tool investments.

You have an unlimited-size team now, with very strong capabilities. Edit them and increase your ambition!

Looking for more to read?

Want to hear about new essays? Subscribe to my roughly-monthly newsletter recapping my recent writing and things I'm enjoying:

And I'd love to hear from you directly: andy@andybromberg.com