Ir para o conteúdo principal
Voltar aos artigos

Agentes mais baratos: talvez o gargalo esteja na arquitetura, não no prompt

O relato do Instagram sobre Compose sugere testar contratos e fronteiras mais claros antes de ampliar o contexto dos agentes.

·3 min de leitura·2 visualizações

A equipe do Instagram Direct relata que a migração da interface Android de Views para Jetpack Compose reduziu em 50% o código de UI, 35% o tempo de execução dos agentes, 33% o custo de tokens por sessão e 32% as interações entre engenheiros e agentes.[17] São resultados divulgados para essa migração, não uma promessa de economia para qualquer aplicação.[17] O ponto que merece investigação é a relação entre estrutura do código e esforço de orientação do agente.

O que muda para quem desenvolve

Segundo o relato, a equipe reorganizou estado, comportamento e fronteiras em vez de apenas pedir à IA que convertesse componentes isolados.[17] Os fluxos assistidos foram padronizados para preservar convenções compartilhadas enquanto o desenvolvimento de funcionalidades continuava.[17]

Minha leitura é que um agente precisa gastar menos esforço adivinhando quando os contratos são explícitos. Isso é uma hipótese de engenharia aplicável a outros contextos, não um resultado demonstrado pelo caso para Java, Python ou qualquer frontend. A forma de avaliar é comparar mudanças equivalentes e observar o que melhora, inclusive para revisores humanos.

O controle da migração usou métricas de produção, como tempo até a tela interativa, carregamento completo e rolagem, além de feature flags e testes A/B.[17] A equipe relata que a avaliação confiável só apareceu com telas completas em Compose, porque contêineres legados podiam distorcer a medição.[17]

Como aplicar

Escolha um módulo em que pequenas alterações costumem exigir muita explicação. Antes de reescrevê-lo, registre um conjunto de tarefas: adicionar um campo, mudar uma validação e corrigir um comportamento com teste de regressão, por exemplo.

Faça uma intervenção limitada: explicite entradas e saídas, reduza dependências ocultas e documente uma convenção que hoje só existe na memória da equipe. Depois, repita tarefas comparáveis com o mesmo modelo, ferramentas e critérios de aceite.

Meça custo por mudança aceita, tempo de revisão, regressões e quantidade de correções necessárias. Guarde também o tempo gasto na melhoria arquitetural. Uma redução por sessão pode esconder mais sessões ou uma tarefa concluída com menos qualidade; a unidade de comparação precisa ser o resultado.

Se o módulo atende usuários, defina indicadores funcionais e de desempenho que não podem piorar. A economia do agente só interessa depois de preservar o comportamento do produto.

Cuidados e limites

O caso inclui uma transição gradual com componentes compatíveis com contêineres antigos e novos e posterior substituição de RecyclerView por LazyColumn.[17] Também houve efeito de aquecimento do runtime Compose sobre outras telas.[17] Isso reforça que os números dependem do desenho e da sequência da migração.

Não atribua todo o ganho a um framework nem trate menos linhas como qualidade automática. Minha recomendação é buscar um experimento pequeno que teste clareza e manutenção. Se a arquitetura ficar mais compreensível para pessoas e agentes sem piorar a operação, há um argumento técnico. Tokens menores, isoladamente, ainda não são esse argumento.

Fonte

[17] Fonte: InfoQ. Publicação: 15/10/2026 às 13:00:00.

Continue lendo