New Rules of Software Engineering — AI Studio DeepMind

• Channel: Beyond Coding
• Video: Watch on YouTube
• Tags: new rules software engineering ai studio

Overview

Logan Gilpatrick (Google DeepMind AI Studio product lead) discusses how what’s possible changes every 2-3 months, and why engineers must reset their level of ambition.

Key Takeaways

• The thing that got me excited about learning how to build software was the ability to solve problem. this is logan gilpatrick, product lead for ai studio over at google deepmine. there’s so much interesting innovation that’s happening in this
• Of software engineering have changed. here’s the full episode. i love your keynote yesterday. thank you. i was very excited to see anti-gravity cli. yeah. and i feel like more and more engineers are moving towards cli first. i do
• An sdk and a cli. the ide and an agent manager. and then also in a managed api service. and i think it was cool to see the anti-gravity story come to life. literally with the full breadth of that.
• Story that we’ve been able to pull off before. i think it’s actually based on feedback from developers who are like. give us a single product. we don’t want to have to. you know, wait through the ecosystem of 50
• I noticed that the anti-gravity one is not. yeah, this is an interesting thread. i think we’ll all. i work super closely with the integrity folks and actually also the gemini cli folks. interesting to see how this ends up
• Actually right now. yeah. i think not doing it. and so i think if they decide to go open source, i think they want to like. actually lean in and do it. but my sense is it’s not like there.
• To like go and do that. i think the team who is working on gemini cli and actually some of them are not working on a bunch of anti-gravity stuff. it’s just like maybe less less the thing that they’re
• As well. that says, well, there is this kind of the idea is dying, right? because if your agents are generating code and you have if you have the right guard rails or if you have the right hardness capabilities
• As engineers. but do people then do you see this narrative of the idea you’re dying or what you’re taking on that? i think my framing of it is not necessarily the idea is dying. i think it’s like the
• Where you spend a lot more time reviewing code and a poorer request than historically you would be for. and so like i’d imagine there ends up being a lot more innovation and focus on like how do you build
• The focus definitely moves you still need an editor and so actually for antigravity like there is still an editor. you can actually hook it up to the editor of your choice now as well. so if you’re like hey
• Engineering and i think the agente engineer needs to be able to go into an ide and it code. in some cases they’ll probably maybe predominantly be using some sort of like agent manager. but you still need the ability
• An agent manager experience so i don’t think it’s going to go away. i think developers will spend more time though probably outside the idea and to me that feels like a very natural thing that like developer tooling continues
• The bottleneck will be a request very, very soon right. i feel this already inside a google guy i write code all the time now and it’s like the codes actually reasonable. the burden is now on a bunch of
• Speed up code review and then. the the actually jeff dean made this comment to me a couple of weeks ago, but like the burden a lot of cases actually moved to like tool execution. and so as models get

Transcript

The thing that got me excited about learning how to build software was the ability to solve problem. This is Logan Gilpatrick, product lead for AI Studio over at Google DeepMine. There’s so much interesting innovation that’s happening in this way that was not happening three years ago. Every two weeks, every three months, every six months, what’s possible changes. You have to reset your level of ambition. Somebody should build that company. Which skills really matter nowadays? The rules of software engineering have changed. Here’s the full episode. I love your keynote yesterday. Thank you. I was very excited to see anti-gravity CLI. Yeah. And I feel like more and more engineers are moving towards CLI first. I do feel like we’re trying to meet developers where they are. And I think this story of developer preference has also never been more. I think it’s actually been hard to meet developers where they are because it’s expensive to build an SDK and a CLI. The IDE and an agent manager. And then also in a managed API service. And I think it was cool to see the anti-gravity story come to life. Literally with the full breadth of that. You could literally use it in an IDE. You could use it in the agent manager. You can use the CLI. You can use it through managed agents in the Gemini API. It was really cool. It was a unique story that we’ve been able to pull off before. I think it’s actually based on feedback from developers who are like. Give us a single product. We don’t want to have to. You know, wait through the ecosystem of 50 different AI products that Google’s offering for developers. And so you even like the consolidation of the Gemini CLI sort of moving over to the Integrity CLI is all based on that feedback. Gotcha. The Gemini CLI was open source. I noticed that the anti-gravity one is not. Yeah, this is an interesting thread. I think we’ll all. I work super closely with the integrity folks and actually also the Gemini CLI folks. Interesting to see how this ends up shaking out over time. My sense is that it’s not like a deeply strategic choice right now. It’s just like you can move. There’s like there’s a cost to doing open source. Of course you can move a lot faster actually right now. Yeah. I think not doing it. And so I think if they decide to go open source, I think they want to like. Actually lean in and do it. But my sense is it’s not like there. I don’t think the headspace is that there’s a bunch of like. Secret stuff that they’re trying to do. I think it’s mostly just like an operational thing and like even does that team have like expertise and the desire to like go and do that. I think the team who is working on Gemini CLI and actually some of them are not working on a bunch of anti-gravity stuff. It’s just like maybe less less the thing that they’re that they’ve done before and have the expertise for. So it’ll be interesting. We’ll see how it shakes out. But I definitely saw the feedback of folks wanting to have an open source variant. Yeah, I’ve seen a thread online as well. That says, well, there is this kind of the idea is dying, right? Because if your agents are generating code and you have if you have the right guard rails or if you have the right hardness capabilities even engineering around your harness. Then you don’t necessarily need to look at the code that is generated, right? You might do it in a poor request or even if that becomes a bottleneck that’s something we need to solve as engineers. But do people then do you see this narrative of the idea you’re dying or what you’re taking on that? I think my framing of it is not necessarily the idea is dying. I think it’s like the way that software is being built is evolving. And actually in some sense it’s interesting that there’s maybe even more tools that are involved. In some sense there’s less tools and some sense there’s more tools. And actually your example where you spend a lot more time reviewing code and a poorer request than historically you would be for. And so like I’d imagine there ends up being a lot more innovation and focus on like how do you build great code review tools that maybe actually look different than the code review tools of the today era that were built with the assumption that it was a human writing code not an agent writing code. So I think the the focus definitely moves you still need an editor and so actually for antigravity like there is still an editor. You can actually hook it up to the editor of your choice now as well. So if you’re like hey I love into your favorite editor. You can go and continue to use that and you I think developers will need to do like some this is I think the biggest difference of like. You know vibe coding versus agente engineering and I think the agente engineer needs to be able to go into an IDE and it code. In some cases they’ll probably maybe predominantly be using some sort of like agent manager. But you still need the ability to win the time comes to go and add a code and look through it use a bunch of like rich debugging tools that only exist in an editor and don’t exist in the context of. You know sort of an agent manager experience so I don’t think it’s going to go away. I think developers will spend more time though probably outside the idea and to me that feels like a very natural thing that like developer tooling continues to change the developer tooling of today’s era is very different than it was 10 or 15 years ago and so. It doesn’t feel that that parts of not not super surprising to me. Yeah, same here. I feel like the bottleneck will be a request very, very soon right. I feel this already inside a Google guy I write code all the time now and it’s like the codes actually reasonable. The burden is now on a bunch of engineers across Google after a few of the code that I’m writing and give feedback and all that stuff so it gets. I think it’s like it’s quickly shifted into a bunch of different places and I think we can speed up code review and then. The the actually Jeff Dean made this comment to me a couple of weeks ago, but like the burden a lot of cases actually moved to like tool execution. And so as models get faster or even as you sort of maybe even if you had a human who could review your code right away instantly. There’s still like the CI time maybe becomes you know you have to run a whole set of tests and maybe you have a lot of tests because you’re you know great agent engineer and you’re being really thoughtful about it. Like that becomes the burden so I think the burden the sort of bottleneck actually so the bottleneck is going to be sort of all over the place and I think it’ll actually be interesting to see. How developers and how companies are measuring this like where in the process of creating software is the bottleneck we do and I think Google’s actually had historically a great culture and like a ton of instrumentation that helps us answer this question internally because we want to. So remember the bottleneck for engineers pulling software. Yeah, it’s really a puzzle that it’s more on my day to day to solve how do we measure kind of productivity because that’s the the marketing right you become more effective engineers feel that. But the costs are also rising that’s why specifically with 3.5 flash being very cost efficient. I was super excited. Yeah, if this is where we can go for example, Claude code has opus plan where you reason and you create for example your plan in a higher end model and then you execute in a more lightweight model. And I see the ambition with 3.5 is to just use the same model and do both. That’s the goal. Yeah, and I love I’d love feedback as far as where it lands. I think this is this is definitely like the first iteration of the 3.5 family and I’m like also the first iteration where we’ve done this. Model product harness symbiosis so that the model is being trained at the same time that we’re using the harness at the same time that we’re thinking about like how is that actually impact there’s lots of feedback historically about the Gemini models sort of like looking great on paper and not being great for real. Well, these cases in sort of we’ve taken that feedback super seriously over the last probably more than a year now to try to make sure that they’re as representative in the products themselves as they are in benchmarks and so. It’s cool to see that flywheel actually spinning now and and all of the all the progress happening. Yeah, from either at least in my community for the engineer that’s listening for example, it could be someone that is very on the higher end, but it could also be someone that’s kind of not even double their feet in there and skills are evolving for the person that’s listening which skills really matter nowadays from your perspective. Question I think it depends what you want to do and like what you’re what your actual job is I think there’s there’s there’s definitely like evergreen skills I mean I I think. You know taste I think is important if you’re if you’re an engineer who. You know can sort of see a user bug reported and know like oh this is how I should go and solve that problem and this is how I should get my agent to solve that problem whatever it is. I think there’s alpha and that because I think there’s there’s there’s so much software to be built that them as much as engineers can sort of take the burden of building that software and just go and run with it. I think so much of the and actually again this is like goes back to measuring like where all their bottlenecks so much of the bottleneck is in this like. Human communication loop that happens like someone reports an issue or says they want x y and see feature there’s this like long ping pong game of. Humans talking about something before somebody makes a plan and then actually goes and builds it and then brings it to users and like most of the ping pong probably in some cases it’s really useful and like the the taste aspect is like knowing when you need to play ping pong. And if you if you’re sort of know in a lot of cases and you have a high degree of accuracy of knowing when you need to play ping pong and knowing when you don’t need to. It speeds up the process so much and there’s like a huge amount of alpha and in being able to do that and like actually the best the best sort of engineers I work with. Have a great sense of being able to answer that question. Well, I wonder how long it takes to kind of develop this taste if you start out or if you already hear kind of working with a genetic tooling because it is a I think it’s a

(Transcript truncated — full length available on YouTube)