> 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/w44-formulating-next-years-technical-decisions-for-ai-coding.md).

# W44-Pensando nas decisões técnicas de programação com IA para o próximo ano

Tenho pensado em como definir objetivos e quanto investir em programação com IA no próximo ano. Quero esboçar uma estrutura para esse tipo de decisão técnica. Neste ano, ainda estivemos na fase de ganho individual de eficiência. Se olharmos para a construção de capacidade organizacional, nosso investimento foi praticamente zero.

**Primeiro, entender quanta margem de custo os ambientes interno e externo permitem.**

A margem de custo do negócio é a variável decisiva. A IA provavelmente não terá no próximo ano o mesmo entusiasmo deste. A tolerância ao custo, definida pelos ambientes interno e externo, diminuirá. O que perdemos neste ano não estará novamente disponível no próximo.

Precisamos discutir engenheiros full stack por níveis. Formar alguém que alcance o desempenho médio esperado em cada especialidade custa muito e leva tempo. É mais realista delimitar cenários e estabelecer metas alcançáveis. Por exemplo, formar em seis meses profissionais full stack capazes de atender uma classe geral de cenários de negócio e medir quantas vezes isso reduz o prazo de entrega, ou quanto trabalho humano economiza, em comparação com a colaboração entre especialistas.

**Depois, conhecer os limites da engenharia.**

Devemos aprofundar continuamente a compreensão das fronteiras de um conjunto de tecnologias e práticas, sabendo o que conseguimos fazer com as ferramentas disponíveis. Os limites atuais de engenharia dos LLMs e dos agentes estão ficando mais definidos.

A ideia de que a capacidade dos modelos bateu em uma parede é uma inferência a partir de muitas informações. Há três razões principais.

Primeira, a discussão recente de Sutton sobre “mundo grande e mundo pequeno”. Grandes modelos não seriam inteligência de fato, mas um mundo pequeno, incapaz de aprender continuamente pela observação.

Segunda, o Grok parece confirmar um limite da scaling law. O Grok 4 já usa uma escala de 200 mil GPUs, e Musk é um defensor absoluto da engenharia. Mesmo assim, a reação do mercado foi morna, e a capacidade do modelo não abriu uma vantagem decisiva. Com modelos de nível semelhante, fica claro que a xAI não entrega a experiência ao usuário tão bem quanto OpenAI e Claude.

Terceira, a expectativa de sair da dependência do Transformer ainda não se realizou. A Thinking Machines, tão aguardada, passou mais de meio ano sem uma ruptura.

Por isso, acho que o espaço para grandes saltos de capacidade está diminuindo. Podemos esperar um pouco. É como se a passagem de Intel para M1 já tivesse acabado; agora restasse aguardar M2, M3 e assim por diante. Daqui a alguns anos, ninguém lembrará em qual M estamos.

Muitas pesquisas deste ano esclareceram os limites dos modelos: por que não contam os erres em strawberry, por que alucinam, por que há incerteza e problemas como Context Rot.

Os limites dos agentes como engenharia também estão sendo mapeados. Ainda há uma grande distância para as tarefas reais. Quando o código falha, por exemplo, a IA pode corrigir sozinha problemas simples, como erros de sintaxe. Nos complexos, como erros de lógica ou comportamentos inesperados, uma pessoa precisa primeiro entender o problema e dizer claramente como corrigi-lo. Jogar todos os erros para a IA não basta. Se você não sabe o que fazer, cola tudo e diz “IA, resolva”, ela pode alterar coisas às cegas e piorar a situação.

No próximo ano, a atenção do setor se voltará mais para resultados e aplicações. Uma possibilidade está no custo: chamar grandes modelos ainda é caro, mas o custo marginal pode cair com trabalhos como DeepSeek-OCR. Outra é uma expansão maior do ecossistema de agentes.

**Por fim, encontrar os cenários e caminhos adequados.**

A programação com IA assume parte do trabalho e acelera o aprendizado, mas quem quiser dominar a atividade ainda precisará completar seu conhecimento e construir novas formas de entender. Esse processo não desaparece. Engenheiros práticos sabem que ele leva tempo. Cada exploração é uma negociação entre o novo e o antigo, até encontrar o cenário e o papel com melhor custo-benefício. O frontend já viveu uma onda full stack com Node. Ela não se tornou dominante, mas hoje já não precisamos discutir para que o Node serve. Isso levou de três a cinco anos. Além disso, entender realmente o servidor determina até onde se pode ir. Há domínios em que o frontend não tem experiência, como modelos de processos e controle de concorrência, bancos de dados e transações, autenticação e segurança, expansão de serviços e recuperação de desastres. Tudo isso faz do full stack um espectro de ajustes contínuos, não um salto instantâneo.