Equipes de Engenharia de IA Estão Abandonando o Vibe Coding por Especificações

No primeiro trimestre de 2026, várias equipes de engenharia que passaram o ano anterior "vibe coding" — dando prompts soltos a um agente de IA e iterando até algo funcionar — silenciosamente voltaram atrás. O motivo não foi que os agentes pioraram. É que o prompting não estruturado parou de escalar quando os agentes passaram a ser confiados com mudanças em múltiplos arquivos e pull requests autônomos. A solução em que as equipes convergiram é o spec-driven development (SDD): escrever uma especificação estruturada antes que um agente toque no código, e tratar essa especificação — e não o diff resultante — como a fonte da verdade.

Isso não é um retorno aos documentos de requisitos no estilo waterfall que ninguém lê. É uma resposta direta a um modo de falha específico: código confiante e plausível que resolve silenciosamente o problema errado porque ninguém ancorou o trabalho do agente em uma definição real de "pronto". Em meados de 2026, todos os grandes fornecedores de agentes de codificação — GitHub, AWS, o ecossistema Claude Code da Anthropic e uma onda de frameworks open source — lançaram suas próprias versões de fluxos de trabalho spec-first, e o padrão passou de "experimento interessante" para prática padrão em equipes de produção.

Por que o Vibe Coding quebra em escala

Uma correção de bug em um único arquivo ou um script pequeno tolera prompts soltos porque o raio de explosão é pequeno e um humano revisa todo o diff em segundos. Funcionalidades com múltiplos arquivos não funcionam assim. Um agente instruído a "adicionar cobrança por assinatura" tem que inferir decisões de schema de banco de dados, convenções de tratamento de erros, padrões de nomenclatura e casos de borda que nunca foram declarados — e vai inferir com confiança, mesmo quando errado. A falha não aparece como um crash; aparece três sprints depois como deriva arquitetural, lógica duplicada e uma base de código que não corresponde mais ao modelo mental de ninguém.

A evidência comercial disso agora é pública. O GitHub relatou que equipes que usam seu toolkit Spec Kit em projetos internos entregam funcionalidades com aproximadamente uma ordem de magnitude a menos de ciclos de "regenerar do zero" em comparação com equipes que usam prompting ad hoc. A AWS publicou casos de clientes onde funcionalidades estimadas em 40 horas de engenharia foram entregues em menos de 8 horas de esforço humano depois que o trabalho foi redigido como uma especificação primeiro, com o agente cuidando da implementação mecânica contra critérios de aceitação claros.

As ferramentas que estão tornando as specs o padrão

Cinco frameworks agora definem o cenário spec-driven, e eles adotam abordagens genuinamente diferentes:

• GitHub Spec Kit — um CLI open source licenciado sob MIT com mais de 93.000 estrelas no GitHub (v0.8.7 lançada em maio de 2026). Todo projeto do Spec Kit começa com uma "constituição": um arquivo Markdown com princípios imutáveis e abrangentes do projeto — padrões de teste, restrições arquiteturais, convenções de nomenclatura — que persiste em todas as sessões do agente como um contrato permanente entre desenvolvedor e agente.
• AWS Kiro — um fork do VS Code que atingiu ampla disponibilidade global em maio de 2026 e coloca as specs no centro da própria IDE. O Kiro impõe um pipeline estrito: requirements.md (histórias de usuário com critérios de aceitação escritos em notação EARS — "WHEN [condição] THE SYSTEM SHALL [comportamento]", um formato originalmente desenvolvido na Rolls-Royce para sistemas críticos de segurança) → design.md (diagramas de arquitetura e sequência) → tasks.md (etapas de implementação discretas e rastreáveis) → código.
• BMAD-METHOD — um framework licenciado sob MIT (v6.6.0, abril de 2026; mais de 46.700 estrelas) que orquestra doze ou mais papéis especializados de agentes — product manager, arquiteto, designer de UX, desenvolvedor, QA, scrum master — cada um lendo o documento do agente anterior e produzindo o seu próprio, criando uma cadeia rastreável desde o requisito até o código entregue.
• Tessl — instala-se como "tiles" no diretório .tessl/ do projeto e funciona com qualquer agente compatível com MCP, incluindo Claude Code e Cursor. Seus agentes são instruídos a fazer perguntas esclarecedoras primeiro, escrever a spec, aguardar aprovação explícita do desenvolvedor, e só então implementar — com a spec persistindo no repositório como memória de longo prazo e uma trilha de auditoria conforme o aplicativo evolui.
• OpenSpec — a opção mais leve: gratuito, licenciado sob MIT, vive inteiramente no repositório, não precisa de chave de API ou servidor MCP. Usa cenários opcionais de Given/When/Then e um modelo distinto de rastreamento de delta (ADDED / MODIFIED / REMOVED) construído especificamente para evoluir uma base de código existente, em vez de construções greenfield.

O trabalho acadêmico está começando a alcançar a prática: um artigo de taxonomia de processo de 2026 comparando frameworks para agentes de desenvolvimento de software de IA descobriu que o fio comum entre todos eles é separar "o que construir" de "como construir" em artefatos distintos e legíveis por agentes — exatamente a disciplina que o vibe coding ignora.

Um Prompt Ruim vs. uma Spec de Verdade

A diferença é mais fácil de ver lado a lado. Aqui está um prompt típico de vibe coding para uma funcionalidade real:

Ruim: "Adicione uma forma de os usuários exportarem seus dados como um arquivo CSV, deixe bonito."

Entregue a um agente com acesso de escrita a múltiplos arquivos, esse prompt deixa todas as decisões reais por fazer: quais campos exportar, como dados aninhados ou relacionados são achatados, o que acontece com exportações de 500.000 linhas, se o endpoint precisa de escopo de autenticação, qual deve ser o nome do arquivo e a codificação. O agente escolherá respostas — e as escolherá de forma diferente a cada regeneração.

Aqui está a mesma funcionalidade como uma spec, no formato EARS que Kiro e Spec Kit incentivam:

Bom:

• WHEN um usuário com uma conta ativa clica em "Exportar Dados" THE SYSTEM SHALL gerar um CSV contendo as colunas: id, email, created_at, last_login, subscription_tier.
• WHEN a exportação contiver mais de 50.000 linhas THE SYSTEM SHALL fazer streaming da resposta em vez de armazená-la em memória.
• WHEN um usuário sem permissão de exportação acessa o endpoint THE SYSTEM SHALL retornar um 403 com um corpo de erro que corresponda ao schema de erro existente da API.
• THE SYSTEM SHALL nomear o arquivo export-{userId}-{data ISO8601}.csv e codificá-lo como UTF-8 com BOM para compatibilidade com Excel.

Nada disso é engenharia exótica — é o mesmo raciocínio que um engenheiro competente faria em uma design review. A diferença é que está escrito antes de o agente começar, então o agente implementa contra critérios explícitos em vez de improvisá-los, e um revisor pode verificar o diff contra a spec em vez de fazer engenharia reversa da intenção a partir do código.

O que uma boa spec precisa incluir

Independentemente de qual framework uma equipe adote, as specs que realmente se sustentam em fluxos de trabalho orientados por agentes compartilham uma forma comum:

• Limites de escopo explícitos — o que a funcionalidade NÃO faz, não apenas o que faz.
• Critérios de aceitação testáveis — escritos como declarações WHEN/THEN ou Given/When/Then que um agente (ou um conjunto de testes) possa verificar mecanicamente, não texto em prosa que um humano precise interpretar.
• Forma dos dados e casos de borda — schema, nulabilidade, limites de tamanho e o que acontece nas fronteiras (entrada vazia, entrada máxima, acesso concorrente).
• Restrições não funcionais — orçamentos de performance, requisitos de autenticação/permissão e convenções de tratamento de erros que correspondam à base de código existente.
• Uma "constituição" ou documento direcionador persistente — as regras abrangentes do projeto (padrões de teste, padrões arquiteturais, dependências proibidas) que não devem precisar ser repetidas em toda spec.
• Um gate de aprovação humano explícito — o ponto em que um desenvolvedor aprova a spec antes que o agente tenha permissão para gerar código, não depois.

Conclusões

Equipes que adotam agentes de codificação de IA em 2026 devem tratar a spec, e não o prompt, como a unidade de trabalho de engenharia. Concretamente: escolha um framework de spec (OpenSpec para um início de baixo atrito em uma base de código existente, Spec Kit ou Kiro se a equipe quiser um pipeline imposto de requisitos-design-tarefas) e exija que toda tarefa de agente com múltiplos arquivos comece a partir de uma spec escrita com critérios de aceitação testáveis. Mantenha um documento de "constituição" permanente com as regras arquiteturais e de estilo que se aplicam a toda funcionalidade, para que as specs só precisem cobrir o que é realmente novo. E construa o hábito de revisão em torno de verificar o código contra os critérios de aceitação da spec — não reler o diff inteiro linha por linha, que é exatamente o gargalo que o desenvolvimento spec-driven foi projetado para remover.