After Agents Bring Down the Cost of Experiments, What's Really Scarce Is People Who Know How to Design Controls

RonnyHe published a long post on X titled Why You Should Be in AI, and How to Do It. He is the head of R&D for MiniMax Code and a co-creator of DeerFlow. The article opens with a hard-edged judgment: Agents can already write most code, run experiments, and draft documents, so the cost of building is close to zero. So what's left?

His answer: ask the right questions and design the right controls. What can be built is no longer the hard part; the hard part is knowing what is worth building, and whether what gets built is actually useful.

The article breaks capability into three layers: curiosity, execution, and scientific literacy, stacked one on top of another.

Curiosity is the engine. AI is special because the thing being built and the thing one wants to understand are the same thing. Models get trained but cannot be explained clearly; Agents behave unexpectedly every week; why scale works, where reasoning comes from, and where the ceiling is all lack a complete theory. For engineers, this is rare. Most fields first give you a mature theory to apply; AI's theory is still being written, and you can participate in it from your own terminal. RonnyHe also writes a rather sharp line: if this does not excite you, the methods that follow will not help. Curiosity is also the reason one is not replaced by tools. An Agent will answer the question you ask; it will not decide on its own which question matters.

Execution: curiosity without execution is a hobby. Many people think AI solves execution, but actually it only removes friction and exposes the real problem. The real problem is not typing speed; it is the habit of stopping halfway. With an Agent, you get halfway faster, so you also stop halfway more often. Excuses even upgrade: the model is not good enough, the Agent got confused. Sometimes that is true; more often, it is because you never defined what done means. Execution means pushing until it truly works, or fails for a clear reason. A clean failure has information; a half-finished success teaches nothing. The approach is very concrete: before starting, write down checkable completion criteria; ask for evidence, not reports—passing tests, real runs, numbers; finish the boring last 20%, because the truth is usually there.

Scientific literacy is underrated. When experiments were run once a week, people were careful. Now an Agent can run one an hour, or even run a hundred in parallel overnight. The cost of a single experiment is no longer the constraint; the constraint becomes whether the experiment is meaningful. A hundred experiments without controls are a hundred anecdotes. An experiment that changes three variables at once explains nothing. Cheap experiments make bad methods more dangerous, because misleading evidence can be produced at scale. The question shifts from how to run experiments to how to scale experiments without fooling yourself. Old tools still apply: form hypotheses specific enough to be falsified; boldly test strange variants; separate measurement from belief; consciously use deduction and induction; design controls, changing only one variable in the same experimental setup; use blind evaluation, so evaluators do not know which version they are seeing. In the past this was the work of research teams; now it becomes a process every engineer working with Agents must design.

The article gives a case study about product feature decisions. In the past, when a feature was proposed, there was a meeting, and several engineers, PMs, and designers argued from experience; the loudest or most senior person won. Then a small team spent weeks building a prototype. By launch, no one remembered which options had been rejected or why. When building was expensive, this process made sense; now it does not. A better way: give AI an experimental environment and a factory. The environment is a sandbox where variants run with real tasks, recorded sessions, and testing tools. The factory is an Agent setup that produces five feature versions plus the current behavior as a control, all run on the same batch of inputs. Then compare them with the same data and the same metrics. If metrics are hard to define, use structured feedback: strip labels and show versions side by side to reviewers, and collect preferences. The human role has not shrunk; it has moved. You still decide what the hypothesis is, what success is, which variants are worth trying, and what the control is. These decisions are harder than writing code, and this is where judgment lies. As a result, decisions become more precise: from choosing among opinions to choosing among measured results. When the data is ambiguous, you also know it is ambiguous, and then you design the next experiment.

The last part is less comfortable. RonnyHe writes that if one day you find your curiosity is no longer in AGI, leave the industry. AI is crowded now; many people are here for money and attention. External motivation can sustain you for a while, but it cannot sustain years of doing your best work. Go where your curiosity truly is—space, manufacturing, biomedicine, materials, energy, anywhere. Ironically, the tools built here will make those fields faster too. The same loop of hypotheses, cheap experiments, controls, and verification works just as well in labs and factories. His test is simple: do you want to know how this thing will turn out? If yes, stay, push the idea to the end, and design experiments like a scientist. If not, that's fine too—go find the question you cannot stop thinking about.

Original link: RonnyHe's tweet

Article link: Why You Should Be in AI, and How to Do It

In the comments, some people agreed, while others asked Grok to summarize this long article.