As the project manager for Google’s Developer Tools, Ryan Salva has the front row seat of how AI tools change coding. Previously, Github and Microsoft were responsible for tools such as Gemini Cli and Gemini Code Assist, tweaking developers into a new world of agent programming.
His team announced new third-party research on Tuesday, showing how developers are actually using AI tools and how much progress remains. I sat down with Salva and talked about his personal experiences with reports and AI coding tools.
This interview was compiled for length and clarity.
While Google conducts research on developer trends each year, this year’s report focuses on AI tools, particularly how agent developers are willing to get an approach to programming. Has there anything that surprised you with this study?
One really interesting finding was the median date developers began using AI tools. They discovered that it was April 2024. This is pretty nicely compatible with the Claude 3 coming out and the Gemini 2.5 coming out. This is really the dawn of reasoning or thinking models, and at the same time, tool calls have become much better.
To code a task, you may need to grapple as external information must be able to be utilized to resolve the problem. You may need to compile the code. If your code is compiled, it is recommended to run its unit test and its integration test. I think Tool Call is an important piece that gives the model the ability to self-correct as it moves.
How do you personally use AI coding tools?
TechCrunch Events
San Francisco
|
October 27th-29th, 2025
Most of my coding these days is for hobby projects and spends most of my time using command line-based tools. That includes the Gemini CLI. Next, there’s a bit of Claude code. And I’m really uneven around the IDE I’m using, as you don’t actually use terminal-based tools on its own. Use Zed. Use VS code. You are using a cursor. I use them all. Because I’m interested in seeing how the world works and how the industry is evolving.
In the professional aspect, product managers tend to live in documents, so the first thing to do is to help you write specifications and requirements documentation using AI.
I’m curious how it works. I’m building a Gemini CLI using Gemini Cli, but I don’t think it’s just going to run on its own.
Development tasks usually start as issues, but it may be a GitHub issue that someone dropped in the bug. Often, if I’m really honest, that’s a rather unspecified issue. Therefore, we use the Gemini CLI to create a more robust requirement document in Markdown. It usually creates something pretty technical, probably about 100 lines, but also results-driven specifications. Next, I use the Gemini CLI to write code based on its specifications and general preferences of the team documentation.
Throughout the engineering team, there are several different layers of rules and markdown documents consumed by the model, and you just need to lay out how you work. Here’s how to test: How to manage dependencies, etc. So when I write the code, it works from these documents as well.
And as the Gemini CLI is doing troubleshooting, I’ll have you update the requirements document saying “I fixed this step, I’m moving on to the next step now.” Each of them creates their own commits and pull requests in the repository, so you can rewind or undo them at any time.
I think maybe 70% to 80% of my job is that I work in a terminal in natural language and try to create requirements using the Gemini CLI. And allow Gemini CLI to write most of the code for me. But most of the time, I use the IDE as a place to read the code rather than writing it.
Do you think raw computer code has a future? Or do you just move everything to a terminal window?
For 30 years, IDE was where I went to do all of software development. I had an IDE, a browser, and a terminal window.
I think that’s still mostly true, but over time I think I’ll spend more time in line with my requirements and gradually reduce the amount of time spent in the IDE. And I think that the change may actually happen over a rather long period of time.
There is a lot of concern about what it means as a progression for software development. Ten years from now, we are no longer looking at the code, but what does that mean for developers? Are there still work for them?
I think your job as a developer looks like an architect. It will take large, complex problems and break them down into smaller, more resolvable tasks. To represent it in machine code, you need to think of it as a whole picture of what you are trying to generate, not an intermediate language.
Source link
