AI Engineer World's Fair 2026
Research to Reality with Google DeepMind
Read the talk
From Assembly to Vibe Coding: What Becomes Hard When Code Becomes Cheap?
Benoit Schillings traces the shift from writing code to specifying, verifying, and architecting systems—and asks how cheap experimentation could change science.
From a talk by Benoit Schillings
Before you start: Familiarity with functions, code review, unit tests, and basic machine-learning terminology will help.
What should a research team build next?
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A small edit that waits days for review
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The bottleneck moves from machines to specifications
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.
| Era | Main constraint | Engineering response |
|---|---|---|
| Machine-limited computing | Execution resources | Precise, low-level optimization |
| Cheaper cloud computing | Human manageability | Libraries, functions, modular decomposition |
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A function is not a codebase
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From training data to verifiable practice
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Nearly free code creates a control problem
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?
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Guardrails, architecture, and better objectives
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:
python
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Reasoning beyond a chain of tokens
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make the language demand more correctness
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Cheap experimentation reaches beyond software
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The gold we cannot see
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
DeepMind's overview of learning through self-play and the distinction between AlphaZero and MuZero.
Anthropic's vulnerability-discovery methods, examples, validation process and reported limitations.
The original benchmark paper on resolving real GitHub issues through repository edits.
Explains Lean's programming and proof capabilities, including the assumptions behind verified software.
Google's original account of Gemini's multimodal design and launch capabilities.
Further reading
The 1956 paper explaining memory chunks and recoding behind the familiar seven-plus-or-minus-two formulation.
Read the complete timestamped transcript
- 0:00
[on-hold jingle] Please welcome to the stage the Vice President of Research at Google DeepMind, Benoit Schillings. [upbeat music]
- 0:49
All right. Good morning. Uh, this is really quite exciting to be here and have a chance to, to speak with all of you. Uh, my name is Benoit Schillings.
- 0:57
I'm actually a bit of a noob when it comes to, to machine learning. Uh, till a year and a half ago, uh, I was working for Google X, which some of you may know.
- 1:08
We've done things like Waymo, which seems to be at every street corner now. Uh, we also do things like Glass. So, you know, we had, we had a mix of, uh, hit and success.
- 1:19
Uh, but in many ways, this was, for me, an interesting formative experience on how to run a, a research team in a place like DeepMind. I do have an incredible team.
- 1:29
Uh, 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.
- 1:49
And one year because I don't think anybody can really predict anything that far. So, uh, that's already pretty ambitious, in my opinion, to think about things that would happen, uh, one year in the future.
- 2:02
We do many things, uh, under that, uh, uh, uh role. Uh, a lot of it is related to code, which will be the main subject of my talk today.
- 2:11
Uh, 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?
- 2:24
Uh, we do fundamental work in the science of reinforcement learning, which is so fundamental to what we're doing today, uh, with ML.
- 2:35
Let's do a bit of an origin story. Um,
- 2:41
we started the project at X named Pitchfork, uh, in two thousand eighteen, uh, which was aimed at looking at how ML could really improve the way code is being written.
- 2:54
And this was very interesting because in two thousand eighteen when we presented that at Google, honestly, nobody would give us the time of day. Uh, there was that point like, "Why would you ever need ML to, to write code?"
- 3:09
Um, 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.
- 3:22
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.
- 3:35
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."
- 3:45
Well, I, 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.
- 3:58
Um, I've been writing code for forty-five years. Uh, I started by writing video game for Apple II and Commodore 64. So, uh, my formation was to write assembly language.
- 4:12
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++ and use compiler, you lose-- you look at garbage collected languages as this.
- 4:27
"Hmm, that's not real programming. You need to manage your memory." Well, today I use Python and vibe coding. So, uh, even old dogs can learn new tricks. So, uh, but, but I, I do understand what happened there.
- 4:43
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.
- 4:55
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, uh, um, assembly language, where you really needed to be incredibly accurate in the way you were writing code.
- 5:11
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.
- 5:24
But really what became the limiting factor was the ability for us to design, uh, 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?
- 5:40
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, uh, and that determined a lot of how our software process are working, were actually the human brain.
- 5:55
Uh, 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.
- 6:11
Uh, that fundamental limitation of human determine 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.
- 6:26
Uh, I'll speak some more about it, but the bottlenecks 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.
- 6:41
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 to, to design.
- 6:53
Inductive thinking is another category where I think humans still have a, a very clear edge, uh, 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.
- 7:09
So where are we today? Uh, superhuman syntax generation.
- 7:15
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"?
- 7:23
It's over. Uh, I think that the minutia of code writing, I mean, you can fight, you can argue, you can find counter example, but that time is, is gone.
- 7:34
Where we still have a lot of work to do is multi-step code base. Uh, software engineering is not about writing code. Software engineering is the first time you join a company and you realize that there are thirty-five million lines of PHP in the code base and that you need to make some changes.
- 7:53
That, that's the day you understand what software engineering is. And that's a place where, where models today or frontier models are progressing, but this ability to manage that extreme complexity and break it down into mana-manageable pieces is a place where the frontier is still moving.
- 8:11
Um, it goes all the way to architecture. Uh, 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.
- 8:23
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?
- 8:36
And I, I think this is really the, the range of progress, uh, we are working on today. So code is over, but there's plenty to do. There's plenty of progress to be made.
- 8:48
Now, code is a very unique problem, and in some way, that's the reason we, we did Pitchfork on this. Um,
- 8:57
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.
- 9:05
You could go and go on GitHub and start to, to scrape GitHub. So th-this was one of those problem where the amount of training data was a very unique situation.
- 9:16
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 test. So the ability to figure out is the model generating something correct was something that was pretty reasonable to do.
- 9:33
That brought us where we are today. But today, what happened is that we ran out of training data. Uh, I think that eighty percent of the new code added to GitHub today is machine-generated.
- 9:45
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.
- 10:01
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.
- 10:22
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.
- 10:36
You know, it's interesting. Um, 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.
- 10:51
Uh, 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.
- 11:00
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.
- 11:13
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.
- 11:29
We're now in a world where writing code is free, uh, or nearly free. That's why I've got the tilde there.
- 11:37
That means that the amount of code that we're going to see produced is going to explode. A-and there are some hard implications to that. First is the question of design and adequacy.
- 11:49
How in front of that mountain of code which will be written or written dynamically, how do we keep systems which works and are reliable at the macroscopic level? Great role for human.
- 12:01
It is also the issue that, you know, we're writing code, and we're not reading it very much anymore. I mean, I, I know we still have code review, but, uh, I would predict that in one year we'll let Gemini or other model generate the code, and nobody will actually look at it.
- 12:19
Um, you know, it's similar to compilers. Who still check the assembly output of their compiler? I am-- May-maybe, uh, someone there. But, um, that, that's probably the end of it.
- 12:30
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.
- 12:40
And that's where I've got a [clears throat] a bit of a list. Active guardrails. I mean, you've all seen the news of Mythos looking at a piece of code and detecting a unreasonable number of vulnerability in that code.
- 12:56
Um, there is a rush to go and patch those 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.
- 13:09
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.
- 13:27
A-and the grail, and, 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 thing from the start?
- 13:43
And that is very, very hard to do because it is very context-dependent.
- 13:48
The other aspect is that, you know, that's what I call inductive architecture. Uh, 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-- tho-those context to be able to do deductive
- 14:11
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.
- 14:25
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?
- 14:36
We also need to change the way we do evaluation. I mean, uh, SWE-bench is infamous in, in my book because SWE-bench verifies if a piece of code runs and produce the right output.
- 14:51
That's only a small part of, as I mentioned earlier, of code engineering. So for instance, I think that we need some problems much more in those benchmark that we use which are open-ended problem.
- 15:04
Uh, I'll, I'll give an example. Uh, 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.
- 15:15
You just take a piece of ten 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.
- 15:29
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.
- 15:45
Writing code or doing software engineering is not thinking as a chain of tokens.
- 15:51
Thinking and reasoning today is chain of thought which has been, you know, very successful and improve models a lot. But humans, of course, are much more complex in the way they, they think about problems.
- 16:03
I, 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.
- 16:14
Uh, 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.
- 16:24
That's a very interesting aspect to what we do at Google. Gemini, we made a 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.
- 16:38
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, a must-have.
- 16:52
Another interesting question is: Is this time to create a new language for models?
- 16:58
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.
- 17:13
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.
- 17:32
I mean, program proof is something which has some limits, but at least putting the burden of correctness, uh, 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.
- 17:45
And it doesn't need to be human readable. I, I don't think that that will matter anymore.
- 17:51
So beyond code, um, code is a universal language to solve problems. Uh, I think that what we're starting to see is this ability to experiment very quickly in code is impacting other domain very quickly because doing experiment becomes basically free.
- 18:10
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.
- 18:24
Two which are especially exciting for me is chemistry. Um, you know, as humans, we do not understand chemistry, or we understand a very, very s- small sliver of chemistry.
- 18:36
Once you have more than twenty atoms in your molecule, it's like, well, we don't know what that thing is going to do. Uh, I think we're going to see incredible things emerging out of that.
- 18:45
I mean, once you are able to put ten thousand atom together, that starts to look like life. So what are all the other things you can do with ten thousand atoms?
- 18:54
Biology, you probably heard plenty about it, but you know, biology is the case of nature did an incredible engineering job and terrible job at documentation. Um, but we can crack through that now.
- 19:08
Models are able to find those relationship that might be elusive for us. So I think that that is something that will open incredible door.
- 19:17
And then there is what I call the gold we cannot see. Humans are incredibly biased in what we feel is the correct solution. I mean, we're the result of an evolutionary training that help us survive in the jungle, right?
- 19:31
Not doing quantum computing. So I think that even though we can be brilliant and innovative, there are a whole bunch of progress and breakthrough that can be done, which we just cannot see or perceive.
- 19:45
If I had more time, I would give some examples, but I think that's one of the thing where ML is such a different viewpoint on many of those problems that we're going to get the, "Oh my God, this was in front of us the whole time, and we could not see it."
- 19:59
So exciting times ahead. Thank you very much. [audience applauding] [upbeat music]