Inteligência Artificial no dia a dia de Netflix, Meta e IBM: agentes, contexto e o tal imposto de preparo
IA generativa já parece mágica em muita demo, mas, na prática, ainda está bem longe de algo como mandar um comando do tipo Alexa, cria um e-commerce completo pra mim e ir embora tomar um café. E não adianta emendar com um pedido dramático do tipo NÃO ALUCINE, isso não resolve o problema de fundo. O que está ficando cada vez mais claro, principalmente para quem trabalha em empresas como Netflix, Meta e IBM, é que quanto mais você quer que os agentes de IA façam por você, mais trabalho de bastidor precisa ser feito antes, durante e depois de cada interação.
No palco de eventos recentes sobre IA, executivos e engenheiros dessas empresas vêm repetindo um ponto em comum: a tecnologia até multiplica a nossa capacidade, mas só entrega resultado confiável quando existe um bom nível de preparo, revisão e orquestração. Isso casa direto com algo bem conhecido na economia, o chamado Paradoxo de Jevons: quando uma tecnologia aumenta muito a eficiência de uso de um recurso, a tendência é a gente usar esse recurso ainda mais. Com IA acontece parecido. Em vez de simplesmente substituir tarefas humanas, ela abre novas frentes de trabalho, cria funções que não existiam e empurra os times para um tipo de rotina em que sempre existe mais uma automação possível, mais um ajuste de contexto, mais um experimento para rodar.
Hoje, quem usa modelos como assistentes de programação, suporte a texto, pesquisa ou análise de dados até consegue virar um desenvolvedor 10x em volume de saída. O problema é que essa conta vem com uma pegadinha: você ganha 10x de velocidade, mas também acaba tendo que revisar 10x mais resultados, aparar 10x mais arestas e decidir 10x mais vezes o que fica e o que vai pro lixo. Se algum dia a gente chegar num cenário sci-fi em que uma superinteligência domina tudo, o caminho até lá vai passar por um longo período em que humanos ainda precisam empurrar muito dado, limpar contexto e revisar saída de agente o dia inteiro.
Netflix e a revisão adversarial: muitos agentes, muito contexto, muita conversa
Um exemplo bem concreto de como essa dinâmica está aparecendo no mundo real vem de dentro da Netflix. Ben Ilegbodu, arquiteto de UI na empresa, contou em uma conferência como o trabalho dele mudou com a chegada dos agentes de IA. Em vez de só escrever código e revisar PRs de outros devs, ele hoje monta verdadeiros pipelines de agentes especializados para tarefas específicas, principalmente em revisão de código e automação de partes do desenvolvimento.
Quando ele cria um agente para automatizar uma tarefa, como implementar uma feature em uma base de código grande, ele não para aí. Em seguida, configura um segundo agente com a missão focada de avaliar o trabalho feito pelo primeiro, olhando com olhar crítico para bugs, estilo, segurança e aderência a padrões internos. Essa abordagem em camadas ele chama de revisão de código adversarial, porque um agente atua meio como contraponto do outro, tentando encontrar falhas, inconsistências e pontos de atenção.
- E-BOOK GRATUITO
Um guia prático para avaliar, comparar e implementar inteligência artificial com clareza — sem desperdício de tempo ou dinheiro.
Pare de contratar ferramentas sem direção. Criamos um método estruturado para decidir qual IA realmente faz sentido para o seu negócio.
Entrega em PDF no seu e-mail · Sem spam · LGPD
🔒 Seus dados são protegidos conforme a LGPD. Você pode descadastrar a qualquer momento.
Na prática, isso significa que o fluxo deixa de ser humano → código → revisão e vira algo como humano → agente que implementa → agente que revisa → humano que fecha a conta. Só que o jogo fica ainda mais interessante: muitas vezes Ilegbodu divide a própria revisão em múltiplos agentes, cada um focado em um pedaço diferente do problema. Um pode cuidar de performance, outro de acessibilidade, outro de padronização de componentes. E, sim, entra em cena ainda um terceiro agente para orquestrar a conversa entre todos os outros, consolidar resultados e montar um resumo acionável para o humano fechar a decisão.
Enquanto um desses agentes está mexendo em uma parte da base de código, ele já dispara outro para preparar terreno para uma próxima tarefa em paralelo. Nas palavras dele, é como se estivesse paralelizando a si mesmo, deixando o trabalho sempre andando em diferentes frentes. Esse estilo de trabalho deixa claro o tal Paradoxo de Jevons na prática: quanto mais fácil fica criar agentes para tarefas específicas, mais agentes aparecem, mais revisões são feitas e mais coordenação entra no dia a dia.
Um detalhe curioso é como isso afeta a própria experiência de trabalho. Com tantos agentes rodando, Ilegbodu passou a programar com conforto em linguagens que antes ele não dominava, como Python, Bash e Groovy, porque consegue pedir à IA trechos de código, exemplos e revisões em cima de contextos bem definidos. Ao mesmo tempo, ele admite que o impacto mental disso tudo é pesado: no fim do dia, a sensação é de cansaço não por ter escrito cada linha, mas por ter passado horas conversando, instruindo, corrigindo e refinando com agentes de IA. Em vez de menos conversa, o trabalho virou um diálogo constante com sistemas que precisam de contexto, limites e direcionamento o tempo todo.
Meta e o estagiário que nunca cansa: contexto demais, foco de menos
Na Meta, a metáfora favorita para descrever o uso de IA no desenvolvimento é a do estagiário super empolgado. A comparação é boa: o modelo é rápido, incansável, dá conta de volume absurdo de informação e topa praticamente qualquer tarefa. A diferença em relação a um estagiário humano é que a IA não fica sobrecarregada, pelo menos não em termos de cansaço, mas o sistema começa a sofrer de um outro problema: o que Justin Jeffress, Developer Advocate da empresa, chama de apodrecimento de contexto.
Funciona assim: você começa um projeto com um agente de IA, compartilha documentação, explicações, exemplos, padrões de código, bugs conhecidos e por aí vai. Com o tempo, a conversa cresce, o histórico aumenta e cada resposta nova precisa ser calculada em cima de um rastro cada vez maior de mensagens, instruções e detalhes. Quanto mais coisa compete pela atenção do modelo, maior a chance de ele se apoiar em uma parte irrelevante da conversa ou em um exemplo antigo que já não faz sentido, entregando um resultado distante do que você esperava.
Essa degradação gradual de foco é o tal contexto que vai se estragando com o passar do tempo. Para combater isso, Jeffress defende a prática da engenharia de contexto como algo central no trabalho com agentes: em vez de só ir jogando coisa no histórico, você define cuidadosamente o que entra, o que sai e o que é recuperado a cada etapa. Em termos simples, é como construir um conjunto de regras, ferramentas e habilidades que o agente pode consultar sob demanda, em vez de depender só do texto jogado na conversa.
Uma técnica que ele recomenda bastante é o encadeamento de prompts, ou prompt chaining. Em vez de mandar um pedido gigante, vago e cheio de desejos, você quebra a tarefa em passos específicos, orientando o agente a seguir uma sequência: primeiro entender o problema, depois levantar requisitos, em seguida propor soluções, só então gerar código, e assim por diante. Dá trabalho preparar isso? Com certeza. Mas, na prática, esse esforço antecipado reduz bem a chance de desvio lá na frente e diminui a necessidade de refazer tudo porque a IA resolveu seguir um atalho esquisito.
Jeffress sugere ainda algo bem prático para o dia a dia: usar um arquivo markdown ou outro tipo de documento como fonte de verdade sobre o que está em andamento, o que já foi decidido e quais são as regras do jogo. O agente pode consultar esse arquivo em vez de depender apenas de mensagens soltas, o que ajuda a evitar que ele esqueça objetivos ao longo do caminho. Trabalhando assim, a IA geralmente chega a algo como 80 por cento de uma tarefa, deixando os 20 por cento finais para o humano. Mas aí vem um twist interessante: quando ele tentou automatizar também parte desses 20 por cento, descobriu que outra fatia de 80 por cento daquela etapa podia ser feita por bots. E o ciclo se repete, quase como uma versão fractal da regra 80/20, só que aplicada a um processo de limpeza e refinamento aparentemente interminável.
IBM, decomposição e mellea.ai: menos feitiço, mais engenharia
Enquanto Netflix e Meta trazem relatos bem práticos de uso de agentes, a IBM empurra a conversa para um lado mais estrutural. Luis Lastras, diretor de tecnologias de linguagem e multimodalidade na empresa, cutuca uma ilusão comum: achar que o problema é sempre a IA que não obedece. Segundo ele, na maioria dos casos o problema está na forma como a gente descreve o trabalho, ou melhor, como falhamos em decompor o problema em partes pequenas o suficiente para a máquina lidar com segurança.
Ele chama de prompting ilusório aquela tentativa de resolver tudo na base do drama, com mensagens exageradas do tipo minha carreira depende disso, não alucine, faça perfeito. No fim do dia, isso é quase como tentar lançar um feitiço e esperar que um modelo gigante faça mágica com instruções vagas. Em vez disso, Lastras reforça algo que parece básico, mas é fácil de esquecer no hype da IA: decomposição é Engenharia 101. É a arte de pegar um sistema complexo, identificar peças críticas, modularizar, projetar cada parte e, se preciso, atribuir especialistas diferentes para cuidar de cada módulo.
No mundo dos agentes, isso significa abandonar a ideia de jogar um textão para um LLM genérico e torcer. A abordagem defendida por ele é montar funções bem definidas que ajudem o agente a executar tarefas específicas: validar formatos, aplicar políticas, checar consistência, detectar saídas potencialmente danosas, controlar estilos de resposta, estruturar resultados em esquemas previsíveis e assim por diante. Para apoiar esse tipo de fluxo, a IBM lançou a biblioteca open source mellea.ai, que traz padrões prontos em Python para estruturar chamadas a modelos de linguagem com mais disciplina.
Com esses padrões, dá para anexar requisitos às chamadas de LLM, interceptar e inspecionar respostas antes de entregá-las ao usuário, impor formatos rígidos de saída ou incluir etapas de checagem automática sobre certos tipos de conteúdo. Em paralelo, a IBM pesquisa um conceito que Lastras descreve como troca de cérebro: agentes que conseguem alternar entre modelos diferentes, escolhendo o mais adequado para cada subtarefa. Em vez de depender sempre de um modelo enorme, genérico e caro, dá para usar modelos menores e especializados, desde que se dê tempo de inferência suficiente e se mantenha um bom alinhamento de contexto. Em vários cenários testados, essa combinação de bons padrões de engenharia com modelos menores e focados superou, em qualidade, opções mais pesadas e generalistas.
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
O imposto do preparo: por que assumir que a máquina sabe é dívida técnica
Fechando esse mosaico, entra uma visão prática trazida por Justin Chau, engenheiro sênior na Intuit. Ele resume um ponto sensível com uma frase direta: suposições implícitas são dívida técnica. Aquilo que para você é óbvio, para a IA não existe até ser especificado. Se você não deixa claro o que é aceitável, o que é proibido e quais são os limites da tarefa, está, na prática, plantando bombas de comportamento inesperado para explodirem mais tarde.
Um conselho que ele destaca é inverter um pouco a forma como a gente costuma escrever instruções. Em vez de focar só no que a IA deve fazer, vale enfatizar os limites do que ela pode fazer. Restrições bem definidas funcionam como nãos duros, mais difíceis de serem ignorados pelo modelo. Se você diz que, sob nenhuma circunstância, o agente deve usar HTML em uma determinada saída, por exemplo, a tendência é que essa regra seja respeitada com muito mais força do que um simples faça em texto puro.
Ainda mais forte que restrições explícitas é a ausência de permissão. Se o agente não tem como acessar um repositório, uma API ou uma base de código, ele simplesmente não consegue mexer ali, por melhor que seja o modelo de linguagem por trás. Para Chau, essa é uma forma prática de reduzir riscos: em vez de confiar só em instruções textuais, você desenha o ambiente de forma que certas ações sejam impossíveis, protegendo sistemas críticos sem precisar revisar cada resposta manualmente.
Esse trabalho de preparar contexto, desenhar limitações, escolher fontes e quebrar problemas em partes menores é o que muita gente já está chamando de imposto do preparo. Não tem como fugir dele. Assim como no clássico Guia do Mochileiro das Galáxias, em que um supercomputador passa eras calculando a resposta para a grande pergunta da vida, do universo e tudo mais e dá um seco 42, a gente está descobrindo que ter tecnologia poderosa sem formular bem as perguntas, sem decompor direito os problemas e sem cuidar do contexto só leva a respostas vazias. No lugar de um futuro em que a IA faz tudo por conta própria, o que aparece hoje é um cenário em que ela nos empurra para um ciclo constante de preparação, orquestração e revisão.
No fim das contas, o recado que vem de Netflix, Meta, IBM, Intuit e companhia não é de apocalipse nem de utopia. É um aviso bem pragmático: IA pode sim turbinar o seu dia de trabalho, abrir espaço para experimentar mais, testar mais hipóteses e acelerar projetos. Mas o preço dessa aceleração é aprender a pensar como engenheiro de contexto, aceitar o imposto do preparo e enxergar agentes não como magos infalíveis, e sim como ferramentas poderosas que precisam de limites claros, boas fontes e um humano atento conduzindo a orquestra.
