Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Use AI Coding Assistants Without Losing Their Edge
Transcript
- Lucas: Luna, I want to talk about a topic that's been quietly stressing out a lot of engineers I know: using AI coding assistants without losing your edge. Luna: Oh, this is good. I've definitely seen the split—some engineers swear by Copilot, others refuse to touch it. And then there's this middle group that uses it but feels guilty. Lucas: Exactly. So last month I spent time with a staff engineer at Google who's been tracking how his team uses these tools. He shared something that stuck with me: he said the real danger isn't that AI writes bad code—it's that engineers stop reading code. Luna: That's the crux of it. You get a suggestion, you hit Tab without actually parsing what it does, and over weeks your ability to reason about code starts to dull. Lucas: Right. So let's get concrete. There's a metric this engineer tracks called the 'deletion rate'—how often do you delete or significantly modify an AI suggestion before accepting it. On his team, the senior engineers who maintain strong skills have a deletion rate above 40 percent. The juniors who are getting dependent? Under 10 percent. Luna: Wow. So the act of rejecting or editing the suggestion is actually what keeps you sharp. It's not about how much you use the tool—it's about how critically you engage with it. Lucas: Exactly. And that maps to something I heard from an engineer at Meta. He said his rule is: always read the diff. Even if the AI writes code that compiles and passes tests, you read every single line before you commit. Because if you can't explain what that line does, you shouldn't land it. Luna: That sounds obvious, but I bet most engineers don't do it. It's so easy to just glance and think 'looks right.' Lucas: And that's where the atrophy happens. So let's talk about the specific use cases where AI is genuinely helpful without being a crutch. The consensus from the senior engineers I talked to is: use it for boilerplate, use it for tests, use it for documentation. Do not use it for system design, and do not use it for debugging production issues cold. Luna: The system design one is interesting. Why not? Wouldn't AI propose reasonable architectures? Lucas: It can, but the problem is that system design is about trade-offs specific to your context—your latency requirements, your team's expertise, your existing infrastructure. AI gives you a generic answer. The staff engineer at Google told me a story about a junior dev who asked Copilot for a database schema, got a normalized design with foreign keys, and deployed it. It worked fine for two weeks. Then they had to add a new feature, and the schema was completely wrong for their access patterns. Luna: Because the AI didn't know they were doing event sourcing with high write volume. Lucas: Exactly. The junior dev didn't understand why the schema was the way it was. So they couldn't evolve it. That's the real cost—you lose the ability to adapt the codebase over time. Luna: So what's the alternative? How do you use AI for system design without becoming dependent? Lucas: The engineer I talked to suggests using AI as a 'second opinion'—you sketch your own design first, then ask the AI to critique it or propose alternatives. But you always lead with your own thinking. That way you stay in the driver's seat. Luna: That's a good framework. Let's pivot to the code review process. How do ai assisted PRs change the review dynamic? Lucas: This is where it gets nuanced. A senior engineer at Amazon told me that on his team, they've started asking a simple question in code review: 'Did you write this code or did the AI write it?' Not as a purity test—but because the review should be more thorough if it's ai generated. Luna: Because the AI doesn't understand the broader context. It might introduce subtle bugs that a human wouldn't. Lucas: Right. And the reviewer needs to compensate. So the standard on that team is: if the author discloses that a block was ai generated, the reviewer spends 50 percent more time on that section. They look for edge cases, security implications, consistency with the existing codebase. Luna: I love that. It treats AI like a junior engineer who needs more oversight, not a magic oracle. Lucas: Exactly. And that brings us to another practice: the 'five-second rule.' An engineer at Apple told me he never accepts an AI suggestion in under five seconds. He forces himself to read it, think about it, and then decide. It's a tiny habit, but it keeps the critical muscle engaged. Luna: That's a great low-effort hack. I also heard from a friend at Netflix that they have an unofficial policy: no ai generated code in production without a human-written test that covers the specific edge case the AI might miss. Lucas: That's smart. Let's talk about the negotiation angle—how do you get your team to adopt these practices without sounding like a Luddite? Luna: Yeah, because there's this pressure to use AI or be seen as outdated. How do you push back? Lucas: The approach that works is to frame it as quality, not resistance. You say: 'I want to use these tools, but I want to use them in a way that doesn't compromise our codebase's maintainability. Let's agree on some guidelines.' Most managers will respond to that. Luna: So you're not saying 'no' to AI—you're saying 'yes, with standards.' Lucas: Exactly. And the engineers who've been most successful at this are the ones who lead by example. They use AI visibly—they share prompts, they show how they review AI output—and they demonstrate that their own skills aren't declining. They're the ones who can still debug a production issue without AI, but they choose to use it for boilerplate. Luna: That's the key differentiator: can you still do the work without the tool? Because if you can't, you're not a senior engineer anymore. Lucas: Right. And that's the fear a lot of engineers have. So let's give listeners a concrete self-assessment they can do. Ask yourself: can I write this function from scratch without AI? Can I explain the architecture of the system I'm working on without referencing any code? Can I debug a test failure by reading the stack trace alone? Luna: If the answer to any of those is no, you've got a dependency problem. Time to start deleting more AI suggestions. Lucas: And maybe set some deliberate practice time. Block off an hour a week where you code without any AI assistance. Treat it like a workout for your problem-solving skills. Luna: That's a great takeaway. Alright, before we wrap up this part—I want to zoom out a bit. You mentioned that the best engineers use AI but don't depend on it. That requires a certain level of self-awareness that most people don't naturally have. Lucas: It does. And it's something that comes with deliberate reflection. If today's conversation gave you something usable, that's exactly why we do this show ad-free. We don't take sponsorship money, so we can talk about tools honestly without any vendor spin. If you value that independence, the best way to support it is at buy me a coffee dot com slash fexingo. That's all—no pressure, just a way to keep these conversations going. Luna: Yeah, I'm glad we can talk about AI assistants without some company's PR filter. It makes a difference. Lucas: Absolutely. So let's circle back to one more practical tip. I want to talk about how to negotiate with your manager to get AI tools approved for your team, especially at companies that are still skeptical. Luna: Yes, because not every FAANG team is on the same page. Some managers see AI tools as a security risk or a crutch. Lucas: The winning argument I've seen is: 'Let's run a two-week trial on a non-critical service. We'll measure velocity and code quality metrics, and we'll set explicit guardrails. If it hurts quality, we drop it.' That's hard to say no to. Luna: And what metrics do you propose? Lucas: Number of bugs filed, time to resolve production issues, and—key one—the deletion rate I mentioned earlier. If the team's deletion rate is under 20 percent, that's a red flag that they're accepting too much AI output uncritically. Luna: That's a clever way to turn a quality concern into a measurable threshold. Lucas: Exactly. And once you have data, you can refine the guidelines. Maybe you find that AI is great for writing unit tests but terrible for integration tests. That's actionable. Luna: So the overall theme of this episode is: use AI, but stay in control. Be the pilot, not the passenger. Lucas: Perfectly put. And if you're listening and you've been feeling that guilt or anxiety about using AI, hopefully this gives you a framework to engage with it more intentionally. The goal isn't to use less AI—it's to use it better. Luna: Great episode. I'm going to start tracking my own deletion rate tomorrow. Lucas: Do it. And let us know how it goes. That's all for this episode of The Tech Career Podcast. See you next time.