> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/pt-br/2026/w21-the-inflection-point-of-software-engineering.md).

# W21-O ponto de inflexão da engenharia de software

Na semana passada, assisti à palestra [Software engineering at the tipping point](https://io.google/2026/explore/workshop-2), de Adam Bender, engenheiro do Google, no Google I/O 2026. Ela aborda o impacto da IA sobre a engenharia de software e os limites que o ecossistema existente encontrará quando a geração de código ficar dez vezes mais rápida, ou ainda mais.

A palestra me fez lembrar de [Engenharia de software no Google](https://abseil.io/resources/swe-book/html/toc.html), conhecido no setor como o livro do flamingo. Ele reúne as principais lições de mais de vinte anos de engenharia de software no Google: monorepo, desenvolvimento baseado no tronco principal, mudanças em larga escala, revisão de código, sistemas de testes e cultura de engenharia. Antes, eu via essas práticas sobretudo como referências de grandes empresas. Hoje percebo que o livro trata de como o software continua evoluindo no tempo e em escala, e não de uma ferramenta específica.

Essa é a maior diferença entre engenharia de software e programação. Programar é escrever o código e resolver o problema imediato. A engenharia de software pergunta se, depois de alguns anos e da participação de centenas de pessoas, o sistema ainda poderá ser entendido, alterado, verificado e evoluir com segurança. Escrever o código é só o começo. O difícil é mantê-lo por muito tempo em um ecossistema controlável.

Muitas práticas do Google constroem, em essência, um destino compartilhado. O monorepo faz a empresa compartilhar os mesmos ativos de código. O desenvolvimento no tronco principal mantém todos alinhados à mesma versão. Mudanças em larga escala permitem corrigir automaticamente bibliotecas de base e problemas de segurança. Revisões de código e análises de incidentes sem culpabilização transformam experiência individual em capacidade organizacional. Por trás disso há um sistema sociotécnico, não uma simples veneração de ferramentas. As ferramentas resolvem problemas de escala; a cultura de engenharia resolve problemas de colaboração.

O ponto mais interessante da palestra de Bender é observar a IA dentro desse ecossistema, indo além de perguntar se ela sabe escrever código. Com a IA, os antigos problemas da engenharia de software não desapareceram; foram ampliados. Concordo muito com uma formulação da DORA: [a IA é um amplificador](https://dora.dev/capabilities/user-centric-focus/). Ela aumenta a intensidade, mas não determina a direção. Em uma equipe com testes, arquitetura e colaboração saudáveis, amplifica a eficiência. Se esses fundamentos são frágeis, amplifica a desordem.

Antes, uma pessoa escrevia dezenas ou centenas de linhas por dia, e muitos problemas apareciam devagar. No futuro, vários agentes alterarão o código ao mesmo tempo, e a geração poderá ser dez ou cem vezes mais rápida. O sistema de engenharia chegará mais depressa ao seu limite. Com código barato, será mais fácil acumular código ruim, e o ativo rapidamente se tornará um passivo. Os sistemas de build e testes sofrerão mais pressão. Uma suíte que hoje termina de rodar poderá se tornar inviável com a expansão do código e das dependências. A revisão de código também enfrentará um gargalo de capacidade. Se especialistas humanos passarem o tempo todo sobrecarregados revisando as mudanças produzidas pela IA, será fácil serem forçados a baixar o padrão.

Pior ainda, sem restrições globais, vários agentes podem alterar o código uns dos outros. Um considera que deve refatorar de uma forma; outro desfaz a mudança. O resultado é uma espécie de “guerra civil de edição entre agentes”. Parece uma piada, mas não é impossível quando produzir código fica mais rápido e barato. Sem limites claros de abstração e mecanismos de feedback, a desordem também se automatiza em maior velocidade.

Por isso, a engenharia de software na era da IA não pode se concentrar apenas em “como fazer a IA escrever mais código”. Escrever código fica cada vez mais barato; o que é escasso são as restrições do sistema, a capacidade de validação e o julgamento arquitetural. Precisamos passar de cuidar de uma árvore a cuidar de uma floresta. Antes, observávamos uma função, um módulo ou uma revisão de código. No futuro, precisaremos olhar mais para os limites, os ciclos de feedback e a ordem de evolução de todo o ecossistema.

Vejo algumas direções para as quais a equipe deveria se preparar.

Primeiro, tokens e capacidade computacional de testes serão novos recursos de engenharia. Não devem ser tratados como um serviço de fundo ilimitado.

Segundo, a estratégia de validação precisa ser mais inteligente. Não pode depender apenas de testes completos indiscriminados e revisão humana.

Terceiro, os sistemas precisam de isolamento mais forte, para que código experimental de IA não contamine facilmente os fluxos centrais.

Quarto, as pessoas precisam recuperar a capacidade de compreender o sistema. O maior valor da IA não é só escrever código por nós, mas ajudar a entender sistemas complexos, gerar diagramas dinâmicos de arquitetura, explorar dependências e analisar efeitos de segunda ordem.

Isso se aproxima muito da engenharia AI-Ready que temos discutido. AI-Ready vai além de conectar algumas ferramentas ou escrever mais prompts. É preparar o sistema de engenharia existente para suportar uma forma de produção mais rápida, mais concorrente e mais incerta. Infraestrutura, padrões de código, testes, documentação, representação da arquitetura e mecanismos de revisão, coisas que antes pareciam “lentas”, se tornam ainda mais importantes na era da IA.

Os princípios da engenharia de software não mudaram. Mudaram o nível de produtividade e a pressão sobre o sistema. Quanto mais rápida a geração de código, mais necessário voltar aos fundamentos. A verdadeira vantagem competitiva de uma equipe talvez deixe de ser produzir mais código com IA e passe a ser projetar um ecossistema de engenharia em que a IA participe com segurança, validação contínua e evolução controlada.