Esta série explora uma mudança estrutural na forma como concebemos e praticamos engenharia de software na era dos Agentes de IA.

O argumento central é que estamos migrando de um modelo centrado em código como artefato principal para um modelo centrado em especificação como fonte primária de verdade.

Em vez de tratar LLMs como assistentes improvisando soluções a partir de prompts vagos, passamos a utilizá-los como executores de intenções formalizadas, operando dentro de contratos explícitos, restrições verificáveis e estruturas semânticas bem definidas.

Ao longo de cinco artigos bastante didáticos (no padrão de ensino da Data Science Academy), o foco será mostrar porque o Vibe Coding é insuficiente para sistemas complexos, como a engenharia guiada por intenção redefine o papel do desenvolvedor, quais padrões tornam uma especificação executável de fato, quais ferramentas compõem esse novo stack, como arquitetar sistemas agênticos com contexto rígido e validação formal, e porque o código tende a se tornar um artefato transitório enquanto a intenção se consolida como o ativo durável.

O objetivo não é apenas apresentar ferramentas ou técnicas isoladas, mas propor uma nova arquitetura mental e operacional para desenvolvimento de software, onde especificações estruturadas, contratos explícitos e agentes orquestrados substituem a improvisação por um pipeline determinístico, auditável e escalável.

A série foi dividida em 5 artigos:

  • Parte 1 – Sai o “Vibe Coding” Entra a Engenharia Guiada Por Intenção
  • Parte 2 – Anatomia de Uma Especificação Executável: EARS, GEARS e Markdown Estruturado
  • Parte 3 – O Ecossistema de Ferramentas: Spec Kit, Tessl, Claude Code e skills.md
  • Parte 4 – A Arquitetura Agêntica: Orquestrando LLMs com Contexto Rígido e Validação
  • Parte 5 – O Futuro do Desenvolvimento: Código Descartável e a Persistência da Intenção

Aqui está a Parte 1. Boa leitura.

Parte 1 – Sai o “Vibe Coding” Entra a Engenharia Guiada Por Intenção

Estamos vivendo um daqueles momentos raros na história do software. Algo comparável à passagem do Assembly para linguagens de alto nível ou à revolução que a nuvem e o DevOps trouxeram.

Dessa vez, o protagonista é a Inteligência Artificial Generativa através de ferramentas como GitHub Copilot, Cursor, Claude Code e Amazon Q (entre outras), que tornaram escrever código algo absurdamente rápido e acessível.

E isso é incrível. Mas também criou um problema que pouca gente está discutindo com a seriedade que merece.

Gerar código ficou fácil. Gerar código certo, seguro e que se sustenta ao longo do tempo? Isso continua sendo muito difícil e, em muitos casos, ficou ainda mais difícil.

O Fenômeno do “Vibe Coding”

Com a evolução da IA Generativa, surgiu uma prática que muita gente na comunidade chama de “Vibe Coding”.

Funciona mais ou menos assim: você envia um prompt para a IA, vê se o resultado “parece” funcionar, ajusta aqui e ali, e segue em frente. É programação por tentativa e erro, guiada mais por intuição do que por compreensão real do que está acontecendo por baixo dos panos.

Para um script rápido ou um protótipo? Funciona. Para um sistema empresarial que vai rodar por anos e do qual dependem decisões de negócio? É uma receita para o desastre.

O ponto central é este: o problema não é a IA escrever código ruim. O problema é que nós não estamos sabendo dizer para ela o que queremos com clareza suficiente. A IA entrega o que pedimos, o problema é que muitas vezes pedimos errado.

O Código da IA Dura Mais do Que Imaginamos

Tem um dado que vale a pena prestar atenção.

Pesquisas recentes mostram que o código gerado por IA tende a sobreviver mais tempo nos repositórios do que o código escrito por humanos, com uma taxa de modificação quase 16 pontos percentuais menor por linha. Só que esse mesmo código precisa de mais correções de bugs ao longo do tempo.

Ou seja: o código fica lá, parado, mas carregando problemas sutis que vão aparecendo aos poucos. Isso não é um problema de execução, é um problema de especificação. A IA construiu exatamente o que pedimos. Só que o que pedimos não era exatamente o que precisávamos.

Entra em Cena o Spec-Driven Development

É aqui que o Spec-Driven Development (SDD) (ou Desenvolvimento Guiado Por Especificação) entra na conversa. E não como mais uma buzzword ou modismo, mas como uma mudança real de mentalidade.

A ideia é simples, mas poderosa: em vez de tratar a documentação como algo burocrático que ninguém lê (e que fica desatualizado no dia seguinte), o SDD coloca a especificação no centro de tudo. Ela vira a fonte da verdade. O código passa a ser um produto derivado dela, algo que pode, inclusive, ser regenerado sempre que a especificação mudar.

Pense assim: na construção civil, a planta do engenheiro tem mais autoridade do que a parede que o pedreiro levantou. Se a parede não está de acordo com a planta, a parede é refeita. No SDD, a lógica é a mesma: se o código não reflete a especificação, o código é regenerado.

Por Que o Modelo Antigo Não Funciona Mais

Durante décadas, todo mundo na indústria de software concordou, em teoria, que requisitos e arquitetura vinham primeiro.

Na prática?

O código sempre foi o rei. Documentos de requisitos viravam ficção histórica semanas depois de serem escritos. Quando havia conflito entre o que a documentação dizia e o que o sistema fazia, o código sempre vencia.

Isso já era problemático antes. Com Agentes de IA capazes de gerar milhares de linhas em segundos, virou algo insustentável. Ninguém consegue revisar tudo isso linha por linha, é humanamente impossível. A única saída é subir o nível de abstração.

O engenheiro de software precisa deixar de ser apenas um “escritor de código” para se tornar um “arquiteto de intenção”, alguém que define o que o sistema deve fazer e por que, com precisão suficiente para que a IA cuide do como. E isso vale para outras funções onde o código é parte da solução.

Chega de “Comandar e Rezar”

Muita gente usa IA no modo “prompt-and-pray”: joga um comando vago e torce para que o resultado faça sentido. Quando não faz, ajusta o prompt e tenta de novo. É um ciclo frustrante e ineficiente, principalmente para quem não tem o conhecimento devido.

O SDD propõe o oposto: em vez de dar pistas vagas e esperar que a IA adivinhe, você entrega um contexto rico, estruturado e completo. Regras de negócio explícitas, limites operacionais claros, restrições de arquitetura bem definidas. Isso reduz drasticamente a chance de a IA “alucinar” como inventar bibliotecas que não existem, criar fluxos que não fazem sentido ou ignorar regras de segurança que nunca foram mencionadas.

Na prática, a especificação funciona como um “super prompt”, só que versionado, persistente e legível por qualquer pessoa da equipe. Ela resolve, inclusive, o problema da “amnésia” dos agentes, quando o contexto se perde ao ultrapassar o limite de tokens ou ao reiniciar uma sessão.

Ambiguidade Custa Caro. E com IA, Custa Muito Mais

Requisitos vagos sempre foram um problema no desenvolvimento de software. Mas quando um desenvolvedor humano encontra algo ambíguo, ele pergunta, negocia, pede esclarecimento. A IA não faz isso. Ela tenta adivinhar e faz isso em silêncio, sem avisar ninguém.

Essas suposições silenciosas vão se acumulando no código como uma dívida técnica invisível. O sistema parece funcionar, passa nos testes básicos, mas falha em cenários específicos que ninguém previu, porque ninguém os descreveu.

O SDD exige que a gente “desacelere para acelerar”. Sim, escrever uma boa especificação dá trabalho e leva tempo. Mas esse investimento inicial se paga rápido: menos idas e vindas com a IA, menos bugs, menos retrabalho. O conceito por trás disso é o de “correção por construção”, acertar de primeira porque o pedido foi feito direito. Fornecemos um exemplo perfeito sobre isso no Estudo de Caso dentro de Pipelines Para LLMs com ETL e Orquestração de Dados Não Estruturados, aqui na DSA.

E Como o SDD se Compara com TDD e BDD?

O SDD não substitui práticas como Test-Driven Development (TDD) ou Behavior-Driven Development (BDD). Ele opera em um nível acima, orquestrando o processo.

Enquanto o TDD foca em validar a implementação e o BDD em descrever comportamentos esperados, o SDD foca em definir a intenção e planejar a construção.

Na verdade, uma boa especificação de SDD pode (e deve) incluir instruções para que a IA gere testes no estilo TDD ou cenários BDD como parte do plano. A diferença é que o SDD dá o contexto que essas práticas precisam para funcionar bem, especialmente quando quem vai executá-las é um agente autônomo e não um ser humano. A tabela abaixo mostra uma comparação interessante:

tabela

Resumindo: O SDD não é sobre escrever menos código. É sobre pensar melhor antes de pedir para a IA escrever qualquer código. O que, claro, requer conhecimento.

Se quiser ver o conceito na prática, confira aqui.

Continuaremos na Parte 2.

Equipe DSA