Amazon, Google and Vibe Coding with Steve Yegge

The Pragmatic Engineer

0:00

-1:33:41

Amazon, Google and Vibe Coding with Steve Yegge

Steve Yegge shares why Google struggles with platforms, how AI coding is deceptively hard, and why the "AI Fixer" role could be one spreading inside tech companies, in the future.

Gergely Orosz

Jul 16, 2025

Transcript

Stream the Latest Episode

Listen and watch now on YouTube, Spotify and Apple. See the episode transcript at the top of this page, and timestamps for the episode at the bottom.

Brought to You By

WorkOS — The modern identity platform for B2B SaaS.
Statsig ⁠ — ⁠ The unified platform for flags, analytics, experiments, and more.
Sonar — Code quality and code security for ALL code.

—

In This Episode

Steve Yegge is known for his writing and “rants”, including the famous “Google Platforms Rant” and the evergreen “Get that job at Google” post. He spent 7 years at Amazon and 13 at Google, as well as some time at Grab before briefly retiring from tech. Now out of retirement, he’s building AI developer tools at Sourcegraph—drawn back by the excitement of working with LLMs. He’s currently writing the book Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond.

In this episode of The Pragmatic Engineer, I sat down with Steve in Seattle to talk about why Google consistently failed at building platforms, why AI coding feels easy but is hard to master, and why a new role, the AI Fixer, is emerging. We also dig into why he’s so energized by today’s AI tools, and how they’re changing the way software gets built.

We also discuss:

The “interview anti-loop” at Google and the problems with interviews
An inside look at how Amazon operated in the early days before microservices
What Steve liked about working at Grab
Reflecting on the Google platforms rant and why Steve thinks Google is still terrible at building platforms
Why Steve came out of retirement
The emerging role of the “AI Fixer” in engineering teams
How AI-assisted coding is deceptively simple, but extremely difficult to steer
Steve’s advice for using AI coding tools and overcoming common challenges
Predictions about the future of developer productivity
A case for AI creating a real meritocracy
And much more!

Interesting quotes from the episode

Two interesting thoughts from this conversation with Steve:

Google would not have hired 60% of its own people

Steve (11:13): “When I was at Google, I was on their hiring committee, which is a “double blind”. They don't see the candidates, they don't know the interviewers. They're just reading feedback packets, and the interviewers don't bias each other.
One day they did an experiment with us, because we were the ones that ultimately decided to make that [hiring] decision about, the thumbs up, thumbs down type thing.
Google has a separate committee that looks at all the feedback. The recruiters did an exercise with us where they presented a bunch of packets. They just said, these were just a bunch of candidates, we're going to go and do the process on them.
Went through and we evaluated 'em all and decided we were going to not hire 60% of them. You figured this one out yet?”
Gergely: “No, not yet.”
Steve: “We were reviewing our own packets, so we voted not to hire 60% of ourselves. And it was a very sobering realization! The next week or two was the best time to apply to Google. We were just like ‘come on through’. I mean, it was nuts!”

Working with AI tools is hard, and great developers will thrive

Gergely (01:07:10): “These AI agents can write a lot of code. And I'm wondering — is it good code? Is it the code that you actually want?
Steve: Nobody's born knowing how to do it. It's completely new to humanity to have this sort of human but non-human, distinctly different helpers. And the best advice that I can possibly give you is to give them the tiniest task, the most molecularly tiny segmented task you can give them. And if you can find a way to make it smaller, do that at a time. Keep it real careful, track with them on what they're working on at all times, and then own every line of code that they'll ultimately commit.
You cannot trust anything. And that means multiple safeguards and guardrails and sentries and security and practices. And you have to train yourself to say the right things, do the right things, and look for the right things. And it is not easy.
It has reinforced my belief that people who are really good developers are going to thrive in this new world because it takes all of your skills to keep these things on the rails.