Welcome everyone and thanks for joining
us for the Kaggle and Google 5 days AI
agents intensive course. I'm Smita
Kolli, senior developer relations
engineer at Google Cloud, and I'm
co-hosting this week with Anant Nabha
Garia. Anant, why don't you come on and
introduce yourself?
Thanks. Great to have you here, Smita,
and welcome everyone to your first live
stream for the fourth iteration of this
course.
I'm very excited to have you and guide
you through the rest of the week.
Thanks, Anant. Really glad we're doing
this with you, especially given how much
has changed in the way that developers
actually build software since the last
iteration of this course.
Quick ask before we get started. Drop in
the YouTube chat where you're joining
from. We're always really curious to see
the spread of everyone across all of
these different time zones.
And I already see it's quite a few
people joining from across the world, so
Awesome. Let's start off with a quick
overview of this week. So, throughout
the week you'll get white papers,
companion podcasts, which were honestly
one of the most popular formats last
time because they were they made the
most dense material easier to absorb.
You'll also get hands-on code labs,
daily live streams, and AMAs just like
this one, and an optional capstone
project at the end where you can compete
for Kaggle certificates, badges, swag,
and recognition across Kaggle and
Google's social channels. So, if you
have registered, the content will land
directly in your inbox. If not,
everything is on the Kaggle learner
portal, and it will be announced in this
part as well.
Also, before we move on,
quick thanks to the people who put
everything together, the Google
researchers, the engineers who wrote the
white papers, the speakers joining us
this week and today, and the Discord
moderators who have been answering
questions non-stop. The mods have been a
great resource during this week.
And the awesome Kaggle team as well.
[laughter]
Yeah.
Definitely.
Uh let's actually get into day one
topics, right? So, the reason this
course exists and the reason we're
running the fourth iteration of it is
that the way software gets built has
fundamental fundamentally shifted. So,
as of, you know, early 2026, 85% of
professional developers regularly use AI
coding agents. And roughly 41% of all of
the new code is actually AI generated.
So, that's just not That's not just a
future trend. That's actually the
current baseline, right? So,
the gap between prompting a model and
building something that you can actually
deploy to production is where most teams
are actually stuck right now, and that's
what we're going to be working through
this week. So, here's how we This entire
week is structured. Day one, today,
we're going to be covering introductions
to agents and vibe coding. So, we'll
cover the shift from writing syntax to
expressing intent, the spectrum from
casual vibe coding to disciplined
agentic engineering. And then you also
get to vibe code your very first app
using antigravity and AI studio.
Anant, why don't you walk us through the
white paper?
Thanks, Mitha. So, everyone, hope you
had a chance to uh go through the white
paper uh for SDLC with vibe coding and
how it changed. In today's white paper,
you would have looked at how we are at
the most profound shift in computing
history, transitioning from translating
syntax to expressing intent via natural
language. We also explored the spectrum
of development from casual vibe coding,
quote unquote, where you prompt that
prompt an AI and copy-paste errors back
to iterate, all the way to disciplined
agenting engineering, as I like to call
it, where AI operates within structured,
deterministic boundaries. We also broke
down context engineering, which is the
real skill of modern engineering. You
will you also learn the difference
between expensive static context, like
system instructions,
uh versus cost-efficient dynamic
contracts uh contexts, like agent
skills, loaded on demand. More on that
in day three, uh a day three is all
about agentic skills.
Uh so, this shift fundamentally alters
the software develop- development life
cycle as we knew it. In this new SDLC,
the implementation phase collapses from
weeks to potentially minutes, making
requirements specification and
verification the new human bottlenecks.
Now, uh later on in the white paper, we
look at the factory model of for
software development, and as developers,
our output is no longer just raw code.
It is the system that produces that
code. We also introduced a critical
formula for the system, which is agent
is equal to model plus harness, where um
the model alone plays only around 10% of
the equation, and another close to 90%
is the harness, which contains the
sandboxes, the tools, the orchestration,
and the guardrails that makes the whole
agentic coding system reliable. Finally,
we discussed the developers' changing
role, and we looked at how developers um
uh find themselves moving between
conductor mode, directing real-time
edits in the IDE, and the orchestration
mode, which is uh involves them
asynchronously delegating complex tasks
to autonomous agent networks and swarms.
We uh we also have some great code labs
and a lot of uh
exciting materials for the rest of the
week. Uh Fran will be covering the code
lab later, but after you Smitha for our
guest QA. Woo.
Awesome. Uh thanks Anand. And also a
quick tip for everyone, if you haven't
already, listen to the podcast first and
then read the white paper. The podcast
does a good job of framing the why
before you hit the technical detail and
then the concepts actually stick better
in that order.
All right, let's head on into the QA.
Uh let me bring up all of our expert
speakers we have today. So, we have
Jamie from Cloud AI, we have Logan from
DeepMind.
We have
Partha Sarathi from Cloud AI and we have
Shubham from Cloud AI.
So,
these are the folks shaping how this
stuff actually ships at Google. So, the
answers you're going to get are grounded
in what's being built right now and
thank you all for making the time for
this. Anand, kick us off with the first
few questions.
Thank you. Excited to have you all here.
So, our first question would be
Uh this question is for you, Logan. So,
as development shifts to asynchronous
orchestration, how do you see computer
science education and hiring standards
evolve to prioritize high-level
architecture judgment using coded coding
tools over syntactic coding mastery?
Since um quite a few of our um
participants are developers in the early
stage of their careers or even some
students, they would love to hear about
this.
Yeah, it's a really interesting
question. I think I mean there's a a
huge amount of discourse happening right
now about sort of like how computer
science education is is going to change.
I think the thing that gets me the thing
that makes me very optimistic despite
like what I assume is going to be like a
very
um reasonable amount of change of like
how those programs are taught and things
like that is that
computer science education has always
been about how to think not how to like
type keys into a keyboard. And I think
like historically you sort of had I
think about like as I reflect on my own
computer science education there was
sort of like two tracks. It was like you
know, all the you know, architectural
decisions, the sort of like logic, how
algorithms work etc. And then you
separately had the like applied version
of that which is like what is the Python
syntax that I need to know in order to
like actively do something useful.
It's interesting actually that you would
like
intersperse between the two things. In a
lot of cases you would learn algorithms
and then you would try to apply them.
And I think there's obviously the
applied form of this is going to
continue to be super useful because
as as sort of like a way to express your
thought and sort of the analogy to this
is like we've obviously had calculators
for a very long time and yet I think
it's sort of universally or at least
mostly universally agreed upon that like
learning how to do math is still
important to do because it sort of
forces you to express the mathematical
ideas in practice.
And so I think as we as we turn this
corner where like now code can be
written in large quantity by you know,
AI systems and you sort of don't need to
do that yourself.
The thing that I'm excited to see the
change around is like actually people
coming out of the educational
institutions and infrastructure with
not just like
you know, college degree or some sort of
like proof that they know something but
actually like an entire system or a an
entire business that they built during
that process.
And I think there's like a really
interesting
again like more
um
more akin to sort of like a trade craft
that I think people are going to like
you know, when you do trade craft
apps that have
and you're going like to do something to
feed all this work
in actual practice. I think seeing that
for computer science I think would be
really interesting where like you come
out, you have a business, you have proof
of work, you can like validate for
agency and all that. So, I'm excited to
see and obviously like all the technical
detail still matters a lot.
Um sounds very exciting. Logan, so
how do you think uh from an AI studio
perspective, what tools do you think
that are there a couple of tools or
technology you think
that you would recommend to the
uh audience here?
Yeah, I mean this is the direction we're
going. Like we're very much trying to
like not only ride this wave but like
help make sure that students and people
who are trying to build these types of
businesses can make it happen. So, I
think we we've the I talked to the team
about this all the time. We've sort of
like we've done prompt to prototype
that's like pretty pretty reasonable.
We've done prompt to production like you
can you know, send one prompt, build or
many prompts and then build a fully
functional website and deploy it and
share it with the world.
Um and it's like very obvious that the
next step is
we say like prompt to profitable company
cuz it's not just about like building a
a company, it's actually about like how
you get people to actually use it and
and find product market fit and get your
first users and do that sort of so the
total integration of the experience. Um
and so we're working on lots of stuff in
order to make that possible. Um and
actually like let everyone in the world
have a business. I think all these the
the optimistic version of this is it's
very similar to what YouTube did with
creators. Like prior to YouTube you like
couldn't do it's really difficult. to
like go convince a TV network somewhere
or a radio network to like
tell your story and it was like the the
means of storytelling was controlled by
a few. Um and then YouTube came and
everyone could tell their story. Um and
I think software is going to be that
same exact thing. You used to have to
hire many, many developers and you know,
have a big business and raise money and
do all this stuff and I think now
everyone's going to be able to to build
software business, which is really
exciting.
Amazing. Thanks a lot, Logan. That was
uh and hopefully everybody uh listening
to that cuz we have a lot of cool stuff
coming.
Amazing. Uh
on to our next question.
Uh
So, talking about um building businesses
from prompts,
uh Anantha, Anantha, this question
question is for you. Um
given the recent advancement in
self-evolving AI for coding, how do you
see uh the exciting advancements by
DeepMind brought into Cloud uh by
technologies like Alpha Evolve? Uh how
do you see it helping technological
breakthroughs across the industry?
Yeah, uh thank you for the question,
Anantha.
Um Alpha Evolve, for those of you who
haven't heard about that before, is a
uh
evolutionary algorithmic agent and uh
what Alpha Evolve does is uh it
uh uh
uh Gemini or any large language models
and it uses an evaluator function and it
identifies optimized algorithms for any
use case. And
uh initially when Alpha Evolve was
introduced a year back, we showed how
Alpha Evolve could solve decades-long
math problems. Things like matrix
multiply, which were been optimized and
Alpha Evolve was able to come up with
new optimizations. We've shown how Alpha
Evolve can be used in
a whole bunch of different uh use cases
within Google as well. Uh for example,
how we build large-scale schedulers,
how we even use it to design new
hardware and so on.
Uh and what is very interesting about
these kind of self-evolving uh uh agents
is when you're starting to use uh
agentic wipe coding or agentic
engineering as Anant called it, these
become a tool in your arsenal to start
optimizing the algorithm. So, you don't
need to really think about how do I get
to better performance? You can use this
as an additional skill that you can then
optimize. And in the last year, I've
just been blown away by how we have used
Alpha Evolve across a spectrum of use
cases. We've used it in science
things like DNA sequencing or molecular
simulations.
We have used it in in cloud. And again,
cloud we've used it in financial,
retail, a whole bunch of different use
cases. And we've also used it in
infrastructure. I have personally used
Alpha Evolve in some work I've been
doing around
optimizing new computer architectures.
And so the opportunities really are
incredibly profound. And so think of
this as you have an expert optimizing
agent at your fingertips as you go
through your live coding journey.
On that super exciting how um
everything from everything can be done
just by the means of prompting. So you
write your initial code with prompting
as Logan mentioned prototypes, even even
production ready some some of the
systems. You put that in production to
cloud and you can optimize it for
technological breakthroughs and take it
a level higher with another system like
Alpha Evolve.
It's exciting times to be living in. All
right, to our third question.
Uh Smitha, yes.
So this question is towards you Jamie
and Shubham. What architectural patterns
and cloud products are proving most
successful in helping autonomous agents
uh cleanly cut across the final context
heavy 20% milestone of a complex task
with ideally minimal human intervention.
I can start.
Okay, go ahead Shubham.
I I would just take a step back here and
go back to the first question that you
asked Logan and just want to point out
that we are living in a very exciting
world where engineering power is pretty
much abundant and unlimited. Everyone
has that at their fingertips. You just
go in and fire up AI Studio, fire up an
agent, go and use Gemini. You have all
of that at your hand at your fingertips.
Uh
the things that are becoming really,
really important is understanding your
core problem, being able to communicate
that to an LLM, to an AI agent, and be
able to verify the output that it
generates.
Now, mapping that mapping those skills
to the scaffold, build observe scaffold,
build, observe, and optimize loop for
agents
is what really helps you go from
80% white coded part to 100% that 20%
missing part Anand that you're talking
about. And the good thing about it is we
have actually mapped those that journey
here at Google for you.
Uh and the day one white paper and the
entire five-day course really owns in on
that. So, you start with building an
agent in ADK, you can go and evaluate it
on agent platform, deploy it on agent
platform, you can have the traces coming
out, and that gets optimized. So, what
you're essentially building is the
entire loop. And on top of that, when
context becomes heavy, you have this
concept of agent skills which helps you
dynamically inject context when the
agent needs it and not have it load the
context. So, that entire loop plus agent
skills uh
is what really helps you get to the
100% uh
part
to cross that 20% gaps to make your
agents work reliably in production.
Yeah, I think that's great. I think this
is a great question. I think
uh
you know, that last mile is really where
it's often the biggest challenge. Uh and
for we're from prompt to prototype to
prompt to production deployment of
of a website that you're sharing to like
actually using something to run a
business on,
uh, that last mile of quality and
um, uh, ability to do the task really
consistently, handle error cases, is is
often the the biggest challenge.
And so, I think
having a full tool set to help you
evaluate, have verification tests, have
long-term memory across sessions, have
the ability to optimize in production
and learn automatically to improve the
quality over time, um, a lot of that is
what becomes necessary to really close
that last mile. I think
a couple things I would add to that, you
know, part of this is around
architectural patterns and what's been
successful recently. And I think two
things I would call out are, uh, you
know, first, using agents to to write
code. And so, instead of just an agent
being something that is a set of LLM
calls with a custom prompt and some
context and maybe some tools available,
moving to something where you're giving
the agent a sandbox environment to write
code, create its own tools on the fly,
um, create sub agents, um, which
evaluate the work of of the agent and
evaluate the code that's being written.
Um, I think that that pattern's showing
much more success than than just having
an agent be a set of LLM calls with
custom context. Um, the second piece in
there I think is is really around the
verification loops. Both automated
verification loops, so having a sub
agent that evaluates the work and and
iterates,
uh, but also having a human in the loop
step. So, set of conditions that flag
for human in the loop verification or
review,
um, and then creating a data set from
that verification that can allow
self-improvement over time.
Uh those are some of the things that I
think we're seeing a lot of success with
to kind of close that last mile.
I think evaluation and curation of
golden data sets from that human loop in
loop is definitely something which we uh
we need to focus a lot on as well.
Thanks a lot, Shubham and Jamie for for
your view on this. And Smitha, let's go
on to the community questions.
Uh thanks, Shubham. Really uh sorry,
thanks, Anand. Really great signal in
all of these answers. I also want to add
on to what Shubham was talking about on
agent skills. So, day three we'll be
covering agent skills, and we have an
entire white paper which is coming out
on agent skills. I'll also be leaving a
link in the description box to Google's
skills repository as well.
Let's actually move on to the community
questions now. Uh so, the first one we
have from Deblina Kar. Uh and this is
directed at you, Jamie. So, what are the
primary long-term risks and potential
failure modes of using an AI-driven
software development life cycle as
opposed to its widely discussed benefits
like, you know, cost reduction and
increased productivity?
Yeah, great question.
I think I think first I'd say I'm
incredibly optimistic here. I think that
um
you know, our ability to adapt as uh
humans in general, but also as, you
know, technical innovators is is really
high. And so,
uh I think that how we do that is by
thinking about the risks and, you know,
planning for them and auditing them as
we go.
Uh but but I am very optimistic. I think
some of the biggest risks of, you know,
moving to an AI-driven SDLC, I think,
are first
the erosion of the human expertise,
specifically with that code base. So, I
I think we should assume the AI is going
to be very successful at writing code,
at evaluating it,
testing it over time,
um responding to issues and fixing them.
And assuming a successful path with
that, what will happen to the developer
or architect's expertise with the code
base? You know, more and more of the
code base will be written and managed by
the AI. And so, we'll have this sort of
erosion of that human expertise with the
code base.
As that happens, um
how much ability does that human have to
actually properly orchestrate and direct
the AI,
um and ensure that, you know,
things are architected well for where we
want to be going in the future, drive
the improvements that are needed,
you know, resolve issues when they come
up, et cetera.
Uh I think that sort of leads into the
second big risk, which is really around
the accountability that happens when
there are issues. You know, if if we
become less expert with the code base,
the AI really is successfully
driving the the code base and resolving
a lot of the issues,
how do we manage accountability when
issues come up, you know, between which
uh employee or
uh architect or engineer is is
responsible for for issues as they come
up? And then I think the third risk is,
you know, with both of those things
happening, there could be lost
opportunities for improvement. I think a
lot of the innovations that engineers
have really come from a depth of
understanding of what's happening in the
code base or in the product. And so, if
we're not careful, we may have um a a
lost opportunity for further
improvement. Obviously,
uh the AI will come up with some of its
own opportunities for that, um but I
think that the engineers ingenuity and
and opportunity to come up with those
maybe lost if we're not careful if we
drift too far our understanding of the
code base. And so I think
those are the risks.
If we if we're careful, we can plan for
those and come up with ways that we
ensure that we don't have that erosion
of expertise or or drift in
understanding over time.
Fantastic insight. Just one thing more
which I wanted to add
I want to Jamie. I also think if if we
lose that technical expertise over time,
the security gaps and risks that get
exposed as well, which we'll be covering
more in our day four, would also become
even more pronounced than they are as of
today.
Just that's that kind of is something we
should maintain good control of our
knowledge of our code base for.
Yeah, totally. Good insight. I agree.
Awesome. Okay, let's head on to the next
community question from Kristoff.
Can we combine the open knowledge format
with a localized graph rag architecture
to let agents map and iterate on full
system designs at a semantic graph level
before writing code? And I think
Shubham, you would be a great one to
answer this.
First of all, it's a great question.
So, we recently launched open knowledge
format which is based on Karpathy's neat
idea of LLM Wiki.
So, the beauty about it is how simple it
is. It's just a set of markdown files
that links links each link to each other
that you can have in in your system. And
each markdown file is representing a
thing. Could be a service, could be a
database, a contract, whatever. And the
nodes link to each other. That's it.
It's plain text that you can read and
the agents can read as well and can edit
it.
Uh now think of these uh
as index cards on a board uh with
strings connected to each other. These
are like markdown files that are
connected to each other representing
some entities. And you're asking the the
problem that you're essentially talking
about is uh can I combine it with Craft
Rack? So, agents can actually have the
map of the entire system or the whole
system, the entire repository before it
starts before it even starts writing a
single line of code. Which is a pretty
neat concept because uh what happens is
when you fire up an agent in a big code
base or a GitHub repository, it usually
jumps into straight writing the code
without really looking at the entire
context. Now, you have open knowledge uh
uh format. Combine that with Craft Rack.
Craft Rack uh what it does is follows
those strings between cards. So, it
actually understand how the connection
works.
It can answer if I change X, what gets
affected. So, if I change this specific
card, this markdown file, what gets
affected? And it can look at those
connections. So, I think uh it is
definitely possible to combine Craft
Rack with open knowledge format, which
could be a pretty neat concept to solve
the contextual problem for very, very
big uh code bases. And it could give the
agent right context not just about what
all exists, but also about the
connections between different files, the
connection among your code bases. This
is more or less like mimicking how an AI
architect or AI engineer would go about
uh writing code. It's not about just
changing one file. It is also an
understanding of if I change X, how that
would impact my entire code base. What
breaking changes would that introduce?
So, I feel this is a very interesting
concept that could be definitely
explored uh and would be like super
interesting.
Nice. So, it almost seems like this is
really a context engineering question.
Like, how do you give the agent a
structure representation of the system
that's, you know, denser than just kind
of dumping the whole repository into the
context window, it seems.
Yeah.
Awesome.
I love this. I think we have our first
road map request to to add here from the
week. This is great.
Great.
Uh okay, moving on
to the third community question from
Adam. Um so, this is directed towards
you, Logan. So, about the autonomous
agents, what are reasonable use cases
for long-running agents?
Yeah, it's a good question.
Um
I think maybe some of the historical
context for this is I think if you look
at like what was Google's first
successful long-running agent, it was
Deep Research. Um Deep Research, I think
it was the first thing that we sort of
released into a consumer product, and
then ultimately it's actually available
in the API as well, where you can
actually go off, do sort of an
autonomous research loop, uh come back,
create a bunch of artifacts, and provide
them to a user.
Um and so, I think we learned a bunch of
stuff about that. I think the second one
that's like more widely ubiquitous is
around AI coding, obviously. There's
something interesting about
both of those use cases, and I think why
they've actually worked well. I think in
the context of
um in the context of Deep Research,
you're often times the answer to the
question is not like a is not like a
finite thing. It's like in some cases it
is, where you're traversing the internet
and you're sort of trying to collate
like a very specific answer. Often times
there's like all of this like
uh scaffolding, contextual scaffolding
that you need for the answer to be
relevant and make sense. In the context
of autonomous coding agents, which I
think are the most maybe from a a token
consumption these days, like probably
obviously the most predominant
long-running agent,
Um the thing that the the reason that
those systems can work so well is
because they're actually like
continually testing and being verified.
Um and this is the balance of of
long-running agents today is you don't
want the agent to go off and do a bunch
of work and basically waste your money
and time and then ultimately it didn't
do something productive. Um and so in
the case of of coding agents, you can
sort of like continually run the code
and make sure that the the incremental
additions that are happening aren't
breaking a bunch of stuff or sending you
down the wrong path. In some cases that
does happen still and so the models get
better over time. Um and then again in
the case of deep research sort of it's
uh there's sort of a peace of mind
knowing that like I'm I'm willing to let
the model and agent run for a longer
period of time so that it it sort of
truly covers the fullness of the
ecosystem.
Um
I think there's definitely other use
cases that are successful. Those feel
like the two most successful right now.
Um and I think the the interesting thing
to think about and I had this
conversation with Jeff Dean a few weeks
ago around sort of like as the models
become longer running, you start to see
a bunch of like really interesting new
bottlenecks come up. Um which I think is
actually like corre- like more
correlated to the use cases than I think
you would imagine. Um and so if you're
thinking about like what problems to be
solving or um as as you build
long-running agents, like where to look
to go and and find alpha, um it can
actually be in the tools. And if you
look at if you've ever like looked at a
long agent trace, um some reasonable
amount of the time that the model spends
and this is going to be an increasing
portion of the time
is spent just like using external tools.
It's not actually the model answering
your question or thinking or whatever it
is. It's actually the model using
external tools. And the challenge is
that these external tools were not
actually built to be used in this
capacity. They're often times like
different systems that we're assuming
there was like a human interacting, so
some latency would make sense and like
maybe a lack of parallelism would make
sense, but that's actually not the case
in agents now. Um and so I think we'll
see all of these like weird bottlenecks
show up as we make agents run longer.
Um and I also think like as model
capability improves, we'll see like a
better diversity of like successful use
cases. Um
but it really does feel like coding I'll
I'll be excited to see like something
some use case like dethrone coding. I
think maybe it's like starting to become
Like at Google I/O we launched Gemini
Spark, which is sort of your always-on
24 24/7 like personal agents that you
can throw tasks over the wall and
they'll do. So maybe that use case over
time just given the volume of people who
are needing a personal assistant versus
coding, maybe that will dwarf it from a
total consumption perspective, but it
feels like uh coding agents is
uh by a long shot the biggest use case
today.
Yeah,
I I I also feel like
you know, stuff which takes humans a
long time to do are the best use cases
for long-running agents. So research is
definitely one of them. Uh we also have
an episode of the agent factory where we
go into three different use cases of
long-running agents, which I'll be
leaving in the description box below.
And we have a blog post released by
Google Cloud, which shows you exactly
how you can build a long-running agent
example from ADK and that will be in the
description box as well.
Yes. Thank you, Smitha. And uh talking
about use cases of long-running agents,
I fully agree. Um
there's a lot possible. Coding is one,
deep research and deep research maths,
uh which is my my personal favorites as
well. But there's also stuff like core
scientist where and and Alpha Ewar which
are like super long-running agents. And
the longer you run them, the better the
quality. Um
and then also another thing uh which I
think used to receive a lot of attention
the last iterations within this course
but less so now is multimedia. Like uh
Thomas Fister from my Cloud AI research
received uh
published his team published a paper
around how you can make uh longer movies
more than just say 20 or 30 seconds with
uh an agentic long-running agent uh
agentic system uh combining a lot of the
best practices around eval and um
agentic engineering as well. So yeah,
really looking forward to um what comes
out.
I think another thing I'd add there is
um
if you think about a dynamic environment
where inputs are changing,
long-running agents can often be well
suited. So for example, um you know,
banks processing loans, you may a
typical loan process in a bank may take,
you know, weeks to a month to approve
and there's different inputs that the
agent needs to go back to the employee
to get more information. Um and and
process and and change the dynamic
decisions based upon that.
Um you know, insurance claims, um
uh a legal agent working on a court
case, you know, the input information
changes dynamically and you need to have
that ability to have the agent be be
long-running to continually dynamically
adapt to the different inputs.
Jimmy, I think this should actually be
something interesting for the Cloud team
to map which is like you sort of have
the like length of the how long the
agent can run for um on the sort of
x-axis and then over time as it can run
for longer, you actually see like all of
these additional like markets and
different segments unlock. So I feel
like there's a lot of things where like
actually, you know, maybe for uh the
example would be like one bank, you
know, your favorite choose your favorite
bank takes, you know, they they need 30
days but the other one maybe needs, you
know, 60 days or something. And so like
it doesn't work now for the bank that
needs 60 days but it does for the one
that that can get it done in 30 days. Um
so it'll be interesting to see and and
track that over time.
Uh Logan, I think uh cutting out but I
believe uh
uh
talking about different longer running
use cases across across different
industries uh uh makes a lot of sense.
Um
So,
uh
I believe uh
so yeah, as as as as as
in industry uh as there's some use cases
which longer you run the agent, uh
the better the output and you can see
that in many industries. Shall we move
on to the next question, Smita?
Uh so, we have a community question from
Sayan. Um and he's asking, "Could you
share some real-world examples where
wipe coding has been applied
successfully? And what challenges
developers face when
when moving from chatbots to fully
autonomous systems?"
Uh
Partha, would you want to answer this?
Sure. Uh so, thanks Sayan for the
question. It it it's actually a pretty
um uh interesting question. I think it's
actually two questions in one and uh
I could probably spend a lot of time
talking about both of those. So, so the
first part is uh
uh where are we using wipe coding? Uh I
think Smita mentioned earlier uh uh
a good fraction of code the last time I
think we talked about it was 75 80% of
code at Google is developed
using AI. Uh but I think uh I've been
particularly lucky to work on a whole
bunch of applications and uh it's just
been amazing on where you could use it.
AI for coding of course, but you can
think about um AI for system
development, AI for performance, AI for
efficiency, AI for reliability, AI for
operations. You can think about AI for
supply chain management, AI for
productivity, AI for science. So, I
think the applications for uh uh AI are
just phenomenal and across the board you
could apply it in various different
ways. If I had to pick one example, uh
we recently wrote a blog post where we
talked about how we've been using AI to
automate migration from TensorFlow to
JAX. And as you can imagine, these kind
of migration problems are
incredibly hard and they're very
time-consuming. And we were able to use
an agentic approach to
automate this in a way that got us on
YouTube, for example,
when they did their TensorFlow to JAX
migration, we were six to eight times
faster. And And you can imagine the
amount of time that you can save by
doing something of this sort.
And maybe Smitha, we can put a link to
the blog post that we wrote about this
later on as well. So that is all the
various applications for AI, but really
I think you're just limited by your
imagination and where you can use white
coding and agentic engineering to try to
do stuff.
Now, in terms of some of the challenges,
we've already alluded to a few of those.
Jamie mentioned some of the things
around how you want to think about
safety. And I usually think about the
three H's, hate, harm, hallucinations.
And so you want to obviously make sure
that you're grounding, you're thinking
about bias in the data set, you're
thinking about the safety aspects of how
all of the AI works. And
Anant mentioned evals, and we're going
to have a whole section on evals, I
believe, in one of the days here. And
And thinking about security and
verification and hate, harm,
hallucination, super critical. The
second observation I would make is uh
similar to what maybe Logan talked
about. You really want to think about
the entire workflow. So especially when
you think about long-running agents,
it's very easy to optimize one portion.
And And And I think of the
old children's game of Whac-A-Mole where
you kind of hit one thing and something
else pops up. And And so you have
similar problems here where if you just
optimize one, for example, if you're
thinking about optimizing coding and you
optimize coding by 10x, uh testing
becomes a problem. And so you really
want to think about what does AI-infused
workflow look like. What does the entire
journey look like, and how you can
optimize for that. And so, that's a
challenge and a lesson that we have
learned uh
uh in terms of how as you start having
uh wipe coding and agentic
architectures, you want to think about
the full workflow and not just optimize
one portion where something else becomes
a problem.
The uh third challenge I would uh um
observe or at least uh I have been
observing is um
thinking about again the uh life cycle
of how you apply AI.
I have this framework that I call IUS.
And uh I stands for impressive, U stands
for useful, S stands for sustainable.
And what I usually talk about is often
times when you're using um wipe coding
agentic engineering,
the first demo that you come up with is
impressive, so the I. And uh and that's
always where you start off with this.
You take a specific use case. Uh
uh you build something really nice, and
that's always a good starting point. But
then you want to go beyond that to
saying
beyond that particular use case, how can
I make it commonly applicable? So,
something worked for me, but how can it
work for everybody else who's using it?
And so, you go from impressive to
useful.
And then once you get useful, you want
to think about how this this scalable,
secure, sustainable, and that's the S
part. And when I say sustainable, often
times I've seen people come up with an
AI use case that can be three times more
expensive than the regular current way
of doing that. And it's of course AI,
but what you also want to do is to start
thinking about how can you be
sustainable about how you use AI as
well. And so, that's the other lesson we
are learning is as you navigate the wipe
coding agentic uh engineering journey,
you want to think about are you in the
impressive or the useful
or sustainable stage? And it is a
journey, and you go through all three.
But you do want to ultimately get to the
sustainable scalable solution that helps
everyone else and so on. And so, that's
something to look at.
But but I I'll I'll go back to something
that Logan said. Ultimately, this is a
new paradigm and we are all learning
together. And and I'm sure you're going
to have a lot of lessons as well. So,
the most important thing is to be
adaptive and be nimble about what we are
learning. And be aware that it's a new
paradigm and that we're going to be
learning things as we go along. But
hopefully the three observations I said
were useful to you folks as you think
through your journey as well.
I love that acronym IUS. I feel like I
could use that, you know, even when I'm
picking up a skill or something. Is this
impressive, you know, useful, or
sustainable?
Um
And sustainability is one of the reasons
why for those of you who'll be facing
quota quota restrictions um
in the code lab throughout the week
because we have limited quota for for
free usage. So, um this
sustainability is a part of that.
Awesome. Uh thank you to all the guest
speakers for coming on here to answer
all these questions. This was super
helpful.
Now, all right, we're going to start
actually moving on to the code labs. And
uh today's code labs, there's two code
labs which are designed to actually get
you hands-on with live coding from
minute one. So, Fran's actually going to
walk us through both of them. Over to
you, Fran.
Thank you, Smitha.
Um hi everyone. Wow, what a good
discussion. Um welcome to the code labs
for day one day one of our code. I'm
Fran Hinkelman. I lead the AI DevTools
team in Google Cloud DevRel. And I'm so
excited to guide you through your first
steps of agentic development.
For day one, we have two practical code
labs that will get you up and running.
First, we'll introduce you to Google
anti-gravity, which will be your main
tool for the whole week. And second,
we'll look at Google AI Studio as
another option for building apps, how to
publish them, and how to share them with
all your friends. Um
in your first codelab, you will install
and configure antigravity. Could we
share the screen? Yes, so you'll install
antigravity. It's um your central
command center for managing your agents,
your workspaces, and your code. And once
you have it installed, I encourage you
to work through the codelab, click
around, and explore. It's a very visual
way to partner with your agent. You'll
see how to how they create
implementation plans and guide you
through the tasks. You'll see your your
artifacts on the right here. Um
you can open the IDE. If you want to try
out different models, you do that right
here where you set your prompt. And one
thing I want everyone to look at is if
you go to settings,
and then to models,
um then you can see your remaining token
quota. And if you run out of Gemini
tokens, um you can always pick another
model, Claude or GPT models, right in
your prompt. That should get you about
twice as far as what you've used so far.
All right. So, let's look at the
codelabs for day one.
Let me share.
Codelabs.
So, as I said, um
first codelab is about Google
antigravity. The links to the codelabs,
those were shared with you in your
welcome email. They're also in the
discussion post. Um
so, go to those links. You don't need to
log in or anything for codelabs. As you
work through your codelabs, you can go
back and forth. Um there's no time limit
or anything. There is a time right here.
It's just showing you how long you sort
of expect that to complete it, but you
can work on those infinite time. Um
there's there's no timer ticking or
anything.
Um and then our second code lab um
introduces Google AI Studio as another
option to build labs. And you already
heard Logan talk about AI Studio. Um
you'll learn the basics of how to write
code um an app by describing it in plain
English or any other language. Um I
built this very silly corgi app here in
the impressive, useful, sustainable.
It's
maybe in the impressive part. It's
definitely not in the useful part.
[laughter]
Um but we'll show you how you can build
any app and how you can publish it to
the cloud with just a few clicks.
I'm super excited to see what you all
building on day one. Um once you have
your vibe coded app deployed, please
please please share it with us. Drop the
link in the Discord server. Like we're
all here to learn from each other. And
I'm sure you'll do something way more
impressive than my corgis jumping around
here.
Um
one last thing for the code labs. There
is
you don't need to submit anything after
you finish a code lab. Um work through
them. I really encourage you to
carefully read between the steps. Don't
just copy and paste the commands. Um
you'll learn the most if you actually
read it to to understand it.
All right. So, that's all for the day
one code labs. Have fun with the labs.
Share your impressive apps and back to
Smitha.
Awesome. Thanks, Brian. Both those code
labs actually look amazing and they're
super worth running end to end. And the
AI Studio to CloudRun one is
particularly such a concrete example,
like going from idea to a deployed URL
in minutes.
That used to be a multi-day setup. Now
you can do that in minutes. So, now for
arguably the most exciting part of the
live stream, the pop quiz. Off to you,
Anant.
Yes, I would say it's the second or
third most exciting after the QA, but
for those of you who have been listening
and and reading the white papers, we
start off with our first question of the
pop quiz.
So, your first question
would be
Every AI agent is built from five parts.
Which part is described as the reasoning
engine that reads the context and
decides what should happen next? Your
options are
A, the memory, B, the tools, C, the
model, or D, the orchestration.
Think about it, and your answer will be
shown in 3 2 1 and
C. C is the main brain, the reasoning
engine that powers your AI agent,
especially for AI coding agents.
Moving on to the next question.
Um which of the following is a key
differentiator of agentic agentic
engineering compared to the casual vibe
coding on the development structure?
Your options are A, minimal code base
understanding and selective review, B,
sole reliance on manual spot checking
and user prompts, or C, a systematic
process of testing, CICD gating,
evaluation judges, etc., or D,
copy-pasting raw error message back to
the LLM to so that the LLM can resolve
them.
Your correct answer will be shown in 3
1 and it's C. Agenting engineering is a
systematic verification through
automated test tools, CICD gating, and
evaluation churches.
Moving on to our third question.
According to our white paper, our day
one white paper, what becomes the
primary new bottleneck in the compressed
AI-driven software development life
cycle?
Your options are
A, designing the database schemas, or B,
writing the boilerplate syntax to
bootstrap the process, C, running code
in isolated sandboxes, or D,
specification quality.
Your correct answer will be shown in 3 2
1 and it's D. So, whenever given the
power that AI has,
being very the
writing your specs to a lot of high
quality, which you also see in day five,
becomes a big bottleneck to make sure
you build the right things.
Uh
question four.
Uh so, in this equation, what
constitutes the missing harness
component? Um agent is equal to model
plus harness, as we saw earlier in the
white paper overview. What is that
missing component? Your options are A,
the physical GPU infrastructure holding
the LLM,
uh the custom trained weight matrix of
the transformer model, or whichever
model diffusion model uh you use,
C, the surrounding scaffolding,
or D,
uh uh
the a functioning function of memory
storing long-term user preferences.
C is the correct answer, because that's
what the harness is. The model powers
the harness and vice versa.
Pretty important part. All right, to
your last question.
Our last question is, what financial and
operational trade-off describes the
investment of each agentic engineering?
Is it
um is it option number um
A, low capex, high opex, B, high capex,
low opex, or C, low capex, low opex, or
D, high capex, high opex?
So, think about it and your correct
answer will be shown in three, two, one,
and it's B. Agentic engineering uh leads
to a higher initial investment, be it in
your training your models, your GPUs, or
setting up and using tokens, but it
leads to lower opex, which is the actual
developer life developer time and
effort.
All right, that brings us to the end of
our pop quiz.
Awesome. Thank you, Anand, and also
quick wrap-up before we sign off.
Day two assignments will drop shortly,
and tomorrow's topic, agent tools and
interoperability,
picks up right where today's left off.
It goes deeper into MCP, A2A, and how
agents actually plug into the outside
world. So, keep the discussion going on
Discord, the mods are active, and also
get started on the code labs if you
haven't already. Try to actually deploy
something to Cloud Run. It's actually
really satisfying to see your bycoded
app live that you can share. And also,
see every Hope to see everyone tomorrow
at the same time. Thank you for being
here.
Same time, same channel, different
topic. See you, everyone.