> 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/2025/w50-what-should-the-team-do-next-year-in-ai-coding.md).

# W50-O que a equipe deve fazer em programação com IA no próximo ano

Nesta semana, li [State of AI](https://openrouter.ai/state-of-ai), da a16z e da OpenRouter. O estudo empírico usa cerca de 100 trilhões de tokens reais da plataforma OpenRouter. Já no começo senti uma confusão temporal: a versão oficial do o1 saiu em 5 de dezembro de 2024, há exatamente um ano. A participação dos modelos de raciocínio no volume de tokens cresceu durante 2025 e recentemente passou da metade.

Se os modelos continuarem melhorando nos próximos anos — com avanços em multimodalidade, memória e agentes se espalhando —, o objetivo central da equipe não deveria ser apenas adotar algumas ferramentas e reunir prompts. Deveria ser construir uma base de engenharia AI-Ready, para que modelos melhores liberem cada vez mais nossa capacidade de entrega.

Para manter o trabalho nessa direção no longo prazo, há cinco áreas em que o investimento se acumula.

**1) Arquitetura**

Em um projeto que ninguém consegue explicar claramente, a IA também terá dificuldade. Além de consumir muitos tokens, pode ignorar dependências implícitas e causar regressões. O principal problema da arquitetura de frontend é misturar visão e lógica de negócio, entrelaçar lógica e efeitos colaterais e não separar o que muda do que permanece. Adotar MVVM ou MVC não resolve isso por si só.

O projeto deveria responder claramente qual é seu código central. Esse código contém toda a lógica de negócio e a evolução de estado. No ideal, consiste em funções puras, independentes de framework e ambiente, testáveis isoladamente e com entradas e saídas determinadas. O restante cuida de I/O de rede, efeitos colaterais e renderização da interface. Assim, a IA tem um ponto de apoio estável, e as mudanças ficam mais controláveis.

**2) Tornar o contexto explícito**

Sem a história, a IA também não entende por que certos hacks estranhos existem. Documentação e comentários já não servem apenas para preservar conhecimento: afetam diretamente a qualidade da geração de código.

Mais concretamente, informações de domínio, restrições de arquitetura, preferências de pilha tecnológica e padrões da equipe devem ser explícitos. É melhor registrá-los em formatos fáceis para a IA consumir, como ADRs, listas de restrições e itens “que não podem ser quebrados” no README. Uma cadeia de ferramentas adequada entrega esse contexto ao modelo.

**3) Antecipar as restrições**

Concordo muito com a ideia de detectar problemas mais cedo por compiladores e análise estática. Rust é uma referência de compilação rigorosa, mas a maioria dos cenários de frontend não exige Rust para evitar incidentes. O verdadeiro problema é não aproveitar plenamente as vantagens do TypeScript. Historicamente, permitimos um uso muito flexível de TS para acelerar sua adoção. Na prática, muitos projetos não habilitaram todas as restrições de tipos e compilação.

O modo strict é básico e inegociável. Precisamos proibir com firmeza tipos sem significado como any. Também são necessárias regras de lint personalizadas e unificadas. Regras próprias de ESLint podem impor limites de arquitetura e um estilo comum, como exigir Composition API ou proibir dependências entre camadas indevidas.

**4) Validação por programas**

Gerar código será cada vez mais barato. O caro será verificar se está correto. As verificações de baixo custo devem acontecer primeiro. Isso acompanha o pensamento de TDD e também reduz um antigo problema da sua adoção: o custo elevado.

Com uma boa arquitetura, identificamos facilmente o código central, e cobri-lo com testes unitários passa a ter ótimo custo-benefício. Frontend e backend colaboram por contratos; acrescentar Zod para validar schemas em runtime é necessário. Frontend e QA colaboram por casos de teste. Escrever critérios de aceitação ou testes em linguagem natural antes da implementação parece tedioso, mas pode ser muito eficaz.

**5) Observabilidade e diagnóstico**

Responder a reclamações e investigar problemas em produção fica menos eficiente com a expansão da organização e a especialização do trabalho. Os logs ficam espalhados entre serviços, e reunir os fatos por mensagens em grupos pode consumir horas.

Precisamos integrar logs e observabilidade para que a IA veja os dados completos antes e depois de cada etapa. O mínimo é ter logs estruturados, rastreamento unificado e reprodução dos fluxos essenciais. Automatizar primeiro a coleta de fatos torna a resposta dos engenheiros mais ágil. Também é um pré-requisito para o diagnóstico automático por IA.