Before we start urging our developer “hens” to lay more golden eggs with AI, let’s examine a statement from Google’s recent Q3 earnings call: 25% of new code at Google is now written by AI. (ref: https://www.businessinsider.in/tech/news/google-ceo-says-more-than-a-quarter-of-the-companys-new-code-is-created-by-ai/articleshow/114752080.cms)

This news is everywhere, and understandably so. The way it’s worded seems designed to set a new baseline in AI assisted development, especially as Google emphasizes its leadership in AI. It’s worth examining what this truly implies beyond the headlines. After all, earnings calls are crafted with precision, especially when addressing such a high-stakes innovation area.

Here is what was said:

“More than a quarter of all new code at Google is generated by AI, then reviewed and accepted by engineers.”

Depending on how we choose to interpret it, this could suggest one of two things:

1. If we take the quote at face value, one could say Google developers are 25% more productive with AI.
   But an earnings call, with its enormous visibility and focus on investors, is no place for casual remarks. When a company like Google, once undisputed in AI, now faces competition from the likes of OpenAI, every word is intentional, meant to reaffirm their leadership.
   It’s highly unlikely this was a casual or overly simplified claim. Instead, let’s focus on the phrasing and think about its implications more deeply.
2. The term “new code” is key: If we focus on the wording, it implies that AI is creating over 25% of Google’s new code—not modifications to the existing, not refactoring, but new code—is generated. And then it was reviewed and accepted.

A “review” here is more like a “peer review”. Let’s list down the typical steps in a peer review that the human peer does: read, understand, compile, verify, refactor, extract common code, modify or implement review comments, and finally commit with an appropriate message.

Besides, Google is not the first to claim this. For example, Amazon AWS Q co-pilot has similar wording, “25% Faster initial development,” on their website, here: https://aws.amazon.com/q/developer/.

But even here, we are only talking about writing code, which is only the last step in a developer’s tasks; all the steps before writing code are left out. It is like the story of the doctor who fixes a patient’s shoulder with a simple tap of a rubber hammer. The patient questions the fees, arguing ‘it was just a tap’, and the doctor replies, “The tap is $2. Knowing where to tap is $998.” As claimed by Google, the AI does 25% of tapping the hammer. The quote specifically excludes the depth and breadth of everything else that goes into tapping the hammer.

Let me emphasize: this is not a critique of AI co-pilots themselves. My team and I are already heavily reliant on them, just as we are on our IDEs. They absolve us from the need to the syntax, nitty-gritty of the language and frameworks we use. There is still a large gap in their integration with the IDEs, and the mileage of their usefulness varies with language, frameworks, and the type of task we are attempting. So far, we love Cursor but are unhappy about having to move away from Intellij IDEA.

And no, Google’s Gemini Code Assist is not that well integrated into the leading IDE; even when it is Google’s official IDE for Android; neither is the integration as versatile as Cursor’s tab, nor are code suggestions as good in comparison with Claude or Cursor’s own AI. Which is what drove me to write this post.

The takeaway? Today’s co-pilot AIs play a substantial role in code generation, but there’s a significant gap between generating snippets and truly understanding the full scope of development. The “25%” metric may highlight one piece of the puzzle, but it leaves out critical aspects of a developer’s work—designing, problem-solving, and adapting solutions to complex, real-world needs—and doesn’t fully reflect overall developer productivity.