Spec-Driven Development: quando a especificação vira a fonte da verdade (não o código)

Wildrik — Tue, 21 Jul 2026 01:19:33 +0000

Venho usando agentes de código (Claude Code, Cursor) e bati numa parede que todo mundo conhece: o vibe coding — descrever a tarefa e deixar a IA cuspir código — escala mal. Funciona até a terceira mudança, quando ninguém mais lembra qual era a intenção original. O código virou a única fonte de verdade, e ele é péssimo pra contar por que algo foi feito.

Foi aí que caí no Spec-Driven Development (SDD): colocar a especificação antes do código. Na prática, a "spec" é um markdown versionado no repo — requisitos + critérios de aceite — que a IA lê antes de gerar qualquer linha. Ela vira o artefato principal, não um doc que apodrece numa pasta.

A tese que tirei: o gargalo de programar com IA deixou de ser "a IA escreve código bom?". Hoje é "a IA entende o que eu realmente quero?". A spec é o que fecha essa lacuna.

Três coisas que me fizeram levar a sério:

Não é waterfall. A spec é viva — você roda quatro fases em ciclos curtos: specify → plan → tasks → implement (que em ferramentas como o Spec Kit viram comandos: /speckit.specify, /speckit.plan...). Mais perto de TDD do que de cascata.
A spec guia o agente. Em vez de prompts soltos, a IA lê a especificação e o plano. No meu uso, errou menos — e me deixou revisar a intenção antes de revisar 400 linhas de diff.
Já tem ferramenta de verdade. Spec Kit (GitHub), Kiro (AWS), Tessl, OpenSpec — todas com repo aberto. E pra começar nem precisa de muito: um simples CLAUDE.md (ou AGENTS.md) na raiz do repo já é uma forma enxuta de aplicar a ideia.

Não é bala de prata. Pra script de 50 linhas, é overhead. O ganho aparece em código que vai ser mantido, em time, ou quando você delega pesado pra agentes autônomos.

Escrevi um guia mais fundo com as 4 fases em detalhe, a comparação Spec Kit vs Kiro vs Tessl vs OpenSpec (qual escolher) e o passo a passo rodando SDD com Claude Code na prática: techknow.com.br/post/spec-driven-development

Quem aqui já tá usando spec como fonte da verdade no fluxo com IA? Curioso pra saber qual ferramenta pegou — e onde travou.

OpenCode: a alternativa open source ao Claude Code (sem lock-in de modelo nem de nuvem)

Wildrik — Thu, 25 Jun 2026 16:51:59 +0000

Venho testando agentes de código (Claude Code, Cursor, Copilot) e o que mais me chamou atenção foi o OpenCode: open-source, 160k+ stars, com duas decisões de design que mudam o jogo.

Model-agnostic de verdade: roda com Claude, GPT, Gemini, DeepSeek e modelos locais via Ollama (75+ providers). Você troca de modelo sem trocar de ferramenta, o oposto do lock-in do Claude Code (só Claude) ou Cursor.
Sem lock-in de nuvem: com Ollama local e deploy air-gapped, dá pra rodar o agente sem o código sair da máquina. Relevante pra quem tem restrição de compliance (banco, gov, jurídico).

A tese: o eixo de competição saiu de "qual modelo é mais inteligente" pra "quem controla seu workflow e seus dados".

Não é bala de prata. Em qualidade bruta de modelo o Claude Code ainda lidera. É um trade-off (liberdade, custo e controle dos dados vs qualidade no topo), não superioridade.

Escrevi um comparativo completo (OpenCode x Claude Code x Cursor x Copilot, com setup e pra quem vale) aqui: https://www.techknow.com.br/post/opencode-alternativa-claude-code

Alguém já botou o OpenCode no fluxo de trabalho? Curioso sobre a experiência com modelos locais.

DEV Community: Wildrik

Spec-Driven Development: quando a especificação vira a fonte da verdade (não o código)

OpenCode: a alternativa open source ao Claude Code (sem lock-in de modelo nem de nuvem)