FINALLY Good AI News From Google Boss

Dev Leader Weekly 99

Dev Leader

Jun 21, 2025

TL; DR:

Code-by-AI metrics are trash
Software development work is NOT finite
Check out the live stream on Monday, June 23rd at 7:00 PM Pacific!

Why AI Isn’t Taking Your Job

If you’ve been doomscrolling lately, you’ve probably seen the headlines.

“AI to replace developers.”
“Software engineering is dead.”
“80% of code now written by AI.”

And if you’re early in your career, or even mid-career, it’s easy to internalize that fear. After all, who’s publicly arguing the opposite?

Turns out: Sundar Pichai is.

In a recent interview with Lex Fridman, the CEO of Google laid out a very different story -- one that mirrors what I’ve seen in my own work and what I personally believe is our path forward as software engineers. Now, I don't have a crystal ball and I could of course be wrong, but I talked about it more in depth in this reaction video on YouTube:

This newsletter unpacks what he said, why it matters, and what you should actually focus on right now to stay ahead. This one is for all of the developers in this position:

First, Let’s Talk About the Fear

There’s a reason so many engineers are anxious. Media outlets and tech influencers love fear-driven narratives. Executives at AI-forward companies are incentivized to push aggressive adoption curves. And developers are seeing real examples of teams getting smaller as tools get smarter.

So yeah, the fear is understandable. But much of it is built on bad assumptions.

Let’s look at the three core myths driving it:

There’s a fixed amount of developer work to do
AI replacing some tasks means replacing whole jobs
Metrics like “X% of code written by AI” tell the full story

Plus, we have REAL examples of companies that downsized their dev teams only to hit the "OH CRAP!" button not too long after. It's just that the other side of the narrative gets a LOT more attention.

Actionable Tip: If you’re feeling anxious, stop doomscrolling. Start questioning the assumptions behind the headlines.
Ask: What exactly is being measured? Who benefits from this framing? Then dig deeper.

If you're feeling overwhelmed from it, you can always disconnect. Remember, the more time you spend lingering on social media content, the more those platforms will continue to serve it to you.

AI Isn’t Shrinking the Work -- It’s Scaling Our Capacity

Sundar’s view is that the more people we can enable to solve creative problems with AI, and the more things those people create, the more need we have for engineers.

This echoes my own view: Software engineering has never had a shortage of things to do. If anything, we’re drowning in it.

Everywhere I’ve worked, from startups to Microsoft, the problem hasn’t been “Do we have enough to work on?” It’s “Which fire do we put out first?”

The backlog of work NEVER truly shrinks. So what does AI really do?

It removes bottlenecks. It accelerates the boring stuff. It frees us up for higher-leverage, more creative engineering.

Sundar said it outright: Google is using AI to increase engineering velocity. And they're still hiring more engineers.

Actionable Tip: Look for ways AI can help you eliminate grunt work in your current flow.

Start with:

Test scaffolding
Refactoring boilerplate
Generating docstrings or summaries

Let it give you a head start, then make the real impact with your judgment and creativity. My next series of YouTube videos will be highlighting all of the ways I am trying to use AI in my own development flow, so stay tuned to Dev Leader.

The Metrics Are Misleading (And Often Useless)

You’ve probably heard stats like:
“30% of Google’s code is written by AI.”
Or “Copilot authored 80% of recent commits.”

That doesn’t tell you anything about value.

In my own project, BrandGhost, Copilot shows up as the author on most commits since I started using GitHub Copilot with pull requests. But guess what?

I’m the one reviewing the code
I’m steering direction changes
I’m cleaning up and debugging the generated output
I'm committing changes to the pull request as well
I'm pulling down the branch and running it

The commit history doesn’t show any of that. These stats we're bombarded with don’t reflect impact, insight, or iteration. They just count keystrokes.

Sundar makes this distinction clearly. What matters is engineering productivity -- not how many lines were generated.

Actionable Tip: If your team starts quoting AI code-gen metrics, reframe the conversation around productivity.
Ask:

How are we measuring productivity?
What’s the quality of the AI-assisted output?
How much time did we save, and where did it go?

If you have more code written by AI and you're not delivering more value faster... is it actually helping?

AI as a Multiplier, Not a Replacement

One of the best analogies Sundar hinted at is that AI is like giving developers power tools. You’re still the builder. But now you can shape things faster, more precisely, and more ambitiously.

AI doesn't reduce the need for engineers it multiplies what good engineers can do.

I’ve had moments where I wake up, check GitHub, and find that an idea I jotted down the night before has already been scaffolded by an agent. That’s not job replacement. That’s time unlocked.

The difference comes down to ownership. The tool can start the work. I get to finish it. And often times I'm getting it to do the boring stuff or the stuff that I'm not mentally ready to jump into.

If the code it generates is trash, I toss it out. It takes me moments to read through it and decide if I want to move forward with it. But I often at least get something interesting to steer my own direction, and often a helpful starting point.

Actionable Tip: Shift your mindset from “AI might replace me” to “How do I become great at using these tools?”
Try this:

Run a one-week experiment where you default to asking AI first (Copilot, ChatGPT, Cursor)
Track what it gets right, what you have to correct, and what genuinely saved you time
Reflect: what workflows feel stronger with AI as a partner?

Again, I'll remind you that I have videos coming out on Dev Leader that I'm so excited to talk through on AI tooling. It's a hot topic for me on Code Commute as well, and speaking of which, you can see my first take on the Sundar & Lex interview on Code Commute:

We’ve Been Here Before...

For my dotnet developers out there... Remember WinForms? WPF? Visual Studio source generators? All of those produced machine-written code. If someone was counting the lines of some applications over time, they might start seeing disproportionate amounts of code not written by a human. You do know all of that stuff you dragged-and-dropped in the designer view generates code, right?

Nobody panicked then because lines of code by a computer increased.

Why? Because it doesn't matter -- it's wildly beneficial that a computer was able to generate that code for us. Just like it's wildly beneficial for us to have source generators for regular expressions in dotnet as well, adding more lines of machine-written code to our software.

AI just adds more volume -- faster. But volume isn’t necessarily value.

This isn’t the first time tooling has changed how we work. It’s just the first time the tooling is talking back.

Actionable Tip: Use history to ground yourself.
Look back at previous tooling shifts:

How did IDEs change your workflow?
How did source control change team collaboration?
How did frameworks change your development practices?

Now ask: How does AI fit into that lineage?

The Ceiling Is Higher Than Ever

A big part of Sundar’s framing is that this isn’t a zero-sum game.

It’s not “either AI writes the code or you do.”

It’s: how do we get even more done, by expanding who can participate, and reducing the cost of experimentation?

Think:

Faster iteration on side projects
More inclusive environments for early-stage devs
More creativity applied to product and platform design

The ceiling on what one person or small team can build just went way up.

Actionable Tip: Plan a “stretch project” that would’ve been too time-consuming six months ago.
Use AI tools to handle the scaffolding, documentation, and setup. Focus your time on design, decision-making, and feedback loops... And like, the parts you ACTUALLY are most interested in.

You’ll be surprised how far you can get in a weekend.

AI in Interviews: Not Yet, But It’s Coming

One last interesting angle in the Lex interview: how AI is shaping hiring.

Sundar doesn’t go into detail, but the message is clear -- companies are still assessing core fundamentals. But being good with AI tooling is already becoming a differentiator, just not directly in the interview setting.

I suspect we’ll soon see interview loops where “prompt literacy” and AI-assisted debugging are real skills being assessed. I don't think it will happen overnight, and I don't think it will necessarily replace all of the other interview components, but I think it's on the way.

Actionable Tip: Start practicing “visible AI workflows” in your projects.

Annotate and track in your work where Copilot, Cursor, or your favorite AI tool was helping
Include AI-generated suggestions alongside manual ones in review comments
Use README or wiki entries to document how AI contributed to implementation

It doesn't have to be IN your code, but try keeping a record of this and see how it evolves.

Final Thoughts: Let’s Zoom Out

Sundar’s view reflects the opposite of what we've all been doom-spiralling on:

There’s always:

More to fix.
More to build.
More to understand.

AI doesn’t erase that. It gives us a better starting point.

So if you’re worried about your place in this industry, here’s the truth:

You don’t need to outpace AI.
You need to outpace yesterday’s version of yourself with AI on your side.

And if you’re already thinking critically, adapting your workflows, and building for the long term?

You’re going to be just fine.

Dev Leader Weekly