Research to Reality with Google DeepMind

What technology will make Gemini better between one month and one year from now? That is the research horizon Benoit Schillings sets for his team at Google DeepMind. His previous work at Google X, whose projects included both Waymo and Glass, gave him experience with a mixture of successes and misses. Working on what is needed next week would be a different job; predicting what will matter a year ahead already feels ambitious.

Code is a major part of that mandate, alongside model reasoning, research into network topologies that might improve performance, and the foundations of reinforcement learning. The immediate engineering question is how those research directions change the way software gets built.

In 2018, Schillings and colleagues started Pitchfork at Google X to explore how machine learning could improve code writing. He recalls struggling to get people inside Google interested: why would anyone need ML to write code? The initial target was narrower than generating whole applications. A small edit might sit in review for three days; Pitchfork asked how to compress that cycle and accelerate the evolution of an existing codebase.

Schillings also underestimated what would follow. When people proposed writing code in English, he dismissed the idea: programming languages existed precisely because English was not one. His eventual change of mind repeated a pattern from his own career. After starting with Apple II and Commodore 64 games in assembly, he viewed compilers with suspicion. After moving to C++, he resisted garbage-collected languages because managing memory seemed essential to real programming. Today he uses Python and vibe coding. Across forty-five years of programming, each abstraction initially looked like surrendering something important.

Those changes in programming style track changes in the scarce resource. In the assembly era, the machine imposed the fundamental limit: programmers worked to extract the last available performance. As computing became cheaper, brute force became practical for more problems. The harder constraint became organizing software so that people could understand and maintain it.

Writing a capability once and reusing it was part of that response. Functions and libraries were not merely conveniences; they helped people break a large system into pieces they could reason about over time.

Schillings describes human context as seven to nine rich “tokens” and contrasts it with his expectation of effectively unlimited model context. This is an analogy about cognitive limits, not a measurement in tokenizer units. The engineering implication he draws is that conventions built around human comprehension may change as models can work with more of a system at once.

Generating code does not settle whether it is the code you needed. Specification becomes the next constraint: how do you express the desired behavior and recognize whether the result fits the problem? Schillings sees a continuing human role in architecture, in examining a system’s implications, and in inductive thinking—recognizing patterns in a wider context and deciding what those patterns mean.

Schillings calls the present state of local code writing “superhuman syntax generation.” His reference point is personal: when Gemini writes a function for him, he rarely looks at it and thinks he could do better. He acknowledges that counterexamples exist, but considers the routine minutiae of writing code a substantially solved problem.

The harder example is joining a company and discovering thirty-five million lines of PHP that you now need to change. Producing a plausible function is only one step. You must understand the existing system, locate the relevant behavior, and decompose a change into manageable work. Schillings identifies that sustained, multistep handling of codebase complexity as an active frontier for models.

At the architectural level, decisions reach beyond the source being edited. He points to Jeff Dean’s role in Google’s architecture: hardware optimization, security, and choices whose consequences remain visible ten years later. That is the distinction behind his provocative claim that code writing is over while substantial software-engineering progress remains ahead.

Code offered Pitchfork an unusually favorable starting point for machine learning. Public repositories supplied abundant examples, while compilation, execution, and unit tests supplied ways to check generated results. The domain combined a large training corpus with relatively accessible feedback about correctness.

Schillings argues that this supply of fresh human knowledge is reaching its limit. He estimates that 80% of new code added to GitHub is machine-generated, but supplies no measurement for that figure. His proposed next source of improvement is self-play: models generating practice problems and learning from attempts to solve them.

The analogy is AlphaZero, which learned Go and chess through self-play rather than human game examples, with the game rules supplied. Schillings says frontier coding models are reaching a stage where they can create challenges, judge answers, and—to some extent—judge architecture. He presents hundreds of millions of hours of coding self-play as an opportunity for further progress, rather than reporting a measured coding result equivalent to AlphaZero’s game performance.

His thought experiment makes the proposed learning loop concrete. Put a brilliant engineer in a room for two years, supply pizza, and ask them to become a better engineer. They would set themselves challenges whose answers they could verify, work through those challenges, and repeat. For a model, the corresponding constraint becomes how much compute and practice time can be devoted to that loop.

Much of software engineering’s culture, infrastructure, and business ecosystem developed around the expense of writing code. Schillings describes the emerging alternative as nearly free generation, explicitly qualifying “free.” If that cost falls far enough, the volume of code—including code written dynamically—can grow dramatically. The question becomes how to preserve design adequacy and reliable behavior across the whole system.

Schillings predicts that within a year, people will let models generate code without inspecting it. He acknowledges that code review still exists; his comparison is with compilers, whose assembly output most programmers no longer read. The forecast raises an unresolved process question: what will keep software manageable when direct human inspection is no longer the routine control?

Active guardrails begin with an uncomfortable cycle. Schillings points to vulnerability-discovery news about Mythos; the associated research involves agentic testing and validation, not simply a model glancing at source. A generation of models finds vulnerabilities, developers patch them, and stronger models then uncover subtler defects. Security and the consequences of code therefore deserve at least as much attention as generation itself.

The more ambitious goal is to teach models to produce correct code initially, instead of discovering vulnerabilities and suggesting repairs afterward. Schillings says his team is actively working on that problem. Its difficulty is contextual: correctness depends on the system in which a piece of code will operate.

Inductive architecture adds another requirement. Models need to transfer knowledge between domains and combine concepts, then use that understanding to plan. For a complex software problem, the important choice is often the decomposition itself: which boundaries and subproblems will make the result clearer and more correct?

Evaluation must reward more than passing the existing tests. Schillings criticizes SWE-bench for focusing on whether changes run and produce the expected output. SWE-bench already involves repository-level issue resolution, potentially across multiple files; his broader objection is that successful issue resolution still measures only part of software engineering. He wants more open-ended problems that leave room for continuing improvement.

His example is lossless compression. Give a model ten megabytes of code and ask it to write the best compressor it can. Bits per character describes compression efficiency, while his proposed loss adds the compressed file’s size to the compressor source code’s size:

Here, C compresses the input x, and D reconstructs it. The round trip must preserve the input exactly. Including source size makes the implementation’s size part of the objective, rather than rewarding compressed output in isolation.

A small Python evaluator makes those two requirements explicit. It accepts a candidate’s compression and decompression functions, checks the round trip, and returns the combined size in bytes:

from collections.abc import Callable


def compression_loss(
    data: bytes,
    compressor_source: bytes,
    compress: Callable[[bytes], bytes],
    decompress: Callable[[bytes], bytes],
) -> int:
    compressed = compress(data)
    restored = decompress(compressed)
    if restored != data:
        raise ValueError("Compression must be lossless")
    return len(compressed) + len(compressor_source)

This expresses the scoring rule for the proposed task. Unlike a fixed pass/fail endpoint, the objective leaves room for a better compressor or a more economical implementation. Schillings hopes such tasks will push models toward novel algorithms.

The representation used to solve a problem may matter as much as the objective. Schillings credits chain-of-thought reasoning with improving models, but questions whether software engineering can be captured entirely as a sequence of tokens. Programmers also reason visually: a block diagram can express component relationships, while a data-flow view can expose how information moves through a system.

Gemini’s multimodal design makes text one representation among several. Schillings describes emerging work on spatial and dynamic representations as another route to solving problems, and expects such capabilities to become necessary for more advanced software reasoning. The research direction is to expand how a model can represent a problem while working on it.

If a model is doing the writing, should it use a language designed for humans? Schillings argues that Python and other familiar languages make code convenient to write without necessarily making safety and reliability easy to enforce. Once authorship becomes cheap, a language could demand more work from its author in exchange for stronger constraints.

He points toward strong typing and inspiration from Lean: put more of the correctness burden on the model. Formal proof has limits, and executing verified programs still depends on components such as the compiler, runtime, and external code. The proposal is therefore stronger guarantees, not perfect software. Schillings takes the idea one step further: a language intended for model authorship need not even remain human-readable.

Code is also a language for experimenting with problems outside software. Schillings expects the ability to implement experiments quickly and cheaply to accelerate work at the intersection of computation, atoms, and science. The opportunity is not merely producing more programs; it is trying ideas that previously cost too much effort to express and explore.

Chemistry is one area that particularly excites him. He uses molecules above twenty atoms to dramatize the limits of human prediction, then asks what else might be possible with ten thousand atoms, a scale he associates with life. These are rhetorical illustrations of unexplored complexity, not defined thresholds for chemical predictability or living systems. His underlying question is how much useful behavior remains undiscovered in combinations humans cannot readily reason through.

Biology offers a related challenge: nature has done extraordinary engineering and left poor documentation. Models may help recover relationships that remain elusive to human investigators, making that engineering more understandable and opening new possibilities for experimentation.

Schillings closes with “the gold we cannot see”: discoveries hidden by the way humans approach problems. Evolution shaped human intuition for survival, not quantum computing. Even brilliant investigators bring assumptions about what a promising solution should look like. Machine learning offers a different viewpoint that may reveal possibilities those assumptions conceal. He leaves the idea without worked examples, but with a specific prospect: some future breakthroughs may turn out to have been in front of us all along.