Keynote by Benoit Schillings of Google DeepMind on generative AI for code and the future of model reasoning. He leads the Thinking, Reasoning, and Coding teams, directing foundational research on next-generation model reasoning and AI code generation; previously CTO at X. Topics include the shift from syntax generation to architecture and validation, self-play as a training approach as human data saturates, the changing economics of software engineering (guardrails, security, code volume), inductive architectures that plan and decompose problems beyond token prediction, and potential AI applications in chemistry and biology. # Video Identity Observations — Benoit Schillings Talk ## Video Overview A conference keynote talk featuring **Benoit Schillings, VP of Research at Google DeepMind**, arguing that AI has made code generation cheap and that software engineering's remaining challenges lie in specification, architecture, verification, and evaluation. ## Creator Self-Description Evidence This video documents a **guest speaker at an event**, not direct channel self-description. Observable self-description comes from the speaker describing himself and his role: - Speaker states his role and team mission: > "my team goal in deep mind is basically to develop whatever technology will be needed to make Gemini incredible between one months and one year from now" - Speaker describes prior career context: > "Till a year and a half ago, I was working for Google X... We've done things like Whimo... we also do things like Glass" > "I've been writing code for 45 years. I started by writing video game for Apple 2 and Commodore 64." ## Intended Audience - **Software engineers and ML practitioners** — talk assumes familiarity with concepts like GitHub, code review, unit tests, Lean, and benchmarks. - **Conference attendees** — framing language: "good morning," "it's really quite exciting to be here and have a chance to speak with all of you," closing with applause. - Audience expected to know DeepMind's work: > "I suppose all know Alpha Zero" - A possible sub-audience is invoked directly: > "I don't know if we have some language designers here" ## Claimed Scope / Topics Covered - **AI-assisted software engineering**: the Pitchfork project origin story at X (started 2018) for ML-assisted code writing. - **Selfplay and frontier coding models**: models "create their own challenge... judge the validity of the answer." - **Code security**: "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." - **Model evaluation**: critique of benchmarks and proposal of open-ended problems (e.g., lossless text compression). - **Future languages for models**: "How about we make writing the code much harder by having very strongly typed languages." - **Cross-domain applications**: chemistry and biology as frontiers where code-driven experimentation enables novelty. ## Demonstrated Presentation Patterns (Observable) - **Narrative-driven, personal-history style**: uses his own arc (assembly → C++ → Python → "V coding") to frame technological shifts. - **Bold, quotable claims** used as anchors: > "Software engineering is not about writing code" > "writing code is free or nearly free" > "I think that 80% of the new code added to GitHub today is machine generated" - **Thought-experiment rhetoric**: > "Take a a brilliant software engineer, lock him in a room... feed pizza and give the mission you need to become a better software engineer." - **Forward-looking predictions**, e.g., that within a year generated code will not be human-reviewed, analogized to compiler output. - **Humble self-correction as a device**: > "Some people were talking about vibe coding... at the time honestly I totally dismissed that... Well I I guess I was pretty wrong on that front." ## Claims vs. Demonstrated Distinction - **Creator-claimed facts** (speaker statements, unverified in this material): 80% GitHub machine-generated figure, "35 million lines of PHP" anecdote as illustrative, team goals for Gemini. - **Demonstrated**: the speaker's depth of engineering experience, DeepMind affiliation, and the channel's access to senior industry figures — evidenced by the introduction ("vice president of research... at Google DeepMind") and sustained technical detail throughout. ## Metadata No curated metadata was supplied; identity observations rest on title and transcript only. # Delivery Observation Report: Benoit Schillings ## Tone & Register - **Conversational, self-deprecating humor.** He repeatedly pokes fun at himself and the audience's profession: > "I'm actually a bit of a noob when it comes to machine learning." > "So even old dogs can learn new tricks." > "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." - **Casual, spoken register** with frequent "you know," "uh," "I mean," and throat-clearing — the transcript reads as an unscripted talk, not a rehearsed keynote. ## Vocabulary & Framing - **Era-based framing.** He organizes history into distinct periods: assembly-language era, "modern cloud era," and "the AI frontier" — a recurring explanatory device ("I think that we have a number of eras"). - **Economics vocabulary** applied to code: "the economics of code are changing dramatically," "writing code was the hard part… writing code is free or nearly free," "the amount of code… is going to explode." - **Personal coinages / informal labels** for research directions: "vibe coding," "the gold we cannot see," "inductive architecture," "the grail." ## Recurring Rhetorical Patterns - **Admission of past wrongness as a teaching device**, used at least three times: - "Honestly nobody would give us the time of the day… why would you ever need ML to write code." - "I totally dismissed that… Well I guess I was pretty wrong on that front." - His assembly-to-Python career arc as evidence of skepticism toward change. - **Direct audience address and hypothetical scenarios:** > "do the experiment. Take a brilliant software engineer, lock him in a room for two years and feed pizza…" > "I don't know if we have some language designers here, but I think there's something really to be done there." > "Software engineering is the first time you join a company and you realize that there are 35 million lines of PHP…" - **Concrete anchor points** — numbers, products, and named systems used as evidence: "80% of the new code added to GitHub today is machine generated," "seven and nine tokens," Alpha Zero, Waymo, Glass, Jeff Dean. ## Teaching Habits - **Thesis restatement:** the title claim is delivered verbatim mid-talk: > "Software engineering is not about writing code." followed immediately by an illustrative scenario — pattern: claim → vivid example. - **Contrast pairs** structure many points: "writing the code is easy but getting what is needed… can be much harder"; "detecting the vulnerability and then suggesting some fix how about teaching model to write correct things from the start"; biology as "incredible engineering job and terrible job at documentation." - **List-based agenda setting:** "that's where I've got a bit of a list" introduces the guard-rails/evaluation/language section. ## Communication Quirks - **Frequent verbal stumbles and self-repairs** visible in the transcript: "to to speak," "I I I think," "those context to be those context to be." - **Slide-aware narration:** "that's why I've got the tilda there" — he verbalizes on-screen content. - **Rapid topic pivots** via short connectors: "So where are we today?", "Now code is a very unique problem," "So beyond code." ## Uncertainty Notes - The transcript lacks speaker tone, pacing, and gesture data; observations on humor delivery and audience reaction rest only on textual cues (one "[applause]", "[music]"). - One possible transcript artifact: "mythos looking at a piece of code" — likely a mis-transcription; the referent is uncertain and should not be treated as a factual claim about the speaker's wording. # Observation Document: "Software engineering is not about writing code" — Benoit Schillings **Speaker:** Benoit Schillings, VP of Research, Google DeepMind (introduced as such; self-identified in transcript) ## Speaker Background & Role - Self-describes as "a bit of a noob when it comes to machine learning"; worked at Google X until ~1.5 years ago (Waymo, Glass cited as projects with "a mix of hit and success"). - His DeepMind team's goal: "develop whatever technology will be needed to make Gemini incredible between one months and one year from now" — one month because one-week work is a different job; one year because "I don't think anybody can really predict anything that far." - Team also works on reasoning evolution for models, network topology research, and fundamentals of reinforcement learning. ## Origin Story: Pitchfork - Started **Pitchfork** at X in 2018 to explore ML improving code writing. - In 2018, "nobody would give us the time of day" at Google — skepticism of why ML was needed for code. - Original goal: speeding up small code-change cycles ("the small edit which requires a review that takes three days"). - Admits error: "Some people were talking about vibe coding… at the time honestly I totally dismissed that… I was pretty wrong on that front." ## Personal Career Parallel - 45 years writing code; started with assembly on Apple II / Commodore 64. - Describes his own pattern of resistance: suspicion of compilers, then viewing garbage-collected languages as "not real programming" — "today I use Python and V coding. So even old dogs can learn new tricks." ## Eras of Software 1. **Machine-limited era:** assembly, extracting maximal performance. 2. **Cloud era:** performance less critical; limit became modular design ("write it only once," libraries, decomposition) — constrained by the human brain's context capacity ("seven and nine tokens" of working context, contrasted with near-infinite ML context). 3. **AI frontier era (current):** writing code is no longer the challenge; bottlenecks are **verification/specification** ("getting what is needed for a specific problem can be much harder to specify"). ### Remaining Human Roles - **Architecture** and thinking through implications of code. - **Inductive thinking**: seeing systems in wider context, detecting patterns, deciding from patterns. ## State of the Art - **Superhuman syntax generation:** "When is the last time I got Gemini to write a function… and I was like, I can do that better. It's over." - **Open frontier — multi-step codebases:** "Software engineering is not about writing code. Software engineering is the first time you join a company and you realize that there are 35 million lines of PHP…" Managing extreme complexity and architecture (cites Jeff Dean at Google) is where frontier models are still progressing. - Summary claim: "code is over but there's plenty to do." ## Why Code Is Unique for ML - Abundant training data (GitHub scraping). - Verification is feasible: run, compile, unit test. ## Training Data Exhaustion & Self-Play - Claim: "80% of the new code added to GitHub today is machine generated"; human-mined knowledge is "reaching an end." - Solution: **selfplay**, as in Alpha Zero (superhuman Go/chess without human knowledge). Frontier code models can create their own challenges, judge answer validity, and "to some extent judge the architecture." - Analogy: a brilliant engineer locked in a room for two years would self-assign verifiable challenges — the same applies, limited only by compute/self-play time, which sets "the horizon of how far we go in superhuman coding." ## Changing Economics of Code - Software culture/infrastructure assumed writing code was the hard, expensive part; now writing code is "free or nearly free" (hence the tilde). - Implication: amount of code produced will "explode." ### Consequences - **Design and adequacy:** keeping systems reliable amid mountains of code — "great role for human." - **Nobody reads code anymore:** prediction that "in one year we'll let Gemini or other model generate the code and nobody will actually look at it" — parallel to nobody checking compiler assembly output. - **Active guardrails:** models (he references "mythos" in the news) detecting vulnerabilities; patching will be "a neverending process" as models find ever subtler vulnerabilities. Security implications deserve at least as much attention as code writing. - **Grail** (his team's active work): teaching models to write correct code from the start rather than detect-and-fix — "very very hard" because highly context-dependent. ## Inductive Architecture & Evaluation - Models still weak at **knowledge transfer** across domains and at deductive thinking; need to teach **correct planning** and problem decomposition. - **Evaluation critique:** calls "threebench" (HumanEval-type run-and-check benchmarks) "infamous in my book" — running correctly is only a small part of software engineering. Advocates **open-ended benchmarks**, e.g., lossless text compression where the loss = compressed file size + source code size; these force "novel things like creating totally new algorithmic." ## Reasoning Modalities & New Languages - Current reasoning = "chain of code"; humans are more complex. Code writing is "a very visual activity" (block diagrams, data flow). - Praises Google Gemini's multimodal design choice from the onset; models thinking in spatial/dynamic representations will become "a must have." - Proposes **new languages for models**: Python etc. were invented for humans and are poor for safe/reliable code. Since writing cost is gone, make code harder to write — strongly typed languages, Lean-inspired — "putting the burden of correctness on the model." Doesn't need to be human-readable. ## Beyond Code - Code as a universal problem-solving language; free experimentation is spilling into science — "the place where true novelty is going to appear." - **Chemistry:** humans understand only a "very very small sliver"; beyond ~20 atoms prediction fails; "once you are able to put 10,000 atoms together that starts to look like life." - **Biology:** "nature did an incredible engineering job and terrible job at documentation"; models can find elusive relationships. - **"The gold we cannot see":** humans are biased by evolutionary training for jungle survival, "not doing quantum computing" — ML offers a viewpoint that may reveal breakthroughs "in front of us the whole time and we could not see it." ## Preserved Qualifications & Contradictions - "You can fight, you can argue, you can find counter example, but that time is gone" — acknowledges counterexamples even while claiming syntax generation is superhuman. - Self-corrected prediction on vibe coding explicitly retained. - "Free or nearly free" hedged by the tilde on his slide. - Program proof acknowledged to have "some limits." - Models judge architecture only "to some extent." # Speaker Attribution Record — Video `01a15ca8-a202-73d2-89cd-6bacc5a68a81` ## Video **Title:** "Software engineering is not about writing code" — Benoit Schillings, Google DeepMind VP of Research ## Speakers & Roles ### Identified Speaker - **Benoit Schillings** (transcript renders the name as "Benois Schillings / Benois Shellings" in self-introduction) - **Role:** Keynote speaker / presenter (sole substantive speaker) - **Stated affiliation:** Vice President of Research at **Google DeepMind** - **Self-described background:** ~45 years writing code; previously at **Google X** (~until a year and a half before the talk); started writing video games for Apple II and Commodore 64 - **Team mission (as stated by speaker):** develop technology needed for Gemini between one month and one year out; research on code, reasoning evolution, network topology, reinforcement learning science ### Other Voices - **Unidentified emcee/introducer:** "Please welcome to the stage the vice president of research… Benois Schillings." — role: stage introducer, not further identified. - **Audience:** applause and music reactions only; no speaking role. ## Provenance Facts & Referenced Claims (as stated by speaker — unverified) ### Affiliations / Projects Cited - **Pitchfork** — project started at Google X in 2018 on ML for code - **Google X** — Waymo ("Whimo" in transcript), Glass - **Gemini** — Google's multimodal model; speaker's team supports it - **Alpha Zero** — DeepMind self-play example - **Jeff Dean** — named as key architect of Google's architecture - **GitHub** — cited as training data source; speaker claims **~80% of new code added to GitHub is machine generated** (third-party claim, unverified) - **"Mythos"** (as transcribed) — referenced in news re: detecting code vulnerabilities (unverified reference) - **Threebench / "u threebench"** (likely HumanEval-class benchmark; as transcribed) — criticized as an evaluation; naming uncertain in transcript ### Personal Anecdotes - Career arc: assembly → C++/compilers → garbage-collected languages → Python and vibe coding - Initially dismissed writing code in English ("vibe coding") ## Promotional Segments - None explicitly flagged as promotional; talk is an institutional keynote in which the speaker describes his Google DeepMind team's mission and Gemini — noted as **self-promotional context**, not an ad segment. ## Availability Limits - **Curated metadata:** not supplied (no comment availability, chapters, or speaker list beyond transcript). - **Transcript quality:** speaker name inconsistently transcribed ("Benois," "Benoit"); some proper nouns garbled ("Whimo," "mythos," "threebench"); no timestamps available. Please welcome to the stage the vice president of research \[music\] at Google DeepMind, Benois Schillings. \>\> \[music\] \>\> 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 Benois Shellings. I'm actually a bit of a 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 Whimo, which seems to be at every street corner now. Uh 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 deep mind. I do have an incredible team. Uh my team goal in deep mind is basically to develop whatever technology will be needed to make Gemini incredible between one months 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 would happen one year in the future. We do many things under that role. Uh a lot of it is related to code which will be the main subject of my talk today. 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 uh 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 Um, we started the project at X named Pitchfork uh 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 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. 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. 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. Um I've been writing code for 45 years. Uh I started by writing video game for Apple 2 and Commodore 64. So uh 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++ and use compiler, you lose you look at garbage collected languages as this h that's not real programming. You need to manage your memory. Well, today I use Python and V coding. So even old dogs can learn new tricks. So uh 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 process are working where actually the human brain. Uh a traditional human typical human is able to get the context between seven and nine tokens. I mean we have very rich tokens but you compare that to modern ML where the context is basically going to be infinite pretty soon. uh 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. 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. 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. Inductive thinking is another category where I think humans still have 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? Um, 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. 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. 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 35 million lines of PHP in the codebase 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 our models today or frontier models are progressing. But this ability to manage that extreme complexity and break it down into man manageable pieces is a place where the frontier is still moving. Um 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 10 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 over but 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. Um, 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 test. 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 run 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 selfplay and selfplay is something we always liked a lot at deep mind. I suppose all know Alpha Zero. Alpha Zero 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 extent judge the architecture. So that ability to do those hundreds of millions of hours of selfplay writing code is the thing that will bring us to the to the next layer. 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. 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 selfplay time we can have. But that will bring the horizon of how far we go in superhuman coding. So the economics of code 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 tilda there. That means that the amount of code that we're going to see produced 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 will be written or written dynamically, how do we keep systems which works and are reliable at the microscopic level? Great role for human. It is also the issue that you know we're 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 maybe someone there but that's probably the end of it. So 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 \[clears throat\] a bit of a list active guard rails. 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. there is a rush to go and patch those vulnerability but I think that's going to be a neverending 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 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 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 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 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 u threebench is infamous in in my book because threebench 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 problems much more in those benchmarks that we use which are open-ended problem. I 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. 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 code which has been you know very successful and improve 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. 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 that's a very interesting aspect to what we do at Google Gemini we made that 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're great to write code but they're 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, um code is a universal language to solve problems. 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. 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. Um 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 wow 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 atom 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 nature did an incredible engineering job and terrible job at documentation. Um, but we can crack through that now. 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. 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? Not doing quantum computing. So, I think that even though we can be brilliant and innovative, there are whole bunch of progress and breakthrough that can be done which we just cannot see or perceive. If I had more time, I would give some examples. 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. So exciting times ahead. Thank you very much. \[applause\] \>\> \[music\]