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

Agents now write most of the code. They run the experiments. They draft the docs. The cost of building something has dropped close to zero. So what is left for us? My answer: asking the right question, and designing the right control. When anyone can build anything, “can we build it” stops being the hard part. The hard part is knowing what is worth building, and knowing whether what you built actually works. I think about this through three things. Curiosity, execution, and scientific literacy. They stack. Each one needs the one below it.

​

1. Curiosity is the engine

Every exploration starts with someone who wants to know. Why does this work? Where does it break? What happens if I push it one step further? This matters more in AI than anywhere else, because the thing we are building is also the thing we are trying to understand. We train models we cannot fully explain. We ship agents whose behavior surprises us every week. Nobody has a complete theory of why scale works, where reasoning comes from, or what the ceiling is. That is an unusual situation for an engineer. Most fields hand you a mature theory and ask you to apply it. In AI, the theory is still being written, and you can contribute to it from your own terminal. If that does not excite you, nothing else in this post will help. Curiosity is also the only thing that keeps you from being replaced by your own tools. An agent will answer the question you ask. It will not, on its own, care which question matters. The person who keeps asking “why” and “what if” is the person who steers.

​

2. Execution: push it all the way through

Curiosity without execution is a hobby. You would think AI solves execution. It does not. It removes the friction, and that exposes the real problem. The real problem was never typing speed. It was the habit of stopping halfway. I see the same pattern with or without agents. Someone has an idea. They get a first version working. It looks fine on the happy path. Then they stop. The edge cases are “for later”. The measurement is “obvious”. The write-up is “not needed”. With agents, you get to that halfway point faster, so you can stop halfway more often. Excuses also get more sophisticated. “The model isn’t good enough yet.” “The agent got confused.” Sometimes true. Often it means we did not define what done looks like, so neither we nor the agent knew when to stop. Execution means pushing the idea until it either works for real or fails for a clear reason. Both outcomes are fine. A clean failure teaches you something. A half-finished success teaches you nothing, because you never find out whether it was real. In practice:

• Write down what “done” means before you start. Make it checkable.
• Ask for evidence, not reports. A passing test, a real run, a number.
• Finish the boring part. The last 20% is usually where the truth is.

​

3. Scientific literacy is the key

This is the part I think most people underrate. When an experiment took a week, you ran a few per quarter. You chose carefully because you could not afford to be wrong. Now an agent can run an experiment in an hour, or run a hundred in parallel overnight. The cost of a single experiment is no longer the constraint. The constraint is whether your experiments mean anything. A hundred experiments with no control is a hundred anecdotes. A hundred experiments that each change three things at once tell you nothing about any of them. Cheap experiments make bad method more dangerous, because you can now generate misleading evidence at scale. So the question changes from “how do I run this experiment” to “how do I scale up experimentation without fooling myself”. That is a question about scientific method, and the old tools still apply:

• Form a hypothesis. Make it specific enough to be wrong. “This prompt change improves tool selection on multi-step tasks” is a hypothesis. “This might help” is not.
• Test boldly. Try the strange variant. Try the one you expect to fail. Experiments are cheap now. Use that.
• Argue carefully. Separate what you measured from what you believe. Say how confident you are and why.
• Use deduction and induction on purpose. Deduction: if my theory is right, this specific thing should happen. Go check. Induction: across these fifty runs, this pattern keeps appearing. Form a theory, then test it deductively.
• Design controls. Same setup, one change. Think of an A/B test. Think of a double-blind trial: the evaluator should not know which variant it is looking at, whether that evaluator is a person or a model.

None of this is new. What is new is that these methods used to be the job of a research team. Now they are a workflow design problem for every engineer working with agents. You are not just running an experiment. You are designing the loop that runs experiments.

​

4. A case: designing a product feature

Here is how a product idea used to get decided. Someone proposes a feature. A meeting gets scheduled. Several engineers, a PM, maybe a designer. Everyone argues from experience. “Users won’t want that.” “We tried something like it before.” The loudest or most senior voice usually wins. Then a small team spends weeks building one prototype of the winning version. By the time it ships, nobody remembers which alternatives were rejected or why. That process made sense when building was expensive. It does not make sense now. The better approach: give AI an experiment environment and a factory. The environment is a sandbox where variants can run against realistic inputs: real tasks, recorded sessions, a test harness that measures something you care about. The factory is the agent setup that produces variants: five versions of the feature, plus the current behavior as the control, all built and run against the same inputs. Then you compare. Same data, same metric. Where a metric is hard to define, use structured feedback: show reviewers outputs side by side without labels and collect their preferences. The human role does not shrink. It moves. You still decide what the hypothesis is, what success means, which variants are worth trying, and what the control is. Those decisions are harder than writing the code, and they are where your judgment matters. The result: decisions get more precise. You stop choosing between opinions. You choose between measured outcomes. When the data is ambiguous, you know that too, and you design the next experiment instead of guessing.

​

5. The end goal: the unknown

Why do any of this? For me, the answer is not productivity. It is that there is still so much we do not understand, and I want to find out. That is what curiosity is for. Execution and method are how you make it pay off. Which leads to an uncomfortable point. If one day you find your curiosity is no longer in AGI, leave this industry. I mean that seriously. AI is crowded right now, and a lot of people are here because it is where the money and attention are. That is not sustainable. You can grind for a while on external motivation. You cannot do your best work for years on it. Go where your curiosity actually is. Space exploration. Manufacturing. Biomedicine. Materials. Energy. Whatever it is. The irony is that the tools we build here will make those fields faster too. The same loop of hypothesis, cheap experiment, control, and verification works in a lab or a factory as well as in a codebase. What matters is that you are genuinely curious about the thing you work on. That is the only motivation I have seen that lasts. So here is my test. Ask yourself whether you want to know how this ends. If yes, stay, push your ideas all the way through, and design your experiments like a scientist. If not, no shame. Go find the question you cannot stop thinking about.