Todos os artigos
20 min de leitura

Vibe Coding, Specs e a Engenharia Responsável na Era dos Agentes de IA

Ferramentas de IA gerando código a partir de descrições em linguagem natural democratizaram a produção de software. Mas democratizar produção sem elevar rigor é uma receita para sistemas frágeis. Como specs bem escritas são o antídoto para o caos do vibe coding.

Existe um fenômeno crescente que chamo de "vibe coding": descrever o que você quer em linguagem natural para uma ferramenta de IA e aceitar o código gerado sem análise crítica rigorosa. A velocidade é sedutora. O problema emerge quando esse protótipo vai para produção.

O que é Vibe Coding e Por que é Arriscado

LLMs são excelentes em gerar código plausível — código que parece certo, que segue convenções sintáticas. Mas "plausível" e "correto" são categorias diferentes. Em domínios de alta consequência — sistemas financeiros, serviços de saúde, infraestrutura crítica — a diferença é entre um sistema que funciona e um incidente de produção.

Specs como Linguagem de Precisão

Uma spec de qualidade responde:

O que o sistema deve fazer: "Dado um pagamento aprovado pela gateway, o sistema deve criar uma transação, decrementar o saldo e emitir um evento PaymentProcessed com idempotência garantida."

Casos de borda explícitos: "Idempotency key duplicada dentro de 24 horas deve retornar o resultado original sem reprocessamento."

Requisitos não-funcionais mensuráveis: "P99 < 500ms. Disponibilidade 99.9%."

Requirements, Design, Tasks

Requirements — Given-When-Then

Scenario: Successful payment with unique idempotency key
  Given a customer with sufficient balance
  And a valid idempotency key "idem-key-001"
  When the customer submits a payment of R$ 150.00
  Then the system creates a transaction with status COMPLETED
  And a PaymentProcessed event is emitted to payments.v2 topic

Design — Decisões Arquiteturais

Decision: Idempotency table with unique constraint
Rationale: Consistência forte é requisito não-negociável para pagamentos.
  Particionamento por data controla crescimento.
  Índice em (idempotency_key, created_at) mantém O(log n) lookup.

Tasks — Unidades de Trabalho

Task 1: Create idempotency_keys table migration
  Done when: migration runs, index exists, uniqueness constraint tested

Task 2: Implement IdempotencyRepository   Done when: unit tests pass including duplicate key scenario


Task 3: Implement PaymentApplicationService with idempotency check   Done when: integration tests pass all Given-When-Then scenarios

Revisão de Código Gerado por IA

Focos específicos: corretude de casos de borda (lista vazia, null, número negativo), segurança (SQL injection, secrets em logs), performance (N+1 queries, batch operations), consistência com o design (abstrações respeitadas).

Vibe coding é inevitável para prototipagem. Specs rigorosas são inegociáveis para produção.