- Ao contrário da expectativa de que o boom dos agentes de IA chegue com força em 2025, há limitações reais em ambientes de produção
- Devido ao acúmulo de erros e ao problema do custo de tokens, hoje é impossível automatizar completamente workflows de múltiplas etapas
- A maioria dos sistemas de agentes bem-sucedidos exige domínios estritamente limitados e um processo obrigatório de aprovação ou validação humana
- A verdadeira dificuldade não está no desempenho da IA em si, mas no projeto de ferramentas e sistemas de feedback que o agente consiga usar bem
- Em 2025, startups e empresas que colocarem agentes totalmente autônomos no centro da proposta provavelmente enfrentarão grandes obstáculos na adoção e na escalabilidade real
Por que eu aposto que agentes de IA não vão decolar em 2025 (mesmo estando desenvolvendo agentes de IA)
- O hype de que 2025 será o ano dos agentes de IA está por toda parte
- O autor construiu diretamente, ao longo do último ano, diversos sistemas de agentes de IA que operam em produção real
- Com base nessa experiência prática direta, ele mantém uma posição cética em relação à "revolução dos agentes" vendida pelo mercado
Experiência construindo diferentes sistemas de agentes
- Agentes de desenvolvimento: geração de componentes React a partir de linguagem natural, refatoração de código legado, gerenciamento automático de documentação de API, geração de funções com base em especificações etc.
- Agentes de dados e infraestrutura: tratamento de queries complexas e migrações, automação de DevOps em múltiplas nuvens
- Agentes de qualidade e processo: correção automática de lint, geração de código de teste, code review e automação detalhada de Pull Requests
- Esses sistemas geram valor real e economizam tempo, mas essa experiência também é a base da visão crítica em relação ao hype
Resumo central: três verdades duras sobre agentes de IA
- Acúmulo da taxa de erro: à medida que as etapas aumentam, a taxa de sucesso cai exponencialmente. É difícil atender ao padrão de produção (99,9% ou mais)
- Janela de contexto e custo: quanto mais longa a conversa, mais o custo de tokens cresce quadraticamente, destruindo a viabilidade econômica
- Dificuldade de projetar ferramentas e feedback: mais do que um limite técnico do modelo, o maior desafio é o projeto de ferramentas e sistemas de feedback utilizáveis pelo agente
A realidade matemática do acúmulo de erros
- Workflows autônomos de múltiplas etapas são inviáveis em escala operacional real por causa do acúmulo de erros
- Por exemplo, mesmo com 95% de confiabilidade em cada etapa, em 20 etapas a taxa final de sucesso é de apenas 36% (o exigido em produção: 99,9% ou mais)
- Mesmo assumindo alta confiabilidade, a probabilidade de falha cresce fortemente à medida que o número de etapas aumenta
- Na prática, em vez de automatizar todo o processo por completo, a arquitetura é desenhada com validação independente e pontos de rollback em cada etapa, além de confirmação humana
- Padrão de sistemas de agentes bem-sucedidos: contexto claramente limitado, tarefas verificáveis e participação humana nas decisões importantes
Estrutura de custos de tokens e limites econômicos
- O custo de tokens para manter a janela de contexto e a conversa se torna uma realidade antieconômica conforme o sistema escala
- Agentes conversacionais precisam processar todo o histórico da conversa a cada rodada, então o custo dispara quadraticamente à medida que as interações aumentam
- Uma conversa com 100 rodadas consome US$ 50 a US$ 100 só em tokens, e a viabilidade econômica entra em colapso quando aplicada em massa a usuários
- Em contrapartida, um agente Stateless (sem estado) de slot único, para geração funcional sem necessidade de contexto, é mais vantajoso em custo e escalabilidade
- Os agentes de produção mais bem-sucedidos se parecem mais com "ferramentas inteligentes de objetivo claro" do que com agentes "conversacionais"
A barreira do design de ferramentas e sistemas de feedback
- O verdadeiro gargalo no desenvolvimento de agentes realmente produtivos é a capacidade de projetar ferramentas, algo que equipes existentes tendem a subestimar
- A precisão do tool calling em si melhorou, mas o ponto decisivo é como resumir estados e resultados complexos de forma eficaz para devolvê-los como feedback ao agente
- Exemplos:
- Quando uma tarefa tem sucesso parcial, é preciso decidir quanta informação e que tipo de resumo são necessários
- Por exemplo, se o resultado de uma query tiver 10.000 registros, é necessário projetar uma abstração de estado como "sucesso, 10 mil registros, mostrar apenas os 5 primeiros"
- Em caso de falha da ferramenta, é preciso ajustar a quantidade de informação para recuperação e evitar poluição de contexto
- Na prática, o núcleo de um agente de banco de dados bem-sucedido é: fornecer feedback estruturado sobre o qual o agente consiga realmente tomar decisões
- No mundo real, a IA responde por cerca de 30% do trabalho; os outros 70% ficam com habilidades tradicionais de engenharia, como feedback de ferramentas, recuperação e gerenciamento de contexto
Limites da integração com sistemas reais
- Mesmo que os problemas de confiabilidade e custo sejam resolvidos, a integração com o mundo real continua sendo outra barreira
- Sistemas organizacionais reais não oferecem APIs consistentes; eles trazem complexidade imprevisível como legado, erros excepcionais, autenticação em mudança, limites variáveis e exigências de conformidade
- Um agente de banco de dados real exige programação tradicional para gerenciamento de pool de conexões, rollback de transações, respeito a réplicas somente leitura, timeout de queries, logs etc.
- A promessa de que "a IA integrará toda a stack de forma totalmente autônoma" bate de frente com os limites do mundo real na hora da implementação
Padrões de abordagens que realmente funcionam bem
- Princípios em comum nos sistemas de agentes bem-sucedidos
- Agente de geração de UI: a experiência do usuário é revisada por um humano no final (a IA cuida apenas da complexidade da conversão de linguagem natural → React)
- Agente de banco de dados: operações destrutivas sempre são confirmadas por humanos (a IA faz apenas a conversão para SQL, e o controle de preservação dos dados fica com a pessoa)
- Agente de geração de funções: funcionamento limitado a especificações claras (sem estado, efeitos colaterais ou integrações complexas)
- Automação de DevOps: a IA gera o código de infraestrutura, enquanto deploy, versionamento e recuperação continuam no pipeline existente
- Agente de CI/CD: cada etapa é desenhada com critérios claros de sucesso e mecanismos de rollback
- Resumo do padrão: a IA lida com a complexidade, os humanos mantêm o controle, e a confiabilidade é garantida pela engenharia tradicional
Perspectiva e previsões de mercado
- Startups que apostam em agentes totalmente autônomos devem esbarrar primeiro em problemas de rentabilidade
- Em um workflow de 5 etapas, a demo pode ser excelente, mas empresas reais exigem 20 etapas ou mais, o que leva ao limite matemático
- Empresas que apenas adicionarem um agente de IA ao software existente tendem a sofrer estagnação na adoção por falta de integração prática
- Os verdadeiros vencedores serão as equipes que, em domínios claramente limitados, aplicarem IA apenas às tarefas difíceis e colocarem humanos e condições de contorno nas decisões importantes
- O mercado deve aprender, por meio de experiências caras, a diferença entre "IA que funciona bem em demo" e "IA realmente confiável"
Princípios desejáveis para construir sistemas de agentes
- Definição clara de limites: definir com clareza o papel do agente e os pontos de handoff para humanos ou sistemas existentes
- Projeto orientado a falhas: é essencial desenhar estruturas de rollback e recuperação para quando a IA errar
- Validação da viabilidade econômica: projetar a estrutura considerando custo por interação e expansão de escala (sem estado é mais econômico do que com estado)
- Confiabilidade acima de autonomia: um sistema consistente conquista mais confiança do usuário do que um sistema que ocasionalmente faz mágica
- Construção sobre uma base robusta: delegar à IA apenas as partes difíceis (interpretação de intenção, geração etc.), e deixar o restante (execução, tratamento de erro etc.) para o software tradicional
As verdadeiras lições tiradas da experiência prática
- Existe um abismo enorme entre "funciona em demo" e "opera de verdade em larga escala"
- Confiabilidade dos agentes, otimização de custos e complexidade de integração continuam sendo problemas centrais ainda não resolvidos em toda a indústria
- Experiência real de implementação e compartilhamento honesto dessas experiências são essenciais para o avanço do setor
- Quanto mais pessoas com experiência prática discutirem metodologias racionais e casos reais de fracasso, maior será a chance de sucesso coletivo
1 comentários
Comentário do Hacker News
Já conversei com um engenheiro de produção de IA da Amazon, e ele disse que hoje nenhuma empresa usa apenas IA generativa em pontos de contato direto com o cliente; todas as respostas automáticas usam tecnologias antigas, não generativas, porque os problemas de confiabilidade da IA generativa ainda são grandes demais para arriscar a reputação da empresa
Antes eu tinha muito interesse em agentes que combinavam técnicas simbólicas de "IA antiga" com machine learning tradicional, mas acabei trabalhando principalmente com redes neurais pré-transformer; no fim, o fluxo sempre foi construir primeiro sistemas com humano no circuito, coletar dados de avaliação e treino, e só depois fazer o sistema assumir parte do trabalho e melhorar também a qualidade do restante; especialmente em tarefas "subjetivas", sistemas simbólicos também precisam ser avaliados, e se você precisa treinar o sistema, não tem como escapar da avaliação
Na prática, muitas empresas de tecnologia já estão adotando IA generativa em suporte ao cliente por chatbot em tempo real; conheço casos como Sonder e Wealthsimple, e quando o LLM não consegue responder à consulta, a conversa é passada imediatamente para um atendente humano
Um ponto que ainda não foi discutido é a janela de contexto; humanos conseguem lidar com um contexto praticamente "quase infinito" em suas áreas de especialidade; os modelos podem superar parte dessa limitação com dados de treino maiores e mais diversos, mas não acho que isso seja a solução real; hoje as pessoas precisam comprimir seu próprio contexto no prompt, então, em uma língua flexível como o inglês, isso parece mais recitar feitiço ou adivinhar do que engenharia; tenho a sensação de que se perde muita informação em vez de trabalhar de forma determinística
Nos humanos, "contexto" e "pesos" não ficam separados de forma fixa; ao longo do tempo, experiências e resultados continuam alterando os meus próprios "pesos", mas em LLMs isso é impossível por arquitetura, porque os pesos são somente leitura
Tenho certo ceticismo sobre se humanos realmente possuem uma janela de contexto tão grande assim; eu bato com frequência nos limites da minha própria "janela de contexto" humana quando resolvo problemas complexos; queria saber se existem exemplos reais disso
Minha experiência com ferramentas de IA tem sido majoritariamente positiva; elas ajudam muito a assumir pequenas tarefas quando preciso descansar, ou a organizar e iniciar o trabalho; mas o problema de custo aparece rápido; por exemplo, usar Claude Code em uma base de código grande custa algo como $25 em 1 ou 2 horas, e com correção automatizada isso sobe para $50/hr; há um trade-off entre velocidade, precisão e custo; os Agents lançados recentemente ainda estão em um ponto pouco claro desse triângulo, então os experimentos são interessantes, mas ainda acho arriscado
Vendo de forma um pouco cínica, essa estrutura de o LLM ficar se repromptando continuamente para corrigir erros, e a abordagem de "Não precisa de RAG! É só jogar todo o código numa janela de contexto de 1m tokens", no fim encaixa perfeitamente no modelo de negócio de 'cobrança por token'
Uma ideia em que ando pensando é fazer a IA gerar vários rascunhos de commits desde o começo, e depois um humano filtrar e lapidar isso manualmente ou de forma automatizada; quanto maior o trabalho, maior a chance de pequenos desvios iniciais arruinarem o resultado inteiro; então, mesmo com o SOTA atual, deixar agentes tentarem várias opções em paralelo reduz o tempo de refatoração manual; já escrevi sobre esse processo no GitHub
Dá vontade de perguntar se isso é um serviço por assinatura
Fluxos de trabalho humanos em múltiplas etapas normalmente têm checkpoints de validação, porque humanos também não são mais de 99% precisos; no futuro, agentes também terão procedimentos de validação embutidos no output e serão treinados para passar por esse processo antes de avançar para a etapa seguinte; também será possível fazer uma avaliação prévia de risco, do tipo "aqui a precisão precisa ser acima de 99%"
O Claude Code para o tempo todo antes de avançar com a tarefa para perguntar ao usuário se deve prosseguir, e também mostra as mudanças sugeridas com antecedência; isso é eficaz para evitar desperdício de tokens e trabalho ineficiente
Muitos aplicativos também vão precisar ser redesenhados para esse tipo de estrutura; na minha opinião, arquitetura de microsserviços combina bem com LLMs e pode voltar à moda
Concordo com a ideia de que "o verdadeiro problema não é a capacidade da IA, mas projetar ferramentas e sistemas de feedback que o agente consiga usar de forma realmente eficaz"; eu só observava, sem certeza de como o mercado reagiria, e acabei entrando numa startup bem pequena especializada em criar agentes; em 5 meses, passei de cético para alinhado e depois convicto; quando se define um escopo bem estreito e se foca no tooling para o modelo trabalhar, a taxa de conclusão pode ser alta; existe uma tendência de rejeitar o caráter não determinístico, mas com tooling excelente e escopo cada vez mais estreito, isso fica bem utilizável na prática; o tooling em si parece difícil, mas acho que dá para resolver razoavelmente bem; estou otimista com o futuro
Acho que todos esses problemas são solucionáveis, só que muitas startups não focam neles por causa da corrida para conseguir ARR rápido; faz sentido dizer que agentes não são tão úteis quanto prometem, mas na prática isso é um problema de engenharia; se abordarmos de outro ângulo, acho que funciona (pessoalmente sou mais favorável à linha de RL); por exemplo, é preciso um bom verificador (verifier); em muitas tarefas, verificar é mais fácil do que executar; mesmo com 5 saídas paralelas com 80% de precisão, há 99,96% de chance de pelo menos uma estar correta, e o verificador pode escolhê-la; isso também fica matematicamente vantajoso em cenários multietapa; é uma abordagem diferente da que vimos até agora, e o texto também menciona o paradigma de workflow em 3 a 5 etapas, o que de fato faz muito sentido; precisamos ver mais modelos desse tipo daqui para frente
Há um argumento de que, em muitas tarefas, verificar é na verdade mais difícil do que fazer o trabalho em si; no QA de software, em especial, esse raciocínio costuma ser usado para justificar reestruturações, e o resultado frequentemente parece piorar a qualidade; verificadores se tornam extremamente difíceis porque o número de combinações possíveis entre o sistema e os estados do mundo externo cresce geometricamente; LLMs são atraentes nesse tipo de ambiente complexo por assumirem trabalho repetitivo, como mockar dependências ou pré-preencher dados, mas para que testes de verificação sejam significativos surge sempre a exigência de 100% de precisão, e no fim você precisa de outro verificador para cada pré-condição; se cada etapa precisa ser 100% correta, a probabilidade acumulada acaba caindo; humanos normalmente testam casos específicos com cuidado, mas não verificam perfeitamente todos os cenários (teste white-box é muito mais comum que black-box); se o LLM gerar muito código, o trabalhador acaba precisando entender o código inteiro para conseguir fazer uma verificação white-box, e aí o tempo economizado começa a desaparecer; no momento, o LLM gera e eu mesmo tenho que corrigir todos os erros, então minha confiança diminui e também gasto mais tempo; em algumas situações dá para contornar ajustando a interface para bater com o que o LLM espera, mas isso não é geral; fora de software, muitas vezes a verificação é simplesmente impossível (por exemplo: "selecionar as 5 startups de games mais promissoras"), e entregar cegamente esse tipo de área para uma máquina, sem um humano, é receita para desastre
Fico me perguntando se é válido supor que as cinco gerações serão realmente independentes entre si
É verdade, deixar vários agentes tentarem, repetir várias vezes e aplicar soluções diferentes funciona na prática; já vivi casos em que uma abordagem recebeu feedback negativo e outra deu certo
É surpreendente que uma única pessoa (ou um time minúsculo) tenha criado mais de 12 agentes de IA realmente em produção, para desenvolvimento, DevOps, data operations etc.; olhando para a taxa de falha de startups, já é difícil fazer "um" bom produto, então 12 parece impressionante; nós também levamos 2 anos com uma stack de dados + ferramenta de agente de IA como a Definite até ficar razoavelmente boa, e isso só aconteceu há uns 6 meses, Definite
Na verdade, não são 12 produtos independentes; o ponto é que foram criadas 12 ferramentas de propósito muito específico, usadas no trabalho conforme a necessidade; como o texto todo sugere, um agente só se torna útil quando se concentra em objetivos muito simples e claros
Parece estranho ter conseguido fazer mais de 12 ao longo de 3 anos mantendo um emprego full-time
Eu também trabalho desenvolvendo automação com agentes/IA, e agentes de programação open-ended são simplesmente uma ideia burra; checkpoints de validação humana, espaço de busca pequeno e perguntas/prompts extremamente específicos (por exemplo: este e-mail tem uma invoice, YES/NO) são o caminho realista; entendo o desejo por agentes totalmente autônomos, mas a tecnologia ainda não chegou lá; eu não mexo com geração de conteúdo (texto, imagem, código), porque isso uma hora vai dar ruim
Eu também reduzo algo como 50% da carga de trabalho usando chat coding com frameworks de agentes; já senti efeito real com GPT; mas acontece erro em cerca de 1 a cada 10 vezes, e acho que essa taxa não vai cair sem uma mudança fundamental na arquitetura dos LLMs; hoje, desde que o hype não destrua a confiança dos desenvolvedores, tenho certeza de que no futuro teremos sistemas muito mais robustos; o ganho de produtividade é visível a ponto de conseguirmos contratar bem menos gente no time do que antes; a curva de aprendizado em vários temas também caiu drasticamente, porque LLMs compensam a piora da qualidade da busca no Google; em workflows automatizados, a estrutura mais importante é um orchestration framework que deixe o LLM assumir parte do trabalho humano; o LLM também deveria reportar seu próprio nível de confiança, e se o confidence % for baixo, o caso vai direto para um humano; com testes, guardrails etc. bem feitos, já dá para substituir humanos em tarefas não centrais; o objetivo não é substituir pessoas, e sim automatizar o trabalho para reduzir o tamanho das equipes; um exemplo é o dia em que LLMs vão assumir tarefas humanas em grandes e-commerces, como descrição de produto, validação de imagem, correção de erro de digitação, inconsistência entre imagem e texto etc.
Concordo em grande parte, mas seguindo essa linha talvez o que reste seja "apenas um sistema de workflow caro"; fica a dúvida se realmente é necessário usar LLM para coisas que já podiam ser feitas com tecnologia anterior
Também concordo; hoje o ponto ideal para agentes parece ser "escopo estreito, baixo risco, alta repetição e trabalho chato"; como exemplo, deixei aqui uma experiência usando agentes para tarefas auxiliares em markdown de dev-log aqui
Validação humana de fato é a forma mais confiável de criar checkpoints, mas também existem outras abordagens, como testes unitários e validação ad hoc do sistema como um todo
Na verdade, acho que o autor deveria ser ainda mais otimista com agentes autônomos do que já é; 90% do que está sendo feito agora era impossível no início de 2024; não podemos subestimar a curva de progresso
Penso o mesmo; há também um post de blog relacionado e a diferença central é que HITL (Human in the loop) realmente reduz erros, enquanto HOTL (Human out of the loop) tende a criar problemas