Reid Hoffman's AI test: make the machine go second (2026)

Reid Hoffman’s AI test is simple: make the machine go second.

In his August 5 essay, Hoffman argues that the most dangerous AI shortcut is not a bad output. It is losing the repetitions that make a founder, operator, or craftsperson better at the work. His proposed boundary is sharper than “keep a human in the loop”: use the machine freely around your core skill, but do not automate yourself out of the practice that builds it. 1

Hoffman is a co-founder of LinkedIn, Inflection AI, and Manas AI, and a partner at Greylock. That background matters here because he is writing from both sides of the problem: building network products and AI companies while thinking about how technology changes the way people acquire expertise. 2

The line is where learning happens

Hoffman’s essay begins with artist Sougwen Chung, whose work combines drawing, brainwave data, and robotic arms. Chung trained systems on years of their own drawing archive, then added time and biofeedback so a machine could read more of the process—not just the finished image.

The point is not that Chung rejects machine assistance. They have made their practice unusually legible to machines. The line comes later:

“I want to be machine readable, not machine executable.” 1

Chung’s reason is practical: if a system takes over the part they love and learn from, the system may improve while the artist stops improving. Hoffman turns that boundary into a general test for knowledge work: Is this where my learning happens? If the system does it instead of me, do I get worse? 1

Sougwen Chung working with two robotic arms during a live drawing performance — *Hoffman uses Sougwen Chung’s robotic drawing system as the concrete case for separating machine legibility from machine substitution. 1*

Why “automate the boring parts” can backfire

The usual AI advice sorts work by enjoyment: keep the interesting work and hand off the tedious work. Hoffman’s objection is that tedium and skill formation often overlap. The junior associate reading hundreds of documents may be bored, but those repetitions are also what build the instinct to spot a meaningful clause or an unusual opportunity.

That distinction is easy to miss in a startup because early teams perform several jobs at once. A founder may call customer interviews repetitive, yet the repetitions create pattern recognition about who has a real problem. A product lead may call support tickets low-status work, yet reading them builds judgment about where the product breaks. An engineer may call debugging toil, yet the debugging loop teaches which abstractions are actually sound.

Hoffman’s sharper warning is about where the gains accrue. When a model performs the task, the model and its owner learn from the aggregate. The individual who stops doing the task may receive a faster capability while losing the experience that made them distinctive. In his words, “The model’s improvement is not your personal improvement.” 1

That is why “human in the loop” is not enough. A person who only reviews and approves machine output is controlling the system, but may not be building the judgment that comes from doing the difficult work. Approval is a safety mechanism; it is not the same as practice. 1

The three tests Hoffman proposes

1. Let the machine go second

For work at the center of your craft, do the first pass yourself—quickly and imperfectly—then use AI to expand, criticize, organize, or sharpen it. Hoffman’s example is writing, but the rule is broader: the first pass is often where you discover what you think.

For a founder, that means writing the raw customer-problem memo before asking a model to cluster interviews; sketching the product constraint before generating ten product directions; and making the first architecture trade-off before using AI to enumerate alternatives. Outside your core, reverse the order without ceremony. Let the machine draft the meeting recap, normalize the spreadsheet, or produce the first pass of routine code.

The dividing line is not “creative” versus “boring.” It is whether doing the task repeatedly improves a judgment you expect to keep owning.

2. Run the new-hire test

Ask: Would I be comfortable if a new person on the team never did this task?

If the answer is no, the task is probably carrying expertise. Automating it may create short-term capacity while making the team’s future judgment thinner. That does not mean every new hire must perform every task forever. It means the team should deliberately expose people to the work before deciding that a machine can own it.

For an AI startup, apply the test to customer discovery, failure analysis, model evaluation, security review, and product demos. If a new teammate never sees the raw evidence behind these decisions, they may learn the company’s conclusions without learning how to reach them.

3. Check the direction once a year

Hoffman’s final test is simple: are you doing more of your core thing, or less? Chung draws more than before; that is the sign that the tools are extending the practice rather than replacing it. 1

Founders can ask the same question in an operating review:

Am I speaking to more users, or only reading AI-generated summaries of users?
Am I making more product judgments, or approving more machine suggestions?
Am I debugging the hard parts, or losing the ability to tell a deep bug from a polished workaround?
Am I writing more of the company’s actual point of view, or editing text that arrived from somewhere else?

The point is not to maximize manual work. It is to notice when the schedule has quietly changed the person doing the company’s most important thinking.

What to change in an AI startup this week

Hoffman’s essay gives founders a useful way to classify automation proposals before approving them. Put each recurring task into one of three buckets:

Core practice: Repeated work that builds the judgment the company depends on. Keep the first pass human-owned. Use AI after the team has formed a view, or as a critic and simulator.
Evidence work: Tasks that expose the raw material behind a decision. Automate transcription and sorting, but keep people close to the underlying calls, tickets, experiments, and failures. Summaries are not a substitute for contact with evidence.
Commodity handling: Work where the desired output is clear and the task does not build a scarce company-specific judgment. Let the machine go first, then inspect the result at the level of risk the task deserves.

This classification also improves product design. If your startup sells an AI system to professionals, do not assume that the customer wants every difficult step removed. Some steps are where the customer earns confidence, trains a team, or develops the taste needed to catch an exception. A product that hides those steps may look efficient in a demo and leave the customer weaker after six months.

The better product question is: Which part should become easier, and which part should remain legible and owned? That answer will differ by workflow. A machine can prepare a legal-research index while the lawyer still forms the judgment. An agent can assemble a sales brief while the founder still decides what promise to make. A coding assistant can propose patches while the engineer still learns the system’s failure modes.

The boundary is not anti-automation

Hoffman is not arguing that founders should preserve every manual step. His own recommendation explicitly leaves room to automate work outside the center of your craft. The risk is treating all repetition as disposable before asking what the repetition is doing for the person and the team. 1

There is also a product-quality boundary. If an AI system produces a faster answer but hides uncertainty, removes the user’s ability to inspect evidence, or makes recovery impossible, it has not merely automated a task. It has transferred control. “Human in the loop” can preserve a button to approve while removing the practice that lets someone make a good approval.

For the next automation review, ask two questions before asking whether the tool saves time:

What capability does this task build through repetition?
After six months of using the tool, who will be better at the task—the team, the model provider, or neither?

If the answer is that the model improves while the team becomes a thinner layer of reviewers, the workflow is machine-executable in the wrong sense. Keep the human first pass where the company’s judgment is made, and let the machine go second where it can extend that judgment without replacing its source.

Coverage: one qualifying founder-authored long-form post published in the August 2–9, 2026 Pacific-time window.

참고 출처

1
Reid Hoffman, “Become machine-readable, not executable”linkedin.com
2
Columbia University, Reid Hoffman biographyenergypolicy.columbia.edu