Getting the transcript
Reading the captions from YouTube. A video nobody has opened here before takes 10 to 30 seconds; this page fills in on its own.
Getting the transcript
Reading the captions from YouTube. A video nobody has opened here before takes 10 to 30 seconds; this page fills in on its own.

Kaggle · @kaggle
Where viewers went back to watch this video again, from YouTube's public Most replayed graph, lined up with what was said at that moment.
Most replayed moment #1
42:156.4x the video's typical replay level
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
Said at 42:09
Most replayed moment #2
44:184.7x the video's typical replay level
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
Said at 44:12
Most replayed moment #3
24:134.1x the video's typical replay level
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.
Said at 24:08
The graph counts replays. It does not show where viewers stopped watching.
Words
8,675
Runtime
51:31
Speaking pace
168wpm
Reading time
36min
168 words per minute, between the 160 25th percentile and the 181 median of 349 measured videos. That distribution comes from the 349-video hook study.
Opening (first 30 seconds)
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.
84 words, the words spoken in the first 30 seconds at 168 words per minute.
Free, no signup. See how the first 30 seconds hold attention, with rewrites.
Sentence shape
| Measure | This transcript |
|---|---|
| Sentences | 470 |
| Average words per sentence | 18.5 |
| Longest sentence | 88 words |
| Questions asked | 34 |
| Sentences containing a number | 17 |
Most used terms
Filler phrases
467 in total: uh 144 · like 114 · um 94 · actually 43 · you know 34 · sort of 27 · kind of 6 · I mean 2 · right? 2 · basically 1.
A literal whole-word count of the same phrase list the Prepublish browser extension uses, so a phrase inside another word is not counted and a phrase used in its ordinary sense still is. It is a count and not a judgement.
What this transcript is
Every word below is the caption track YouTube publishes for this video, pulled from the video itself and reproduced unchanged. It is not Prepublish's writing, not a summary, and not a re-transcription: it is the video's own published captions. English captions, generated automatically by YouTube, in the video’s original language. Source: the video on YouTube. A channel that would rather this page did not exist can ask for its removal through the contact page, and it is removed.
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 Q&A.
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 Q&A. 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 Q&A, 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.
The words are the caption track's own and nothing is reworded or re-transcribed. Paragraph breaks are placed between sentences so the text reads as prose.
Free tools for your own script. No signup, no login.
Paste your draft and see where viewers are likely to drop off, with a rewrite for each weak line.
Paste the first 30 seconds of your own draft for a hook score and rewrites.
Check your draft against YouTube's advertiser-friendly guidelines before you record it.
Read this channel's public videos and transcripts, and download a writing brief for it.