SpecScore vs CodeSpeak
Duas respostas para "para que servem as especificações". O CodeSpeak trata a especificação comocódigo-fonte — um LLM a compila, e você mantém a especificação em vez do código. O SpecScore trata a especificação como um contrato aberto e durável — você mantém o seu código, e qualquer agente (ou nenhum) pode ler, fazer lint e rastreá-la.
O que têm em comum.
O que o CodeSpeak faz bem.
O CodeSpeaké um sistema de programação movido a LLM que compila especificações em inglês estruturado para código.
Uma tese ousada, defendida com credibilidade
"Mantenha a especificação, não o código" é um reenquadramento genuíno, não um ajuste incremental. Vem do designer da linguagem Kotlin, e merece ser levado a sério: se a especificação é a fonte, o código gerado se torna um detalhe de implementação.
Takeover de código-para-especificação
O codespeak takeover lê o código-fonte existente e produz uma especificação que captura seu comportamento — uma rampa de entrada de baixa fricção para código legado, com compressão especificação-para-código relatada de aproximadamente 5–10×.
Recuperação de intenção a partir de sessões de agentes
O Intent Studio do CodeSpeak extrai requisitos de sessões de agentes anteriores — colhendo a intenção que você já expressou em vez de pedir que você escreva uma especificação a partir de uma página em branco.
Comparação de funcionalidades.
Os dois fazem apostas diferentes, então a tabela compara filosofia e mecânica, não vencedores.
| Capacidade | CodeSpeak | SpecScore |
|---|---|---|
| Fonte da verdade | A especificação (entrada de compilação) | A especificação é o contrato; o código é o entregável |
| Código gerado | Produzido por um LLM, não mantido à mão | Você e seus agentes escrevem e são donos do código |
| Formato da especificação | Inglês simples, definido pelo CodeSpeak | Padrão aberto Markdown + YAML, schema publicado |
| Especificação → código | Funcionalidade central (compilador LLM proprietário) | Fora do escopo — qualquer agente implementa |
| Funciona sem o fornecedor | As especificações compilam através do CodeSpeak | Sim — as especificações funcionam com qualquer agente, ou nenhum |
| Lint de especificação | Não documentado | Qualidade do conteúdo — verbos vagos, ACs ausentes, referências soltas |
| Rastreabilidade código-para-especificação | Via regeneração | specscore: anotações + Verifies: trailers |
| Determinismo | Compilação por LLM (não determinística) | Consultas determinísticas via CLI; código escrito normalmente |
| Código → especificação | codespeak takeover | survey + escrita manual |
| Abertura | Sistema proprietário | Aberto — formato CC BY 4.0, ferramentas MIT / Apache-2.0 |
| Estágio | Prévia alpha | Em produção |
Onde o SpecScore difere.
Você mantém o seu código
O CodeSpeak gera e regenera a implementação; o código é uma saída, não um ativo. O SpecScore deixa o código onde ele pertence — nas suas mãos, na sua linguagem, revisável linha por linha. A especificação adiciona clareza e rastreabilidade sem tirar o código de você.
Suas especificações são portáteis
Uma especificação do CodeSpeak é valiosa porque o CodeSpeak a compila. Uma especificação do SpecScore é valiosa por si só — é Markdown bem estruturado que qualquer agente consegue ler, e permanece útil sem nenhuma ferramenta do SpecScore instalada. Adote-a com qualquer ferramenta, ou nenhuma. Saia quando quiser.
A ambiguidade é pega antes de custar
Com um compilador LLM, uma especificação ambígua vira código errado no momento do build. O lint do SpecScore revela verbos vagos, critérios de aceitação ausentes e referências soltas antes que um agente aja sobre eles.
$ specscore lint checkout/apply-discount.md ✗ R3 no acceptance criteria ✗ verb "handle gracefully" — unmeasurable
Determinismo e rastreabilidade
A resposta do CodeSpeak para "qual código implementa isto?" é "tudo, regenerado". A resposta do SpecScore é um arquivo e uma linha específicos, viaspecscore code refs e trailers Verifies: nos commits — determinística, auditável, comparável em diff.
Um grafo de artefatos estruturado
A unidade do CodeSpeak é um arquivo de especificação em prosa. O SpecScore tem uma hierarquia tipada — Ideas promovem para Features, Features carregam Requisitos e Critérios de Aceitação com IDs, Plans referenciam ACs, Tasks referenciam Plans — tudo navegável por máquina.
Nenhum fornecedor no caminho do build
O SpecScore é um binário Go único. O lint roda no CI e em hooks de pre-commit sem conta, sem chamada de serviço, sem ida e volta a um LLM no seu build.
Quando usar cada um.
Escolha o CodeSpeak quando…
- Você quer parar de manter código e deixar a especificação ser a fonte.
- Você está confortável em depender do compilador de um fornecedor por essa alavancagem.
- Você quer comprimir uma codebase existente em uma especificação muito mais curta.
Use o SpecScore quando…
- Você quer especificações que sobrevivam a qualquer ferramenta — portáteis por construção.
- Você quer manter o seu código, na sua linguagem, revisável e seu.
- Você precisa de imposição de qualidade de especificação — o lint pega ambiguidade cedo.
- Você precisa de rastreabilidade código-para-especificação determinística.
- Você não quer nenhum fornecedor nem ida e volta a um LLM no caminho do seu build.
Duas apostas diferentes.
O CodeSpeak é uma aposta num compilador: entregue a especificação, e confie que ele produzirá e reproduzirá o código. O SpecScore é uma aposta num formato: mantenha a especificação aberta e portátil, mantenha o código seu, e deixe qualquer agente trabalhar contra ela.
Uma troca portabilidade por alavancagem. A outra mantém você livre — e com lint.
Feedback
Esta comparação é baseada em documentação e código-fonte publicamente disponíveis. Algo incorreto ou desatualizado? abra uma issue de correção. Quer que comparemos o SpecScore com outra ferramenta? solicite uma.