Shadowing Practice: How Great Software Engineers Are Moving Faster Than Ever - Learn English Speaking with Video

The thing that got me excited about learning how to build software was the ability to solve a problem.

This is Logan Kilpatrick, product lead for AI studio over at Google DeepMind.

There's so much interesting innovation that's happening in this way that like 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, 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 like story of like developer preference has also never been more.

I think it's actually been hard to meet developers where their because it's expensive to build an SDK and the CLI and ID and an agent manager, and then also in a managed service.

And I think it was cool to see the anti-gravity story come to life, literally with like 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 you could use it and through managed agents in the Gemini API, which is really cool.

It was a unique, unique story that I don't think we've been able to pull off before.

And 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, wade through the ecosystem of 50 different AI products that Google is offering for developers.

And so you even like the consolidation of the Gemini CLI.

Sort of moving over to the integrated CLI is all based on that feedback.

Gotcha. The Gemini CI was open source, 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 anti-gravity folks and actually also the Gemini CLI folks.

It'll be interesting to see how this ends up shaking out over time.

My sense is it's not like a deeply strategic choice right now.

It's just like a you can move, there's a there's a cost to doing open source.

Of course, you can move a lot faster.

Actually right now. I think not doing it.

And so I think if they decide to go open sourcing, they want to like actually lean in and do it.

But my sense is it's not like there.

I don't 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 Kelly and actually some of them are now 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.

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 ID is dying, right?

Because if your agents are generating code and you if you have the right guardrails 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 pull 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 ID is dying or what's your take on that?

I think my framing of it is not not necessarily the ID 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 like, there's there's maybe even more tools that are involved in some sense, you know, there's there's less tools in some sense there's more tools.

And actually your example where like, you spend a lot more time reviewing code in a pull request than historically you would before until 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 anti-gravity, 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 I think developers will need to do like some.

And this is, I think the biggest difference of like, you know, vibe coding versus a genetic engineering.

And I think the engineer needs to be able to go into an IDE and edit code.

In some cases, they'll probably maybe predominantly be using some sort of like agent manager, but you still need the ability to, when the time comes to go and edit code and look through and use a bunch of like, rich debugging tools that only exists in an editor and don't exist in the context of 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 IDE.

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 part's not super surprising to me.

Yeah. Same here.

I feel like the bottleneck will be will requests very, very soon.

Right. I feel this already inside of Google.

Like I write code all the time now and it's like the code is actually reasonable.

The the burden is now on a bunch of engineers across Google who have to review the code that I'm writing and give feedback and all that stuff.

So like, it's I think it's it's quickly shifted into a bunch of different places.

And I think we can speed up code review and then the, the, the actually, Jeff Dean made this comment to me a couple of weeks ago, but like the burden in a lot of cases actually moved to like tool execution.

And so as models get faster, even as you sort of maybe 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 a great agent engineer and you're being really thoughtful about it, but 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 moved to.

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, you know, remove the bottleneck for engineers building 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.

If this is where we can go.

For example, Cloud 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 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 feel like also the first iteration where we've done this model product harness symbiosis.

So 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 world use cases.

And sort of we've taken that feedback super seriously over the last, probably more than a year now to 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 all of the all the progress happening.

Yeah, for me, the 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 dabbled their feet in there.

And skills are evolving for the person that's listening.

Which skills really matter nowadays from your perspective?

It's a good question.

I think it depends what you want to do and like what your what your actual job is. I think there's, there's there's definitely like evergreen skills.

I mean, 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, report it 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.

100

Whatever it is.

101

I think there's alpha in that because I think there's, there's there's so much software to be built that as much as engineers can sort of take the burden of building that software and just go and run with it.

102

I think so much of the and actually, again, this is like goes back to measuring like where all the 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 z feature.

103

There's this like long ping pong game of humans talking about the something before somebody makes a plan and then actually goes and builds it and then brings it to users.

104

And like most of the ping pong, probably in some cases it's really useful.

105

And like the taste aspect is like knowing when you need to play ping pong.

106

And if you if you 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 in 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.

107

Yeah, I like that a lot.

108

I wonder how long it takes to kind of develop this taste if you start out or if you're already here kind of working with a generic tooling, because it is a I think it's a loss in kind of productivity initially.

109

Right? Whenever we try something new, there's an investment there and the payoff could be three months, it could be six months.

110

It really depends also on the curiosity and the eagerness and the drive, but it varies.

111

What is like the minimum investment that you think people should do?

112

Yeah it does. It varies.

113

And I think it also varies depending on what your team has done to set up.

114

And so I think we've had a lot of conversations with the studio engineering team as an example.

115

And one of the conversations and I told them, I told the engineering team this, I was like, hey, I want to do the minimal amount of setup humanly possible to get like full context of all of the engineering information that I need for my agent to go and make a bunch of changes in the studio code base.

116

And they were like, yep, okay.

117

And they literally got a like a whole suite of skills set up.

118

And I literally ran one command and then I not actually, but then I like had as much content.

119

My agent had as much context as every engineer on the team should have.

120

Not fully, of course. It's definitely loss here.

121

And then literally that same day, I was making production code changes in the AI studio code base.

122

So I think in some cases it actually can be months depending on what your setup looks like.

123

In some cases it's like days or hours.

124

And I think that's the that's the interesting thing is also like just trying to identify which of the situations you're in, like, and maybe there's a, you know, I'm sure there's lots of great engineers everywhere.

125

So maybe it's not that we have the smartest engineers who are just really good at doing it.

126

Maybe it's our tech stack actually just like works really well.

127

We already had Agent Rails, sort of.

128

We had the governance structure set up so that we could do the things we needed to add the AI tooling we actually wanted, and maybe that's harder at other companies, but it could be the best cases, like literally ours, where you're able to actually get that.

129

And I felt that as somebody who was doing a ton of software engineering work before I joined Google, joined Google on the product ladder originally, and like actually stopped doing a lot of engineering work because two years ago it was really like Google's internal infrastructure is actually really different than the rest of the world's developer infrastructure.

130

And so the learning curve is really hard.

131

It's sort of a lot more difficult to use some of the tools because they're designed to scale to like billion user products.

132

And even if you're not using a billion user product, it's sort of it's sort of difficult.

133

And this AI coding era has brought me back into like making real production software changes, which I've appreciated so much because I'm a I'm a software engineer and I love building software.

134

Yeah. So I think in that sense I got lucky.

135

But it's been it's been cool to see it happen.

136

And again, the best case is like literally they built the skills that day and I was able to benefit from them and start sending code changes.

137

Yeah, the best engineers that I know, the organization trusts them with kind of overarching ventures, right.

138

Bigger changes across multiple teams.

139

So the ability to fly in a team, kind of do your research or make impact is incredibly valuable.

140

I think we give those stakes when the stakes are high to the best engineers we have within organizations.

141

And then part of that, for me, something I've been recently thinking about is going to be agent experience.

142

So within a code base or within a team, can we measure some form of experience?

143

Right. If I come in and I have my stack, how well can I indeed familiarize myself and what in the repository allows for that to be able to be productive quite quickly?

144

I frame this to our team as I was thinking about this, and I'm curious actually what others think, and I would love to.

145

I'll read the comments on this video and see what people's reaction is to this.

146

But around sort of this idea of like code, code test coverage has existed for a long time.

147

You actually want the same thing for agents.

148

It's like agent coverage.

149

Like how much context?

150

How can you measure the amount of context that your agent has on the systems that it's it's orchestrating over?

151

The impressive thing is oftentimes these models can like, do a bunch of really, really smart things without having any of that context.

152

But if you give it the context, here's why this system was built this way.

153

Here's the chat threads where the engineers talked about, you know, the design trade offs or the meeting notes from the from the design review for this UI feature.

154

So you have that context.

155

The more of that context and the more coverage that exists for the actual software, the faster you can run.

156

And the best case is you actually need a system that's like continually updating that context that's being created about the software.

157

And I think it's a new I think I don't think there's a ton of startups thinking about this, but it's an interesting area of like, somebody should build that company.

158

I feel like it's very it'd be very interesting and it needs to live in the code too.

159

That's the other thing, because the agent needs to go, I'm, I think it needs to actually go there and like one, one really quick example of this is like as agents go and create more software, the artifact in like in anti-gravity.

160

And we use antigravity internally, and I use it outside of Google to the artifact that gets created is like this plan and this walk through and all this like checklist of like, here are the 50 things I did.

161

Here are the test that I ran.

162

When you actually commit the code, all that goes away.

163

So like I as somebody reviewing even going back to like where's the bottleneck?

164

Move to the code review process looks completely different than the fact that I just created all these artifacts that actually show the the proof of work is now different.

165

The proof of work for developers used to be creating code, passing the set of tests that were running at CI, and then that was like sort of it.

166

And I think the proof of work is now different because the bottleneck is not creating code.

167

Yeah, I've seen people experiment with spectrum and development frameworks where they then in the end, they trust the process and the guardrails they've built around not just agent, but also built around the harness capabilities, specifically making making it explicit some of the things they want.

168

And then in the review, reviewing the spec that is then also committed as part of the change, which I think is fascinating, I love it, I feel like it's the, the, my main takeaway is like there's there's so much interesting innovation that's happening in this way that like was not happening three years ago.

169

I feel like we all sort of like were, you know, this is how software gets built, whatever the, whatever the way is that the company was operating.

170

That's how software gets built.

171

And I feel like now that there's so much disruption happen, people are like, oh, let's try ten different things and we'll see.

172

And like maybe it is spec driven development that's going to be the thing.

173

Maybe it's something else.

174

So it's cool to see the level of experimentation.

175

I have so much fun.

176

Just like reading about what teams and are doing to to try out things.

177

Yeah, I feel like a kid in a candy store and like you like a couple years ago I was responsible for product.

178

I always wanted that role, being responsible more from a vision, more high over perspective.

179

And then things just accelerated and I got the biggest FOMO I have to go back to hands on.

180

And now I have a new role, which is more kind of productivity based.

181

And how do we level up our whole engineers entirely?

182

And then there are different challenges, right?

183

Some people are they don't really mind as much.

184

They like it even.

185

And some people really take pride in the craft that they have built in this, which is also the the writing code is a big component of that.

186

And that's slowly going away. Yeah.

187

To the to them I say, well, like there's still the part that is personal hobby projects where you can always do that, get that fulfillment.

188

But there is kind of a strong narrative.

189

That generation is just really what agents are good at and the engineering capabilities, they are kind of going more high over, and we are stacking things to make this work right.

190

We have agents, we have harnesses, we are building around that.

191

So it's a fascinating time. It is fascinating.

192

I feel this myself too.

193

I used to get the thing that got me excited about learning how to build software was like the ability to solve problems.

194

And I think if I go back to, you know, like computer science education, I think like independent of like clicking a bunch of keys on a keyboard is, is about sort of like a way of it's like a way of seeing the world.

195

Actually, I draw this analogy to like the, the legal system when you if you haven't studied the legal system and like have a deep understanding of how law works, you see the world in a way.

196

They're like, oh, there's a bunch of laws in a vacuum, and maybe I follow a speed limit here and there, and I have to pay my taxes, otherwise something's going to happen.

197

But you sort of don't have this depth of appreciation of like, actually, how does how do all of these complex systems work?

198

I think about and when you have that appreciation, you go about the world in a specific way.

199

You see the world in a specific way.

200

Software is the same thing, I think, like because I study computer science, because I understand how systems work, I see the world in a specific way.

201

The fact that now, today, I'm not the one who's like typing the keys.

202

I think doesn't actually diminish the the fact that there's alpha and seeing the world in that way in a lot of cases.

203

And so the abstraction layer changes.

204

But actually the skill of solving problems and actually very acutely, like the art of building software is the art of, you know, the code doesn't run, there's a problem, there's a bug, this thing, it's like almost like a building resilience in software engineers who are like trying to tackle all these really complicated problems and thinking about things in an interesting way is like the art of thinking, the art of, you know, again, solving problems.

205

That's such a useful skill.

206

Like, it's so, so I'm very I'm very bullish for like both like computer science education, but also like people who have this ability in the world.

207

Because if you can solve problems, you can do the world is filled with problems to be solved, which is exciting.

208

Yeah, I, I recently had this thought and it was because of one of the demo booths.

209

Right. The demo was you've got your own game, and I asked a lot of questions on kind of what happened under the hood, and they said they're going to release it in a month or so.

210

Open source, I can play around with it.

211

But in essence, I could just put my thoughts on paper and a game rolled out.

212

It took a little bit of a back and forth, but the outcome was there.

213

And then I felt this kind of like, I'm happy with how my career flew.

214

I'm happy with where I'm at now, but I am a little bit jealous about this newer generation because I feel like I think in constraints.

215

Right. And as a kid I had that less and less.

216

So if all of a sudden I can, for example, my little brother or my cousins, I can put them in front of the system and say, let's design a game.

217

I am sure they will be way more creative than I can be, because I now think in constraints, this is what you have to reset.

218

And I feel like this.

219

This is this is the hardest thing as humans and I fall, I'm I'm saying this to you to remind myself that I need to do this.

220

But like the every two weeks, every three months, every six months, what's possible changes.

221

And I frame this to people and like you have to reset your level of ambition and I've there's a double edge of this and I'll give this for like personal projects.

222

I've reset my level of ambition on personal projects so much that I'm like, my bar is now.

223

This is like I'm basically building a company.

224

Like if I can only companies everywhere, mini company that I'm going to go after.

225

And so I'm like, okay, if this isn't a mini company, like I probably shouldn't do this because like, it's not ambitious enough, but like that is that is the level of ambition that I think you can actually have.

226

And like the crazy thing is, I was always personally somebody who, like, wanted to who like you, I'm sure, who's like wanted to be able to build something ambitious.

227

And I was like, I just couldn't like, I never had enough time.

228

I couldn't actually, you know, I wasn't good enough software engineer.

229

I didn't have the right team, whatever it was.

230

And that's now completely changed.

231

And it is like it feels very empowering.

232

Yeah. For me, the the thing that will give people an edge, right.

233

All of a sudden, if you're looking for a job or you're looking to level up specifically a portfolio right now, doing really cool things is what will give you an edge.

234

I feel like more easily your foot in the door.

235

Do you also see that from a hiring perspective or the things you've been involved in?

236

Yeah, I love this proof of work set up, which has always made hiring a little bit easier when you have this proof of work.

237

And I think like actually open source historically to the original thread of our conversation, I think is a was always a great example.

238

So I love the open source community and why I spent like so much of my early career doing open source, because it was it was permissionless in many ways, like getting a job is like or an internship.

239

Your first internship doing software engineering is like convincing someone to let you change to like, contribute to their code base.

240

And the coolest thing in the world is open source.

241

I could just show up to anyone's code base and ideally in a non annoying way, like contribute something meaningful and actually become a part of this thing without needing them to like hire me.

242

And I still think that's like such an empowering force.

243

And now it's even more significant than that is like, I don't even need to go to it.

244

You still could go to an open source project, but like, you can actually just go build the project yourself and like, you could be in the driver's seat of the whole thing and the story and the narrative and the problem you want to solve and the way of bringing that thing to the market.

245

It's very interesting to see that that transition.

246

And it does feel it does feel empowering.

247

Yeah. The how you do that for me is incredibly crucial, right?

248

Because I feel like I learn a lot from it.

249

But I'm so curious, like, I want to know intricacies and I ask questions and that's where I get my knowledge.

250

You can also just go autopilot. No, no.

251

You build something, you don't know what it is.

252

You can go autopilot.

253

And then there's the best quote, the best sort of the quote of the era, which I'm going to get on a t shirt or something or put up a poster, will end with that.

254

The mascot of the poster in my room, which is sort of you can you can outsource intelligence, but you can't outsource understanding.

255

And so there's so many things.

256

There's a there's a, there's nuance of a line to walk of in what cases, what can you build where like it's actually fine to outsource both of those.

257

But like you go and build a product and you put real users and then you don't understand how it works.

258

Like you probably it's probably a recipe for bad things to happen.

259

So you could, you know, take advantage of the fact that you can outsource intelligence, don't outsource understanding.

260

I think there's a ton of alpha still on that.

261

Logan, thanks so much for coming on. This is a blast.

262

Thank you for coming to IO and having this conversation.

263

Thanks for having me, man. This was a blast.

264

I love it. Cool. That's it.

📺 Same Channel

Why Coding Agents Keep Making Your Codebase Worse

Business EnglishUniversity StudentsWorking Adults

✨ Recommend Video

129 sentences

What is the Shadowing Technique?

Shadowing is a science-backed language learning technique originally developed for professional interpreter training and popularized by polyglot Dr. Alexander Arguelles. The method is simple but powerful: you listen to native English audio and immediately repeat it out loud — like a shadow following the speaker with just a 1–2 second delay. Unlike passive listening or grammar drills, shadowing forces your brain and mouth muscles to simultaneously process and reproduce real speech patterns. Research shows it significantly improves pronunciation accuracy, intonation, rhythm, connected speech, listening comprehension, and speaking fluency — making it one of the most effective methods for IELTS Speaking preparation and real-world English communication.

Shadowing technique: read the full step-by-step guide →

Shadowing Practice: How Great Software Engineers Are Moving Faster Than Ever - Learn English Speaking with Video

Why Coding Agents Keep Making Your Codebase Worse

How to Become a Great Software Developer — Best Advice from Top-Notch Engineers

Gemma 4 Just Released - Whats In? In 2026!

Building Anthropic | A conversation with our co-founders

Day In my Life as a Software Engineering Intern at Google

Rapid Engineering With AI

I cloned 3 apps and now make $35K/month

I'm an ex-Google interviewer. You're doing LeetCode wrong.

What the heck is the event loop anyway? | Philip Roberts | JSConf EU

Google product manager behavioral interview (Top 5 questions)

Next.js 16.3 got good (if you care)

how AI broke the SWE Career Ladder

Why practice speaking with this video?

Grammar & Expressions in Context

Common Pronunciation Traps

What is the Shadowing Technique?