I’m lucky enough to have a job where I sit at the intersection of helping customers solve challenges around the most transformative technology we’ve seen since the Industrial Revolution and doing it for a company who is helping to lead the charge. I get to talk to customers about how to use Generative AI and I work for Google Cloud. To be fair, it’s a pretty sweet gig.

If you’ve ever worked with me in the past, you know I like to focus on fundamental knowledge and principles. Unfortunately, that’s not always the easiest thing to do when you’re working with a technology that is evolving as rapidly as Generative AI. Ideas that seem absolutely essential are outdated by the time they’re publicly available.

Even worse, it’s 10x as confusing for my customers. I live and breathe this stuff all day every day. For them it’s a component of their professional life, not the long pole (or at least they don’t know it is yet). It’s almost impossible to separate the signal from the noise for me. For them, it’s a hopeless chore.

Out of all that noise, the single most annoying and potentially dangerous talking point I hear is around the idea of ‘AI is writing X% of our code’. It’s the first question to large enterprise CEOs. I get it. But there is NO WAY to properly express the amount of effort it takes to get to the first 1%, much less the 25% or 46% or thousands of developer-years saved that you hear thrown around.

How do I know? I get to watch Google Engineering working on their harness to do this every single work day. It’s stunning. It’s inspiring. It’s also incredibly difficult. There is no way that much detail makes it to the CEO’s briefing. So let’s dig into just a little (with what I can share) about what it actually takes to get to that first 1% and beyond.

  1. Be Serious Google has spent years focused on bring traditional AI and Machine Learning to bear on the problem of software development. Engineering teams are expected to use these tools from day one.

    If you’re not serious about building quality software, the hurdles you get to clear are a lot taller. Example:

    I’ve been working with a customer for several months who is conducting a seemingly eternal bakeoff between my product (Gemini Code Assist/Gemini CLI) and one (maybe two?) similar products from other vendors. They’re confused and confounded why their developer velocity isn’t increasing more and faster.

    By their own analysis, they break their build process 15-20 times a week. Their primary CI server is a Jenkins instance in a local datacenter that may well have witnessed the Vancouver Winter Olympics.

    They’re not serious about improving. They expect a magic button from an infomercial to cure their systemic ills.

  2. Be Dedicated This is what I get to see most often. There are countless channels inside Google dedicated to cross-team collaboration on how to use these tools. What is working. What isn’t. Product PMs are in them all gathering requirements and feeding them back to the engineering teams. In my 5 years at Google, I truly believe this sort of naked collaboration is what allows Google to move as fast as it does.

    This isn’t a “6 week blast” or a collection of hackathons or a ‘series of sprints’. We’re talking about fundamentally changing how software is created, validated, and shipped. CI workflows change (a LOT). Security procedures change (a LOT A LOT). The increase is amazing. But you have to want it and you have to work for it. In this Olympic season, that sounds a lot like every inspirational clip that talks about our athletes in Milan and the surrounding countryside.

  3. Know Yourself This is a topic that I’m going to have to dedicate a whole post to someday. But there are times when you’re a consumer of a technology and there are times when you are a creator of a technology. Understanding which you are is critical. Example:

    A customer just last week, who is barely scratching the surface of using generative AI technology to create applications spent 30 minutes asking me about whether or not they should be fine-tuning their own model. One day? Probably. They’re in a data-heavy and relatively rare line of business. But they’re still unsure about any number of security patterns and their developers haven’t bought in. They’re not even consumers yet. They certainly should not be creators.

  4. Be Ready This is probably the most important, and equally the easiest and hardest simultaneously. We’re IT Professionals. We have procedures, policies, and precedents, whether we like them or not. Procurement teams tell us what we can buy and for how much. We have evaluations and RFPs and all sorts of things to help raise the confidence in what we’re using to solve our customer’s problems.

    We’re not getting rid of it. But we’re certainly throwing it into an MC Escher drawing and wondering what happens. This technology evolves WEEKLY. Sometimes DAILY. You’re not buying a database. You’re integrating the most transformative tool our industry have ever seen. It’s noisy and disruptive and directions are going to change all the time. You’ve got to figure out how to be OK with that.

So What?

I tell customers all the time that all of these things out there. Gemini CLI, Code Assist, Claude Code, Cursor, Antigravity, Clawdbot, whatever you want to think of; it’s just chat with context bolted on to it in different ways. The way that context is managed and introduced is how you shape your agentic experience. When you’re talking about a single developer, that’s great.

But the thing that makes me annoyed is the “Google generated 25% of code by AI” stuff. That’s not a single harness. That’s the system dedication to building tooling and expertise to make that amazing statistic possible. That doesn’t test well with the marketing team. But it’s the reality.

Measure The Harness, Not The Code

If you are a leader looking at these numbers and demanding 30% of your codebase be AI-generated by Q4, you’re measuring the exhaust, not the engine.

  • The question isn’t “How much code can the AI write?”
  • The question is “How much context can our system reliably provide?”
  • The question is “How dedicated am I to making this change?”
  • The question is “How ready am I to throw the company into an MC Escher drawing?”

Building the harness—the tests, the context providers, the guardrails—is the actual work. If you build a great harness, the 30% figure will happen naturally. If you mandate the 30% without the harness, you’re just going to get 30% more technical debt, 100% faster.

Don’t let the line count fool you. Focus on the engineering that makes the line count possible.