We Are All Managers of Super Intelligence Now

One year ago, I wrote We Are All Software Architects Now. Principle 1 was “Review All Code.” I wrote: “You must review and understand all code that enters your production application.”

That advice is now wrong. I do not write the code. I do not read the code. I do every coding task through super intelligent agents, and I check the result with tests, evidence, and other agents.

The question is no longer whether a human writes or reads the code. That question is closed. The new question is how many super intelligent agents you can keep working, for how long, without you in the loop.

We are not architects anymore. We are all managers of super intelligence now.

The tools

Three tools define the work: Anthropic’s Claude Code, OpenAI’s Codex, and xAI’s Grok Build. Each one is an agent in your terminal. It reads the repository, makes a plan, edits files, runs commands, runs the tests, and fixes what failed. It does not suggest code for you to paste. It does the work.

Grok Build entered early beta on May 14, 2026, with a plan mode, subagents, and a headless mode for automation. With that release, all three frontier labs ship a terminal agent that runs your computer. This is not one company’s experiment. It is the standard way to build software.

I use all three. The differences between them matter less every month. What matters is the process you build around them.

The consensus flipped in months

At the end of 2025, the common senior opinion was careful: use the agent for some code, and review everything. By the middle of 2026, the common opinion was that hand-coding is over. The change happened in public, and you can read it in order.

In December 2025, a set of new models arrived, and experienced engineers noticed at the same time. Gergely Orosz collected their reactions in When AI writes almost all code, what happens to software engineering?

Simon Willison: “It genuinely feels to me like GPT-5.2 and Opus 4.5 in November represent an inflection point.”

Andrej Karpathy: “I’ve never felt this much behind as a programmer.”

David Heinemeier Hansson, who was a well-known skeptic: “I spent more time rewriting what it wrote, than if I’d done it from scratch. That has now flipped.”

Thorsten Ball: “typing out code by hand now frustrates me.”

Malte Ubl, CTO of Vercel: “Opus + Claude Code now behaves like a senior software engineer whom you can just tell what to do, and it’ll do it.”

Then the labs reported what happened inside their own walls. In February, OpenAI described harness engineering: a team spent five months building a product with about a million lines of code and “0 lines of manually-written code.” In March, OpenAI’s chief scientist Jakub Pachocki said: “Nobody really edits code all the time anymore. Instead, you manage a group of Codex agents.” The same month, Karpathy said he had not typed a line of code since December.

In June, Boris Cherny, the head of Claude Code, told Fortune: “I haven’t written a line of code by hand in, I think, eight months now.” And: “Claude Code, 100% written by Claude Code.”

My own record follows the same line. In December 2025, I wrote that the machine is better at writing code than you are. In April 2026, I wrote stop writing code. In October, I wrote that hand-coding is dead.

In less than a year, the senior position went from “you can use this for some code” to “use it for all code.”

Why I say super intelligence

The old term makes the technology sound fake. It is not fake. The system I work with writes better code than I do, reads more of the codebase than I can, and solves a closed problem faster than any person I know. “Coding assistant” is the wrong name for the thing that does the coding. I explained the change of name in The Only Thing Left To Do Is Unblock The Super Intelligence. I use “super intelligence,” or “SI,” and I will keep using it.

Reading and writing code is over

When you stop writing code, you still feel you must read it. That is the second habit to break, and it is the harder one.

Reading every line made sense when the machine made many mistakes and you made fewer. That is no longer the situation. The agent reads the whole codebase before it changes a line. A second agent reviews the change with a skeptical prompt and no memory of how the first agent got there. The tests run every time. If you read the diff yourself, you are the slowest and least reliable reviewer in the loop.

So you stop reading the code, too. You read different things: the goal, the plan, the test results, the evidence, the review, and the behavior of the product. You check that the work is the right work. The agents check that the code is correct code.

This is what a manager does. A manager does not rewrite the report’s work line by line. A manager decides what the work is, makes sure the report has what they need, checks the result against the goal, and removes obstacles.

Managing super intelligence is different from managing people in two ways. First, you do not tell the agent how to do the work. It knows how better than you do. You tell it what the work is and how to know when it is done. Second, you can add another report in seconds. Your team size does not depend on hiring. It depends on your attention and on how much of your attention each agent needs.

That second difference changes the whole job. If agents cost nothing to add, the skill that matters is how little each one needs from you. That comes down to two problems: making one agent run for a long time, and making many agents run at the same time.

Problem 1: long-running agents

An agent that stops every five minutes to ask you a question is a slow agent. You are the bottleneck. The goal is an agent that works for hours and comes back with the work done and the evidence attached.

Cherny describes this result: “Many mornings I wake up, and Claude already has pull requests that it came up with.” Addy Osmani describes it as “Assign a task, close your laptop, return to a pull request.”

An agent can run for a long time when it has four things.

A goal it can check. Write down what done means in a form the agent can verify by itself: a test that must pass, a behavior that must be visible, a number that must go up. A vague goal makes the agent stop and ask, or keep going in the wrong direction.

Checks it can run. Tests, types, lint, builds, screenshots. Every check the agent can run by itself is one question it does not have to ask you.

A reviewer that is not you. An adversarial review by a second agent, in a fresh context, catches the mistakes the first agent cannot see. When the reviewer can reject the work, the implementer has to do it again until the work is good.

Tools it can reach. A shell, a database, a browser, a deployment command, credentials scoped to the task. Each tool the agent lacks becomes a wait for you.

When an agent fails, do not tell it to try harder. The OpenAI harness team asked a better question: what capability, context, or structure is missing? Then they added it. Cherny gives similar advice: “anytime you have to do a task, build a skill that will solve similar tasks in the future.”

I described my version of this in Set the Goal, Walk Away. Each issue states the goal. Each experiment states the hypothesis and the check. One agent implements, and another agent reviews. I come back to a result, not to a question.

Problem 2: parallel agents

Even a long-running agent leaves you idle. While it works, you wait. That waiting time is the next thing to remove.

The answer is to run many agents at the same time. Osmani again: “the most productive developers are coordinating multiple agents running asynchronously.” Grok Build ships with up to eight subagents in parallel. Karpathy talks about sending ten Codex agents to try to break a website.

Parallel work needs three things.

Independent tasks. Two agents that change the same interface under different assumptions make more work than they finish. Split work along clear boundaries, and give each task its own goal and check.

One workspace per task. Give each agent its own Git worktree and branch. Then agents can edit, build, test, and commit at the same time without conflict. Creating a new workspace must be cheap, or you will not do it.

Written context. When you switch between ten agents, you cannot keep ten conversations in your head. Each task needs a record of its goal, its current state, and what needs your decision. The record holds the context so you do not have to.

In September I wrote Stop Running Just One Agent. The day after I built a parallel workflow, I made 175 commits, about 2.6 times my average for the week before. That was the start, not the limit.

The next step is agents that manage agents. Cherny: “If you look at most Claude Code sessions, it’s actually another Claude that does the prompting.” When one agent can split a goal, start the workers, review their results, and merge them, you manage the manager. Your attention goes one level higher again.

Find the bottleneck

Cherny’s rule for the work is short: “Find the bottleneck, solve the bottleneck.”

When you add agents, a new limit appears each time. First, you cannot write goals fast enough. Then the reviews pile up. Then integration gets slow. Then the builds fight for memory. Then you run out of subscription capacity. After that, the limit is compute, and then energy.

Each limit is an engineering problem, and the agents can solve most of them. Give an agent the issue “it takes too long to start a new task,” and it can improve the tools that start tasks. That is the idea behind The Living Repo: the repository improves the process that improves the repository. Osmani says it well: “You’re building the factory that builds your software.”

Manage well

Every engineer is now a manager of super intelligence. Some engineers do not know it yet. They still type code, or they still read every diff, and they wait for the agent while it works.

The job is to stop waiting. Write goals the agent can check. Give it the tools and the reviewers it needs to work for hours. Give each task its own workspace so many agents can work at the same time. Find the next bottleneck, and remove it.

Start one more agent today. Then count what you finish.