How Google’s dev tools manager makes AI coding work

As Google’s project manager for developer tools, Ryan Salva plays a pivotal role in witnessing the transformation of coding through AI tools. With a background at GitHub and Microsoft, he is currently leading innovations such as Gemini CLI and Gemini Code Assist, guiding developers into the era of agentic programming.

Recently, his team published new third-party research revealing insights on how developers engage with AI tools, and the journey ahead. I had the opportunity to sit down with Salva to discuss the findings of the report and his personal journey with AI coding tools.

This interview has been condensed for brevity and clarity.

Every year, Google conducts a survey on developer trends, but this year’s report significantly emphasizes AI tools and the trend toward agentic programming. Were there any surprising revelations from the research?

One key finding was the median date developers started integrating AI tools into their workflows—April 2024. This aligns well with the release of Claude 3 and Gemini 2.5, marking what seems to be the beginning of a new wave of reasoning models. During this period, our ability to call external tools dramatically improved.

For coding tasks, leveraging external information is crucial for effective problem-solving—be it through grepping data or compiling code. Once compiled, running unit tests and integration tests becomes essential. This improvement in tool-calling is fundamental, as it enables models to self-correct throughout the development process.

How are AI coding tools impacting your personal coding practices?

Most of my current coding endeavors revolve around hobby projects, heavily utilizing command line-based tools, with a focus on Gemini CLI. I dabble in a bit of Claude Code and Codex as well. It’s rare for me to use any terminal-based tool in isolation; I’m quite diverse in my choice of IDEs. I switch between Zed, VS Code, Cursor, and Windsurf, driven by a curiosity to understand how the landscape is evolving.

On the professional front, product managers typically work extensively with documents. I primarily use AI to assist in drafting specifications and requirements documents.

Can you elaborate on the process? You’re using Gemini CLI to develop Gemini CLI—how does that function?

Typically, a development task begins as an issue—often from GitHub—sometimes it’s vaguely defined. In such instances, I harness Gemini CLI to develop a more comprehensive specification document in Markdown format. This generally results in around 100 lines of detailed, outcome-focused descriptions. Following that, I utilize Gemini CLI to generate the necessary code based on those specifications and our team’s documentation preferences.

Within the engineering team, we have multiple layers of rules and Markdown documents that guide how we operate. This may include our testing methodology and dependency management practices, which the model references when it generates code.

As Gemini CLI addresses troubleshooting tasks, it updates my requirements document accordingly, stating, “I fixed this step; now I’m progressing to the next.” Each adjustment creates a new commit and pull request, allowing for easy tracking and rollback.

I’d estimate that about 70% to 80% of my work involves using the terminal with natural language to craft requirements via Gemini CLI, while allowing it to write the majority of the code for me. I then review this in whichever IDE I am using, but typically, I engage with the IDE more as a reading tool rather than a writing platform.

Do you envision a future where raw programming code becomes obsolete, or will we continue to utilize terminal environments?

For the last thirty years, the IDE has served as the primary environment for software development, alongside the browser and terminal. While that remains the case today, I foresee a gradual shift towards spending more time focusing on requirements, with our time in IDEs likely diminishing over the years ahead.

There seems to be a lot of apprehension surrounding this evolution in software development. If ten years hence, we find ourselves disengaged from raw coding, what implications does this have for developers? Will their roles remain relevant?

I believe the developer’s role will evolve to resemble that of an architect. The focus will shift toward tackling complex problems, breaking them down into manageable tasks, and maintaining a broader perspective on the outcomes we aim to achieve, rather than being mired in the intricacies of machine code and intermediate languages.