Introdução: quatro frentes de engenharia de LLMs
Entre 2024 e 2026, a engenharia de modelos de linguagem de grande porte (LLMs) deixou de ser associada a truques isolados de prompt e se transformou em um conjunto de disciplinas com métodos próprios. Não se trata apenas de uma mudança de vocabulário: a indústria e a academia passaram a tratar os LLMs como componentes de sistemas de software que precisam ser especificados, testados, monitorados e integrados. O que antes era uma prática artesanal — escrever uma instrução bem formulada e torcer para o modelo responder — tornou-se um campo com requisitos, contratos de saída, benchmarks e arquiteturas de orquestração. Essa transição é visível não apenas nos artigos de pesquisa, mas também na proliferação de guias práticos publicados por grandes empresas de tecnologia, que tentam transformar o conhecimento disperso em procedimentos ensináveis.
Quatro frentes estruturam esse amadurecimento. A primeira é a especificação de comportamento: antes de executar um modelo, é preciso definir com clareza o que ele deve fazer e sob quais restrições. A segunda é a validação de saída: uma vez especificado o comportamento, é necessário garantir que as respostas do modelo sejam consumíveis por outros sistemas, com formatos previsíveis e verificáveis. A terceira é a avaliação empírica: benchmarks baseados em problemas reais de repositórios de código permitem medir se os modelos realmente resolvem as tarefas propostas — e, mais recentemente, questionar se esses benchmarks medem o que afirmam medir. A quarta é a orquestração de agentes: modelos isolados não entregam valor produtivo; eles precisam ser conectados a ferramentas, fluxos de trabalho e guardrails, e a adoção em larga escala nas organizações produz dados que ajudam a separar o que funciona do que é apenas entusiasmo.
Um sintoma desse amadurecimento é a própria proliferação de material didático. A IBM, por exemplo, publicou um guia de engenharia de prompts para 2026 que trata a criação de prompts como um recurso prático e ensinável, e não como uma habilidade quase mística. O Google Cloud, na mesma linha, define a engenharia de comandos como o processo de refinar as instruções dadas a um LLM para obter respostas mais precisas e úteis. A existência desses guias não é trivial: ela indica que o conhecimento acumulado no campo atingiu um nível de estabilidade suficiente para ser codificado, ensinado e difundido. Ao mesmo tempo, o fato de grandes empresas manterem páginas constantemente atualizadas sobre o tema sugere que ainda há disputa sobre as melhores práticas.
O que conecta as quatro frentes é a preocupação com sistemas inspecionáveis. A especificação define a intenção; a validação de saída garante a forma; os benchmarks medem o desempenho; a orquestração coloca os modelos no mundo real. Uma falha em qualquer camada compromete a confiabilidade do conjunto: um modelo bem especificado pode produzir saídas mal formatadas; uma saída bem formatada pode resolver a tarefa errada; uma tarefa resolvida em laboratório pode não se sustentar em produção; e um agente bem construído pode fracassar em uma organização desestruturada. Este artigo percorre essas quatro frentes em seções temáticas, entrelaçando dez referências acadêmicas e técnicas que, em conjunto, permitem mapear o estado da arte entre 2025 e 2026. A seção 2 examina a especificação de comportamento. A seção 3 trata da validação de saída. A seção 4 discute os benchmarks de código. A seção 5 aborda a passagem do modelo isolado ao agente em produção. A seção 6 sintetiza convergências, divergências e lacunas.
Como especificar comportamento: do prompt ao princípio
O ponto de partida das abordagens de especificação de comportamento é o diagnóstico de que a interação com LLMs não pode ser improvisada. Um prompt operacional carrega uma série de suposições tácitas: sobre o que o modelo conhece, sobre o que o usuário deseja, sobre quais restrições são aceitáveis. A engenharia de prompts tradicional concentrou-se em técnicas cada vez mais automatizáveis — role-plays, cadeias de raciocínio, templates prontos — mas negligenciou uma variável central: a qualidade do requisito humano. Foi essa lacuna que motivou o framework Requirement-Oriented Prompt Engineering (ROPE), de Qianou Ma e colaboradores, que propõe tratar o prompt como um artefato de requisitos, à semelhança do que a engenharia de software faz com documentos de requisitos [1]. No ROPE, usuários são treinados a articular explicitamente o que esperam do modelo antes de formular qualquer instrução [1].
O ROPE parte de uma crítica direta às práticas convencionais: em vez de ensinar usuários a pensar sobre as informações que o LLM precisa para executar uma tarefa, os tutoriais tradicionais ensinam macetes como "finja ser um especialista" ou "pense passo a passo" [1]. Em um experimento controlado randomizado com 30 novatos, o treinamento orientado a requisitos produziu um ganho de 20% na qualidade das respostas, contra 1% do treinamento convencional; a otimização automática de prompts não fechou a lacuna, e o estudo identificou correlação direta entre a qualidade dos requisitos de entrada e a qualidade das saídas [1]. O trabalho, disponível no arXiv sob o identificador 2409.08775 e publicado no TOCHI em 2025, situa-se na interseção entre interação humano-computador e inteligência artificial [1]. Um dos exemplos utilizados pelos autores é a construção de um chatbot de viagens com requisitos explícitos como "comece a resposta com um tl;dr", mostrando que usuários finais podem especificar comportamentos complexos quando recebem a formação adequada [1]. A visão do ROPE dialoga com a definição de engenharia de comandos utilizada pelo Google Cloud, que enfatiza o refinamento iterativo das instruções como caminho para respostas úteis: um comando bem formado explicita o contexto, define o formato esperado e informa ao modelo o que fazer diante de ambiguidades. Especificar antes de executar é, nesse sentido, uma forma de refinar o que importa.
A Anthropic seguiu um caminho distinto. Em vez de treinar usuários para formular melhores requisitos, a empresa optou por treinar o modelo para internalizar princípios. A "Claude’s Constitution" descreve essa abordagem: em vez de depender exclusivamente de regras situacionais, o Claude deve ser dotado de valores, conhecimento e sabedoria para se comportar com segurança em circunstâncias imprevistas [2]. A Constitution distingue duas estratégias: encorajar o modelo a seguir regras claras e procedimentos de decisão, ou cultivar bom julgamento e valores sólidos aplicáveis em contexto [2]. Regras claras oferecem previsibilidade e transparência, mas falham ao antecipar todas as situações e podem produzir resultados ruins quando aplicadas de forma literal fora de propósito [2]. Bom julgamento adapta-se a situações novas, mas à custa de previsibilidade e avaliabilidade [2]. A posição da Anthropic é, em geral, favorável ao cultivo de valores: a empresa argumenta que a maioria dos casos previsíveis de insegurança em IA decorre de modelos com valores prejudiciais, conhecimento insuficiente do mundo ou falta de sabedoria para traduzir boas intenções em boas ações [2].
A OpenAI abordou o mesmo problema por um terceiro ângulo: a especificação normativa. O Model Spec, na versão de 18 de dezembro de 2025, é um documento que descreve objetivos, princípios de linha vermelha e comportamentos esperados do modelo [3]. Seu elemento central é a cadeia de comando: uma hierarquia explícita que determina como reconciliar instruções concorrentes entre plataforma, desenvolvedor e usuário [3]. Sem essa hierarquia, um conflito entre uma instrução do usuário e uma política da plataforma seria resolvido de maneira ad hoc pelo modelo — exatamente o tipo de imprevisibilidade que a especificação busca eliminar [3]. O Model Spec não é um catálogo estático; ele é tratado como uma especificação viva, sujeita a revisões e atualizações conforme o modelo e o ecossistema evoluem [3].
As três abordagens convergem em um ponto essencial: o comportamento do modelo pode e deve ser formalizado. O ROPE formaliza o lado humano, transformando o prompt em um artefato de requisitos [1]; a Constitution formaliza o lado do modelo, transformando princípios em base de treinamento [2]; o Model Spec formaliza a governança, transformando a interação entre as partes em uma hierarquia explícita [3]. Essa convergência é notável porque parte de pontos de partida diferentes — pesquisa em interação humano-computador, filosofia de segurança e engenharia de produto — e chega a uma conclusão comum: o implícito precisa ser explicitado. A IBM, em seu guia de engenharia de prompts para 2026, reforça essa visão ao apresentar o prompt como um recurso prático cuja qualidade é determinada pela clareza da intenção. O guia orienta o leitor a definir o objetivo da interação, fornecer contexto relevante, especificar o formato da resposta e iterar a partir do resultado — passos que ecoam, em linguagem acessível, as mesmas preocupações do ROPE, da Constitution e do Model Spec. Não por acaso, as três frentes acadêmicas e os guias corporativos convergem para a mesma recomendação: antes de conversar com o modelo, converse consigo mesmo sobre o que deseja.
As divergências, no entanto, são tão relevantes quanto as convergências. A Constitution aposta na internalização: o modelo deve absorver valores para que seu julgamento seja confiável em situações que nenhuma regra previu [2]. O Model Spec aposta na explicitação: o modelo deve seguir regras de precedência para que seu comportamento seja auditável [3]. O ROPE acrescenta uma terceira dimensão: a qualidade do requisito humano é o fator determinante, seja qual for o estilo de especificação [1]. Essa tensão entre internalizar e explicitar não é meramente filosófica; ela influencia decisões concretas de design, como a escolha entre treinar o modelo com princípios gerais ou com regras de conduta específicas, e determina o que pode ser verificado externamente. Um modelo que internaliza valores pode ser mais robusto diante do inesperado, mas é mais difícil de auditar; um modelo que segue regras explícitas é mais fácil de controlar, mas pode falhar diante de situações não previstas. A próxima seção mostra como a validação de saída tenta resolver, na prática, essa tensão.
Da intenção ao contrato: garantia de saída válida
Se o comportamento do modelo é especificado por princípios internalizados [2] ou por regras explícitas [3], a saída precisa ser verificável em relação a essa especificação. De nada adianta definir uma hierarquia de comandos ou uma constituição de valores se as respostas do modelo chegam em formatos ambíguos, com campos ausentes ou valores inesperados que quebram os sistemas que as consomem. Foi exatamente essa necessidade que a OpenAI atacou com o recurso de Structured Outputs, documentado no guia de API [4]. A motivação é simples e poderosa: JSON é um dos formatos mais utilizados para troca de dados entre aplicações, e o Structured Outputs garante que o modelo sempre gerará respostas que aderem a um JSON Schema fornecido pelo usuário [4]. O recurso elimina uma classe inteira de falhas: o modelo não pode omitir uma chave obrigatória nem alucinar um valor de enumeração inválido [4].
O guia lista três benefícios principais [4]. O primeiro é a segurança de tipos confiável: dispensa validações manuais e repetições de solicitações para corrigir respostas mal formatadas. O segundo é a explicitação de recusas: recusas baseadas em segurança tornam-se programaticamente detectáveis — em um cenário em que o modelo é especificado para obedecer a princípios de linha vermelha [3], o sistema precisa distinguir uma recusa intencional de uma resposta ausente ou corrompida [3][4]. O terceiro é a simplificação do prompting: não é mais necessário redigir prompts longos e frágeis para obter formatação consistente [4]. Esse último ponto cria um diálogo interessante com o ROPE: parte do treinamento de usuários que o ROPE considerava necessário — ensinar o usuário a especificar a forma da saída — foi delegada à infraestrutura da API, liberando o usuário para se concentrar no conteúdo [1][4]. A especificação da forma, que antes era mais um requisito a ser verbalizado no prompt, passa a ser um contrato técnico.
A implementação técnica dos Structured Outputs é madura [4]. Além do suporte a JSON Schema na API REST, os SDKs da OpenAI para Python e JavaScript permitem definir esquemas com Pydantic e Zod, respectivamente; o guia também fornece exemplos em Go [4]. Em Python, uma classe CalendarEvent com campos name, date e participants é usada como esquema, e o modelo extrai as informações do evento; o mesmo padrão se repete em JavaScript com o helper zodResponseFormat e em Go com JSON [4]. O guia menciona tanto a API de Responses (client.responses.parse) quanto a API de Chat Completions (client.chat.completions.parse), evidenciando a evolução das interfaces de programação [4]. Os exemplos usam modelos com nomenclatura futurista como gpt-5.6, o que situa a documentação no cenário pós-GPT-5 e no mesmo período do Model Spec datado de 2025/12/18 [3][4].
Do ponto de vista arquitetural, os Structured Outputs funcionam como um contrato entre intenção e execução [4]. A especificação de comportamento [1][2][3] define o que o modelo deve fazer; o JSON Schema define a forma da entrega. Um modelo que opera sob uma constituição de valores [2] ou sob uma cadeia de comando [3] precisa de um mecanismo para que suas respostas sejam consumidas por outros sistemas, e é isso que o recurso oferece [4]. Essa função de contrato é ainda mais crítica para agentes autônomos: chamadas de ferramentas, preenchimento de formulários e interações com APIs dependem de saídas estruturalmente válidas [4][8]. Ferramentas de engenharia de prompts, como as listadas pela TrueFoundry em seu panorama de 2026, exploram exatamente essa interface: ao otimizar saídas de IA e gerenciar fluxos de trabalho, elas dependem de formatos previsíveis para funcionar em escala. A combinação de Structured Outputs com agentes autônomos reduz uma classe inteira de falhas de integração, permitindo que os desenvolvedores se concentrem na lógica de orquestração em vez da sanitização de respostas [4][8].
Há, porém, um limite inescapável: a correção estrutural não implica correção semântica. Um JSON bem formado pode conter informações factualmente incorretas ou resolver a tarefa de forma errada [4]. Esse limite não é um defeito do Structured Outputs, mas uma distinção entre dois níveis de validade. A conformidade estrutural resolve o problema da forma; o problema do conteúdo permanece aberto e exige avaliação empírica. Um desenvolvedor que usa um esquema JSON para extrair eventos de uma agenda pode receber um JSON perfeitamente formatado com a data errada do evento [4]. A forma está garantida; a verdade, não. Essa distinção é precisamente a motivação dos benchmarks de código discutidos na próxima seção: depois de garantir que o modelo fala a língua do sistema, é preciso saber se ele entende o problema. A garantia contratual, portanto, não é uma solução mágica: ela resolve a camada de transporte, não a camada de conhecimento.
Como medir se o modelo sabe programar
A validação por JSON Schema garante que o modelo fale a língua do sistema, mas não que ele resolva a tarefa. Para medir a capacidade real de programação, a comunidade construiu uma linhagem de benchmarks que evoluíram em sofisticação e, em seguida, em ceticismo. O ponto de referência inicial é o SWE-bench, disponível em swebench.com: um conjunto com 2.294 instâncias compostas por issues reais do GitHub extraídas de 12 repositórios Python, com a métrica central de porcentagem de instâncias resolvidas [5]. A plataforma se expandiu em múltiplas direções: SWE-bench Verified, um subconjunto de 500 instâncias filtradas por humanos em colaboração com a OpenAI; SWE-bench Lite, com 300 instâncias para avaliação mais econômica; SWE-bench Multilingual, com 300 tarefas de 42 repositórios em 9 linguagens; SWE-bench Multimodal, com 517 instâncias descritas por elementos visuais; e o modo "Bash Only" [5]. Essa proliferação de variantes reflete a tentativa de cobrir diferentes dimensões da capacidade de resolução de problemas e, ao mesmo tempo, revela que nenhuma métrica única é suficiente [5].
O histórico documentado na plataforma mostra o ritmo da evolução do campo: em março de 2024, o SWE-agent marcou 12,47% no SWE-bench; em agosto de 2024, o SWE-bench Verified foi lançado; em outubro de 2024, o SWE-bench Multimodal; em março de 2025, o SWE-agent 1.0 tornou-se o estado da arte open source no Lite; em maio de 2025, o SWE-smith foi lançado para treinar modelos para agentes de engenharia de software; em julho de 2025, o mini-SWE-agent alcançou 65% no Verified com apenas 100 linhas de Python; em novembro de 2025, foi introduzido o CodeClash; em maio de 2026, o ProgramBench [5]. Em pouco mais de dois anos, os agentes passaram de menos de 15% para percentuais que beiram ou ultrapassam 60% nos conjuntos mais difíceis, em paralelo com um aumento na sofisticação dos próprios benchmarks [5]. Cada marco representa um avanço dos agentes e, simultaneamente, uma pressão crescente sobre a qualidade do processo de avaliação [5][6].
O SWE-bench Verified é a resposta à primeira grande crise de confiabilidade. Em 13 de agosto de 2024, a OpenAI anunciou o subconjunto em colaboração com os autores do SWE-bench, com atualização em 24 de fevereiro de 2025 [6]. A motivação foi direta: o benchmark original sofria de dois problemas — testes unitários frequentemente específicos demais e, em alguns casos, pouco relacionados à issue, e descrições de issue subespecificadas, que geravam ambiguidade sobre o problema a resolver [6]. Para sanar essas falhas, a OpenAI contratou 93 desenvolvedores para identificar e filtrar manualmente as tarefas problemáticas, resultando no subconjunto de 500 tarefas [6][10]. O processo de avaliação é descrito em detalhe: cada amostra tem um pull request associado com código e testes; os testes FAIL_TO_PASS falham antes da solução e passam depois; os testes PASS_TO_PASS passam antes e depois; os agentes recebem o texto da issue e acesso ao codebase, sem ver os testes; e, para que uma edição seja considerada correta, ambos os conjuntos de testes precisam passar [6]. O anúncio foi feito quando os melhores agentes pontuavam 20% no SWE-bench e 43% no SWE-bench Lite, segundo o leaderboard de 5 de agosto de 2024 [6]. Além disso, o SWE-bench Verified foi integrado ao Preparedness Framework da OpenAI, que desenvolve métricas para rastrear a capacidade de os modelos agirem autonomamente, um componente-chave do nível de risco Médio na categoria de autonomia de modelos [6].
A segunda expansão da linhagem veio com o SWT-Bench, um benchmark dedicado à geração de testes unitários [7]. O site swtbench.com mantém um leaderboard próprio, e a evolução do estado da arte é impressionante: em fevereiro de 2025, o SWT-Bench Verified foi lançado com 433 issues solucionáveis verificadas por humanos; em abril de 2025, o Amazon Q Developer Agent alcançou 37,3% no Lite e 48,7% no Verified; em agosto de 2025, o OpenHands com GPT-5 reivindicou o primeiro e o terceiro lugares no Verified; também em agosto de 2025, o e-Otter++ alcançou 50,7% no Lite e 60,7% no Verified; em setembro de 2025, o LogicStar alcançou 84% no Verified, e uma nova versão do SWT-Bench corrigiu problemas de avaliação, aumentando pontuações anteriores em 2-3%; em dezembro de 2025, o TEX-T, da Salesforce, alcançou 87% no Verified em modo de script de reprodução; em março de 2026, o DevstralTestGen, da Mistral AI, alcançou 89,1% de precisão no Lite; em abril de 2026, o ReProAgent alcançou o primeiro lugar no Lite com GPT-5-mini; em julho de 2026, o PatchTwin alcançou o segundo lugar no Verified usando GPT-5 [7]. O SWT-Bench também documenta o impacto da configuração do ambiente: a avaliação do OpenHands saltou de 22,8% para 28,3% no Lite quando o ambiente de CI foi configurado para o agente [7]. Esse achado é crucial: o desempenho não é uma propriedade apenas do modelo, mas do sistema em que ele opera [7][8]. Em janeiro de 2025, o AEGIS alcançou 47,8% de sucesso no Lite e 26,0% de aumento de cobertura, sendo o primeiro agente especificamente adaptado para tarefas de teste [7]. O SWT-Bench complementa o SWE-bench: enquanto o SWE-bench mede a capacidade de resolver issues, o SWT-Bench mede a capacidade de gerar os próprios testes que verificam soluções [5][6][7]. Um agente pode resolver um problema sem gerar bons testes, e vice-versa [7][10].
O contraponto cético dessa linha evolutiva é o PatchDiff. O estudo "Are 'Solved Issues' in SWE-bench Really Solved Correctly? An Empirical Study", de You Wang, Michael Pradel e Zhongxin Liu, parte da constatação de que testes raramente são exaustivos: um patch pode passar nos testes e ainda assim não corresponder às expectativas dos desenvolvedores, configurando um "patch plausível mas incorreto" [10]. A metodologia, chamada PatchDiff, realiza testes diferenciais de patches para expor discrepâncias comportamentais entre o patch gerado e o patch de ground truth [10]. O estudo avaliou três ferramentas de estado da arte — CodeStory, LearnByInteract e OpenHands — no SWE-bench Verified [10]. Os resultados são severos: 7,8% de todos os patches contam como corretos enquanto falham no conjunto de testes desenvolvido pelo programador; 29,6% dos patches induzem comportamento diferente dos patches de ground truth, sendo 46,8% por implementações semelhantes mas divergentes e 27,3% por patches que adaptam mais comportamento do que o ground truth; a inspeção manual classifica 28,6% dos patches comportamentalmente divergentes como certamente incorretos [10]. Combinadas, essas fraquezas geram uma inflação de 6,2 pontos percentuais nas taxas de resolução reportadas [10].
Olhando para o conjunto, as quatro fontes formam uma linha evolutiva de sofisticação da avaliação. O SWE-bench estabeleceu o protocolo: tarefa real do GitHub, patch gerado pelo modelo, verificação por testes [5]. O SWE-bench Verified respondeu à baixa qualidade das tarefas com validação humana [6]. O SWT-Bench reconheceu que a geração de testes é uma habilidade distinta da resolução de issues [7]. O PatchDiff expôs o limite de toda a abordagem: a validação por testes é necessária, mas insuficiente [10]. Nesse sentido, o PatchDiff não anula o SWE-bench; ele o qualifica. Os números dos leaderboards devem ser lidos com uma margem de ceticismo, e a inspeção humana, ainda que cara, permanece indispensável [6][10]. Essa lição não se restringe a benchmarks; ela vale para a produção de software, como mostra a discussão sobre agentes na próxima seção [8][9][10].
Do modelo isolado ao agente em produção
Os benchmarks medem o modelo em tarefas isoladas, mas o valor produtivo dos LLMs aparece quando eles são orquestrados em fluxos de trabalho. Há duas fontes complementares para entender essa passagem: o guia prático da OpenAI para construção de agentes [8] e o relatório DORA 2025 do Google Cloud [9]. O primeiro é prescritivo: descreve como construir um agente. O segundo é empírico: mede o que acontece quando organizações adotam IA no desenvolvimento de software. A distância entre os dois é a distância entre intenção e realidade. Entre os dois, há ainda uma camada de conhecimento prático que circula em guias, vídeos e cursos: a engenharia de prompts para agentes tornou-se um tópico próprio, distinto da engenharia de prompts para chatbots de turno único.
O guia da OpenAI define agente como um sistema que realiza tarefas de forma independente em nome do usuário, gerenciando um workflow com um LLM [8]. Um workflow é uma sequência de passos para alcançar um objetivo, como resolver um problema de atendimento ao cliente ou reservar uma mesa em um restaurante [8]. Aplicações que integram LLMs sem usá-los para controlar a execução — chatbots simples, LLMs de turno único, classificadores de sentimento — não são agentes [8]. As características centrais incluem: o LLM gerencia a execução e toma decisões; o agente reconhece quando o workflow está completo e corrige proativamente ações; em caso de falha, interrompe e transfere o controle ao usuário; e tem acesso a ferramentas para coletar contexto e agir, selecionando-as conforme o estado do workflow, sempre dentro de guardrails [8]. O guia é explícito sobre quando construir agentes: eles são adequados para workflows em que abordagens determinísticas não funcionam [8]. O exemplo canônico é a análise de fraude de pagamento: um motor de regras funciona como um checklist, enquanto um agente funciona como um investigador experiente, avaliando contexto e identificando atividade suspeita mesmo quando nenhuma regra clara é violada [8]. Casos típicos incluem tomada de decisão complexa (aprovação de reembolsos), manutenção de sistemas de regras difíceis de sustentar (revisões de segurança de fornecedores) e forte dependência de dados não estruturados (reivindicações de seguro residencial) [8]. Em sua forma mais fundamental, um agente consiste em modelo, ferramentas e guardrails [8]. O guia também recomenda validar o caso de uso antes de construir: se o problema pode ser resolvido de forma determinística, um agente é um excesso de complexidade [8].
Essa visão ecoa em materiais educacionais voltados a desenvolvedores iniciantes. A DIO, plataforma brasileira de educação em tecnologia, ensina que a base de qualquer agente começa pela comunicação com o LLM: antes de orquestrar ferramentas, é preciso dominar a estruturação de prompts — entrada clara, contexto relevante, formato esperado. É uma lição que o guia da OpenAI pressupõe, mas não detalha: para que um agente gerencie um workflow, cada etapa da comunicação com o modelo precisa ser bem especificada [8]. Na mesma direção, vídeos e tutoriais sobre engenharia de prompts para agentes têm enfatizado a chamada engenharia de contexto como a chave para construir agentes que realmente funcionam. O termo designa a prática de construir o contexto em torno da tarefa — histórico, ferramentas disponíveis, restrições, exemplos — antes de qualquer chamada ao modelo. É uma ideia que conecta o ROPE [1], a cadeia de comando do Model Spec [3] e a arquitetura de agentes da OpenAI [8]: o contexto é o requisito em tempo de execução. A diferença é que, em um agente, o contexto não é estático; ele é atualizado a cada interação com ferramentas e a cada resultado intermediário, o que torna a especificação do comportamento um processo contínuo.
O relatório DORA 2025, intitulado "State of AI-Assisted Software Development", baseia-se em mais de 100 horas de dados qualitativos e respostas de quase 5.000 profissionais de tecnologia [9]. A conclusão central é que a IA não conserta uma equipe; ela amplifica o que já está lá [9]. Equipes fortes usam IA para se tornarem mais eficientes; equipes com dificuldades veem seus problemas amplificados [9]. Pela primeira vez, o relatório encontrou relação positiva entre adoção de IA e throughput de entrega e desempenho do produto, o que sugere que a indústria está aprendendo onde e como a IA é útil [9]. No entanto, a adoção de IA continua associada a menor estabilidade da entrega de software [9]. A teoria do relatório é que a IA acelera o desenvolvimento, mas essa aceleração expõe fraquezas a jusante: sem testes automatizados fortes, controle de versão maduro e loops de feedback rápidos, o aumento no volume de mudanças leva à instabilidade [9]. Equipes com arquiteturas fracamente acopladas veem ganhos; equipes com sistemas firmemente acoplados e processos lentos veem pouco ou nenhum benefício [9]. Os números confirmam a adoção quase universal: 90% dos entrevistados relatam usar IA no trabalho; mais de 80% acreditam que a IA aumentou sua produtividade; 30% relatam pouca ou nenhuma confiança no código gerado por IA, uma queda pequena em relação ao ano anterior [9]. O relatório identifica a centralidade do usuário como pré-requisito para o sucesso da IA: a IA se torna mais útil quando apontada para um problema claro [9]. A engenharia de plataforma aparece como fundação: 90% das organizações adotaram pelo menos uma plataforma, e há correlação direta entre a qualidade da plataforma interna e o valor extraído da IA [9]. A análise de clusters revela sete arquétipos de equipe, dos 'Foundational challenges' — baixo desempenho, alta instabilidade, burnout, fricção — aos 'Harmonious high achievers', que se destacam em desempenho, estabilidade e bem-estar [9].
A lacuna entre o prescritivo e o empírico é instrutiva [8][9]. O guia da OpenAI recomenda guardrails, transferência de controle em caso de falha e validação cuidadosa dos casos de uso [8]. O DORA mostra que, na prática, os benefícios dependem de condições organizacionais que muitas equipes não têm: plataformas de qualidade, workflows claros e loops de feedback rápidos [9]. Um agente construído seguindo o guia pode funcionar em um ambiente bem estruturado e falhar em um ambiente caótico, não por causa dos componentes internos, mas por causa do sistema em que está inserido [8][9]. Essa conclusão dialoga diretamente com os resultados do SWT-Bench, que mostrou o impacto da configuração do ambiente de CI no desempenho dos agentes [7][9], e com o PatchDiff, que revelou que patches que passam nos testes podem estar errados [10]. A confiança no código gerado por IA — ou a falta dela, relatada por 30% dos profissionais — é uma resposta racional a um ecossistema em que a validação ainda é imperfeita [9][10]. Por isso, a orquestração de agentes não é apenas um problema de engenharia de software; é um problema de design de sistemas sociotécnicos [8][9]. A recomendação da OpenAI para que agentes interrompam e devolvam o controle ao usuário em caso de falha [8] é, no fundo, o mesmo princípio que o DORA identifica como centralidade do usuário [9]: a IA deve operar dentro de um perímetro definido por humanos.
Nesse contexto, as ferramentas de engenharia de prompts e orquestração ganham relevância prática. A TrueFoundry, em seu panorama das melhores ferramentas de engenharia de prompts para 2026, destaca soluções que otimizam saídas de IA, gerenciam fluxos de trabalho e aumentam a confiabilidade das aplicações. Essas ferramentas ocupam exatamente o espaço entre o guia prescritivo da OpenAI e as condições empíricas descritas pelo DORA: elas tentam materializar guardrails, versionamento de prompts e monitoramento de agentes em produtos concretos [8][9]. A maturidade dessas ferramentas é um sinal de que a orquestração de agentes está se tornando uma disciplina de engenharia, com padrões, boas práticas e infraestrutura dedicada. Ao mesmo tempo, o DORA lembra que ferramentas não substituem fundações organizacionais: um agente bem orquestrado em uma plataforma de qualidade pode transformar uma equipe; o mesmo agente em um ambiente com testes frágeis e processos lentos pode apenas acelerar a produção de bugs [9].
Síntese: convergências, divergências e próximos passos
O panorama composto pelas dez referências revela uma tensão central entre duas escolas de especificação de comportamento. A Anthropic, com sua Constitution, defende a internalização de valores: o modelo deve desenvolver bom julgamento para lidar com situações que nenhuma regra previu [2]. A OpenAI, com seu Model Spec, defende a explicitação de regras de precedência: o modelo deve seguir uma cadeia de comando que torne o comportamento auditável [3]. O ROPE, de certa forma, age como mediador: argumenta que a qualidade do requisito humano é o fator decisivo, independentemente de o requisito ser formulado como valor ou como regra [1]. A pergunta que permanece é se essas escolas são realmente opostas ou se a distância entre elas é maior no discurso do que na prática.
Na prática, as escolas convergem mais do que a polarização sugere. A Constitution não elimina regras: a Anthropic afirma que tenta explicar as regras que deseja que o Claude siga, e reconhece situações em que regras rígidas são preferíveis [2]. O Model Spec, por sua vez, não é um catálogo de proibições: ele organiza princípios e comportamentos em uma hierarquia, o que implica aplicar princípios de forma contextual [3]. A diferença é de ênfase: a Constitution prioriza a formação do caráter do modelo; o Model Spec prioriza a contratação explícita entre as partes. Ambos, porém, dependem da mesma infraestrutura de verificação. Os Structured Outputs não são apenas uma conveniência técnica; são o mecanismo que permite auditar se um modelo constitucional ou especificado realmente cumpre o que foi combinado [4]. Uma saída que não adere a um contrato formal não pode ser inspecionada em larga escala [3][4]. A tensão filosófica entre valores e regras, portanto, dissolve-se parcialmente na engenharia: por mais que os princípios sejam internalizados no treinamento, a saída precisa ser externamente verificável [2][3][4].
Os benchmarks de código adicionam uma camada empírica a essa discussão. Enquanto a Constitution e o Model Spec definem como o modelo deve se comportar, o SWE-bench e o SWT-Bench medem se ele consegue resolver problemas reais [5][6][7]. O PatchDiff mostra que essa medição é imperfeita, pois testes não esgotam a correção [10]. A consequência é dupla. Primeiro, as avaliações devem ser lidas com ceticismo: os 6,2 pontos percentuais de inflação identificados pelo PatchDiff são uma margem de erro concreta nos leaderboards [10]. Segundo, a confiabilidade não é alcançada apenas com melhores prompts ou melhores benchmarks; ela exige mecanismos de validação em múltiplas camadas — testes diferenciais, inspeção humana, monitoramento contínuo [7][10]. Essa é a mesma conclusão do DORA: a IA amplifica as capacidades existentes, e sem sistemas de controle robustos a aceleração do desenvolvimento produz instabilidade [9].
Há também uma lição sobre o papel do humano. O ROPE coloca o usuário no centro da especificação de requisitos [1]. O SWE-bench Verified empregou 93 desenvolvedores para validar tarefas [6][10]. O PatchDiff recorre à inspeção manual para confirmar que patches divergentes são incorretos [10]. O guia da OpenAI recomenda que, em caso de falha, o agente devolva o controle ao usuário [8]. O DORA mostra que a centralidade do usuário é pré-requisito para o sucesso da IA [9]. Em todas as frentes, o humano permanece como árbitro final — o que não é uma limitação temporária, mas uma propriedade estrutural do campo: modelos cada vez mais autônomos exigem especificação, supervisão e avaliação humanas cada vez mais cuidadosas [1][6][8][10].
As lacunas não cobertas pelas dez referências são igualmente reveladoras. A primeira é a avaliação de tarefas de longo horizonte: os benchmarks existentes medem issues de escopo relativamente curto, mas agentes em produção executam workflows com dezenas de passos interdependentes [5][8]. A segunda é a coordenação entre múltiplos agentes: nenhuma das fontes trata em profundidade o problema de vários agentes compartilhando contexto, ferramentas e objetivos [8]. A terceira é o custo econômico e ambiental da orquestração: o DORA mede produtividade e estabilidade, mas não o custo computacional das arquiteturas sugeridas [8][9]. A quarta é a interpretabilidade: a Constitution fala em sabedoria, o Model Spec fala em hierarquia, mas nenhuma das fontes oferece uma metodologia para explicar por que um modelo tomou determinada decisão [2][3]. A quinta é a equidade dos benchmarks: o SWE-bench concentra-se em repositórios Python de nicho; o SWT-Bench cobre principalmente linguagens tipadas; a generalização para outros ecossistemas é incerta [5][7]. A sexta é a segurança em ambientes não controlados: o guia da OpenAI menciona guardrails, mas não há uma avaliação sistemática dos riscos de agentes que interagem com o mundo real, embora o SWE-bench Verified, por meio do Preparedness Framework, toque nesse tema [6][8]. Finalmente, falta uma discussão sobre padrões comunitários para avaliação: o PatchDiff propõe testes diferenciais, mas a adoção dessa técnica pela comunidade ainda é incipiente [10].
O saldo do período 2025-2026 é o de um campo que amadureceu sem se estabilizar. A especificação de comportamento tornou-se parte integrante da engenharia de LLMs [1][2][3]. A validação de saída tornou-se programática [4]. Os benchmarks de código tornaram-se mais sofisticados e, ao mesmo tempo, mais criticados [5][6][7][10]. Os guias de orquestração tornaram-se mais pragmáticos [8]. Os dados empíricos mostraram que as organizações estão adotando IA em massa, mas que a adoção não é uma solução mágica [9]. A distância entre o que se mede em laboratório e o que se observa em produção permanece — e é precisamente essa distância que define a agenda dos próximos anos: em vez de buscar truques de prompt, o campo precisará construir sistemas que especifiquem com clareza, validem com rigor, meçam com honestidade e operem com controle. Guias como os da IBM e do Google Cloud já refletem essa percepção; a questão é saber se as práticas organizacionais acompanharão o discurso.
Referências
[1] Ma, Q., Peng, W., Yang, C., Shen, H., Koedinger, K., Wu, T. "What Should We Engineer in Prompts? Training Humans in Requirement-Driven LLM Use." arXiv:2409.08775. https://arxiv.org/abs/2409.08775
[2] Anthropic. "Claude’s Constitution." https://www.anthropic.com/constitution
[3] OpenAI. "Model Spec (2025/12/18)." https://model-spec.openai.com/2025-12-18.html
[4] OpenAI. "Structured model outputs | OpenAI API." https://developers.openai.com/api/docs/guides/structured-outputs
[5] SWE-bench. "SWE-bench Leaderboards." https://www.swebench.com/
[6] OpenAI. "Introducing SWE-bench Verified." https://openai.com/index/introducing-swe-bench-verified/
[7] SWT-Bench. "SWT-Bench: Assessing capabilities at Unit Test Generation." https://swtbench.com/
[8] OpenAI. "A practical guide to building agents." https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/
[9] Harvey, N., DeBellis, D. "Announcing the 2025 DORA Report: State of AI-Assisted Software Development." Google Cloud Blog. https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
[10] Wang, Y., Pradel, M., Liu, Z. "Are 'Solved Issues' in SWE-bench Really Solved Correctly? An Empirical Study." arXiv:2503.15223. https://arxiv.org/html/2503.15223v1