Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Use AI Pair Programming Tools
Transcript
- Lucas: So earlier this week I was talking to a staff engineer at Meta who works on their content delivery infrastructure, and he told me that his team has started using an internal fork of Cursor with custom fine-tuned models trained on their own codebase. Luna: Wait — an internal fork of Cursor? So they're not just using the off-the-shelf version? Lucas: Exactly. And that's actually the story I want to unpack today. Because the conversation around AI pair programming tools like GitHub Copilot and Cursor has shifted dramatically in the last year. It's no longer just 'is this thing useful for writing a quick function.' It's now 'how do we integrate this into our engineering culture without compromising security or code quality.' Luna: And I think the security angle is huge. I've heard from friends at Amazon that they have strict policies against feeding proprietary code into any public AI tool. Lucas: Yeah, that's standard across all the big tech companies. You cannot paste internal API logic into ChatGPT or even Copilot's public version if it's connected to the cloud. That's why we're seeing this trend of internal deployments. Microsoft has a version of Copilot that runs entirely inside Azure's tenant for enterprise customers. Google has Duet AI, which also respects data boundaries. Luna: But the interesting question for me is: does using these tools actually make engineers better? Or does it just make them faster at writing bad code faster? Lucas: That's the million-dollar question. And there's actually some data now. GitHub released a study earlier this year — I think it was in March — that looked at code quality across teams that adopted Copilot versus those that didn't. They measured things like code review rework rate, bug density, and test coverage. Luna: And what did they find? Lucas: The headline finding was that code churn — meaning lines changed within two weeks of being written — increased by about 15% for teams using Copilot. But here's the nuance: that increase was concentrated among junior engineers. Senior engineers actually saw a slight decrease in churn. Lucas: Right. But the study also found that overall productivity, measured by tasks completed per sprint, went up about 26% across the board. So the tradeoff is real. You get more output, but you need to invest more in review and mentoring. Luna: That actually mirrors what I've heard from a senior dev at Google. She said that the junior engineers on her team lean heavily on Copilot to generate boilerplate, but they often don't fully understand what the generated code is doing. So code reviews become longer because the senior has to explain the logic. Lucas: And that's the key insight. The tool is not a replacement for understanding. It's a force multiplier for people who already know what they're doing. The Meta staff engineer I mentioned — he uses Cursor to generate the scaffolding for a new service, but he always rewrites the critical path logic by hand. Luna: So he treats it like a really fast typist, not like a co-pilot in the literal sense. Lucas: Exactly. And that's the mental model I think every engineer should adopt. The AI is your intern. You still need to be the architect. One concrete example: his team had to write a new data pipeline that ingests logs from dozens of microservices. The boilerplate for parsing, validating, and routing each log type is tedious but formulaic. He used Cursor to generate the first draft for each service, then manually reviewed and adjusted the error handling and edge cases. Luna: How much time did that save? Lucas: He estimated about 40% reduction in time to first prototype. But the interesting thing is that the code that came out of Cursor had fewer bugs in the common paths — because the model is trained on millions of examples of similar patterns. The bugs were all in the edge cases, which is exactly where human expertise matters most. Luna: So the AI is good at the 80% case, but terrible at the long tail. That feels like a pattern we've seen before with other automation tools. Lucas: It's the same pattern, just amplified. And it's forcing engineering teams to rethink how they evaluate code quality. Some teams at Amazon are now using AI to generate unit tests as well. They feed the function to Copilot and say 'write tests for this.' But again, the tests are only as good as the prompt. Luna: I've seen that too. A friend at AWS told me they have an internal tool called 'Test Pilot' that generates integration tests from API specs. But then a human has to go in and add the negative test cases — what happens when the input is malformed, or the database is down. Lucas: And that's where the real engineering judgment comes in. So the skill that's becoming more valuable isn't the ability to type code quickly — it's the ability to define the problem clearly, write a good prompt, and then critically evaluate the output. Luna: Which actually changes what we look for when hiring. I've noticed that some interview loops at Google now include a 'prompt engineering' section where they give candidates a problem and ask them to craft a good prompt for an AI tool. Lucas: I've heard about that too. And it makes sense. If the job is increasingly about directing AI, then the ability to communicate clearly and decompose a problem is more important than memorizing syntax. But I think there's a risk that we overcorrect. Luna: What do you mean? Lucas: That we stop teaching fundamentals because 'the AI will handle it.' I've seen junior engineers who can't debug a null pointer exception without Copilot. That's dangerous. You need to understand the underlying system to know when the AI is giving you garbage. Luna: Yeah, it's like using a calculator without knowing arithmetic. You can get the right answer, but you won't catch the mistake if you hit the wrong button. Lucas: Exactly. And this is something that senior engineers I talk to are genuinely concerned about. There's a cultural shift happening in how code is written, and not all of it is positive. But I also think there's a huge opportunity for engineers who can bridge the gap — who understand both the AI tools and the underlying systems deeply. Luna: And that's where the career growth is. If you're a mid-level engineer and you become the person on your team who knows how to use these tools effectively, you can deliver way more value than your peers. Lucas: Absolutely. I actually wrote a piece last month about how engineers are using AI tools to accelerate their promo cycles. If you can ship features faster with fewer defects, that shows up in your performance review. But you have to be smart about it. Luna: And that's something we try to help with on this show — giving you the real, practical advice. It's conversations like these that keep the podcast going, and honestly, a big reason we can keep it ad-free and focused on substance is because of listeners who support us directly. Lucas: Yeah, it makes a real difference. A couple of dollars a month is genuinely what keeps these going — buy me a coffee dot com slash fexingo, if you've gotten something out of them. Luna: And it really does. Every bit helps us keep the conversation going without selling your attention to advertisers. So thank you. Lucas: Alright, back to the tools. So one thing I want to touch on is how the adoption of AI pair programming varies by company culture. At Google, the approach is more cautious — they have strict guidelines about not using external tools on internal code. But internally, they have their own models that are quite powerful. Luna: Yeah, Google's internal model, I think it's called 'Codey'? Or is that the public version? Lucas: Codey is the public-facing one for Google Cloud. But internally they have a much larger model that's fine-tuned on Google's massive monorepo. And it's interesting because the quality of completions is actually higher than Copilot for Google-specific frameworks, because the model understands the idioms. Luna: So the network effects are real. The more code you feed the model, the better it gets at your specific patterns. That's a moat for big tech companies that have huge codebases. Lucas: Exactly. And that's why I think the next frontier is custom fine-tuning. Not just using a general model, but training it on your team's specific codebase. The Meta team I mentioned is doing that, and I know some teams at Uber are experimenting with it too. Luna: But that requires a lot of infrastructure and expertise. Not every company can do that. Lucas: True. But the tools are getting easier. Cursor now lets you point it at a GitHub repo and it will index it locally. So even a small startup can get some of that benefit without building a custom model. The key is to invest time in setting up the context properly. Luna: And that brings us back to the skill of defining the problem. If you spend 30 minutes configuring your project's context — the key files, the architecture docs, the coding standards — the AI will produce much better results. Lucas: Right. It's like giving a new hire a good onboarding document versus just throwing them into the codebase. So the meta-skill is becoming 'how to set up an AI to be effective for your specific context.' And that's a skill that's going to pay dividends for years. Luna: I think that's a great note to end on. What do you think, Lucas — is there one thing you'd tell engineers listening right now to start doing today? Lucas: Yes. Start a small side project — it doesn't have to be work-related — and try to use an AI pair programming tool for every line of code. But force yourself to understand every line it generates. If you can't explain what it does, rewrite it until you can. That's how you build the skill without falling into the trap. Luna: Great advice. Thanks, Lucas. Lucas: Thanks, Luna. See you next time.