# Research to Reality with Google DeepMind — Benoit Schillings — session 2026-07-01T17:05:00.000Z → 2026-07-01T17:25:00.000Z

_61 transcript lines · 38 slides · source: full recording_

## Transcript

We have Expo talks. We also have another computer use track talk coming up with my colleague, Gaurav Mishra, at 01:30 in the computer use track. Highly recommend checking out his talk from RL to IRL. And then ultimately, come find us. We have a huge presence down at the Expo Hall. We would love to continue the conversation with you all. If you're not here in person, you can also check out our code on our GitHub repo and check out Our website. And with that, thank you very much. Please welcome to the stage the vice president of research at Google DeepMind Benoit Schilling. Alright. Good morning. It's really quite exciting to be here and have a chance to to speak with all of you. My name is Benoit Shillings. I'm actually a bit of The noob when it comes to to machine learning. Till a year and a half ago, I was working for Google X, which some of you may know. We've done things like Waymo, which seems to be at every street corner now. We also do things like Glass. So, you know, we we had a mix of, hit and success, but in many ways this was for me an interesting formative experience on how to run a research team in a place like DeepMind. I do have an incredible Team. My team goal in DeepMind is basically to develop whatever technology will be needed to make Gemini incredible between one month and one year from now. So one month because if you start to work on what is needed in one week, that's a very different type of job. And one year because I don't think anybody can really predict anything that far. So, that's already pretty ambitious, in my opinion, to think about things that Could happen one year in the future. We do many things, under that role. A lot of it is related to code, which will be the main subject of my talk today, but we also do a lot of research on what is the evolution of reasoning for models for instance. Or we do topology research. What are new type of network that might bring better performance? We do fundamental work in the science of reinforcement learning which is so Fundamental to what we're doing today, with ML. Let's do a bit of an origin story. We started the project at X named Pitchfork in 2018 which was aimed at looking at how ML could really improve the way code is being written. And this was very interesting because in 2018 when we presented that Google, honestly, nobody would give us a time of day. There was that point, like, why would you ever need ML to to write code? At the same time, I think that we totally underestimated how fast this could go. When we did that project originally the idea was to look at how we could speed up the evolution of a piece of code, How could we make many of those small changes which slows down code speed development? You know, the small edit which requires a review that takes three days and how we could compress that cycle. Some people were talking about vibe coding, writing code in English, and at the time, honestly, I totally dismissed that. I was that's why we have programming language. English is not a programming language. Well, I I guess I was pretty wrong on that front. But the resistance we felt at the time reminded me of how my own career was pretty resistive to to change. I've been writing code for forty five years. I started by writing video game for Apple two and Commodore 64. So, my formation was to write assembly language. And when you spend a long time writing assembly language, you look at compilers with a lot of suspicion. Right? Are those things really working correctly? And then when you switch to c plus plus and use compiler, you lose you look at garbage collected languages as this. That's not real. Programming, you need to manage your memory. Well, today, I use Python and byte coding. So, even old dogs can learn new tricks. So, but but I I I do understand what happened there. I think that we have a number of eras in what happened with software. And and the first one was, you know, the one where I started writing code where the fundamental limit was really the machine. And there was a lot of work to go and extract. The last ounce of power out of those machine, and that was the days of assembly language where you really needed to be incredibly accurate in the way you were writing code. Computing became much cheaper, and we switched to the modern cloud era where getting the best performance is not the most critical aspect. You can actually brute force many problems. But, really, what became the limiting factor was the ability For us to design, in a modular way. You know this was the era where software was write it only once and this was this whole idea of how are you going to build libraries, how are you going to write functions, How are you going to break down that problem into something that is long term manageable? The limitation there, and that determine a lot of how our software processes are working, were actually the human brain. A traditional human, typical human is able To get the context between seven and nine tokens. I mean, we we have very rich tokens, but you compare that to modern ML where the context is basically going to be infinite pretty soon. That fundamental limitation of human determined a lot of how software was being written. This is over, and we're switching now to that AI frontier where really writing the code is not the challenge anymore. I'll speak some more about it, but the bottleneck Are really how do you ensure that that code is what you really wanted? Because writing the code is easy, but getting what is needed for a specific problem can be much harder to to specify. So humans, at least in the near future, will be that role of architecture or thinking of what are really the implication of that piece of code I'm getting the ml two to design. Inductive thinking is another category where I think humans still have a a very clear edge. Which is to look at a system in a much wider context and to be able to detect patterns, and from those pattern, take some decision. So where are we today? Superhuman syntax generation. When is the last time I got Gemini to write a function for me? And I looked at the function, and I was like, I can do that better. It's over. I think that the minutiae of code writing I mean, you can fight. You can argue. You can find counter example but that time is is gone. Where we have a lot of work to do is multi step code base. Software engineering is not about writing code. Software engineering is the first time you join a company and you realize that there are 35,000,000 lines of PHP in the code base and that you need to make some changes. That that's the day you understand what software engineering is. And that's a place where where modules to There are frontier modules are progressing but this ability to manage that extreme complexity and break it down into manageable pieces is a place where the frontier is still moving. It goes all the way to architecture. You look at, I don't know, the Google architecture. Thanks god. We have Jeff Dean, which was, you know, the the key architect there. But that's the level of thinking which has many implication, which can go from how do you do Hardware optimization. How do you manage security? How do you build a system so that ten years later, you're not full of regrets? And I think this is really the the range of progress, we are working on today. So code is server. There's plenty to do. There's plenty of progress to be made. Now code is a very unique problem. And in some way, that's the reason we we did pitchfork on this. First of all, code is a lot Of data. There are other domains where you can find a lot of data to train your model but code was so incredible. You could go and go on GitHub and start to to scrape GitHub. So this was one of those problem where the amount of training data was a very unique situation. It is also a domain where doing verification is reasonable. You can run a piece of code, you can compile it, you can have unit tests. So the ability to figure out is the model generating something Correct. Was something that was pretty reasonable to do. That brought us where we are today. But today, what happened is that we ran out of training data. I think that 80% of the new code added to GitHub today is machine generated. So the notion of human bringing some knowledge that can be used for mining and to train model is reaching an end. But the good news is that we can do self play, and self play is something we Always liked a lot at DeepMind. I suppose all know AlphaZero. AlphaZero became a superhuman Go and chess player without any human knowledge just by playing against itself. We are now at that stage where frontier model for code are able to do the same, where they can create their own challenge. They can judge the validity of the answer. They can even, to some extension, judge the architecture. So that ability to do those Hundreds of millions of hours of self play writing code is the thing that will bring us to the to the next layer. You know, it's interesting. Do the experiment. Take a a brilliant software engineer, lock him in a room, lock him or her in a room for two years and feed pizza, and give the mission you need to become a better software engineer. What do you do as a person? You you give yourself some challenges challenges that you can verify and you keep working and coding on those challenges. We can do the same here. So this is an issue of how much compute, how much self play time we can have but that will bring the horizon of how far we go in superhuman coding. So the economics of code are are changing dramatically. You know, as I say, we developed a whole software engineering culture and infrastructure and set of companies based on the assumption that writing code was the hard part, that this was the expensive part. We're now in a world where writing code is free, or nearly free. That's why I've got the tilde there. That means that the amount of code that we're going to see produce is going to explode, and there are some hard implications to that. First is the question of design and adequacy. How in front of that mountain of code which would be written or written dynamically? How do we keep systems which works and are reliable at the macroscopic level? Great work for human. It is also the issue that, you know, we are writing code, and we're not reading it very much anymore. I mean, I know we still have code review, but, I would predict that in one year, we'll let Gemini or other model generate the code, and nobody will actually look at it. You know, it's similar to compilers. Who still check the assembly output of their compiler? And may maybe, someone there. But, That that's probably the end of it. So the the same thing is going to happen to code, and that brings some question of what are the new process that we need to put in place to keep that manageable. And that's where I've got a a bit of a list. Active guardrails. I mean, you've all seen the news of Mitos looking at a piece of code and detecting, unreasonable number of vulnerability in that code. There is a rush to go and Attached to this vulnerability, but I think that's going to be a never ending process. You know, we're going to get a certain layer of vulnerability discovered by models. We're going to fix those. Models will get smarter. They will go a bit deeper and find even more subtle vulnerability. So I think that the first aspect is that we need to think at least as much about code security and the implication of a piece of code than on the code writing itself. And the Grail You know, something my team is working actively on is instead of detecting the vulnerability and then suggesting some fix, how about teaching model to write correct things from the start? And that is very, very hard to do because it is very context dependent. The other aspect is that, you know, that's what I call inductive architecture. I think that models today are still not very good at transferring knowledge. Of taking knowledge from one domain and applying it to another one or taking two concepts and finding the intersection of those context to be those context to be able to do deductive thinking. If we really want to write those very complex software system using ML, that is a skill that we need to teach. And, you know, one aspect of that is to really teach models how to do correct planning in front of a problem. How do you look at a very complex problem and decide what is the right Decomposition of that problem that will bring the best clarity or correctness to the to the problem. We also need to change the way we do evaluation. I mean, three bench is infamous in in my book because three bench verifies if a piece of code runs and produce the right output. That's only a small part of, as I mentioned earlier, of code engineering. So for instance, I think that we need some problem. It's much more in those benchmarks that we use, which are open ended problem. I'll I'll give an example. I love the question of text compression. How many bits per character do you need and how far can you go? So that's a very simple eval to to write. You just take a piece of 10 megabyte of code, and you tell the model write the best compressor you can that is lossless. And the loss function in that case will be, you know, the size of the compressed file plus the size of the source code. That's never ending. I mean, those problems are, I think, what's going to force those model to do novel things like creating totally new algorithmic, for instance. And I I think we're now getting to that stage. Writing code or doing software engineering is not thinking as a chain of tokens. Thinking and reasoning today is chain of thought, which has been, you know, very successful and improved models a lot. But humans, of course, are much more complex in the way they think about problems. I always think that code writing is a very visual activity, and that can be, I don't know, the block diagram of what you're doing or the flow of data through your code. But saying that code will be just a set of token that you emit that are going to be the code, I think goes only up to a certain point. That's a very interesting aspect to what we do at Google. Gemini. We made the choice from the onset that this would be a multimodal model, that, you know, text was only one of the modality that Gemini would be able to apply. And we're starting to see, you know, how can a model start to think in term of spatial or dynamic representation to to solve problem. And I think that's going to become a must have. Another interesting question is, is this time to create a new language for models? Python, you name it, have been invented for humans. And those language are not very good to write safe or reliable code. I mean, they are they are great to write code, but they are certainly not the the best thing. I think we're getting to the point where since the pain of writing the code does not exist anymore, How about we make writing the code much harder by having, you know, very strongly typed languages or, you know, some inspiration from lean on how To write code that by design, it's not going to be perfect. I mean, program proof is something which has some limits, but at least putting the burden of correctness on the model. So I don't know if we have some language designers here, but I I I think there's something really to be done there. And it doesn't need to be human readable. I I don't think that that will matter anymore. So beyond code, code is a universal language to solve problems. I think that what Starting to see is this ability to experiment very quickly in code is impacting other domain very quickly because doing experiment becomes basically free. So I think that looking at that intersection of code writing and atoms or science is another big front that we are opening. That is the place where true novelty is going to appear. Two which are especially exciting for me is chemistry. You know, as humans, we do not understand chemistry, or we understand a very, very small sliver of chemistry. Once you have more than 20 atoms in your molecule, it's like, well, we don't know what that thing is going to do. I think we're going to see incredible things emerging out of that. I mean, once you are able to put 10,000 atoms together, that starts to look like life. So what are all the other things you can do with 10,000 atoms? Biology, you probably heard plenty about it, but, you know, biology Is the case of Netgear did an incredible engineering job and terrible job at documentation. But we can crack through that now. Modals are able to find those relationship that might be elusive for us. So I think that that is something that will open incredible door. And then there is what I call the gold we cannot see.

## Slides

### 00:00:21

# Go deeper on human-agent interaction.

### MAKING A MIND - PODCAST
The cognitive science of building a mind
hosted by Dr. Danielle Perszyk

Amazon AGI Lab

[

### 00:00:51

# More sessions this week.

## MAIN STAGE & TRACKS
MON - 2:20 WORKSHOP
**Build with Perception Agents**
Emile Baizel, Shruti

### 00:01:17

# Google DeepMind
AIE

### 00:01:53

- AI Engineer World's Fair
- Microsoft
- OpenAI
- Akamai
- DataDog

[Logos for Microsoft, OpenAI, Akamai, and DataDog are displayed.]

### 00:02:48

# From Assembly to **Vibe Coding**
A technical roadmap of constraints, ML capabilities, and the future of engineering intent.

Benoit Schillings
Google DeepMind

---

Research to Reality with Google DeepMind
Benoit Schillings / Vice President of Research Google DeepMind

### 00:03:19

# From Assembly to **Vibe Coding**
A technical roadmap of constraints, ML capabilities, and the future of engineering intent.

Benoit Schillings
Google DeepMind

### 00:04:24

# Origin story

## Resisting Technical Shift
It is natural to resist progress. From writing 68000 assembly and eyeing early compilers with strong suspicion, to dismissing GC/interpreted languages, the cycle of skepticism is predictable. Today, building with modern high-level abstraction loops turns even the most cynical purist into an avid ml coder.

## Google X & Pitchfork Roots
Project Pitchfork was initially designed to optimize codebase evolutions by matching review edits.
We never anticipated LLMs would scale this fast. The once impossible concept of vibe coding has become an daily workflow reality.

---

### Research to Reality with Google DeepMind
Benoit Schillings / Vice President of Research Google DeepMind

### 00:04:47

# Origin story

## Resisting Technical Shift
It is natural to resist progress. From writing 68000 assembly and eyeing early compilers with strong suspicion, to dismissing GC/interpreted languages, the cycle of skepticism is predictable.

Today, building with modern high-level abstraction loops turns even the most cynical purist into an avid ml coder.

## Google X & Pitchfork Roots
Project Pitchfork was initially designed to optimize codebase evolutions by matching review edits.

We never anticipated LLMs would scale this fast. The once impossible concept of vibe coding has become an daily workflow reality.

### Research to Reality with Google DeepMind
Benoit Schillings / Vice President of Research Google DeepMind

### 00:05:20

# Origin story

### Resisting Technical Shift
It is natural to resist progress. From writing 68000 assembly and eyeing early compilers with strong suspicion, to dismissing GC/interpreted languages, the cycle of skepticism is predictable.

Today, building with modern high-level abstraction loops turns even the most cynical purist into an avid ml coder.

### Google X & Pitchfork Roots
Project Pitchfork was initially designed to optimize codebase evolutions by matching review edits.

We never anticipated LLMs would scale this fast. The once impossible concept of vibe coding has become an daily workflow reality.

## Research to Reality with Google DeepMind
Benoit Schillings / Vice President of Research Google DeepMind

### 00:05:47

# The Software Eras

| Phase | The Core Bottleneck | Human Role |
|---|---|---|
| The Assembly/C++ Era | Silicon & Memory (Hardware constraints) | Manual optimization, extreme precision |
| The Modern/Cloud Era | Human Cognitive Load (Context stack constraints) | Designing for modularity and maintainability |
| The Frontier AI Era | Verifiability & Intent (Correctness constraints) | Inductive thinking, architecture, security guardrails |

## Research to Reality with Google DeepMind
### Benoit Schillings / Vice President of Research Google DeepMind

[Table comparing software eras by core bottleneck and human role]

### 00:06:20

# The Software Eras

| Phase                   | The Core Bottleneck                               | Human Role                                                |
| :---------------------- | :------------------------------------------------ | :-------------------------------------------------------- |
| The Assembly/C++ Era    | Silicon & Memory (Hardware constraints)           | Manual optimization, extreme precision                    |
| The Modern/Cloud Era    | Human Cognitive Load (Context stack constraints)  | Designing for modularity and maintainability              |
| The Frontier AI Era     | Verifiability & Intent (Correctness constraints)  | Inductive thinking, architecture, security guardrails     |

## Research to Reality with Google DeepMind
Benoit Schillings / Vice President of Research Google DeepMind

### 00:06:48

# The Software Eras

| Phase | The Core Bottleneck | Human Role |
|---|---|---|
| The Assembly/C++ Era | Silicon & Memory (Hardware constraints) | Manual optimization, extreme precision |
| The Modern/Cloud Era | Human Cognitive Load (Context stack constraints) | Designing for modularity and maintainability |
| The Frontier AI Era | Verifiability & Intent (Correctness constraints) | Inductive thinking, architecture, security guardrails |

### Research to Reality with Google DeepMind
Benoit Schillings / Vice President of Research Google DeepMind

### 00:07:19

# The Software Eras

| Phase                 | The Core Bottleneck                       | Human Role                                                |
| :-------------------- | :---------------------------------------- | :-------------------------------------------------------- |
| The Assembly/C++ Era  | Silicon & Memory (Hardware constraints)   | Manual optimization, extreme precision                    |
| The Modern/Cloud Era  | Human Cognitive Load (Context stack constraints) | Designing for modularity and maintainability              |
| The Frontier AI Era   | Verifiability & Intent (Correctness constraints) | Inductive thinking, architecture, security guardrails     |

## Research to Reality with Google DeepMind
### Benoit Schillings / Vice President of Research Google DeepMind

### 00:07:48

# The Software Eras

| Phase | The Core Bottleneck | Human Role |
| :-------------------- | :------------------------------------------ | :---------------------------------------------------- |
| The Assembly/C++ Era | Silicon & Memory (Hardware constraints) | Manual optimization, extreme precision |
| The Modern/Cloud Era | Human Cognitive Load (Context stack constraints) | Designing for modularity and maintainability |
| The Frontier AI Era | Verifiability & Intent (Correctness constraints) | Inductive thinking, architecture, security guardrails |

Research to Reality with Google DeepMind
Benoit Schillings / Vice President of Research Google DeepMind

### 00:08:20

# State of AI Software Engineering

- Super-human Syntax Generation: 95%
- Local Problem Solving & Tasks: 70%
- Multi-step Codebase Planning: 45%
- Architectural System Decisions: 25%

Models generate localized code rapidly but struggle to form cohesive systems, design complex architectures, and predict overall security flaws.

### Research to Reality with Google DeepMind
Benoit Schillings / Vice President of Research Google DeepMind

[Horizontal bar chart showing AI software engineering capabilities across four categories with percentages]

### 00:08:53

# State of AI Software Engineering

- Super-human Syntax Generation: **95%**
- Local Problem Solving & Tasks: **70%**
- Multi-step Codebase Planning: **45%**
- Architectural System Decisions: **25%**

Models generate localized code rapidly but struggle to form cohesive systems, design complex architectures, and predict overall security flaws.

### Research to Reality with Google DeepMind
Benoit Schillings / Vice President of Research Google DeepMind

[Horizontal bar chart illustrating AI capabilities in software engineering tasks, showing percentages for different levels of complexity]

### 00:09:14

# State of AI Software Engineering

- Super-human Syntax Generation: 95%
- Local Problem Solving & Tasks: 70%
- Multi-step Codebase Planning: 45%
- Architectural System Decisions: 25%

Models generate localized code rapidly but struggle to form cohesive systems, design complex architectures, and predict overall security flaws.

---

### Research to Reality with Google DeepMind
Benoit Schillings / Vice President of Research Google DeepMind

[Horizontal bar chart showing percentages for different AI software engineering capabilities]

### 00:09:47

# State of AI Software Engineering

- Super-human Syntax Generation: **95%**
- Local Problem Solving & Tasks: **70%**
- Multi-step Codebase Planning: **45%**
- Architectural System Decisions: **25%**

Models generate localized code rapidly but struggle to form cohesive systems, design complex architectures, and predict overall security flaws.

### Research to Reality with Google DeepMind
Benoit Schillings / Vice President of Research Google DeepMind

[Horizontal bar chart showing the state of AI software engineering capabilities with percentages]

### 00:10:20

# The AlphaZero Sandbox

## Self-Play & Executable Loops

Unlike standard text generators, coding tasks exist within highly structured, deterministic environments that compile and run.

- **Continuous Verification**: Compilers and execution provide strict feedback loops.
- **Reinforcement Optimization**: Self-play enables models to validate their work automatically.
- **Infinite Sandbox**: Increasing performance through continuous closed loops.

---

### Research to Reality with Google DeepMind

Benoit Schillings / Vice President of Research Google DeepMind

[

### 00:10:45

# The AlphaZero Sandbox

## Self-Play & Executable Loops
Unlike standard text generators, coding tasks exist within highly structured, deterministic environments that compile and run.
- **Continuous Verification**: Compilers and execution provide strict feedback loops.
- **Reinforcement Optimization**: Self-play enables models to validate their work automatically.
- **Infinite Sandbox**: Increasing performance through continuous closed loops.

### Research to Reality with Google DeepMind
Benoit Schillings / Vice President of Research Google DeepMind

[Diagram showing multiple grid-like squares with scattered white dots, some squares labeled with percentages like 18%, 9%, 35%, 23%, 42%]

### 00:11:20

# The AlphaZero Sandbox

## Self-Play & Executable Loops
Unlike standard text generators, coding tasks exist within highly structured, deterministic environments that compile and run.
- Continuous Verification: Compilers and execution provide strict feedback loops.
- Reinforcement Optimization: Self-play enables models to validate their work automatically.
- Infinite Sandbox: Increasing performance through continuous closed loops.

[Diagram showing multiple grid-like cells, each with a percentage (e.g., 18%, 35%, 9%, 23%, 42%) and a scattering of white and black dots, representing a sandbox or loop concept.]

### Research to Reality with Google DeepMind
Benoit Schillings / Vice President of Research Google DeepMind

### 00:11:49

# The AlphaZero Sandbox

## Self-Play & Executable Loops

Unlike standard text generators, coding tasks exist within highly structured, deterministic environments that compile and run.
- **Continuous Verification**: Compilers and execution provide strict feedback loops.
- **Reinforcement Optimization**: Self-play enables models to validate their work automatically.
- **Infinite Sandbox**: Increasing performance through continuous closed loops.

Research to Reality with Google DeepMind
Benoit Schillings / Vice President of Research Google DeepMind

[Diagram showing multiple grid-like structures with dots, some highlighted, and percentages (18%, 35%, 23%, 9%, 42%) overlaid]

### 00:12:20

# The Economics of Code

## ~$0
Marginal Cost of Code

### The Bottleneck Transformed
When generating code becomes virtually free, software creation is no longer the key constraint.

### 00:12:47

# The Economics of Code

- ~$0
  Marginal Cost of Code

## The Bottleneck Transformed
When generating code becomes virtually free, software creation is no longer the key constraint. The system pressure shifts to validation and specification.

The core disciplines of the future engineer will focus on defining system correctness, auditing security boundaries, and designing precise constraints.

Write only code, fast code refresh. This is the same step we saw with compilers, who still reads the assembly output ?

---
Research to Reality with Google DeepMind
Benoit Schillings / Vice President of Research Google DeepMind

[Diagram showing an arrow from "Marginal Cost of Code" pointing towards a sequence of icons: a chip for validation, a checkmark for specification, a brain for security architecture, and a shield with a network diagram.]

### 00:13:21

# The Economics of Code

~ $0
Marginal Cost of Code

### The Bottleneck Transformed
When generating code becomes virtually free, software creation is no longer the key constraint. The system pressure shifts to validation and specification.

The core disciplines of the future engineer will focus on defining system correctness, auditing security boundaries, and designing precise constraints.

Write only code, fast code refresh. This is the same step we saw with compilers, who still reads the assembly output ?

## Research to Reality with Google DeepMind
Benoit Schillings / Vice President of Research Google DeepMind

[Abstract background with glowing code elements and a diagram showing a flow from validation to specification to security architecture, with icons for a CPU, a checkmark, and a brain.]

### 00:13:50

# Frontier AI Engineering Challenges

## Active Guardrails
We must transition our focus from post-generation patching to secure-by-default architecture at the initial model production level.

## Inductive Architecture
Teaching neural nets to reason from code outputs to construct broader systems without losing context is a key active research focus.

## Evals Refactoring
Transitioning coding evaluation criteria from strict binary pass/fail unit tests to nuanced, continuous performance and logic scores.

[Shield icon, Brain icon, and Gears icon illustrating the three challenge areas]

### 00:14:25

# Frontier AI Engineering Challenges

## Active Guardrails
We must transition our focus from post-generation patching to secure-by-default architecture at the initial model production level.

## Inductive Architecture
Teaching neural nets to reason from

### 00:14:53

## AI Engineer World's Fair
# Frontier AI Engineering Challenges

### Active Guardrails
We must transition our focus from post-generation patching to secure-by-default architecture at the initial model production

### 00:15:16

# Frontier AI Engineering Challenges

- ### Active Guardrails
  We must transition our focus from post-generation patching to secure-by-default architecture at the initial model production level.
- ### Inductive Architecture
  Teaching neural nets to reason from code outputs to construct broader systems without losing context is a key active research focus.
- ### Evals Refactoring
  Transitioning coding evaluation criteria from strict binary pass/fail unit tests to nuanced, continuous performance and logic scores.

## Research to Reality with Google DeepMind
Benoit Schillings /

### 00:15:48

# Frontier AI Engineering Challenges

- **Active Guardrails**
  We must transition our focus from post-generation patching to secure-by-default architecture at the initial model production level.
- **Inductive Architecture**
  Teaching neural nets to reason from code outputs to construct broader systems without losing context is a key active research focus.
- **Evals Refactoring**
  Transitioning coding evaluation criteria from strict binary pass/fail unit tests to nuanced, continuous performance and logic scores.

### Research to Reality with Google DeepMind
Benoit Schillings / Vice President of Research Google DeepMind

[Icon of a shield next to "Active Guardrails"]
[Icon of a brain next to "Inductive Architecture"]
[Icon of a wrench next to "Evals Refactoring"]

### 00:16:21

# Frontier AI Engineering Challenges

### Active Guardrails
We must transition our focus from post-generation patching to secure-by-default architecture at the initial model production level.

### Ind

### 00:16:47

# Next-Gen Architecture Foundations

### Multimodal Design Reason
Software architecture is visual and spatial, not just textual. Modern multimodal models like Gemini are bridging this gap, allowing direct evaluation of visual flowcharts and interface layouts against the synthesized code.

### LLM-Native Target Languages
Human developers require languages that optimize for code readability. For AI models, do we still need standard languages, or do we pivot to mathematically precise, highly rigorous specification engines like Rust?

## Research to Reality with Google DeepMind
Benoit Schillings / Vice President of Research Google DeepMind

[Image of a person working at a desk with multiple monitors, drawing in a notebook, and interacting with holographic architectural diagrams]

### 00:17:19

# Next-Gen Architecture Foundations

## Multimodal Design Reason
Software architecture is visual and spatial, not just textual. Modern multimodal models like Gemini are bridging this gap, allowing direct evaluation of visual flowcharts and interface layouts against the synthesized code.

## LLM-Native Target Languages
Human developers require languages that optimize for code readability. For AI models, do we still need standard languages, or do we pivot to mathematically precise, highly rigorous specification engines like Rust?

Research to Reality with Google DeepMind
Benoit Schillings / Vice President of Research Google DeepMind

[Image of a person working at a desk with a monitor showing code and a notebook with a diagram, overlaid with a holographic software architecture diagram]

### 00:17:47

# Next-Gen Architecture Foundations

### Multimodal Design Reason
Software architecture is visual and spatial, not just textual. Modern multimodal models like Gemini are bridging this gap, allowing direct evaluation of visual flowcharts and interface layouts against the synthesized code.

### LLM-Native Target Languages
Human developers require languages that optimize for code readability. For AI models, do we still need standard languages, or do we pivot to mathematically precise, highly rigorous specification engines like Rust?

---
Research to Reality with Google DeepMind
Benoit Schillings / Vice President of Research Google DeepMind

[Conceptual illustration of a person working on software architecture, with a holographic overlay of a system diagram]

### 00:18:20

# Next-Gen Architecture Foundations

## Multimodal Design Reason
Software architecture is visual and spatial, not just textual. Modern multimodal models like Gemini are bridging this gap, allowing direct evaluation of visual flowcharts and interface layouts against the synthesized code.

## LLM-Native Target Languages
Human developers require languages that optimize for code readability. For AI models, do we still need standard languages, or do we pivot to mathematically precise, highly rigorous specification engines like Rust?

### Research to Reality with Google DeepMind
Benoit Schillings / Vice President of Research Google DeepMind

[Image of a person working at a desk with a computer and a notebook, overlaid with a conceptual diagram of a software architecture]

### 00:18:53

# Next-Gen Architecture Foundations

## Multimodal Design Reason
Software architecture is visual and spatial, not just textual. Modern multimodal models like Gemini are bridging this gap, allowing direct evaluation of visual flowcharts and interface layouts against the synthesized code.

## LLM-Native Target Languages
Human developers require languages that optimize for code readability. For AI models, do we still need standard languages, or do we pivot to mathematically precise, highly rigorous specification engines like Rust?

### Research to Reality with Google DeepMind
Benoit Schillings / Vice President of Research Google DeepMind

[Illustration of a person working at a desk with multiple monitors, overlaid with a glowing digital architecture diagram showing interconnected components like UI, API Gateway, and Database.]

### 00:19:20

# Beyond Code
## Universal Execution Engines
Code is becoming a raw material for wider discovery. Agents construct software toolboxes on the fly, run complex scientific simulations, and immediately discard the program once a solution is reached.

[A robotic arm in a lab setting, with a person in the background]

### 00:19:53

# Beyond Coding: The Next Frontier
## Applying Universal Execution to Physical Sciences

Having mastered the virtual logic of software generation, AI execution engines are pivoting to the infinitely more complex physical world. The next phase shifts from synthetic code to discovery in the atom space.

### Computational Chemistry
Simulating atomic bounds, discovering novel catalysts, and predicting molecular configurations on the fly, transforming materials science from trial-and-error to pure computation.

### Complex Biology
Mapping evolutionary cellular pathways, engineering bespoke proteins, and modeling cellular machinery to treat previously incurable human conditions at scale.

[Diagram illustrating an AI Discovery Pipeline, showing stages from protein folding prediction and data analysis of molecular structures to
