Google AI for Developers: What it actually looks like, one year into the Agentic Shift

A few weeks ago, Sigert Sipido, Managing Partner at Codana, flew to Google Cloud Next in Las Vegas. Codana is a custom software studio in the Cronos community, and like a growing number of teams here, they already build with Google AI every day. The question worth asking is a simple one: what is the real power of Google AI for developers right now? Sigert’s read on it, fresh off the event, has less to do with shiny demos and more to do with a shift in how serious software gets made.

From “can we?” to “you have to”

Sigert has watched Cloud Next for a few years. The tone used to be tentative. Can we apply AI? How would we even do it? This year the message was blunt. It’s here, it’s finished, you can build production-ready applications with it. But you have to make the shift to thinking fully agentic.

The clearest signal was a rename. Vertex AI, where a lot of teams took their first steps, is now the Gemini Enterprise Agent Platform. Sigert calls it the compiler move: everything is Gemini now. Underneath sits a four-layer model of Scale, Build, Govern, and Optimize, plus a long list of new tooling, with most of the attention on the agent platform, security, and observability.

That last part matters more than it sounds.

Trust and certainty, or putting the model in a harness

This is the heart of it. Anyone can open Gemini and talk to it. In a business context, that is exactly the problem. You can’t fully control what comes out, so you can’t yet trust it with anything that really matters. Sigert’s framing for this year is trust and certainty.

The mechanism is unglamorous, and that’s the point. You write skills and workflows, the more deterministic documents that steer an agent. You couple those to a rights system and a knowledge catalog. Every interaction produces runs, or traces. You visualize those traces, run evaluation on them, and build what Google calls golden routes. What you get is more deterministic behavior on top of a fundamentally non-deterministic thing. Sigert was clearly impressed by how well Google now visualizes those traces so you can actually evaluate them.

His image for this is a harness. “You put a model in a kind of harness,” he says. Not only inside your own software factory, but facing outward too, so a company actually dares to let a model handle real workflows in a UI that people find usable.

The maturity curve is obvious once you see it. First it was “here’s an agent, look what it can do.” Now it’s due diligence: what does an agent need to be reliable, so you can deploy it without it quietly wiping your production database one afternoon. Plenty of companies are sitting with exactly that worry.

How Google AI software development shows up in real work

Codana has always been agnostic. They work with Google, with Microsoft, with whatever the job needs, and they care about staying open and not married to one partner. So why lean into Google now? Because there’s so much change in the air that people need a single place to learn. “We’ve offered our team the Google ecosystem as a playground,” Sigert says, so everyone learns to work inside one system instead of stitching tools together ad hoc.

In practice that means Cloud Run and Cloud SQL for the agents and their data, a few buckets, and MCP. Google Cloud now exposes MCP connections across its platforms, so an SDLC can talk to BigQuery or other services in plain language and get a lot done almost automatically. Working inside one ecosystem, with the monitoring built in, beats hand-hosting a pile of agents on a brittle setup.

Internally, the real work is the SDLC itself. With around two dozen developers writing code, quality only holds if everyone pulls from the same skills. Codana uses a skill registry and shared guardrails, the markdown files and global rules that spell out which checks and unit tests have to happen, to keep code uniform on top of agents that are powerful but unpredictable. Without that, you end up with giant pull requests nobody reviews properly, and the gaps creep in.

This is turning into an offering. Codana wants to install SDLCs at clients, so each company has its own agents and its own software factory, with Codana staying on to keep it current. As their colleague Dirk put it, it’s a full SDLC environment with AI skills that Codana keeps improving, a mix of AI driven software development with oversight from experienced developers. Sigert’s one-liner is sharper: “We’re not only selling applications anymore. We’re also selling the engine that builds them.”

AI is not only for writing code

One of the bigger shifts is about analysis and design, not code. Custom work is complex by definition, because if it were obvious it would already exist. A 400-page analysis loses the client somewhere around page 30, and what you build could end up not quite matching what they pictured.

So Codana has worked with visual blueprints and clickable customer journeys for years. What’s different now is speed. Drop in an analysis from a year ago, add the brand pack, and you get a fully clickable prototype in no time. Sigert calls it the death of the wireframe. Wireframes were throwaway: expensive to produce, then discarded, never updated once feedback came in. Now the analysis, the visual, and the actual code can live in one place and stay in sync. A user gives feedback, you make a branch, generate a preview, and it’s done. You only pull in a designer for the genuinely complex screens.

The handoff is the satisfying bit. You ask the model to package everything you’ve reviewed into components, assets, and a README that explains what it built, then hand that to a coding agent with a single instruction: make a plan and a to-do list to build this. That plan and to-do list give the developer a solid base to work from. From there they steer the agent through the build into a finished product, reviewing and adjusting along the way rather than writing every line by hand.

Security you can’t do without AI anymore

Security scanning was part of Codana’s software lifecycle long before AI got powerful, with tools like Aikido and Sentry doing the work. What changed is the other side of the fence. Attackers have AI too, with big context windows that find gaps in old systems fast. You can’t defend against an AI-powered attacker without AI of your own. The process is the same as it always was. The tools doing the scanning are what make the difference now.

The human is still the point

The thread running underneath the whole conversation is this. All of this only works if people keep their critical eye. It’s easy to see clean output, pretty colours, and approve a pull request you would have questioned if you’d written it yourself. Sigert’s answer isn’t a new process. It’s a mindset. If you stay proud of your work, you don’t wave things through. The processes haven’t really changed. There’s just more output and more compute now, and that’s an advantage as long as you keep a human who cares in the loop.

That’s also the honest version of the Google AI for developers story. The platform is ready. The agents are capable. The teams getting value from it are the ones treating that capability as leverage for people who still own the quality, not as a reason to stop thinking.

What this means for you

If you lead a business, Google AI for developers has crossed from experiment to production. The question is no longer whether you can build with it, but whether your software is set up so an agent can work safely inside it. The companies seeing returns are putting trust and certainty in place first.

If you’re a developer getting started with Google AI, start where Codana did. Work inside one ecosystem, with a real SDLC and a shared set of skills. Get the harness right before you scale.