Google dirige las herramientas de desarrollo para integrar la IA en el desarrollo de software

Como director de proyectos de herramientas para desarrolladores de Google, Ryan Salva tiene un punto de vista único sobre cómo las herramientas de IA están transformando el desarrollo de software. Con experiencia en GitHub y Microsoft, ahora dirige iniciativas como Gemini CLI y Gemini Code Assist, que guían a los desarrolladores en el cambiante panorama de la programación agéntica.

Su equipo ha publicado recientemente un estudio independiente en el que se examina cómo utilizan los desarrolladores las herramientas de IA y qué mejoras son necesarias. He hablado con Salva sobre el informe y sus experiencias personales con los asistentes de programación basados en IA.

Esta entrevista ha sido editada en aras de la claridad.

Google realiza una encuesta anual sobre las tendencias de los desarrolladores, pero el informe de este año hace especial hincapié en las herramientas de IA, sobre todo en lo dispuestos que están los desarrolladores a adoptar enfoques agénticos en sus flujos de trabajo. ¿Le ha sorprendido algún resultado de la investigación?

Un descubrimiento especialmente sorprendente fue la fecha media en la que los desarrolladores empezaron a integrar herramientas de IA en su trabajo: Abril de 2024. Esta fecha coincide con los lanzamientos de Claude 3 y Gemini 2.5, que marcan la aparición de modelos centrados en el razonamiento. Alrededor del mismo periodo, observamos avances significativos en las capacidades de llamada a herramientas.

En las tareas de codificación, los modelos deben aprovechar eficazmente la información externa para resolver problemas, ya sea buscando en el código, compilándolo o ejecutando pruebas unitarias y de integración. El avance en la llamada a herramientas es crucial porque permite a los modelos autocorregirse a medida que avanzan en tareas complejas.

¿Cómo utiliza personalmente las herramientas de codificación de IA en su propio trabajo?

Únete a más de 10.000 líderes tecnológicos y de capital riesgo para crecer y establecer contactos en Disrupt 2025

Netflix, Box, a16z, ElevenLabs, Wayve, Sequoia Capital, Elad Gil... son sólo algunos de los más de 250 líderes del sector que ofrecerán más de 200 sesiones repletas de ideas para impulsar el crecimiento de las startups y mejorar su competitividad. No te pierdas el 20º aniversario de TechCrunch ni esta oportunidad de aprender de los mejores innovadores tecnológicos. Reserva tu entrada antes del 26 de septiembre y ahorra hasta 668 $.

Únete a más de 10.000 líderes tecnológicos y de capital riesgo para crecer y establecer contactos en Disrupt 2025.

Netflix, Box, a16z, ElevenLabs, Wayve, Sequoia Capital, Elad Gil... son sólo algunos de los más de 250 líderes del sector que ofrecerán más de 200 sesiones repletas de ideas para impulsar el crecimiento de las startups y mejorar su competitividad. No te pierdas el 20º aniversario de TechCrunch ni esta oportunidad de aprender de los mejores innovadores tecnológicos. Reserva tu entrada antes del 26 de septiembre y ahorra hasta 668 $.

La mayor parte de mi programación actual es para proyectos personales, y trabajo principalmente con herramientas de línea de comandos como Gemini CLI. También experimento con Claude Code y Codex. Dado que las herramientas basadas en terminales rara vez se utilizan de forma aislada, cambio regularmente entre diferentes IDEs -Zed, VS Code, Cursor y Windsurf- para mantenerme al día de los desarrollos de la industria y comprender cómo evolucionan las distintas herramientas.

Profesionalmente, los jefes de producto pasan mucho tiempo trabajando con documentos, por lo que mi primer paso suele ser utilizar la IA para ayudar a redactar especificaciones y documentos de requisitos.

Tengo curiosidad por el lado práctico. Utilizas Gemini CLI para ayudar a crear Gemini CLI, pero supongo que el proceso no está totalmente automatizado.

Una tarea de desarrollo típica comienza como una incidencia, a menudo una incidencia de GitHub en la que se informa de un error. Para ser honesto, estos son con frecuencia poco especificados. Utilizo Gemini CLI para generar un documento de requisitos más exhaustivo en Markdown, que normalmente produce unas 100 líneas de especificaciones técnicas orientadas a los resultados. A continuación, utilizo Gemini CLI para escribir el código real basándome en esas especificaciones y en las directrices establecidas por nuestro equipo.

Nuestro equipo de ingeniería mantiene varias capas de reglas y documentación Markdown que informan al modelo sobre nuestro flujo de trabajo, abarcando protocolos de pruebas, gestión de dependencias y otras normas. Al generar código, el modelo hace referencia a estos documentos para garantizar la coherencia.

A medida que Gemini CLI se encarga de la resolución de problemas, hago que actualice el documento de requisitos para realizar un seguimiento del progreso: "Arreglado este paso, paso al siguiente", y así sucesivamente. Cada actualización se convierte en un commit y un pull request independientes, lo que facilita la revisión o reversión de los cambios según sea necesario.

Calculo que entre el 70 y el 80% de mi trabajo consiste en utilizar el lenguaje natural en el terminal con Gemini CLI, primero para afinar los requisitos y después para generar la mayor parte del código. Reviso el resultado en cualquier IDE que esté utilizando, pero cada vez me apoyo más en el IDE para leer el código que para escribirlo.

¿Cree que persistirá la escritura de código tradicional o que pasaremos por completo a flujos de trabajo basados en terminales?

Durante los últimos treinta años, el IDE ha sido el eje central del desarrollo de software, complementado por el navegador y el terminal.

Creo que esa estructura seguirá siendo relevante durante algún tiempo, pero preveo que gradualmente dedicaremos más tiempo a definir requisitos y menos a la codificación práctica en el IDE. Es probable que esta transición se desarrolle a lo largo de un periodo prolongado.

Naturalmente, preocupa lo que esto significa para el futuro de las carreras de desarrollo de software. Si dentro de una década ya no escribimos código directamente, ¿qué significa eso para los desarrolladores? ¿Seguirán existiendo sus funciones?

Creo que el papel del desarrollador evolucionará hasta parecerse al de un arquitecto. Su atención se centrará en descomponer problemas complejos en tareas manejables y tener en cuenta la visión más amplia de lo que está construyendo, en lugar de estancarse en los detalles de los lenguajes de programación y el código máquina.