Ryan Salva, who leads Google’s developer tools projects, has a unique perspective on how artificial intelligence is transforming software development. With previous experience at Github and Microsoft, he now oversees products like Gemini CLI and Gemini Code Assist, guiding programmers toward the era of agentic programming.
On Tuesday, his team unveiled independent research that sheds light on how developers are currently adopting AI tools—and highlights the challenges that remain. I had a conversation with Salva to discuss the findings and his own journey with AI-powered coding solutions.
This conversation has been condensed and edited for clarity.
Google conducts an annual survey on developer trends, but this year’s edition zeroes in on AI tools and how open developers are to agentic programming. Did anything in the data catch you off guard?
A particularly notable insight was the median point when developers began using AI tools: April 2024. This lines up closely with the launches of Claude 3 and Gemini 2.5. It marks the beginning of the era for reasoning-based models, and around this period, our capabilities with tool-calling improved significantly.
To tackle programming problems, it’s essential to access outside information—sometimes searching with grep, compiling code, or running unit and integration tests. Tool-calling is what truly empowered these models to adjust and correct themselves as they progress.
How do you personally incorporate AI coding tools into your workflow?
These days, most of my programming is for personal projects, and I primarily use command-line tools, including Gemini CLI. I also occasionally use Claude Code and Codex. Terminal-based tools are rarely used in isolation, so I work across a variety of IDEs—Zed, VS Code, Cursor, Windsurf—because I’m curious about the evolution of the industry and how different environments function.
Professionally, as a product manager, much of my work revolves around documentation. My first use of AI is to draft specifications and requirements documents.
I’m interested in how that process unfolds. You’re using Gemini CLI to develop Gemini CLI, but I assume it doesn’t operate autonomously.
Typically, a development task begins as an issue—often a bug report on GitHub, which is frequently lacking in detail. I’ll use Gemini CLI to flesh out a comprehensive requirements document in Markdown, usually resulting in about 100 lines of technical, outcome-oriented specs. Next, I have Gemini CLI generate code based on those specs and the team’s documented preferences.
Within our engineering group, we maintain several layers of guidelines and Markdown files that the model references—covering our approaches to testing, dependency management, and more. So when code is generated, it’s informed by these documents as well.
As Gemini CLI works through debugging, I have it update the requirements document with notes like, “This step is fixed, moving to the next,” and so forth. Each of these steps results in a new commit and pull request, allowing me to revert changes if needed.
I estimate that about 70% to 80% of my workflow involves interacting with the terminal in natural language, using Gemini CLI to draft requirements, and then letting it handle most of the code writing. I review and read the code in whichever IDE I’m using at the time, but for the most part, the IDE serves as a code reader rather than a writing tool for me.
Do you foresee a continued need for raw code, or will everything shift to terminal-based workflows?
For the past thirty years, the IDE has been the central hub for software development, alongside the browser and terminal.
While that’s still generally true, I anticipate that over time, we’ll devote more attention to working on requirements, and the time spent in the IDE will gradually decrease. That transition, however, is likely to unfold over a considerable period.
There’s a lot of concern about what this shift means for the future of software development. If, a decade from now, we’re no longer directly interacting with code, what does that mean for developers? Will their roles still exist?
I believe the developer’s role will evolve to resemble that of an architect—focused on deconstructing large, complex challenges into manageable, solvable components. The emphasis will shift to understanding the broader objectives and outcomes, rather than the specific syntax needed to translate those ideas into machine code.
