Heat. Heat.

Heat.

Hey, heat. Hey, heat.

Heat. Heat. N.

Heat. Heat.

Heat.

Heat.

Heat. Heat.

Heat. Heat.

Heat. Heat.

Heat. Heat.

Heat. Heat.

Heat. Heat.

Heat.

Heat. Heat.

Launch control. We have a go. Roger.

I need

I need it.

I need

the right

baby.

Baby

Ladies and gentlemen, welcome to the AI

Engineer Worlds Fair. Thank you for

joining us as we continue an exciting

week of innovation, technical insights,

and conversations shaping the future of

AI. Now, please join me in welcoming

your MC, developer advocate at IBM, Tjas

Kuman.

Good morning, AI engineer.

We are here. We made it. We are here. It

is day two. It is such an honor and a

privilege to see so many of you here

today. This conference has broken

records, right? Last year uh was was way

fewer. This year, 7,000 people.

Incredible. Huge round of applause. This

is this is it. This is it.

This is where it happens. Listen,

there's announcements. There's

takeaways. There's content across 18

tracks. 18 track. There's expo sessions.

There's breakouts. There's all kinds of

things, right? And and undeniably, I'll

say this, there is value. Yes. If you've

got value, make some noise this morning.

Absolutely. Absolutely. I have learned

so much uh from so many brilliant people

here and and I have no question that you

have as well. Uh we had an incredible

keynote yesterday. We had so many

keynotes yesterday um where where Swick

started the conference talking about

loops. Um the the theme was was loops.

Why is that funny? Um

okay, it wasn't a joke but um but we had

more keynotes after that about the the

golden age of AI, right? Um one thing

that really stuck out to me and I'm sure

many of us was wiring the agent into the

intent upstream really unlocks more

work. When we start to say why things

are important, we're able to unlock more

work and quality work. We don't just

hand it the task, but we say do this and

and this is why and this is how you

verify, this is how you deploy. We we

get so much more done. Um Teresa talked

about reliability, how important it is.

She talked about the 30x productivity

gap between leaders and laggers. Uh

showing us that really it's about

reliability more than anything else. Um

huge focus about evals at this

conference. Um, and finally, I I was

really struck by by Daksh yesterday who

talked about uh reviewing 1 million AI

generated PRs and and found some

incredible insights. If you didn't catch

that, I highly recommend the videos, the

live stream. So cool. Uh, one thing that

stood out, Claude, uh, code generates,

what was it, three times uh, more off

bypass vulnerability code, unfortunately

for now, but it's just so cool all the

insights that come out of this. Um,

today we've got a lot of things. It is

jam-packed day and I'm very, very

excited about it. There's the newspaper

if you haven't yet read the news. We

have a newspaper now analog uh just to

balance you know the AI. Uh so there's a

there's a daily print newspaper

available for you. There's a live stream

audience. Hello live stream. Thank you

for joining. Um there is over 100 expo

partners. Anyone been to the expo? These

expo booths are incredible. I've seen so

many cool things. There's robots lying

around. So much stuff. There's also this

cool device that I got the B one of the

sponsors. uh it's a notetaker but for

in-person meetings. Anyway, check out

the expose. It's so incredible. Uh we've

got 3.5 days of expo and four uh stages

as well, expo stages. So, look forward

to that. We want to offer a huge thank

you and a massive round of applause for

the incredible sponsors. Honestly, this

conference would not happen without the

support of our sponsors. So, please

everybody, your hands together for the

sponsors of the conference.

We've got Microsoft, the presenting

sponsor. Keep it going. We got

Microsoft.

We've got the lab and platinum sponsors.

We've got You've got to keep it going.

We've got the gold sponsors.

We've got silver and bronze. We've got

so many sponsors. And this conference

genuinely would not be possible without.

So, we're very very thankful. Um, now we

get to introduce we get to open the

state. This is so cool. Today is going

to be such an incredible jam-packed

agenda and I hope all of you can make

all that you want. I mean, there are

quite a few tracks, but don't worry. Uh

there's a live stream, there's also

videos. We're going to start introducing

our first speaker. Oh, I'm excited about

this one. Who saw the announcement about

Fable yesterday?

>> Yeah, let's go. I This is so exciting.

So, so uh coincidentally,

the first talk has changed today. Uh

we're going to This conference moves at

the speed of AI. It's so cool. Um, our

first speaker, uh, Tariq comes to us

from Antropic. Give it up for Tariq.

Comes comes to us from Antropic.

Oh, I'm excited about I was talking to

him backstage and I said, "What what's

this going to be about?" Um, this talk,

I think the first time it's ever been

given, if I'm not mistaken, is about is

going to teach us all how to work with

the new mythos class of models uh, of

which Fable is going to be soonly

available. So, your biggest round of

applause for Tariq.

Please welcome to the stage member of

technical staff at Anthropic, Tariq

Shihipar.

Hey everyone, I'm Thoric. Uh, I work at

Enthropic on Cloud Code. Uh, before we

get started, we have a tradition on

cloud code where we take a selfie before

a talk. So, if you don't mind, if you

strike a pose with me, I'll, uh, take a

quick selfie at AI engineer.

Okay. Incredible. Well, uh, yeah, to

kick things off, like we said, Fable is

back. Um,

we're rolling it out later today. Uh,

keep stay tuned for exact timeline. Me

and Cat Woo and Simon Wilson will be

doing a fireside chat at 12:30. We might

have some updates for you then. Um,

but Fable is a model I'm just so so

excited about. It's one of those

anthropic models where you just like

you're just going to remember it. Like

Sonnet 3.5 new, Opus 4, Opus 4.5. It's a

model that I just have a lot of like

affection and excitement for. And the

best way to describe Fable to me is like

the the map is opening up, you know,

like you are playing like an RPG and

you've been on the tutorial and now you

get to the point where the like, you

know, the open world starts, right? And

there's so much that you can do and

explore. Uh but there's also it's also a

little bit intimidating and confusing,

right? Because there's so much you can

do. And so what I wanted to do in this

talk is give you guys a field guide to

fable, right? How do you work with this

new class of models?

So I've got four parts to it. I've been

working on this as a series of articles

and blog post. Uh but you know when we

announced Fable was coming out I was

like okay let me do uh all of this at

once at the talk uh you know uh

speedrun. So there are four parts

unhobling claude finding your unknowns

dealing with the grief and being

unreasonable.

So first unhobling claude

uh I think something we say really often

is that the models are grown not

designed right we don't wake up and be

like we need 99% on su bench right like

the models are you know something we we

grow carefully we give it data and

feedback and compute um but ultimately

it's you know something that we it's a

little bit organic and we sort figure

out and learn with the model as we use

it. And so um that what that also means

is that what contains them is us, right?

The harness we put them in and the way

we prompt them is basically like a

function of our understanding of Claude,

right? And by unhobling it, I mean how

can we understand Claude better to

unleash it? And we need to understand

Fable more. So I think one of my points

is that you know uh we're still so early

and I think there's a lot more

understanding in Fable uh to unlock

and uh I think I'll give you a quick

example about how models get smarter

because it's a little bit unintuitive

right like there I saw this viral tweet

a couple weeks ago being like you know

why can't LLM say which Pokemon end in

aw there are a thousand Pokemon right

and turns out there are two who whose

names end in AW crocodile and dreadnot,

right? And it turns out if you ask like

a normal chat model, it can't answer it,

which is kind of confusing because like

you know it definitely knows all the

names of the Pokemon, right? But if you

uh ask cloud code, it can, right?

Because what it does is that it fetches

every Pokemon and writes a script to

filter for AW, right? And so this is

what I mean by like unhobling claude. We

call this capability overhang, right?

Cloud gets smarter in spiky ways. So it

doesn't just remember every Pokemon and

reason through it, but if you give it

the code execution tool, it can find the

two Pokemons that end with AW, right?

And so this is I think part of the

challenge with Fable is figuring out

this capability overhang. What is now

possible? And I think this is like a

discovery that I'm excited to go on with

you. Uh to make this a little bit

clearer, I'm going to talk about a few

different examples of how models have

progressed in the past. Um one of the

big examples obviously is like chat. You

know the chat models were had to be

given context, right? Like maybe you

paste in your codebase and maybe naively

you might have thought like you know the

way we solve coding is by the context

just gets really large and I can just

paste in my entire codebase. You know

it'll be a 100 million context window.

But it turns out that instead if you

give it arms like you give it the bash

tool and ways to work with the

environment it can build and search its

own context and that's sort of like the

insight that led to cloud code right and

so again spiky like a new like

innovation kind of right in how we think

about and work with the model and then

recently we've rolled out cloud tag uh

and what's sort of unlocked cloud tag is

its ability to work proactively and

multiplayer uh cloud code, you know, is

something that you have to prompt for it

to do work, right? And uh this ability

for cloud to wake itself up and do work

is something that we think is unlocking

the new wave of agents. But there's

there's more here. So for example, uh we

recently removed 80% of the system

prompt for cloud code, right? And this

is one of the ways in which models, you

know, and what they need uh changes over

time. So originally like you know maybe

back in Son of 3.5 new the best

practices for a system prompt was a

small system prompt few tools and lots

of examples right and then as the models

get smarter you can give them more

information and more instructions and

they start following them and so it's a

larger system prompt with lots of

examples and many tools right but most

recently we found this new class of

models want fewer want a smaller system

prompt the examples tend to constrain it

because it's actually more imaginative

than the examples we give it. And so uh

and we tried to give it con context and

not just constraints. We really try and

avoid being like do not do this. Um

which is really necessary for the

previous models. Um and so this is like

a way that the system prompt is changing

and and probably will continue to

change. Uh another feature I really like

is the ask user question tool. This is

something I worked on when I first got

to cloud code and and it's uh when

claude, you know, a is is planning or

wants to ask you a question, it can show

you a multiple choice dialogue. Uh for

Opus 4, it could barely call it. I had

to like really tweak the tool to make

sure that it was uh that it would work,

right? And then sometime opus 4.5, I was

like, well, what if I asked it to like,

you know, ask me 40 questions about the

spec, it can start interviewing me,

right? And so its ability to ask

questions jumped, right? And then most

recently with Opus 4.8 and Fable, I can

now build a whole HTML report with the

questions embedded inside of them. And

uh it's just like a whole new way of

interacting with uh with Claude, right?

And and so this progression of like how

Claude can get information from you is

also changed. Um speaking of which, uh

markdown and HTML is something I've also

talked a lot about. um you know it

turned initially markdown was a a good

output for the model um you know it

could show a little bit of rich

information and then you know with plan

mode it started to be for you like you

could understand what cloud was about to

do um and now you know claude can build

you these in-depth HTML reports right

and so again a way of this the models

getting smarter in a spiky way I really

like to emphasize that this is closer to

a biology than a physics, right? It's

still very empirical, very organic. Um,

we don't know all the rules, but there

is some sort of science behind it,

right? Like there is an intuition to

build as well. And so I really, you

know, encourage you to treat Fable like

that. Uh, one of my favorite papers uh

that at Enthropic that we've written is

on the biology of a large language

model. Um, all of our research papers

are meant to be read by, you know,

people with various degrees of technical

expertise, but this is one of my

favorites. So, uh, if you're looking to

learn a little bit more, suggest you

check it out.

But, so, uh, yeah, we talked about

unhobling Claude, but it turns out when

you're working with Fable, you also need

to unhobble yourself, right? And so, one

of the things that I think a lot about

is that the map is not the territory,

right? When I'm working on a coding

problem, the plan and prompt and spec

that I have in my mind is the map,

right? But the territory is the actual

codebase, the real world, the

constraints that Claude needs to

navigate, right? And whenever Claude

runs into something in the territory

that's not in the map, I call that an

unknown, right? Claude has to figure out

what to do about it. It's a decision

point that I haven't specified. And

Fable is one of the first models where I

felt that like I really have to figure

out my unknowns because if not it's

going to traverse such a large area that

like it's going to run into a lot of

them. So how do you figure out your

unknowns? Um

it I fable bottleneck my abil by my

ability to match the map and the

territory to find my unknowns. So a few

um few ways to think about this. I like

to think of it in a a matrix. So like

for any problem, I have a bunch of known

knowns. This is usually like what I

write in my prompt. What do I want?

Right? Then I have known unknowns.

Things that like I know I haven't don't

really know yet, but I just haven't

figured out yet. I can um uh yeah, then

I've got unknown known. Like what's so

obvious that I just wouldn't write it

down, you know, but I I know it when I

see it, right? And then finally,

unknowns. Unknowns. What haven't I

considered at all? What do I not know?

right? Like what is something that if I

knew could change how I prompt Claude?

And and luckily you can use Claude, you

can use Fable to find your unknowns. So

I'm going to go over a few examples of

how I do that with Fable. Um the first

is I like to do what I call a blind spot

pass. So I like to say something like,

"Hey, I'm working on a new O provider

that I know nothing about uh like in

this codebase. Can you do a blind spot

pass to help me figure out my relevant

unknown unknowns and help me prompt

better? Right? And so this like might

have Claude go through the the O module

and figure out like, oh, you know, this

is kind of like a hairy little uh dead

end that comes up a lot. Maybe searches

my git diff or slack. I might tell it

where there's context, right? So that I

can learn about, you know, all the

gotchas. And and you can use this very

broadly, right? You can use it to teach

you about new fields. I I recently did

this for color grading when doing video

editing. Um because I think this is

really powerful and and Fable is

incredible at it. Um in many ways the

model knows more about you know almost

everything than I do. I just need to get

it out of it. Um then I like to use

brainstorms and prototypes. Uh this

helps me figure out my unknown known

right things like especially for design

for me it's like know it when you see

it, right? So, I might ask it to uh

create a dashboard. Um, and I tell it I

have no visual taste. Uh, make me an

HTML page with four wildly different

design decisions so I can react to them,

right? And and you know, you tweak this

as you want, but like the idea is to

sort of get an idea of like what are the

things that you uh you know, you can't

describe in words, right? And uh like

work with the model to help figure that

out.

Uh then f then interviews. So once I

have an idea of like, you know, this is

what I want to do. Uh there's probably

still a lot of like uh unknowns here,

right? Where I might not have considered

something. I might not have specified

it. And so I'll ask Clog to interview

me, right? And I'll give it a little bit

more context in any of these questions.

Like giving it a little bit more context

about you and the work and the stage

you're at, like, hey, yeah, prioritize

questions that would change the

architecture is extremely helpful.

Uh then references. One of the best ways

to give Claude a map is to give it

another map, right? So instead of me

writing out the spec, uh I can just say,

"Hey, here's some code that represents

what I want to be done, right? It could

be in a different uh system or language.

Uh but just read this code, understand

it, and then use that to start your

work, right? And uh again, this can be

in a lot of different ways. If I'm

making a a React component, I might have

an HTML mockup that is my map, right,

that I pass in as a reference. I think

this is really really powerful and Fable

is really incredible at it. Uh something

else I've like really appreciated is

implementation notes. So if uh while

you're running Fable uh and it runs into

an unknown, ask it to log it, right? So

that um you uh you can see where the

deviations happened and then you can

sort of figure out why as well. you

know, we'll usually give you some

context about what happened.

And then finally, I like to get a fable

to quiz me about what happened. Uh, just

to make sure I understand what I'm doing

and I can represent this work, you know,

when I'm creating a PR or merging it.

Um, this is a really great way of like

making sure that you're like really in

the loop with Fable. And I think that's

like one of the most important parts of

Fable is like staying in the loop and

making sure that you uh you get what you

want. So

um those are some of my tips for working

with Fable. Uh I also want to say that

the first time I used a mythosclass

model uh used Fable I felt both a huge

sense of like gain but also a sense of

loss and I I wanted to talk a little bit

about that you know um when I think

about coding before LLMs it feels like a

foreign country you know like I used to

run a YC startup about 30 people and we

were just constantly forced into

trade-offs because of how hard code

right? Like we could make the the app

fast or we could try prototyping a new

feature and and this might take a month

or this would take two months and so we

had to choose and it was just really

really hard. Um and now I went back to

that codebase a couple weeks ago and I

thought about some of the things that I

wanted to do and uh it was just way

easier. It was like the things that

would have taken me weeks I could do in

hours, you know? And uh at some point

it's like yeah like how can you not

laugh but also how can you not cry

honestly like it's like one of these

things where um I really really loved

programming and writing code by hand. I

love the feeling of like seeing the

codebase in my mind and like rotating it

but I also remember just you know like

staying up late nights trying to debug

working on things for weeks without

working right. I just remember swimming

in failure. I just remember that like

the most of the projects I've ever

worked on have failed. Most startups go

bankrupt. You know, I think just overall

programming and coding is extremely hard

and like as much as I enjoy those highs,

I I can cannot go back, right? And uh

the way my reflection here is like the

only way out is through, right? There's

still a lot to learn with the coding.

There's a lot to learn with Fable. Uh

but I think if we try really hard and if

we like stay in the loop, we unhobble

it, uh we can get there, you know, and

we can come out on the other side, uh

with just um so much more. And so the

last bit I wanted to talk about is is

the so much more part, right? I call

this being unreasonable.

Um one of my favorite parts of anthropic

is that we believe that trade-offs are

not real. Um, like I think that very

often I like in my previous company I

was very used to being reasonable. So

I'd like write down this list of

priorities and I'd be like, "Well, I

guess we can prioritize this against

this, right?" Um, and uh, like, you

know, that makes sense. So we'll we this

will be our priority this quarter, but

what if you uh just did all of it? You

know, what if you forced reality to show

you the trade-off, right? Um, this is

something I've really valued at our

culture and anthropic. And my reflection

going forward is that I'm going to be a

lot less reasonable. Um, I think one of

this like the math of Claude and Fable

really changes how you think about

trade-offs. And there are so many

trade-offs that you make implicitly in

your head, right? Like good, fast,

cheap. Now it's pick three, right? Um, I

think that like the best way to like do

more ambitious work is to uh like

reframe and make big make ourselves more

ambitious because I think the only way

to prove that agents work is to do the

best work of our lives faster than ever

before. Um, you know, for example, I

made this deck last night in about four

hours with Fable. I feel like it's a

it's a deck I really like and I I really

enjoyed it, but I also um you know did

it really fast. Uh and I think that if

you're here, you know, at AI engineer,

the world is kind of looking at you to

prove that AI works, right? That it's

not just like a fad or something, but

that it can make us more productive and

also save us time. And and that's my

resolution for this year is to work, be

more productive, but work less and spend

more time with people I really care

about.

Uh, I think it's also worth calling out

that building is easier, but generating

value is still hard. And I think this is

something that we run into, you know, as

AI engineers sometimes where we think so

much about the process of building and

our our setups. Um, but the the point is

to generate value, right? And uh there

it takes a lot of swings. It takes a lot

of tries to find the valuable stuff. Uh,

but that really is the goal. And that's

like you know again what the world is

looking to us to prove that AI can

really transform it. So to to end I just

wanted to say like go explore make it

real and uh yeah be less reasonable.

Thank you.

Please join me in welcoming the chief

executive officer at Sonar, Tariq

Shakat.

Morning everyone.

Do you enjoy that last talk? That was

amazing. Um, you particularly love the

end, the being unreasonable part. I

thought that was awesome. Um, I also

want to just I'm trying to calculate the

odds of Tar following Tar as the first

two sessions in the morning. Uh, I think

the odds are pretty low on this one, but

uh, thrilled to be here today. Um, as as

we just mentioned, I am with Sonar. We

are in the code verification space and

I'm here today to talk about

verification. And I think we're all here

uh in large part because we believe to

some extent that AGI is here. It's

coming. The models we just heard about

Fable, it's really incredible what is

going on in the in the world today. And

yet we work almost exclusively with

enterprises around the world. And the

conversation that we have more is the

question mark version. Is AGI here? And

why are they asking these questions?

It's because you can read the news every

day. And I'm not trying to name and

shame here, but if you look at KPMG

putting out reports that they have to uh

uh retract because of hallucinations, uh

EY doing the same thing, law firms

getting into lots and lots of trouble

because of madeup citations, madeup case

law, things like this. I think we can

really start to question how do we get

value out of AI? The models are amazing

as we just heard, but the hard part as

the other target just said is getting

value out of it.

The struggle is that AI slop is

everywhere. I'm sure you all see this

inside of your organizations. I'm sure

you see this in your everyday life that

AI is amazing. The models are incredible

at generating very plausible output.

They're incredible at generating things

that sound correct, but are they

correct? And how do you know that

they're correct is a big problem. And

it's a big problem in professional

services as we saw. It's a big problem

in legal. But really, I think if we're

honest, it's it's a big problem in every

sector, in every field, whether it's

marketing or finance or you name it. You

have this question of how do you

actually know if it's true? How do you

know if it's good or if it is slob? And

the question that we we deal in the

coding space in particular, we deal with

software development. And the question

we get as we talk to I'm sure many of

the people here in the room and a lot of

our customers is, isn't software

development different?

And we can look at the data on this and

uh the mythos models. Um this is data

from um meter. Uh you may have seen this

MER um the coding agents are getting

better uh very quickly. They're getting

a lot better very quickly. And you can

see uh the progression the exponential

curve here. What this shows on this

chart is how capable are the models at

completing tasks that humans would take.

So can they complete a task that takes 1

hour, 2 hours, whatever it is. is the

latest Mythos model at least per the

benchmarking which was done a month or

so ago in the preview mode was you're

getting to 16 to 18 hours. So they're

actually able the agents are able to

complete longunning tasks and it really

is starting to transform how work is

happening. But the critical caveat when

you read the data is this is at a 50%

success rate. Okay. So it is again able

to complete tasks but is it able to

complete tasks correctly is the

question. So if you start looking at

let's dial up the accuracy rate you dial

it up to 80%. And there's still progress

but it is much slower progress. Instead

of 18 hours you're at about 3 and a half

hours or something along these lines.

And by the way this is still at 80%

accuracy. And as I was presenting this

to the CTO of one of my uh large

customers, his response was, "Betaric, I

would still put someone who gave me 80%

accurate information on a performance

review probably, right? This isn't

necessarily enterprisegrade.

The problem is that the models

themselves, and full disclosure, we have

not yet uh done this benchmarking on the

Fable models obviously because they are

just being released. But as you look at

the models, the models are getting

smarter, but they still produce a lot of

problem problematic code. This is

benchmarking that we do. We give the

models a series of over 4,000 problems

and we basically ask it to generate the

response to the problems and then we

analyze both the functional correctness

which is critical and they all do

extremely well on this notion of

functional correctness, right? Um, but

then we look at how complex is the code,

how buggy is the code, how secure is the

code. And what you see with even the

state-of-the-art models is that

complexity is still high. It's actually

quite variable as you can see here. Um,

GPT55 is done particularly well on the

complexity side of things. It still

generates bugs. It doesn't generate

massive amounts of bugs, but it still

generates bugs and it still generates

security issues. So this is the output

of the models that are going into the

agentic workflows. And again, this is

not, you know, I'm at the AI engineer

conference. This is not me saying AI is

fake or or um incorrect, but it is um

trying to address this question of how

do you really get value in a production

setting out of AI? This is a study that

was done in Carnegie Melon uh University

and it looked at what is the actual

productivity benefit that you see from

the use of AI coding agents. And what

you see I think really resonates with a

lot of what I see firsthand in the

market which is you have a initial just

amazing boost of productivity of

velocity in particular. what you see is

a three to 5x boost in productivity or

in in velocity. Um that dissipates in

three months. At the end of three

months, it starts to come back to the

the normal before you were using the

agents. And if you ask why, it is

because of the two pieces in red here

that you start to see there's an

increase in velocity, but there's an

increase in security issues. there's an

increase in maintainability issues.

There's an increase in reliability

issues and there's an increase in

complexity. So essentially you're

building the technical debt as quickly

as you are generating the code or maybe

even more quickly and that creates a

different set of work. it creates a

different bottleneck. And so to us, this

is now the critical question in AI,

which is in a world in which code is

provable. And there's sessions that um

uh I'm actually very much looking

forward to attending about formal

methods and proofs and things like this.

Code is provable, but when you start

dealing with large code bases, software

is not. It's still very complex. It is

still very messy. there's lots of um

dependencies. There's lots of uh

technical debt already in most code

bases. And so this question of

verification is actually key. And what

I'm going to be arguing is that you can

treat verification as an afterthought or

you can bake verification into the

process. And if you bake it into the

process of generating code, of doing

software development, you can actually

start to get materially better outcomes

from the coding agents than if you view

it as an afterthought, if you view it as

just the old school code review.

So as we've been thinking through this,

we basically have constructed a

framework and there's lots of competing

frameworks around this, but I'll just

talk you through uh ours. We call it the

agent centric development cycle. for

shortand we call it AC/DC sometimes and

the idea here is how do you get

verification powered to Gentic loops at

the center's a lot of focus on the code

generation piece like how do you

actually get the models and the agents

to generate the code that you need to

solve the problem and what we argue is

that you should surround this with the

right disciplines the right tools the

right processes to do three things to

guide the agents and tar is talking a

lot about different aspects of this

actually. Guide the agents, verify the

outcomes and then solve the problems.

And you have to make this part of the

discipline, part of the process, part of

the new software development life cycle

if you want to be successful in the AI

world. So if I double click on some of

these pieces, what do we mean by guide?

We've done a lot of experimenting around

guide. We've just launched a product um

yesterday I think called sonar vortex

that starts to get into this area. What

we find is critically important is to

think about guide as context and

constraints and we separate out context

and constraints very deliberately

because context is you have your code

repositories. How do we make it easier

for the agents to understand for the

models to understand what is in your

codebase? If you have a million lines of

code, if you have a hundred million

lines of code, you have a billion lines

of code, the agents work better if they

understand your codebase. So, how do you

give it architectural awareness? How do

you provide uh semantic navigation uh

maps um and uh and help them understand

the territory to borrow what Tar was

just talking about and we find it

equally valuable and I don't think this

part is talked enough about to provide

the constraints as well. You have

guidelines that you want your code to

follow. You have dependencies you are

okay using. You have dependencies that

you are not okay having. You have coding

standards. You have guardrails. You have

intended architecture. We spend a lot of

time talking about existing

architecture. But what about where you

want to go? And so this idea of context

and constraints uh we've found in our

testing generates a massive improvement

in agent effectiveness and a massive uh

improvement in token consumption. O over

30% reduction in tokens being used to

solve a given problem. And and if you

ask why, it's because you're actually

making the life of the agent easier.

You're helping it navigate better.

So then we get into the heart of this

and we really think of guide as

preemptive verification. How do you make

sure there's less to verify, less to

fix, this sort of thing. Then you get to

the heart of verification and what we

believe quite strongly and what we've

seen work in practice is this idea of

zero trust multi-layered verification.

Zero trust every model has biases. Every

model produces has a character has a

personality. So, let's make sure we use

different models and different

techniques to make sure your code is

safe, to make sure it's reliable, to

make sure it's secure. And multi-layered

really speaks to the earlier point that

software is complex. Software is very

messy. Software has lots of of of

intricacies involved with it. And so

what we believe and again have found to

be quite um impactful here is that a

combination of algorithmic verification

looking at things like data flows,

control flows, known patterns, secrets,

these areas combined with what is now

possible with agentic verification

looking at intent, business logic, the

unknown unknowns. Actually again to

borrow from the last uh presentation the

fusion of these things the the

deliberate multi-layered fabric that you

put in place can actually you can see

the results of this in production. So as

we look at our partners and customers

who use a multi-layered verification

approach they are reporting AI derived

production outages being 44% less

frequent than the ones who do not. So

you can start seeing a material

improvement in reliability, in security

and in maintainability.

And then the last point I mentioned is

technical debt does explode. Right? As

you generate code, technical debt is

also generated. And again, this is not

stop doing it. This is be aware and

let's start controlling it. And so what

we um have seen be super effective is to

have an active process to have an active

discipline again around code maintenance

and thinking about how you do verified

code maintenance. Um I won't walk

through every step of this but a the

agents whether that is a set of

remediation agents whether it's a strong

discipline around verification does keep

your codebase clean

and a lot of people have asked me all

right but do agents care about clean

code human developers care about clean

code do agents care about clean code and

what we find again is they absolutely do

because the agents have to understand

the codebase if they're going to operate

on it so this is is a oneshot view. Um

we think this is something that

compounds. But if you just do the exact

same agentic tasks on a typical codebase

and then one that has been cleaned, you

see a material reduction in the amount

of tokens, reasoning, energy, etc.

needed for those cleaner uh code bases

versus the typical code bases. Right? If

you make the life of the of the agent

easier, if you maintain your codebase,

then you'll actually see compounding

effects.

Now the important thing in our mind is

to construct the system. And this is how

I started is saying, you know, I'm sure

all of us do code reviews, you may use

static analysis tools, you may use AI

code uh review tools, a whole range of

things. And we believe that you have to

put this in a system. And again, uh,

we're happy to in our booth downstairs

talk through what this looks like, but

we really believe that the construction

of the software development life cycle

in an AI world um, needs to embed this

notion of guide, verify, and solve

inside of it. And you need to do it in

three loops. And you need to think about

these three loops. There's the agentic

loop, which I think is the key buzzword

of the conference. Um now but how do you

provide the agents as it's generating

the code as it's doing the work with the

context and constraints

with the inloop verification so that the

agent is getting verification as it's

working and how do you fix problems

that's that's the blue loop here what we

what we talk about is the inner loop

verification piece there's a second

which is your continuous improvement

process and how do you really combine

the power of algorithmic and agentic to

generate your your pull request, review

the code and by the way the velocity of

this has to go up massively. So to

review the code using agents and to this

multi-layered verification and then you

have your evals and I think the opening

speaker talked about how eval may be the

buzzword of the um conference. You have

your evals and you have your quality

gates to check are you actually passing.

So you have your your code maintenance

loop, agentic loop, CI verification loop

and deliberate design of these loops

with verification at the center is a

compounding system. It's a system that

reinforces itself and it reinforces

itself in the positive and it reinforces

itself in the negative. And we've seen

customers who uh have kind of neglected

as they've rolled out AI coding tools,

they've neglected verification. they've

neglected this idea of code quality, of

code um maintenance, things like that,

and you get into a downward spiral

pretty quickly. This is what the

Carnegie Melon uh case study uh or study

actually shows is that you actually have

all the benefits start to dissipate or

you can get into this self-reinforcing

loop. And one of the tests we did with

one of the large banks who are using

some of the cutting edge the folks who

are all around here today um cutting

edge agentic coding tools they can get a

92% reduction in issues if you actually

take this guide verify solve approach

inside of those agentic loops. If again

this compounds it's not that each loop

is 92% better. it's that as you go

through solving the problem over minutes

and hours that you actually see a

compounding benefits.

So that is uh essentially how we see the

benefit here. The how we see the

controlled um value creating use of AI

in enterprise settings. And when I say

enterprises, people with existing code

bases, people with with you know

millions of lines of code already.

There's the agentic loop, there's a CI

verification loop, there's the code

maintenance loop. I am required by my

marketing team to put up a version of

this that has our products on here. So

these are our products and you can come

and see us later. But the most important

thing is really to say our

recommendation is this agent the ACDC

agentcentric development cycle. The core

part is deliberate verification built

into the system. So if you'd like to

learn more um we have a booth that's the

big red booth downstairs. We'd love to

talk more. We have some doubleclick

sessions coming up. So please do uh join

those and uh have a great conference.

Thank you all.

Joining us on stage is a member of

technical staff at Amazon AGI lab onjab.

Good morning. It's so great to be back

here at the AI Engineer Worlds Fair.

Just a year ago, the hard problem was

getting an agent to find a button and

click it on a screen, especially screens

it had never seen before.

Now agents can drive browsers and

they're starting to also drive desktop

apps.

But what we figured out click clicking

was actually the easy part.

What we didn't solve is the actual work.

And what do I mean with this? Let's take

a very simple example. A new team member

starts on Monday. And maybe your job is

to set up their accounts, add them to

your Slack channel,

book intros with colleagues,

order the laptops, etc.

And nobody really owns this end to end

process in the company and it might be

also touching five different systems.

Now, agents can most likely perform each

single individual individual step of

this workflow,

but agents still struggle to do this end

to end because the real work lives

within the seams of all of those

different applications, of all of those

different steps you have to take. And

this is mostly where it all falls apart.

The agent can use every single tool you

give it, but it still can't do the full

work.

So why do we see this gap?

Think about for a minute what we

actually built.

We taught computers to use computers.

So what do I mean with this? We started

building out the basics. We taught them

clicking, scrolling, typing, calling an

API, filling out a form, and we got

those steps, these steps really

reliable, and you can string them

together in a workflow. And agents these

days are fairly good at like operating

those workflows.

So, why can't you not just hand them

more of your work and then literally

just walk away and trust it to be

completed?

So all the things I talked about like

using a tool models itself,

tool use, stringing agents together,

this is all capabilities

and we mostly figured out how to add

capabilities to models.

Now the next hard part is really

reliability

and without reliability we cannot really

build up trust in those systems.

So here's a quick gut check and maybe

all of you can just think about an agent

doing work in an end to end workflow.

How often do you think that actually

succeeds these days? Maybe 60 maybe 80%

of the time.

And it sounds really fine, but if you

look into this,

if your agent

one in four times deletes a database,

you will never touch that agent again,

right?

So

when you need this reliability, you

really need to be it in the nines. You

need to have the trust that it actually

can do the work successfully.

Now, there's actually one place

where we made enormous progress on

reliability and trust and this is

coding, right? Think about how fast

coding evolved.

I still remember the first time when it

started autocompleting for you, right?

You just tapped autocomplete. Amazing.

Then short time later, it started to

write functions. And we thought that is

amazing.

And now look at these days. Coding

agents write the code. They open up the

pull requests themselves. And we had it

earlier this week. Code keeps flying by.

So once in a time we were able to just

every single line that it generated we

felt like the urge we need to really

read it and make sure it's correct right

I think most in the audience here can

still relate to that

these days I think hardly anyone is

still doing that like we cannot even do

that right code is generated at such a

pace

at the same time coding made that jump

so why is that because we were able to

bring it from just being capable the

coding agents to actually be reliable

and then trusted.

So why is that? Why was coding first

solved?

It's because code is verifiable.

You can run it, you can test it, you can

check it and you can be for sure that it

worked.

So reliability showed up in the first

place you can actually verify the

answer.

But here's the catch.

Most of the work we do if you look at

the broader knowledge work areas is not

like that.

Knowledge work is messy and heck the

whole real world is really messy.

Did the report I created land? Is the

design on brand?

Did it get it what I actually meant? So

there is no unit test that can answer

those questions.

So verification really hits the wall

right where most of our work lives.

It's living in the seams of all of those

applications we're using on a day-by-day

basis.

And nobody really has cracked this part

yet.

How do you make an agent reliable when

there's no way to verify the answer that

easily? And that's a field that is still

wide open.

So, how can we solve this?

Well, so how do humans handle messy

work? I mean, we're successful at it,

right? Each of us like every day we work

across different systems. We manage out

how to onboard a new colleague. We do

this.

Well, we're doing it by figuring things

out together. You grab a colleague, you

jump on a Zoom meeting, you're

discussing things, you're looking at the

problem to solve, you're discussing p

pointing at systems, and maybe two

minutes later, you solved it. You're

done. But none of this work is actually

directly verifiable.

And we do this all day.

So one of the things is we're looking

mostly at the same screen, right? If

you're jumping on a meeting with a

colleague, you see the same screen, both

of you, and you can actually like figure

out really quickly what needs to be

done.

So this is what the agent these days is

missing.

You don't necessarily need a bigger

brain. What you need is this shared

context. Because if we're looking the

agent and myself at the same screen, I

probably have much less explanating to

do.

So what kind of agent do we really need

to build to achieve this?

And today's agent, as I said, they can

already see a screen, right? and they

can click and take actions in it. That

part works.

But if they fire off actions, what they

usually do, they move on. They don't

watch what happens or recover if one

step didn't succeed or something goes

sideways.

And we need an agent that can actually

work like you do, like humans work.

And one example is robotics. If you just

look for a moment as how robotics do it,

a robot perceives what's around it and

it plans what to do and then acts. So

this loop here from perceiving to

planning to acting, this is actually

what we also would need on a screen.

And it starts here really with the first

word which is perceive.

The agent has to take in the screen the

way you do,

not scrape the code behind the page, but

what's actually rendered, the layout,

the state, what just changed the work,

what we're doing, and then do it.

And it would also have to keep up in

real time. Think about how we as humans

work together.

You jump in, you react to build on top

of what each other you say.

And today agents can still don't do it.

What we're doing is we're sending a

prompt, we're waiting, it goes away and

at one point the agent come back and we

might have to take a couple of turns,

right? Because what the agent come back

with is not exactly what we might want

to do. So we're sending another prompt

say, "Hey, go back, do this, do this

differently." And we have this long back

and forth which we got so used to from

our chatbot experience and from this

rhythm taking turns.

But what we actually would need, think

about it, is an agent that can react

while you're still working. Wouldn't

that be really cool, right? Like at the

same time you're working, it can also

come up with suggestions, can help you,

and there is no waiting time.

So basically an agent that perceives

what you perceive and understands what

you mean.

We call them perception agents.

So why perception agents? Why do they

matter? So first they complete the loop

on computer use.

Today's agents again they can act, they

can click, they can type, they can

scroll,

but what they can't do well is looking

at the results and whether it actually

worked out. A perception agent can read

the rendered screen so it can confirm

its own output instead of just firing

off those actions

and then hoping.

Second, it doesn't need an API or

backend process.

And that's important because it works

off the rendered interface. It sees the

same pixels and the structure you see.

And most of today's software people use

every day don't expose APIs at all.

And then third, the input also goes the

other way here. Instead of writing a

long paragraph to describe what you want

to change, let's say you're working on a

website and you want to describe all the

changes you want to apply. Instead of

writing this really long description,

wouldn't it be great if you can just

point to it and say, "Hey, here this

heading needs to change. Hey, can you

update this section?"

This is a much more precise signal and

less lossy than text.

and the agent can act exactly on what

you marked.

So this is where we started and I'm

happy to share that we just recently

launched the first two pieces of our

perception agent harness

open source.

There's two pieces. There is annotation

which you can use to tell it what you

want.

And then the second piece, the

verification part gives the agent the

capability to check its own work.

So let me show you the first one. So

here's a very quick demo on our

annotation tool.

This one is a Chrome extension, so it's

super easy to use. And I'm going to play

here this quick video demo.

So you have the extension installed and

then you can just select different

elements on a screen. So this example,

we're just drawing around the heading

there, marking the section. And maybe

you want to change it. Why not? Let's

change it to red.

You could also select the elements on

this page. You see how if I hover over

it, finds the right element. You click

it, you select it, and say something

maybe double the font size. And you see

also how the agent here captures on the

screen exactly the feedback, the

location, the style elements and it

creates this complete summary which you

can then use and then give your agent to

implement. So there is no back and forth

anymore because you captured exactly

what you saw on screen and the agent can

see the same thing.

Now let's have a very brief look at the

second one at verification.

So the idea of verification is that you

can describe let's stay in this case of

the web development. You can describe in

a design MD file what your design rules

are for this.

And then what happens if I play this

video here, the act the agent can

actually check its own work against

those design specs.

So it will take what you defined, the

colors, the components, your layout, and

it turns it into those rules if you

don't have it written before yet. And it

does two kinds of checks. Then it does a

visual check, which is really cool. So

everything is on brand, for example.

it's the right layout.

The other part is also checking user

flows. So what it does there, it

actually walks through this experience

through the app for example depending on

the tasks available. It might add a

task, it might delete a task like a real

user would. So it helps you walk through

those user flows as well in an automated

fashion. And then once it's done, it's

writing a report which you can review

and it's going to call out which tests

passed and it's going to tell you

anything that didn't.

So ultimately, you're the one that

doesn't have to click through this at

midnight at the end of the day because

great work. The agent already did this

job for you.

Now there might not always be a screen,

right? So I talked a lot right now. I

called it perception. I talked about the

agent sees what you see on a screen.

But there are times in your day where

you don't have a screen. Maybe you're in

the office. You're walking into a

meeting with a colleague.

So I did a fun experiment yesterday

at the conference here. So I grabbed my

colleague Giovanni who is also here and

actually on the second floor there's a

great like little meeting booth. We

found that by coincidence. So we went in

there and we had our design meeting. And

the goal here is really kind of show you

how perception is so much more than just

the visual part. So in this example,

what we want to show you is perception

can also be listening in the room to

what you're discussing.

And you can see here on the picture,

both of us are wearing our B devices.

Big shout out to B for sponsoring these.

Um, so we're sitting there. We have our

B devices that can do a transcript.

They're listening to what we're saying.

And then we have this design meeting.

And I had a couple of great ideas how to

change this website. Um, you will see

them in a in a second here. So let's

have a quick look how this changed the

same workflow on this website using this

device.

So we had the discussion the be did the

transcript and you can see here on the

right we're pulling this meeting

transcript right in there is a whole

detailed summary of the meeting.

There is

what we discussed and then it basically

captures those insights. We have them

right here and we can click apply. So

what this apply button does is it sends

it straight to the agent. And you can

see here my crazy ideas to turn the

background to yellow, turn the heading

to red, and also change an emoji

directly applied. And it also straight

kicks off the verification right away.

So it creates this report and and

luckily this color scheme was apparently

into in the approved rules otherwise

this would have looked like you did some

weird things here. But again you could

change those rules if you don't want to

have yellow backgrounds and it will make

sure um that we still adhere to those

guidelines. It would flag anything

that's off. So you have the judgment

call if you want to either update the

design specs because you actually like

yellow or you take an action and say no

um fix this violation.

But this is really the very first step.

These two pieces are the very first

beginning and we're building out the

rest in the open because these patterns

can only get better if more people are

using them, building on top of them,

breaking things. So my ask here to you

is go and try them out. They're on our

GitHub repos.

Tell us what we're missing. Give us the

feedback what you would like to see

where this should go next. because

ultimately none of us get smart alone

and that's the whole point. We want to

build AI that makes all of us smarter

together.

Now, if you're interested in a little

bit more on human agent interactions and

how we see those patterns changing, I

would highly recommend this podcast by

my colleague Danielle Persik. She is a

cognitive scientist and runs our AGI ACI

team at the lab and discusses a lot

about human computer interaction

patterns with experts in the industry.

You can find the podcast on on a popular

podcast platform.

We also have more sessions this week. Um

so check them out. We have a booth down

there. We have expert talks. We also

have another computer use track talk

coming up with my colleague Gav Mishra

at 1: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, Benois Schillings.

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 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 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 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 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 VIP coding. So even old dogs

can learn new tricks. So uh 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 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 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? U superhuman

syntax generation.

When is the last time I built 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 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 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 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 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 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

toad 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

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 a 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.

Ladies and gentlemen, as we continue

today's program, please welcome back

your MC developer advocate at IBM, Tea

Scamar.

What an incredible start to the day.

Woo! Everybody's leaving. This looks

amazing from here. Um

before we break off uh or after um let's

take a moment and acknowledge the

sponsors. Honestly, this would not be