Temos sido bombardeados com afirmações sobre o quanto a IA generativa melhora a produtividade dos desenvolvedores de software program: ela transforma programadores regulares em programadores 10x e programadores 10x em 100x. E ainda mais recentemente, fomos (um pouco menos, mas ainda assim) bombardeados com o outro lado da história: Relatórios METR que, apesar da crença dos desenvolvedores de software program de que a sua produtividade aumentou, o rendimento complete de ponta a ponta diminuiu com a assistência da IA. Também vimos indícios disso em relatório DORA do ano passadoque mostrou que a cadência de lançamento na verdade diminuiu ligeiramente quando a IA entrou em cena. O relatório deste ano inverte essa tendência.
Quero tirar algumas suposições primeiro:
- Eu não acredito em programadores 10x. Conheço pessoas que pensavam que eram programadores 10x, mas sua principal habilidade period convencer outros membros da equipe de que o resto da equipe period responsável por seus bugs. 2x, 3x? Isso é actual. Não somos todos iguais e nossas habilidades variam. Mas 10x? Não.
- Existem muitos problemas metodológicos com o relatório METR – eles foram amplamente discutidos. Não acredito que isso signifique que possamos ignorar o seu resultado; o rendimento ponta a ponta de um produto de software program é muito difícil de medir.
Como eu (e muitos outros) escrevemos, escrever código é apenas cerca de 20% do trabalho de um desenvolvedor de software program. Portanto, se você otimizar isso completamente – código seguro perfeito na primeira vez – você alcançará apenas uma aceleração de 20%. (Sim, eu sei, não está claro se a “depuração” está incluída nesses 20%. Omiti-la é um absurdo – mas se você assumir que a depuração adiciona outros 10% a 20% e reconhecer que isso gera muitos de seus próprios bugs, você estará de volta ao mesmo lugar.) Isso é uma consequência de Lei de Amdahlse você quiser um nome sofisticado, mas na verdade é apenas aritmética simples.
A lei de Amdahl torna-se muito mais interessante se olharmos para o outro lado do desempenho. Trabalhei em uma startup de computação de alto desempenho no closing da década de 1980 que fez exatamente isso: tentou otimizar 80% de um programa que não period facilmente vetorizável. E enquanto Computador multifluxo falhou em 1990, nossa arquitetura de palavras de instrução muito longas (VLIW) foi a base para muitos dos chips de alto desempenho que vieram depois: chips que podiam executar muitas instruções por ciclo, com fluxos de execução reordenados e previsão de ramificação (execução especulativa) para caminhos comumente usados.
Quero aplicar o mesmo tipo de pensamento ao desenvolvimento de software program na period da IA. A geração de código parece ser um fruto fácil de alcançar, embora as vozes dos céticos da IA estejam aumentando. Mas e os outros 80%? O que a IA pode fazer para otimizar o resto do trabalho? É aí que realmente reside a oportunidade.
Angie Jones falar no AI Codecon: codificação para o mundo agente adota exatamente essa abordagem. Angie observa que a geração de código não está mudando a rapidez com que entregamos porque ela abrange apenas uma parte do ciclo de vida de desenvolvimento de software program (SDLC), e não o todo. Esses “outros 80%” envolvem escrever documentação, lidar com solicitações pull (PRs) e o pipeline de integração contínua (CI). Além disso, ela percebe que a geração de código é um trabalho de uma pessoa (talvez duas, se vocês estiverem formando pares); codificação é essencialmente um trabalho solo. Fazer com que a IA ajude o restante do SDLC requer o envolvimento do restante da equipe. Nesse contexto, ela afirma a regra 1/9/90: 1% são líderes que farão experiências agressivas com IA e construirão novas ferramentas; 9% são pioneiros; e 90% são “esperar para ver”. Se a IA quiser acelerar os lançamentos, 90% precisarão adotá-la; se for apenas 1%, um PR aqui e ali será gerenciado mais rapidamente, mas não haverá mudanças substanciais.
Angie dá o próximo passo: ela passa o resto da palestra abordando algumas das ferramentas que ela e sua equipe criaram para tirar a IA do IDE e colocá-la no restante do processo. Não vou estragar a palestra dela, mas ela discute três estágios de preparação para a IA:
- Curioso em IA: o agente pode ser descoberto, pode responder perguntas, mas não pode modificar nada.
- Pronto para IA: A IA está começando a fazer contribuições, mas são apenas sugestões.
- Integrado com IA: A IA está totalmente conectada ao sistema, outro membro da equipe.
Essa progressão permite que os membros da equipe verifiquem a IA e gradualmente desenvolvam confiança – à medida que os próprios desenvolvedores de IA ganham confiança no que podem permitir que a IA faça.
As ideias de Angie nos levam até o fim? É disso que precisamos para ver aumentos significativos na velocidade de envio? É um começo muito bom, mas há outro problema ainda maior. Uma empresa não é apenas um conjunto de equipes de desenvolvimento de software program. Inclui vendas, advertising and marketing, finanças, manufatura, o resto de TI e muito mais. Há um velho ditado que diz que você não pode se mover mais rápido que a empresa. Acelere uma função, como o desenvolvimento de software program, sem acelerar o resto e você não terá realizado muita coisa. Um produto que o advertising and marketing não está pronto para vender ou que o grupo de vendas ainda não entende não ajuda.
Essa é a próxima pergunta que temos que responder. Ainda não aceleramos o desenvolvimento actual de software program de ponta a ponta, mas podemos. Podemos acelerar o resto da empresa? O relatório do METR afirmou que 95% dos produtos de IA falharam. Eles teorizaram que isso acontecia em parte porque a maioria dos projetos visava o atendimento ao cliente, mas o trabalho de back-end do escritório period mais receptivo à IA em sua forma atual. Isso é verdade – mas ainda há a questão do “resto”. Faz sentido usar a IA para gerar planos de negócios, gerenciar mudanças no fornecimento e assim por diante, se tudo o que ela fará é revelar o próximo gargalo?
Claro que sim. Esta pode ser a melhor forma de descobrir onde estão os gargalos: na prática, quando eles se tornam gargalos. Há uma razão para Donald Knuth disse que a otimização prematura é a raiz de todos os males — e isso não se aplica apenas ao desenvolvimento de software program. Se realmente quisermos ver melhorias na produtividade através da IA, temos de olhar para toda a empresa.