Engenharia de Especificação: a nova habilidade depois da engenharia de prompt

Por que a engenharia de prompt não é mais suficiente

Nos últimos dois anos, aprendemos a extrair melhores resultados dos grandes modelos de linguagem (LLMs) escrevendo prompts mais claros: adicionar contexto, definir o papel, dar exemplos, especificar o formato e iterar. Isso ainda é útil. Mas, à medida que a IA avança dos chatbots para agentes de código, assistentes de pesquisa, copilotos de ciência de dados e fluxos de trabalho autônomos, um “bom prompt” já não é mais suficiente.

A nova habilidade é a engenharia de especificação (specification engineering): a capacidade de definir o objetivo, as restrições, as saídas esperadas, os casos extremos, os testes, os critérios de sucesso e os modos de falha de uma tarefa assistida por IA.

Um prompt pode produzir uma resposta com boa aparência. Uma especificação define se essa resposta é realmente aceitável.

Essa distinção importa porque os sistemas modernos de IA não estão apenas gerando parágrafos. Eles estão escrevendo consultas SQL, modificando bases de código, analisando planilhas, produzindo JSON estruturado, criando aplicações e tomando decisões em múltiplas etapas. Nesses cenários, o problema principal não é “a IA entendeu meu pedido?” — é:

• A resposta está estruturalmente correta?
• A saída respeita todas as regras de negócio?
• Casos extremos foram tratados corretamente?
• A IA omitiu algo importante?
• A IA inventou dados ou fez suposições não declaradas?
• Como sabemos se o resultado é realmente aceitável?

Essa última pergunta é especialmente importante. Pesquisadores de segurança de IA estudam há tempos o reward hacking (“especificação corrompida”), em que um sistema de IA satisfaz o objetivo formal mas perde o resultado pretendido. É exatamente o problema que vemos no trabalho cotidiano com IA: peça a um agente de código para “corrigir o bug” e ele pode gerar um patch que passa no teste visível mas quebra uma suposição oculta. Peça para “resumir este relatório” e o modelo pode gerar um texto fluente omitindo a única métrica que a liderança realmente precisava.

O prompt funcionou. A especificação falhou.

O que significa engenharia de especificação

A engenharia de especificação é a prática de transformar uma tarefa vaga em um conjunto de instruções executável, testável e revisável.

Um prompt fraco diz: “Resuma este artigo.”

Uma especificação melhor diz: “Resuma este artigo em até 200 palavras. Inclua: (1) a tese principal, (2) três descobertas-chave com dados, (3) uma limitação mencionada pelo autor. Não inclua opinião editorial. Se o artigo não mencionar limitações explicitamente, indique ‘Nenhuma limitação declarada pelo autor’.”

Uma boa especificação geralmente inclui:

• Objetivo: o que o modelo deve alcançar?
• Contexto: o que o modelo precisa saber?
• Entrada: quais dados, arquivos, ferramentas ou suposições são permitidos?
• Formato de saída: como deve ser a resposta final?
• Restrições: o que o modelo deve evitar?
• Critérios de sucesso: como julgaremos a correção?
• Modos de falha: o que pode dar errado?
• Testes: quais verificações devem ser aprovadas?

É por isso que a engenharia de especificação se aproxima mais da gestão de produtos, teste de software, validação de dados e design de pesquisa do que da engenharia de prompt tradicional.

A pesquisa já aponta nessa direção

Um artigo de 2024 sobre Requirement-Oriented Prompt Engineering (ROPE) argumenta que grande parte do treinamento de prompt foca em truques como role-play ou “pense passo a passo”, enquanto o uso complexo de LLMs depende mais de uma articulação clara de requisitos. Em um estudo randomizado com 30 iniciantes, o treinamento ROPE melhorou a capacidade de escrever requisitos em 20%, comparado a apenas 1% do treinamento convencional de engenharia de prompt.

Vemos a mesma tendência nas ferramentas de IA em produção. O Structured Outputs da OpenAI permite que desenvolvedores restrinjam as respostas do modelo a um esquema JSON, com aderência estrita ao esquema. Isso é engenharia de especificação em forma de API: em vez de torcer para que o modelo retorne JSON válido, o desenvolvedor define a estrutura que a saída deve obedecer.

O Model Spec da OpenAI e a Constituição da Anthropic mostram a mesma ideia no nível de comportamento do modelo. O Model Spec especifica como os modelos devem se comportar no ChatGPT e na API; a Constitutional AI da Anthropic usa princípios escritos para guiar o comportamento do modelo.

A própria indústria de IA está migrando dos prompts para as especificações.

Do “vibe coding” ao código orientado por especificação

A diferença fica muito clara na programação com IA. Uma abordagem de engenharia de prompt diria: “Adicione validação de e-mail ao formulário de cadastro.”

Uma abordagem de engenharia de especificação diz: “Adicione validação de e-mail ao formulário de cadastro em src/forms/signup.ts. Regras: (1) rejeitar e-mails sem @, (2) rejeitar domínios sem ponto, (3) permitir subdomínios, (4) retornar mensagens de erro em português, (5) não modificar a lógica de envio existente, (6) adicionar 3 casos de teste em signup.test.ts cobrindo: e-mail inválido, subdomínio válido, string vazia.”

A segunda versão dá menos espaço para a IA improvisar de maneira perigosa. Isso importa porque benchmarks de engenharia de software como o SWE-bench avaliam se modelos conseguem resolver issues reais do GitHub editando bases de código, não apenas gerando trechos isolados. Mesmo assim, os testes não são perfeitos — um estudo descobriu que mesmo patches de agentes que passavam nos testes podiam diferir significativamente dos patches humanos.

Outro artigo, o SWT-Bench, mostrou que testes gerados podem atuar como um filtro eficaz para correções de código propostas, duplicando a precisão do SWE-Agent.

O novo fluxo de trabalho

O fluxo de trabalho do futuro será menos “prompt → resposta” e mais “especificação → ciclo de validação”. Por exemplo:

• Definir o objetivo e as restrições da tarefa em linguagem natural estruturada
• Fornecer exemplos de entrada/saída esperada com casos extremos
• Deixar o modelo gerar uma primeira versão
• Executar verificações automatizadas (testes, validação de schema, linting)
• Revisar os resultados, especialmente modos de falha
• Iterar refinando a especificação — não o prompt

Isso é especialmente importante para sistemas agentivos. O guia prático de agentes da OpenAI recomenda dividir recursos densos em etapas menores e mais claras, garantindo que cada etapa mapeie para uma ação ou saída específica. Isso é engenharia de especificação aplicada a fluxos de trabalho.

A pesquisa DORA do Google também apoia essa direção. O relatório entrevistou quase 5.000 profissionais de tecnologia e concluiu que a IA atua como um amplificador de forças e fraquezas organizacionais existentes. Plataformas sólidas e processos de qualidade ajudam as equipes a obter mais valor da IA. Processos fracos também são amplificados. A IA não elimina a necessidade de disciplina de engenharia — ela aumenta o retorno de tê-la.

Considerações finais

A engenharia de prompt não está morta. Ela está se tornando parte de uma disciplina maior. A era inicial da IA recompensava pessoas que conseguiam obter melhores respostas de chatbots. A próxima era recompensará pessoas que conseguem projetar trabalho confiável com IA: tarefas com requisitos claros, saídas estruturadas, verificações de avaliação e limites explícitos.

A habilidade não é mais apenas perguntar: “Como resolvo X?”

É perguntar: “Como defino X com precisão suficiente para que uma IA possa resolvê-lo de forma confiável, e como sei que o resultado está correto?”

Isso é engenharia de especificação. E, à medida que os sistemas de IA se tornam mais autônomos, ela pode se tornar uma das habilidades técnicas mais importantes depois da engenharia de prompt.