Ferramentas de desenvolvimento do Google lideram a integração da IA no desenvolvimento de software

Como gerente de projetos do Google para ferramentas de desenvolvedor, Ryan Salva tem uma visão única de como as ferramentas de IA estão transformando o desenvolvimento de software. Com experiência no GitHub e na Microsoft, ele agora lidera iniciativas como o Gemini CLI e o Gemini Code Assist, orientando os desenvolvedores no cenário em evolução da programação agêntica.

Sua equipe publicou recentemente uma pesquisa independente examinando como os desenvolvedores estão realmente usando as ferramentas de IA e quais melhorias ainda são necessárias. Conversei com Salva sobre o relatório e suas experiências pessoais com assistentes de codificação alimentados por IA.

Esta entrevista foi editada por questões de extensão e clareza.

O Google realiza uma pesquisa anual sobre tendências de desenvolvedores, mas o relatório deste ano enfatiza muito as ferramentas de IA, principalmente a disposição dos desenvolvedores em adotar abordagens agênticas em seus fluxos de trabalho. Alguma descoberta da pesquisa o surpreendeu?

Uma descoberta particularmente surpreendente foi a data média em que os desenvolvedores começaram a integrar ferramentas de IA em seu trabalho: abril de 2024. Isso se alinha muito bem com os lançamentos do Claude 3 e do Gemini 2.5, marcando o surgimento de modelos focados em raciocínio. Por volta do mesmo período, vimos avanços significativos nos recursos de chamada de ferramentas.

Para as tarefas de codificação, os modelos devem aproveitar efetivamente as informações externas para resolver problemas, seja pesquisando o código, compilando-o ou executando testes unitários e de integração. O avanço na chamada de ferramentas é crucial porque permite que os modelos se autocorrijam à medida que avançam em tarefas complexas.

Como você usa as ferramentas de codificação de IA em seu próprio trabalho?

Junte-se a mais de 10 mil líderes de tecnologia e de capital de risco para crescimento e conexões no Disrupt 2025

Netflix, Box, a16z, ElevenLabs, Wayve, Sequoia Capital, Elad Gil - apenas alguns dos mais de 250 líderes do setor que realizarão mais de 200 sessões repletas de insights para impulsionar o crescimento de startups e aprimorar sua vantagem competitiva. Não perca o 20º aniversário do TechCrunch e esta oportunidade de aprender com os principais inovadores em tecnologia. Reserve seu ingresso até 26 de setembro para economizar até US$ 668.

Junte-se a mais de 10 mil líderes de tecnologia e de capital de risco para crescimento e conexões no Disrupt 2025

Netflix, Box, a16z, ElevenLabs, Wayve, Sequoia Capital, Elad Gil - apenas alguns dos mais de 250 líderes do setor que realizarão mais de 200 sessões repletas de insights para impulsionar o crescimento de startups e aprimorar sua vantagem competitiva. Não perca o 20º aniversário do TechCrunch e esta oportunidade de aprender com os principais inovadores em tecnologia. Reserve seu ingresso até 26 de setembro para economizar até US$ 668.

Atualmente, a maior parte da minha codificação é para projetos pessoais, e trabalho principalmente com ferramentas de linha de comando, como o Gemini CLI. Também faço experiências com o Claude Code e o Codex. Como as ferramentas baseadas em terminal raramente são usadas isoladamente, eu alterno regularmente entre diferentes IDEs - Zed, VS Code, Cursor e Windsurf - para me manter atualizado com os desenvolvimentos do setor e entender como as várias ferramentas estão evoluindo.

Profissionalmente, os gerentes de produtos passam muito tempo trabalhando com documentos, portanto, meu primeiro passo é usar a IA para ajudar a redigir especificações e documentos de requisitos.

Estou curioso sobre o lado prático. Você está usando a Gemini CLI para ajudar a criar a própria Gemini CLI, mas presumo que o processo não seja totalmente automatizado.

Uma tarefa de desenvolvimento típica começa como um problema - geralmente um problema do GitHub relatando um bug. Para ser honesto, esses problemas são frequentemente mal especificados. Uso a CLI do Gemini para gerar um documento de requisitos mais completo em Markdown, geralmente produzindo cerca de 100 linhas de especificações técnicas orientadas por resultados. Em seguida, uso a CLI do Gemini para escrever o código real com base nessas especificações e nas diretrizes estabelecidas pela nossa equipe.

Nossa equipe de engenharia mantém várias camadas de regras e documentação Markdown que informam o modelo sobre nosso fluxo de trabalho - abrangendo protocolos de teste, gerenciamento de dependências e outros padrões. Ao gerar o código, o modelo faz referência a esses documentos para garantir a consistência.

À medida que o Gemini CLI lida com a solução de problemas, faço com que ele atualize o documento de requisitos para acompanhar o progresso: "Corrigida esta etapa, passando para a próxima", e assim por diante. Cada atualização se torna um commit e um pull request separados, facilitando a revisão ou a reversão das alterações conforme necessário.

Estimaria que 70 a 80% do meu trabalho envolve o uso de linguagem natural no terminal com o Gemini CLI - primeiro para refinar os requisitos e depois para gerar a maior parte do código. Reviso o resultado em qualquer IDE que esteja usando, mas, cada vez mais, confio no IDE mais para ler o código do que para escrevê-lo.

Você acha que a escrita de código tradicional persistirá ou mudaremos totalmente para fluxos de trabalho baseados em terminais?

Nos últimos trinta anos, o IDE tem sido o núcleo central do desenvolvimento de software, complementado pelo navegador e pelo terminal.

Acredito que essa estrutura permanecerá relevante por algum tempo, mas espero que passemos gradualmente mais tempo definindo requisitos, com menos tempo dedicado à codificação prática no IDE. É provável que essa transição se desenrole por um longo período.

Naturalmente, há uma preocupação sobre o que isso significa para o futuro das carreiras de desenvolvimento de software. Se não estivermos escrevendo código diretamente em uma década, o que isso significa para os desenvolvedores? Suas funções ainda existirão?

Vejo a função do desenvolvedor evoluindo para se assemelhar à de um arquiteto. Seu foco passará a ser a decomposição de problemas complexos em tarefas gerenciáveis e a consideração da visão mais ampla do que está sendo construído, em vez de ficar preso às especificidades das linguagens de programação e do código de máquina.