How to Invent Everything at Once

I was talking to an AI researcher the other day who was building models to find new catalytic converters. A noble and specific goal. It reminded me of how we wrote software in the old days. If you wanted to make a 3D game in the early 90s, you had to figure out how to draw a shaded triangle on a screen, how to manage memory, how to get sound to play without crashing the machine. You essentially had to invent computer science from the ground up just to make a character jump.

That's what most scientific research still feels like today. It's problem-driven. A biologist wants to cure a specific cancer. A chemist wants to create a specific polymer. They are, in effect, hand-crafting a game engine for a single game. They spend 90% of their time building bespoke tooling for one specific problem.

But a quiet revolution is happening, and it looks a lot like the shift that changed software development forever. We're entering the age of method-driven research. The most important work is no longer solving the specific problem, but building a general-purpose engine that can solve whole classes of problems.

Two Ways to Invent

Let's be precise about these two modes of thinking -

Problem-driven research is what you see in movies. A genius obsesses over a single, monumental challenge. Think of Andrew Wiles spending seven years in his attic proving Fermat's Last Theorem. The problem is a fixed, distant star, and the researcher's entire life is spent building a single ship to reach it. This is incredibly heroic, but its weakness is that the ship is designed for a single destination. When the journey's over, the ship is retired.
Method-driven research is less romantic but far more powerful. It's not about building a ship for one star; it's about building a warp drive. The goal is to create a new capability. You build a tool that's so powerful it opens up problems you couldn't even conceive of before. The Large Hadron Collider is a perfect example. Physicists didn't build it to find the Higgs boson; they built it to smash particles together at unprecedented energies. They knew that by building such an engine, they would inevitably find new things. The Higgs was just one of the first discoveries it enabled.

For a long time, the problem-driven approach was the only way forward in many fields because the "methods" were just human brains. And a single brain can only hold so much context. But that's no longer the constraint. General-purpose AI models are becoming the ultimate method. They are the warp drives. An AI that can generate novel protein structures is not aimed at solving one disease. It's a method for exploring the entire protein universe.

The most common objection I hear is that method-driven research feels aimless. You have this powerful new engine, but what do you do with it? You have to be opportunistic. But this is exactly what makes it so potent. It's a directed search for serendipity.

The Game Engine Analogy

The best historical parallel to explain this shift is the evolution of video game engines. In 1993, id Software wrote the Doom engine. It was a masterpiece of engineering, perfectly suited for making Doom. It was problem-driven. But you couldn't use it to make a flight simulator.

Then, a few years later, Epic Games started building something different: the Unreal Engine. Their goal wasn't just to make a single game, but to create a tool that could power any 3D game. They focused on the general methods: How do you render light in any arbitrary scene? How do you create a flexible physics system? How do you build a scripting language that lets creators invent their own game logic?

The Unreal Engine became the "method" that powered a thousand different "problem-driven" games. The scarce resource was no longer the low-level programmer who could write a rasterizer, but the designer who could use the engine to create a compelling world.

This is what's happening in science. Companies are starting to build the "Unreal Engine for biology" or the "Unreal Engine for materials science." These are not apps; they're platforms for discovery. Let's call them discovery engines. A mature discovery engine has four key parts, just like a game engine.

The Asset Manager (The Data Scheduler): A game engine needs to handle thousands of different asset types, including 3D models, textures, sound files, and animations. A discovery engine for biology needs to do the same for genomic data, protein assays, microscopy images, and clinical trial data. Its job is to ingest and normalize this firehose of messy, real-world information so the core engine can use it.
The Physics & Rendering Engine (The Simulation Environment): This is the heart of it all. For a game engine, this is the component that simulates physics and renders pixels, creating a believable digital twin of a world. In scientific applications, this is often a differentiable simulation of a complex system, like molecular dynamics, creating a virtual laboratory for high-throughput experimentation. This is precisely what models like AlphaFold represent. It functions not just as a predictive tool but as a learned simulation of the physical laws governing how proteins, DNA, and other molecules interact, effectively becoming a rendering engine for biology at the atomic scale. A more advanced methodological layer involves models that infer the rules of a system from data, rather than being explicitly programmed with them. MuZero learned the rules of chess simply through gameplay, AlphaMissense learned to classify the disease risk of genetic mutations just by identifying patterns across the genomes of related species, and GraphCast built its own high-fidelity simulation of Earth's atmosphere by learning directly from decades of weather data. This paradigm will undoubtedly spur the creation of a new generation of discovery engines, each tailored to a unique and complex frontier.
The Live-Reload/Playtest Button (The Validation Engine): A game designer constantly hits "play" to test their creation in the real engine. For a discovery engine, this is the connection to the physical world. It takes the most promising designs from the simulation, a novel protein structure, and a new battery electrolyte formula, and uses robotic labs to automatically synthesize and test them. It closes the loop between simulation and reality, turning the scientific method into a tight, continuous cycle.
The Editor & Scripting Language (The Problem Formulation Interface): This is the human interface. In Unreal Engine, it's the visual editor and the Blueprint scripting system that let designers build worlds without writing C++. In a discovery engine, this is the interface that lets a chemist or biologist translate their high-level goal ("find a molecule that binds to this protein without being toxic") into a mathematical objective the AI can optimize for. This is a subtle but profound challenge.

What to Build

The heuristic for identifying a domain ripe for a discovery engine is precise and technical. One must look for problems characterized by a combinatorially vast search space coupled with an exceedingly expensive validation function.

Think of any major R&D challenge as an optimization problem: finding an input x that maximizes a desired outcome f(x).

x_optimal = arg max_{x ∈ s} f(x)

In traditional research, the search space S is astronomical (e.g., the ~10⁶⁰ possible drug-like small molecules), and evaluating the function f(x) (e.g., running a full clinical trial for a drug candidate) is a decade-long, billion-dollar process. Progress is slow because you can only afford to run f(x) a handful of times.

A discovery engine's primary technical function is to build a high-fidelity, low-cost surrogate model, g(x), that approximates f(x). By leveraging massive datasets and a scalable architecture like a transformer or a graph neural network (GNN), the engine can evaluate g(x) millions of times in silico, rapidly identifying the most promising candidates x' to then test with the expensive real-world function f(x).

The opportunity here is to identify the domains where the gap between the cost of evaluating g(x) and f(x) is the largest.

Therapeutics: The search space S is the landscape of all possible molecular interactions with human biology. The validation function f(x) is the multi-phase clinical trial process. The fuel for your surrogate model g(x) is the enormous, passively collected corpus of genomic, proteomic, transcriptomic, and historical clinical data. An engine here doesn't just predict binding affinity; it learns a deep, internal representation of human biology itself to co-optimize for efficacy, toxicity, and bioavailability before a single molecule is ever synthesized.
Semiconductor Design: The search space S here is not just the layout of transistors (a placement problem), but the fundamental architecture of the transistors themselves. The validation function f(x) is the complex, multi-billion-dollar process of tape-out and fabrication at a modern foundry. A discovery engine for this domain would learn from the vast history of chip design files (GDSII data) to generate novel circuit layouts or even new types of logic gates optimized for power efficiency or performance in ways no human engineer would intuit.

The Economics of Discovery

The economic framework is that of a high-leverage R&D portfolio manager.

Traditional R&D in fields like pharma is a game of high-stakes, low-probability bets. A company might spend hundreds of millions on a handful of drug candidates, with a >90% failure rate. A discovery engine transforms this economic equation.

The value of a discovery portfolio can be modeled as v = n * p * m, where n is the number of projects (shots on goal), p is the probability of success for each, and m is the magnitude of the payoff. The engine radically increases n (by exploring millions of candidates instead of dozens) and p (by using high-fidelity simulations to eliminate poor candidates early). This fundamentally de-risks the entire discovery process, leading to a much higher expected value for the same capital input.

The business model is value capture. The discovery engine is not an equivalent of a SaaS; it is an asset mine. The business model must reflect this by capturing a share of the downstream value of the intellectual property generated. This is accomplished not through licenses, but through structured partnerships: joint ventures, royalty agreements, equity stakes.

And, the moat is a compounding data flywheel. This economic model creates one of the most powerful and defensible moats in business. Unlike a traditional software moat based on network effects or high switching costs, a discovery engine's moat is built on a proprietary data flywheel.

A partner brings a problem (e.g., find a new Alzheimer's drug).

The engine generates a set of promising candidates in silico.
The partner validates these candidates in the real world, generating a unique, high-value dataset of what worked and what didn't.
This proprietary validation data is fed back into the engine, making its core surrogate model g(x) more accurate.
A smarter engine attracts more partners with harder problems, which in turn generates more proprietary data.
The marginal cost of the next discovery decreases with every successful discovery made on the platform.

This creates a winner-take-all dynamic where one dominant engine per scientific vertical becomes a gravitational center for the entire industry's R&D efforts.

More Than a Hammer

Building an engine is hard. It requires a long-term view and a taste for building infrastructure. You're not getting the instant gratification of solving a single, visible problem. But the leverage is immense. The creators of the Unreal Engine didn't just build one hit game; they built a platform that has generated thousands of hits and billions in value for a whole ecosystem of developers.

The temptation is to grab the latest, most powerful AI model and immediately go looking for a problem to solve. It's the old "when you have a hammer, everything looks like a nail" trap. But the truly non-obvious and valuable work is to step back and ask: What kind of factory can I build around this hammer?