A IA é um amplificador, não uma direção.

Autor e fonte do artigo: InfoQ

A IA tornou sua escrita de código 10 vezes mais rápida, e daí? Mais código significa compilações mais longas, testes mais pesados, revisões de código mais congestionadas e um repositório de código que ninguém consegue entender. Software é dívida; quanto mais rápido você escreve, mais você deve.

O aviso do engenheiro de software sênior do Google, Adam Bender, é direto: o modo como você constrói software hoje não funcionará em uma velocidade 10 vezes maior. Mas os verdadeiros vencedores da era da IA não são as equipes que produzem mais, e sim aquelas com as bases mais sólidas. Porque a IA apenas amplifica, não define a direção.

Durante uma palestra principal na Google I/O 2026, Adam Bender levantou uma pergunta que a maioria ainda não teve tempo de considerar: quando a IA impulsionar a velocidade de produção de código além da capacidade dos processos de engenharia atuais, o que colapsará primeiro em nosso ecossistema de desenvolvedores? Ele unificou toda a palestra com um conceito que talvez você nunca tenha ouvido: ecologia de software, a disciplina que estuda de forma holística o ecossistema sócio-técnico da produção de software. Em outras palavras, você não deve apenas observar a tecnologia, mas também as pessoas, a cultura e as regras não escritas dentro das organizações. Com base no vídeo da palestra, o InfoQ organizou o conteúdo.

Os pontos principais são os seguintes:

• A IA não resolve automaticamente nenhum problema para você. Se sua prática for boa, ela amplifica-as. Mas se não for boa, ela apenas cria mais problemas.
• É legal que todos sejam construtores, até você ter que manter tudo o que todos construíram.
• As práticas de engenharia não são sagradas ou inalienáveis. As práticas mudam; os princípios é que são importantes.
• Como engenheiro de software na linha de frente, neste momento crítico, você está no centro da decisão sobre para onde a engenharia de software se dirigirá. Das ferramentas aos fluxos de trabalho, das práticas de engenharia à cultura de engenharia, se você conseguir enxergar o sistema em funcionamento, poderá encontrar alavancas.

O que é “sistema”?

O seu trabalho em 2026 é completamente diferente do que você imaginava em 2020. Se eu tentasse explicar ao meu eu de 2020 o que está acontecendo hoje, eu não acreditaria. As mudanças foram tantas que é um pouco esmagador. Não consigo prever o futuro, mas acredito que, se estudarmos cuidadosamente o ecossistema de software atual, algumas respostas estão mais próximas do que imaginamos.

Hoje vou falar com você sobre uma palavra: ecologia de software. Parece que eu inventei isso só para subir ao palco, mas não é — é um termo real. Antes de dar a definição, quero estabelecer algum contexto, vamos mergulhar um pouco no pensamento sistêmico.

Um sistema é um conjunto de elementos interconectados que operam segundo um conjunto de regras, formando um todo unificado. Parece abstrato, mas você já está familiarizado com sistemas. Por exemplo, um ar-condicionado: um termostato que conhece a temperatura desejada, um sistema de aquecimento, ventilação e ar-condicionado responsável por aquecer ou resfriar, um quarto, e quando a temperatura está adequada, o sinal é interrompido — isso é um sistema.

Se você for engenheiro de software, você lida diariamente com sistemas, projetando sistemas, construindo sistemas e operando sistemas, e nesse processo você provavelmente aprendeu uma coisa: tudo está conectado.

A seguir, temos o ecossistema, um sistema especial. A definição é um pouco longa, mas importante: um ecossistema é uma rede dinâmica de atores interdependentes que coevoluem com seu ambiente, caracterizada por comportamentos emergentes e autonomia descentralizada. Em termos simples, um ecossistema é complexo, com componentes profundamente interconectados, cada um com sua própria autonomia para tomar decisões e agir. E o ponto mais crucial: o ambiente faz parte do sistema — você não pode separá-los.

Um ecossistema também é um sistema complexo adaptativo que pode crescer, mudar e evoluir ao longo do tempo. Eles também possuem uma característica chamada propriedade emergente: algo que não pode ser visto observando-se qualquer componente individual, mas que surge apenas quando todo o sistema é montado como um todo. É exatamente essa mudança contínua, aprendizado contínuo e emergência que tornam extremamente difícil compreender o que realmente está acontecendo dentro de um ecossistema.

Quando se fala em ecossistema, provavelmente vem à mente montanhas, rios, canto de pássaros e flores perfumadas. Mas o ambiente interno de desenvolvedores também é um ecossistema: possui diversas ferramentas e serviços, pessoas com suas próprias ideias e necessidades, e restrições de negócios. E é um sistema especial: um sistema sócio-técnico, ou seja, um sistema composto por pessoas e tecnologia. Sistemas sócio-técnicos são extremamente complexos, pois você começa com todas essas tecnologias e depois introduz as pessoas nesse mix.

Você provavelmente já entrou em contato com a inteligência dos sistemas sociais técnicos sem perceber. Você conhece a Lei de Conway? A tecnologia construída por uma organização reflete sua estrutura de comunicação interna. Em termos simples, se você tem quatro equipes trabalhando no mesmo compilador, acabará com um compilador de quatro passos — é assim que as coisas funcionam. A observação central da Lei de Conway é que a maneira como construímos tecnologia é inseparável da estrutura da organização que a constrói; a organização molda o que acaba sendo criado.

Mas não é apenas a estrutura organizacional que afeta o ecossistema de desenvolvedores; os valores e a cultura também têm um impacto profundo. O ecossistema que você constrói é o que a organização incentiva; sua cultura de engenharia cria o ambiente ao redor do ecossistema de desenvolvedores. Uma vez que você compreende os sistemas sócio-técnicos, os verá em todos os cantos do desenvolvimento de software: arquitetura, cultura de análise de incidentes, revisão de código, políticas de segurança — estão em toda parte. O que construímos e a maneira como escolhemos construí-lo reflete o que valorizamos. Se fizermos isso com cuidado, podemos usar esse conhecimento para amplificar nossos valores e injetá-los no que construímos.

Agora posso te dar uma definição correta: ecologia de software é a disciplina que estuda de forma holística o ecossistema sócio-técnico de produção de software. Se o que foi dito antes parecia um pouco abstrato, não se preocupe, vamos agora a um caso real.

O ecossistema de desenvolvedores do Google

Eu menciono o Google não porque trabalhe lá e precise elogiá-lo, mas porque é o ecossistema de desenvolvedores que mais conheço. Meu objetivo não é dizer a vocês que devem copiar o Google — isso não seria benéfico para vocês. Vocês são empresas diferentes, em estágios distintos e enfrentam decisões de compromisso diferentes. Muitas das escolhas feitas pelo Google foram feitas em resposta às necessidades específicas que tínhamos ao construir nosso ecossistema naquela época.

Há alguns anos, escrevemos um livro, internamente chamado de "Livro do Flamingo". Metade do livro trata de controle de versão e testes, mas toda a primeira metade é dedicada à cultura de engenharia. Muitas pessoas perguntaram por que gastamos tantas páginas falando sobre cultura, porque se você não entender a cultura do Google, não conseguirá compreender por que fizemos aquelas escolhas técnicas — essas coisas estão interligadas.

O Google possui várias características culturais únicas. Somos profundamente orientados por engenharia, e engenheiros estão sempre presentes ao tomar decisões importantes; valorizamos extremamente a transparência, tornando todos os documentos e códigos acessíveis a todos, sempre que possível; incentivamos a ajuda mútua — de fato, qualquer pessoa que já tenha deixado o Google mencionará a generosidade dos colegas como o primeiro ponto que lhe vem à mente; tratamos a revisão de código como uma oportunidade de orientação, e não como uma correção de prova; valorizamos extremamente a padronização; acreditamos na melhoria contínua; promovemos análises de incidentes sem culpa; e acreditamos firmemente que sustentabilidade é mais importante do que heroísmo, e automação é preferível ao trabalho manual. Claro, nem sempre alcançamos todos esses ideais, mas esse é o rumo que buscamos culturalmente.

Em termos técnicos: um repositório monolítico, onde quase todo o código está em um único repositório; desenvolvimento baseado na mainline, com cada alteração integrada diretamente na branch principal; ao construir um arquivo binário, quase cada linha de código é compilada a partir da fonte; uma cadeia de ferramentas de construção unificada, usada por todos; uma plataforma global de automação de testes, onde todos os testes são executados em um único local, com bilhões de casos de teste por dia; um sinal global de "último verde", que me permite informar o status de qualquer build por meio de um site interno simples; um ambiente de computação unificado, tornando praticamente impossível o problema de "funciona na minha máquina"; frameworks de desenvolvedor altamente padronizados e um pequeno conjunto de linguagens de programação principais.

Essa mistura de cultura e tecnologia moldou o Google tal como é hoje; você não pode entender apenas metade e ignorar a outra.

Compartilhar o destino

Se eu tivesse que escolher um princípio que tem estado constantemente nos guiando, escolheria “Destino Compartilhado (Shared Fate)”. Ele descreve o grau de interconexão entre um ecossistema e seus componentes; em um ecossistema de alto destino compartilhado, um componente pode afetar todos os outros. No ecossistema de desenvolvedores, o destino compartilhado é tanto uma escolha técnica quanto uma escolha social. Você não pode alcançar o destino compartilhado apenas fazendo todos usarem a mesma tecnologia; você também precisa estabelecer um contrato social sobre como gerenciar essas tecnologias.

No Google, o destino compartilhado começa com um repositório de código único. Cada linha de código da empresa, com poucas exceções como Android e Chrome, está em um repositório compartilhado. Todo o código é enviado para a linha principal, sem ramificações, sem versões — tudo em um único lugar. Esse destino compartilhado nos permite aplicar um patch de segurança em um único arquivo e saber que, em uma semana, todas as aplicações da empresa estarão corrigidas. Corrigir dez linhas de código para reparar dez bilhões de linhas de software de aplicativos e sistemas é como ter superpoderes.

Mas compartilhar o mesmo destino nem sempre é algo bom; é uma escolha. Em alguns lugares, compartilhar o mesmo destino não é apropriado, como em ambientes de produção, onde nunca desejamos que um serviço derrube todos os outros ou que um cluster infecte toda uma região. Por isso, investimos muito esforço em evitar destinos compartilhados perigosos, aqueles que causam falhas em cascata. Compartilhar o mesmo destino é um compromisso; você deve encontrar o local correto para colocá-lo e garantir que ele funcione a seu favor.

Mudança em grande escala

Um dos atributos emergentes mais interessantes em nosso ambiente compartilhado é a mudança em larga escala. Observe isto: muito antes do surgimento da IA, as ferramentas internas do Google já permitiam que um desenvolvedor modificasse milhões de linhas de código — milhões de linhas que eles nunca leriam, nunca mais veriam e possivelmente não tinham nenhum conhecimento. Construímos ferramentas que tornam tudo isso automaticamente possível, e é assim hoje, e temos feito isso há pelo menos quinze anos.

Essa capacidade nos permite evoluir continuamente o repositório de código monolítico, atualizando linguagens e frameworks, evitando que o ambiente interno se torne rígido. Sem mudanças em larga escala, não seríamos o Google de hoje. Os colegas que desenvolvem essas ferramentas desempenham um trabalho de heróis anônimos, permitindo que a empresa avance na velocidade necessária.

Mas o ponto crucial é que você não pode realmente compreendê-lo se não entender os componentes culturais e técnicos que tornam mudanças em larga escala possíveis. O que você precisa? Uma cultura de testes generalizada, onde todos escrevem testes. Uma plataforma de testes unificada, para saber onde obter os resultados. Ferramentas de construção comuns, para que seu build produza o mesmo resultado que o meu. Bibliotecas padronizadas, para que, ao substituir componentes, você não precise pular de versão em versão tentando descobrir qual funciona para você e não para mim. Revisão de código padronizada e transparência no repositório de código, para que você saiba quais partes do código precisam ser modificadas. Mudanças em larga escala são a expressão final da filosofia do Google de “automação优于 trabalho manual”, e só são possíveis quando todo o ecossistema colabora. Você não pode apontar para uma única parte do ambiente de desenvolvimento e dizer: “é isso que causou isso” — é a conexão de todas as partes que é a causa.

Seu ecossistema, seus equilíbrios

Cada ecossistema de desenvolvedores possui essas propriedades emergentes. Elas geralmente são aquilo que faz você sentir que o lugar onde trabalha é único, pois são o resultado de uma série de escolhas que você fez.

O ecossistema de desenvolvedores do Google gerou um conjunto único de compromissos que atendem aos nossos objetivos tecnológicos e de negócios. Mas, como qualquer ecossistema, não pode se destacar em todas as tarefas. Optamos por otimizar escala extrema, segurança e desempenho, mesmo que isso signifique, às vezes, sacrificar a produtividade dos desenvolvedores — estamos dispostos a fazer esse compromisso. Um ecossistema de uma startup de cinco pessoas seria completamente diferente, com velocidade e agilidade sendo os fatores mais importantes.

A maioria de vocês está em um ecossistema que varia entre cinco e duzentos mil pessoas. As trade-offs que vocês precisam fazer são muito relevantes, pois, ao examinar essas escolhas, você começa a entender os valores da organização: o que ela realmente valoriza, não apenas o que diz valorizar, mas o que as decisões reais revelam. Quando você compreende esses valores, pode começar a moldar a transformação que está em curso.

Momento de alavancagem 10x: Cada nó está sob pressão

É hora de falar sobre o elefante na sala que come tokens: como é um ecossistema de desenvolvedores com IA em primeiro lugar?

Claro, construir um ecossistema totalmente novo do zero seria ideal, mas ninguém tem esse luxo. Vocês precisam continuar entregando software enquanto substituem quase cada componente. A empresa espera que você continue criando valor, ao mesmo tempo em que garante que nada dê errado.

Então, faça-se uma pergunta: quanto você sabe sobre o ecossistema de desenvolvedores da sua empresa hoje? Você consegue desenhá-lo por completo? Você sabe onde estão todas as peças, não apenas as técnicas, mas também as sociais? Você consegue listar o que compõe seu ecossistema? Quanto os outros em sua organização sabem sobre ele? Quais são suas vantagens e desvantagens? Onde estão os gargalos? Onde há restrições e onde há liberdade? Quais opções você tem? Que propriedades emergentes você já observou? Talvez o mais importante: se seu ecossistema precisar, de repente, processar de 10 a 15 vezes mais código nos próximos dezoito meses, você sabe o que entrará em colapso primeiro?

Cada ecossistema de desenvolvedores na Terra está passando por uma transformação radical — talvez ainda não tenha chegado a todos os seus cantos, mas está a caminho, e cada ecossistema de desenvolvedores terá de enfrentar este momento de 10x. É uma época incrível, mas também bastante confusa. Todos os compromissos que evoluímos intencionalmente nos últimos vinte e cinco anos serão reequilibrados.

Gerar código 10 vezes mais rápido e desenvolver engenharia 10 vezes mais rápido são duas coisas diferentes. No Google, costumamos dizer que engenharia é programação integrada ao longo do tempo. Mas o problema é que estamos acelerando drasticamente a parte de programação, fazendo a máquina de código funcionar mais rápido. Portanto, precisamos encontrar maneiras de realizar engenharia de forma eficaz em torno dessa máquina de código, para realmente entregar resultados aos clientes. Ninguém sabe até onde esse aumento de produtividade pode levar, mas uma coisa é certa: estamos subindo a partir daqui.

O problema é que a maneira como construímos e entregamos software hoje não funciona em uma velocidade 10 ou 100 vezes maior; algo precisa mudar.

Vamos começar analisando uma versão simplificada do ecossistema de desenvolvedores. Em um mundo onde a atividade aumentou dez vezes, o que precisa mudar?

Código armazenado

Escreva o código-fonte. Se todos escrevessem código muito mais rápido, haveria muito mais código, e isso não é algo bom. Jeff Atwood disse que software é uma dívida. Portanto, 10 vezes mais código, 10 vezes mais dívida. E você não pode simplesmente dar a cada pessoa um monte de tokens e dizer “boa sorte”. Espero que você invista apenas após o treinamento: você sabe onde estão seus documentos de práticas de engenharia? Sabe como evoluí-los? Depois disso, considere.

Construir sistemas. Mais código, sistemas maiores significam tempos de compilação mais longos. Tenho certeza de que ninguém na sua empresa atualmente se queixa da compilação lenta. Mas adivinha só, eles vão ficar ainda mais lentos. E se o agente estiver impulsionando uma grande quantidade de trabalho, o número de compilações também está disparando. Compilar não é gratuito, nem em tempo nem em recursos de computação. Você talvez nunca tenha percebido quanto tempo gasta compilando, mas em uma escala 10 vezes maior, você certamente vai notar.

Design de código. Você possui habilidades adequadas em agentes para incentivar o desacoplamento? Existe um framework de servidor adequado para garantir a combinação rápida e segura de diversas capacidades? Você sabe quantos métodos de implantação de aplicações web existem na sua empresa? Quantos frameworks de servidor diferentes estão em execução? Como você gerencia a reutilização de componentes do código escrito por agentes? Talvez você esteja apostando que isso não é importante. Mas se os agentes produzirem código fácil de escrever, mas difícil de manter, não fique surpreso — esse é o nível atual de referência. Agentes são bons em escrever código, mas nem sempre pensam no longo prazo. Esse código, tenho certeza, não será facilmente refatorado. Não importa, resolveremos isso no futuro. Mas o fato é que os agentes estão realizando uma grande quantidade de trabalho para nós, e precisamos encontrar diariamente maneiras mais eficientes de aplicar essas capacidades.

Em algum momento, esses trabalhos baseados em agentes podem tornar seus arquivos binários tão grandes que não conseguem mais ser compilados. Ou tão grandes que não conseguem mais ser enviados para o celular. Você já se perguntou: qual é o maior arquivo binário que você pode compilar? Não sei a resposta, mas sei que, na Google, estamos atingindo os limites, e em alguns lugares os arquivos binários já são tão grandes que não conseguem mais ser compilados. Acredito que vamos resolver isso. Mas o fato é que a escala traz muitas consequências em cadeia; os efeitos da escala estão em toda parte.

Talvez você esteja na pilha de microserviços e pense: “Meus serviços são todos pequenos, por que me preocupar?” Mas tenho uma pergunta: 10 vezes o tráfego de rede, 10 vezes o número de serviços, 10 vezes a quantidade de comunicação — você está preparado? Ninguém pode sair ileso; os efeitos da escala estão em toda parte.

Revisão de código. Suponha que você não consiga compilar confiavelmente todo esse código; como seria seu processo de revisão de código? Todos estão preocupados com a revisão de código, e com razão. Estamos colocando uma enorme pressão sobre esse processo profundamente humano, e em muitos casos ele está se tornando um gargalo — e as pessoas não gostam de ser gargalos. Quando você exerce pressão sobre elas, seu comportamento se torna estranho. Dez vezes mais código significa ou dez vezes alterações maiores, ou dez vezes mais alterações. Seu líder técnico consegue manter a velocidade de revisão necessária? A maioria dos líderes técnicos nem consegue revisar o código de cinco desenvolvedores 10x em um único dia.

Então, para não se tornarem gargalos, eles começam a reorganizar os processos, procuram atalhos e garantem que ninguém fique bloqueado, pois ninguém quer ser o bloqueador. Talvez você possa resolver parte disso com IA, implantando IA para melhorar a revisão de código. Mas isso resolve apenas parte do problema, porque se os membros da sua equipe não escrevem mais código, o único momento em que interagem com o código é durante a revisão, e se a atenção durante a revisão for insuficiente, quem está acompanhando a evolução do repositório de código? Ninguém. Em pouco tempo, seu repositório de código se tornará uma bagunça que ninguém consegue entender.

Economia de token. Os tokens são caros — alguns de vocês já sabem disso. Em larga escala, o token é um custo real que você precisa considerar. O que aconteceria se todos na empresa começassem a usar tokens 10 ou 100 vezes mais? E se, por acidente, você gastar todo o orçamento mensal em um único dia? Se precisar decidir prioridades sobre onde gastar os tokens, você sabe para onde deve investir primeiro? Você tem visibilidade sobre para onde os tokens estão fluindo?

Nestes primeiros nós do sistema simples, já identificamos problemas. E é muito claro que haverá alguns efeitos de segunda ordem desafiadores.

Teste e controle de versão

Você já viu quantos recursos de computação sua infraestrutura de teste consome? Na Google, nunca fiquei satisfeito com a velocidade dos meus testes.

Cada alteração incorporada ao controle de versão deve ser testada. Mas, além disso, os agentes também gostam de executar testes, pois os testes lhes dizem se estão se saindo bem ou não. Assim, os agentes geram carga de trabalho adicional, e eu tenho mais coisas para fazer. Então, com 10 vezes mais commits mais todo o trabalho feito pelos agentes, quantos recursos de computação de teste estão sendo consumidos agora?

Na verdade, a situação pode ser ainda pior. Observamos no Google que, à medida que o código aumenta, o gráfico de dependências cresce de forma quadrática, não linear. Portanto, se o código aumentar 10 vezes, você pode precisar executar não 10 vezes, mas 100 ou até 1.000 vezes mais testes. Isso será um desafio muito interessante e, em algum momento, se tornará uma linha na sua tabela de orçamento. Se você não se preocupa agora com o custo dos recursos de computação para testes, isso me preocupa ainda mais, pois significa que você provavelmente não tem testes suficientes e esses agents estão YOLOando em seu código sem uma rede de segurança.

Supondo que os problemas de compilação e teste tenham sido resolvidos, agora vamos olhar para o sistema de controle de versão. A maioria dos sistemas de controle de versão mais populares não foi otimizada para desempenho; eles foram otimizados para consistência e ordenação. Esse é o seu trabalho principal: manter um registro completo, não correr rapidamente. Quantas vezes por minuto seu sistema de controle de versão consegue processar commits? Eu garanto que é muito menos do que você imagina. Ele não escala para a velocidade 10 vezes maior que você precisa. Quando foi a última vez que você pensou no desempenho do seu sistema de controle de versão? Se você não for desenvolvedor do Git, provavelmente nunca pensou nisso. Honestamente, chegar ao ponto de discutir o desempenho do controle de versão significa que algo já está seriamente fora do caminho certo. Estamos na camada mais básica da experiência do desenvolvedor, mas esse é exatamente o efeito das mudanças sistêmicas: elas encontram cada canto do seu sistema e dizem: “Ei, você está prestando atenção? Porque algo que você não previu está chegando.”

Para aqueles que pretendem resolver problemas de controle de versão usando muitos repositórios pequenos, pergunte a alguém que já gerenciou centenas ou milhares de repositórios pequenos — posso garantir que isso é um novo conjunto inteiro de desafios, e a IA não torna necessariamente esses problemas mais fáceis.

Lista de incidentes

Até agora, só examinamos os nós de capacidade relativamente fáceis de identificar, que envolvem multiplicar um número por 10 e perguntar se será bom ou ruim, além de muitos desafios inesperados.

Verifique a estratégia. Sua verificação hoje provavelmente consiste em muitos testes unitários e alguns testes de integração. Mas em um mundo com 10 vezes mais código e 10 vezes mais serviços, os testes de integração se tornarão a parte mais importante da estratégia de qualidade. Quantos de vocês estão satisfeitos com sua abordagem atual de testes de integração? Eu também não estou. Testes de integração são realmente difíceis; ainda não tenho as ferramentas que gostaria para fazer testes de integração da maneira que desejo.

Problema de conjunção booleana. Hoje, você está lançando um software e exige que todos os testes passem, todos os valores booleanos fiquem verdes, e apenas quando tudo estiver correto você lança. Isso é razoável. Mas o que acontece quando você tem um milhão de testes e a própria infraestrutura de teste subjacente tem problemas de confiabilidade ao executar um milhão de testes? Talvez se torne impossível exigir que todos os valores booleanos sejam verdadeiros para lançar o software. Você precisará de uma nova estratégia, provavelmente baseada em métodos estatísticos, para determinar quais testes corretos executar, pois não é possível executar todos os testes.

Mudança enorme. É empolgante poder refatorar completamente, trocar linguagens e frameworks. Mas você tem um fluxo de trabalho e um contrato social que permitam às pessoas gerenciar conflitos de merge de dezenas de milhares, centenas de milhares, milhões de linhas? Provavelmente não. Se todos na empresa pudessem fazer mudanças enormes, precisaríamos de novas estratégias de fluxo de trabalho.

Guerra de agents. Um agent fez uma alteração, outro agent veio correndo dizendo: “Não, não gosto, vou fazer uma alteração diferente.” Parece engraçado, até você perceber que está pagando taxas de token para ambos os lados.

Frequência de lançamento. Quantas vezes por dia você lança para os clientes? Diariamente? Isso é bom. Se não for, aqui está o problema: você acabará com mais de 10 vezes o software, e tudo isso precisa ser armazenado em algum lugar. Se você não estiver lançando diariamente, cada alteração se tornará muito maior. E meus amigos da SRE vão te dizer que alterações muito grandes são assustadoras. Não faça isso. Mas o código precisa ser implantado para gerar valor, então você pode tentar lançar com mais frequência — o que é ótimo, e os amigos da DORA ficarão satisfeitos. Porém, em algum ponto, os retornos diminuem; lançar uma vez por segundo provavelmente não trará muito valor adicional. O código ainda crescerá, e você precisará descobrir onde colocá-lo sem aumentar o risco.

API interno. Estive dizendo aos meus colegas que, de repente, todos os seus APIs se tornaram públicos. O agente não consultará você; ele encontrará o API e o chamará diretamente. Ele usará tudo o que conseguir acessar, garanto. Se você nunca protegeu suas interfaces internas e conjuntos de dados internos como faria com APIs públicas, o agente encontrará coisas que você não deseja que ele encontre.

Paradoxo de Jevons. Jevons disse que quanto mais barato e eficiente um recurso se torna, mais nós o usamos. A explosão dos tokens é um exemplo vivo disso. Estamos colocando-os em todos os lugares, o que está mudando a maneira como trabalhamos e como pensamos sobre o trabalho. Estamos atribuindo valor a trabalhos de produtividade anteriormente invisíveis — quais serão os efeitos sobre nosso comportamento? Ainda não sei.

Rollback. Você sabe por que o rollback é basicamente viável hoje? Porque você lança software um pouco mais devagar do que o tempo necessário para detectar problemas em seu ambiente de produção. Se você conseguisse lançar extremamente rápido — tão rápido que não conseguisse detectar nenhum problema — como seria sua postura de rollback? Cada rollback teria que lidar com múltiplas alterações conflitantes acumuladas sobrepostas. Portanto, apenas lançar mais rápido não é suficiente; você precisa considerar todo o sistema, incluindo o rollback, esse importante mecanismo de segurança. Por falar nisso, você precisa ter cuidado com onde coloca o motor de tokens. Se seu processo de rollback depender de um agente com capacidade suficiente, e alguém anteriormente esgotou o orçamento de tokens desse agente, impedindo agora seu rollback, provavelmente não é algo bom.

Todos são construtores. Você já deve ter pensado em criar uma alternativa para aquela ferramenta que não gosta na empresa. Agora, multiplique isso por cada pessoa e cada ferramenta na empresa. O que acontece com a estrutura social da empresa quando todos usam ferramentas completamente diferentes? Se você tiver sorte e possuir uma camada de dados unificada, com todos os dados entrando em um único lugar, tudo bem. Mas e se não tiver? Ser construtor é legal, até o momento em que você precisa manter tudo o que todos construíram.

Curso intensivo de liderança técnica. Leva tanto tempo para se tornar um líder técnico porque você precisa acumular intuição, julgamento e competência profissional para tomar decisões, pois, quando lidera uma equipe, seus erros têm um impacto muito maior do que quando atua sozinho. O que pode dar errado quando um recém-formado entra em um ambiente onde pode invocar cinquenta agentes, mas não possui nenhuma intuição ou julgamento? Como posso ensinar dez anos de experiência em seis meses? Eu não sei.

A atenção humana é o recurso mais valioso que temos. Hoje em dia, há muito ruído, tantos agentes e tantas coisas competindo por nossa atenção, e precisamos encontrar maneiras de gerenciá-lo. Anteriormente, nos beneficiávamos do fato de que nossa capacidade de causar problemas não excedia nossa capacidade de investir atenção, mas agora essa situação já não é mais verdadeira.

Isso soa como muito, porque em um sistema, tudo está interligado. Todos os desafios que mencionei anteriormente não podem ser resolvidos apenas observando um único nó do sistema; você precisa analisar todo o sistema.

Para se adaptar ao desenvolvimento baseado em agentes, todos nós precisamos começar a aprender a pensar de forma contínua e sistemática. Quando você pensa em sistemas, estas são as coisas que deve observar: como as coisas estão crescendo, os efeitos ao longo do tempo, a direção do fluxo de causalidade, quais nós estão se comunicando com todos os seus vizinhos, como surge o comportamento emergente e o que são essas coisas que aparecem sem explicação aparente. E os mecanismos de incentivo? Incluindo os sociais e os técnicos, capacidade, retroalimentações e gargalos — esses são os instrumentos da análise sistêmica.

Parece complexo, mas você realmente precisa apenas de duas perguntas: por quê (Why?), e e se (What if?)? Por que temos tão poucos testes de integração? E se tivéssemos mais testes de integração do que testes unitários? Por que usamos essas linguagens específicas? E se a IA escrevesse todo o código?

“Por que” é a broca que você usa para aprofundar-se no núcleo do sistema e entender como ele funciona. Todos vocês são muito bons em fazer perguntas “por que”, mas “e se” é a parte mais difícil. “E se” pode ser assustador, especialmente quando exige que você abandone práticas que antes acreditava serem muito bem projetadas. E se você não testar assim? E se não escrever testes de forma alguma? Não vá longe demais. Mas se você permitir que isso aconteça, “e se” também pode ser bastante empolgante.

A IA é um amplificador, não uma direção

A IA é um amplificador. Essa ideia veio dos meus amigos na DORA, cujo relatório de desenvolvimento de IA do ano passado descobriu uma relação entre as equipes que realmente entenderam as coisas: elas descobriram como fazer da IA um amplificador.

A IA pode te dar mais. Mais testes, mais documentação, mais código, mas também mais confusão. Ampliar é sobre amplitude, não sobre direção. A IA não se importa para onde essas coisas vão, ela simplesmente te dá mais. O que a DORA realmente descobriu é que equipes com base sólida conseguem direcionar o efeito de ampliação para caminhos úteis.

Isso levanta a questão: como você se sente sobre suas bases? Como é a cultura de tomada de decisão na sua empresa? O que você pode fazer para melhorá-la? E a estratégia técnica? Alguém está prestando atenção à produtividade dos desenvolvedores? Como está a colaboração entre as pessoas na organização hoje? E a postura de segurança? E a saúde do código, a higiene de lançamento, a confiabilidade? A IA não resolve nenhum problema por padrão. Se suas práticas forem boas, ela as amplificará. Mas se não forem boas, ela só criará mais problemas.

Mas mesmo com uma base sólida, estamos prestes a embarcar em uma verdadeira jornada. Suponho que, até 2030, nosso ecossistema de desenvolvedores atual parecerá tão distante quanto o de 2001 nos parece hoje. Em 2001, ainda lançávamos software em CD-ROM; em 2030, podemos estar tão distantes assim.

Enquanto vocês continuam a fortalecer suas bases, deixem-me compartilhar quatro coisas para refletirem ao longo do caminho.

Primeiro, capacidade da infraestrutura. Se você não sabe quantos recursos tem disponíveis, não pode implantar IA nem recursos de computação; precisa de um bom método para rastrear isso.

Em segundo lugar, valide a estratégia. Você não pode nem deve lançar software não validado. Mas as estratégias de validação mudam; é hora de esclarecer isso. Os testes de integração se tornarão sua arma mais importante, e você pode ainda não ter as ferramentas adequadas.

Terceiro, isolamento. Você receberá muitos códigos destinados a diferentes propósitos, alguns dos quais nunca antes foram usados com esse fim. Isso é aceitável, mas você não deseja que um código de protótipo divertido acabe sendo implantado em produção. Mantenha as coisas divertidas longe das coisas que geram receita.

Quarto, abstração. Construímos abstrações para evitar que desenvolvedores tomem más decisões, é por isso que temos bibliotecas e frameworks. Ninguém escreve um servidor web do zero. Permitir que agentes tomem muitas decisões leva ao mesmo resultado, então você precisa de boas abstrações para guiar os agentes. Não dê a eles más escolhas.

Você também deve aceitar uma coisa: práticas de engenharia não são sagradas. As práticas mudam; os princípios é que são importantes. Falar é fácil, fazer é difícil — se você nunca refletiu realmente sobre por que sua equipe testa software dessa maneira ou por que o processo de lançamento funciona assim, você não conseguirá evoluí-lo. Compreender os princípios é o que lhe dará força e confiança para atravessar esse momento de 10x.

Agora é uma época fascinante para engenheiros de software. Cada dimensão do nosso trabalho está sendo redefinida; precisamos mais do que nunca exercitar nossa criatividade; precisamos de habilidades para lidar com problemas como gerenciamento de contexto, economia de tokens e deriva de modelo; precisamos de criatividade; não podemos nos deixar levar pela tentação de otimizar tudo e devemos incentivar a exploração.

Uma questão que sempre me impede de dormir é: como manter o domínio intelectual sobre o código à medida que ele cresce? Domínio intelectual significa se os seres humanos conseguem raciocinar sobre o que está diante deles. Já perdemos essa guerra há pelo menos quinze anos; nossos maiores sistemas já ultrapassaram a escala que qualquer pessoa pode compreender. Se não acredita, faça um experimento: peça a cada pessoa da sua equipe para desenhar um diagrama da arquitetura do sistema e veja quantas versões diferentes você obterá.

Muitos dos nossos sistemas de software são muito frágeis; uma única linha de código ruim ou uma flag de configuração errada pode derrubar um sistema de milhões de linhas, e essa fragilidade obriga você a pensar duas vezes antes de fazer qualquer alteração. Mas tenho uma ideia muito empolgante sobre IA: um espaço arquitetônico continuamente atualizado e quase interativo, ao qual posso fazer perguntas. E se mudarmos essa capacidade para a costa leste? E se o crescimento de usuários aumentar repentinamente em 40%? Para qualquer sistema de tamanho médio hoje em dia, fazer isso é funcionalmente quase impossível — há muitas variáveis envolvidas. Mas a IA consegue compreender conjuntos de dados extremamente grandes, então acho que há algo aqui para ser explorado.

Gosto dessa pergunta porque não estamos apenas focados em fazer as máquinas de código girarem mais rápido; estamos nos perguntando: como aprofundar nossa compreensão do que já construímos?

As mudanças estão acontecendo muito rapidamente, mais rápido do que a maioria de vocês já experimentou. Uma das coisas mais importantes que vocês podem fazer agora é ajudar aqueles que estão lutando e oferecer apoio às pessoas que ainda não entenderam. Todos nós estamos avançando em ritmos diferentes e lidando com essa mudança de maneiras distintas. É fácil sentir que você está ficando para trás.

Engenheiros experientes, sejam mentores. Encontrem as pessoas que estão presas e ajudem-nas. Se você já compreendeu o fluxo de desenvolvimento de IA, compartilhe com os outros; isso não é um segredo valioso. Líderes técnicos, vocês precisam se envolver e ajudar a orientar a direção da engenharia de software em suas empresas. Se você se importa com a qualidade do software ou com o design de software, use sua voz para defendê-lo. São vocês, presentes aqui, quem precisa fazer isso — seu chefe provavelmente não fará.

Se imaginarmos o ecossistema de desenvolvedores como um ecossistema vivo, já nos acostumamos a observar atentamente cada folha em cada ramo, cuidando de cada árvore como se fosse uma forma de vida especial. Mas em breve, não seremos mais responsáveis por uma única árvore, mas por toda a floresta. E você não pode gerenciar uma floresta observando apenas uma árvore; precisa enxergar a floresta como um ecossistema inteiro.

As mudanças sistêmicas têm uma característica: ocorrem simultaneamente em todos os lugares e em todas as coisas, de forma tão vasta que parece impossível agarrar algo. Neste exato momento, você pode sentir que nada consegue lhe manter firme diante das ondas de transformação que parecem vir semanalmente. Mas, como acabamos de descobrir, em um sistema, tudo está interligado — pequenas ações podem gerar grandes consequências.

Por mais que pareça superficialmente, a transformação da IA não é um domínio exclusivo dos líderes corporativos. Como engenheiro de software na linha de frente, neste momento crítico, você está no centro da decisão sobre para onde a engenharia de software se dirigirá. Desde ferramentas até fluxos de trabalho, desde práticas de engenharia até cultura de engenharia, se você conseguir enxergar os sistemas em funcionamento, encontrará alavancas. Você tem mais autonomia do que imagina — use essa autonomia para criar o futuro da sua organização, da sua equipe e de você mesmo.