Por que os engenheiros seniores encontram dificuldades ao construir agentes de IA? @philschmid compartilhou um paradoxo interessante: por que engenheiros seniores experientes geralmente progridem mais lentamente e com mais dificuldade no desenvolvimento de agentes de IA em comparação com engenheiros juniores? Schmid acredita que a causa principal reside no fato de que a engenharia de software tradicional enfatiza o determinismo e a desambiguação, enquanto a engenharia de agentes é inerentemente probabilística, exigindo que os engenheiros aprendam a "confiar" em Modelos de Nível Local (LLMs) para lidar com processos não lineares e entrada de linguagem natural. Ele analisa as dificuldades dessa mudança de mentalidade por meio de cinco desafios principais e fornece insights práticos para ajudar os engenheiros a se adaptarem a esse paradigma. Principais conclusões: Uma mudança de paradigma do determinismo para o probabilismo. O desenvolvimento de software tradicional prioriza a previsibilidade: entradas fixas, saídas determinísticas e isolamento de erros por meio do tratamento de exceções. Em contraste, agentes inteligentes dependem de Modelos de Linguagem Natural (LLMs) como seu "cérebro", conduzindo decisões por meio da linguagem natural e permitindo interações de múltiplas etapas, ramificações e adaptação. No entanto, o instinto dos engenheiros seniores é "codificar para eliminar a incerteza", o que, ironicamente, limita o potencial dos agentes inteligentes. Schmid destaca que os engenheiros juniores tendem a lidar com a incerteza de forma mais intuitiva e conseguem produzir protótipos funcionais mais rapidamente, enquanto os engenheiros seniores precisam superar hábitos desenvolvidos ao longo de muitos anos. Os cinco principais desafios delineiam cinco pontos de conflito entre as práticas tradicionais de engenharia e o desenvolvimento de agentes. Cada desafio é acompanhado de explicações e exemplos, destacando como migrar para uma abordagem mais flexível. 1. O texto é o novo Estado Os sistemas tradicionais usam dados estruturados (como valores booleanos do tipo `is_approved: true/false`) para representar estados, garantindo discrição e previsibilidade. No entanto, as intenções do mundo real muitas vezes estão ocultas nas nuances da linguagem natural, como o feedback do usuário "Este plano parece bom, mas, por favor, concentre-se no mercado americano". Impor uma estrutura binária a um sistema eliminaria essas nuances, impedindo o agente de responder dinamicamente. Ideia: Preserve o texto original como está, permitindo que os LLMs o interpretem dentro do contexto. Por exemplo, armazene preferências do usuário como "Prefiro Celsius para o clima, mas uso Fahrenheit para cozinhar" em vez de simples valores booleanos. Isso exige que os engenheiros mudem de uma abordagem "estrutural" para uma abordagem "flexível semântica". 2. Transferindo o controle Arquiteturas tradicionais, como microsserviços, dependem de rotas fixas e endpoints de API para controlar processos. No entanto, um agente possui apenas um único ponto de entrada em linguagem natural, com o LLM (Learning Language Management) determinando o próximo passo com base em ferramentas e contexto — potencialmente repetindo o processo, retrocedendo ou redirecionando. Por exemplo, uma intenção de "cancelar inscrição" pode ser negociada para "oferecer um desconto para manter o agente". Codificar esses processos de forma rígida limita a adaptabilidade do agente. Dica: Confie no LLM para lidar com o fluxo de controle e aproveite sua compreensão do contexto completo. Os engenheiros devem projetar sistemas que suportem essa "navegação não linear", em vez de pré-definir todos os caminhos. 3. Os erros são apenas entradas. Em códigos tradicionais, erros (como variáveis ausentes) disparam exceções, levando a falhas ou novas tentativas. No entanto, cada execução de um agente consome tempo e recursos, tornando uma falha completa inaceitável. Os autores enfatizam que os erros devem ser tratados como novas entradas, realimentadas ao agente para permitir a autorrecuperação. Ideia: Construa um mecanismo resiliente que reintegre os erros ao LLM para recuperação, em vez de isolá-los. Isso reflete o pensamento probabilístico: a falha não é o fim, mas uma oportunidade de iteração. 4. Dos testes unitários às avaliações Os testes unitários baseiam-se em asserções binárias (aprovado/reprovado), que são adequadas para saídas determinísticas. No entanto, a saída de um agente é probabilística; por exemplo, "resumir este e-mail" pode produzir inúmeras variações válidas. Os testes que simulam LLMs também verificam apenas detalhes de implementação, não o comportamento geral. Insight: Mude para "avaliações" que incluam confiabilidade (taxa de sucesso, como 45/50 aprovações), qualidade (usando o LLM como avaliador para pontuar a utilidade e a precisão) e rastreamento (verificação de etapas intermediárias, como se uma base de conhecimento foi consultada). O objetivo não é 100% de certeza, mas uma alta probabilidade de sucesso. 5. Os agentes evoluem, as APIs não. As APIs são projetadas partindo do pressuposto de que os usuários humanos podem inferir o contexto, mas os agentes inteligentes são "literalistas" — se "email" em get_user(id) for interpretado erroneamente como um UUID, eles podem gerar uma resposta incorreta. A ambiguidade da API amplifica as limitações dos LLMs. Dica: Projete APIs "à prova de falhas" usando tipos semânticos detalhados (como delete_item_by_uuid(uuid: str)) e docstrings. Agentes inteligentes podem se adaptar às mudanças na API instantaneamente, tornando-os mais flexíveis do que o código tradicional. Soluções e implicações Schmid não defende o abandono completo dos princípios da engenharia, mas sim busca um equilíbrio entre "confiar e verificar": construir sistemas resilientes por meio da avaliação e do monitoramento da gestão probabilística. Ao mesmo tempo, ele reconhece que os agentes não são onipotentes — tarefas lineares simples são mais adequadas a fluxos de trabalho do que agentes. Exemplos incluem a preservação do estado textual do feedback do usuário, a permissão de loops de recuperação orientados a erros e a quantificação do desempenho do agente por meio de avaliações (por exemplo, taxa de sucesso de 90%, pontuação de qualidade de 4,5/5). Endereço do blog:
