Entendendo o Desenvolvimento Orientado por Especificação (SDD): Kiro, Spec-Kit, Tessl

• Spec-Driven Development (SDD) é uma abordagem de codificação com IA em que a especificação (spec) é escrita primeiro, antes do código, e passa a servir como fonte da verdade (source of truth) para desenvolvedores e IA
• O SDD é dividido em três níveis de implementação, evoluindo de forma gradual: spec-first (especificação primeiro), spec-anchored (preservação da especificação para manutenção) e spec-as-source (uso da especificação como arquivo-fonte principal, sem edição direta do código pelo desenvolvedor)
• O Kiro oferece um workflow simples de 3 etapas — requisitos → design → tarefas; o spec-kit usa um workflow fortemente baseado em regras chamado constituição (constitution); e o Tessl experimenta uma abordagem spec-as-source, mapeando especificação e código em uma relação 1:1
• As três ferramentas exigem processo demais para correções pequenas, revisar arquivos Markdown é mais trabalhoso do que revisar código, e mesmo com janelas de contexto grandes, a IA ainda tem limitações para seguir todas as instruções corretamente
• O SDD relembra os casos de fracasso do antigo desenvolvimento orientado por modelos (MDD) e pode acabar reunindo os pontos fracos dos dois mundos — não determinismo e falta de flexibilidade —, o que exige validação de sua utilidade em projetos reais

---

Definição de desenvolvimento orientado por especificação (SDD)

• SDD é uma abordagem “documentação primeiro”, em que a especificação é escrita antes do código e atua como fonte única da verdade (single source of truth) tanto para o desenvolvedor quanto para a IA
• O GitHub define isso dizendo que “manutenção de software significa a evolução da especificação; a linguagem comum do desenvolvimento sobe para um nível mais alto, e o código vira a etapa final”
• A Tessl descreve como “uma abordagem de desenvolvimento em que a especificação se torna o artefato principal, e não o código; a especificação expressa a intenção em uma linguagem estruturada e testável, e os agentes geram o código com base nela”
• O SDD se divide em três níveis de implementação
  • Spec-first: escrever primeiro uma especificação bem estruturada e usá-la no workflow de desenvolvimento assistido por IA
  • Spec-anchored: manter a especificação mesmo após o trabalho concluído, continuando a usá-la na evolução e manutenção daquela funcionalidade
  • Spec-as-source: a especificação continua sendo o principal arquivo-fonte ao longo do tempo; o desenvolvedor edita apenas a especificação e não mexe diretamente no código
• Toda abordagem SDD é spec-first, mas nem toda abordagem busca ser spec-anchored ou spec-as-source; em muitos casos, a estratégia de manutenção da especificação ao longo do tempo é ambígua ou totalmente aberta

O que é uma especificação (spec)

• Uma especificação é um artefato estruturado e orientado a comportamento, escrito em linguagem natural, que expressa uma funcionalidade de software e serve de guia para agentes de codificação com IA
• A definição mais consistente é compará-la a um documento de requisitos do produto (PRD)
• A especificação deve ser distinta dos documentos gerais de contexto do codebase
  • O contexto geral inclui arquivos de regras, descrições de alto nível do produto e do codebase; algumas ferramentas chamam isso de memory bank
  • Os arquivos de memory bank são relevantes em todas as sessões de codificação com IA do codebase, enquanto uma especificação só é relevante para uma tarefa específica de criar ou alterar uma funcionalidade
• Cada variação de SDD define sua própria abordagem para a estrutura, o nível de detalhe e a forma de organização das especificações dentro do projeto

A dificuldade de avaliar ferramentas de SDD

• Avaliar ferramentas e abordagens de SDD de uma forma próxima ao uso real consome muito tempo
  • É preciso testar em problemas de diferentes tamanhos, em projetos greenfield e brownfield, e também gastar tempo revisando e corrigindo os artefatos intermediários de forma profunda, não superficial
• O post do GitHub sobre o spec-kit enfatiza que “o importante é que seu papel não é apenas dar direção, mas validar; é preciso refletir e refinar em cada etapa”
• Duas das três ferramentas parecem exigir mais trabalho para adoção em codebases existentes, o que dificulta ainda mais avaliar sua utilidade em ambientes brownfield
• Até ouvir relatos de pessoas que as usaram por algum tempo em codebases reais, ainda existem muitas perguntas em aberto sobre como isso funciona na prática

Kiro

• O Kiro é a ferramenta mais simples e leve das três e, em grande parte, se encaixa em uma abordagem spec-first
  • Só foram encontrados exemplos de uso para tarefas ou histórias de usuário; não há menção de como usar documentos de requisitos de forma spec-anchored ao longo de várias tarefas com o passar do tempo
• Workflow: requisitos → design → tarefas
  • Cada etapa do workflow é representada por um documento Markdown, e o Kiro guia essas 3 etapas dentro de uma distribuição baseada em VS Code

• Principais componentes do Kiro

  • Requisitos (Requirements)
    • Estruturados como uma lista de requisitos em que cada requisito representa uma “história de usuário” (no formato As a...)
    • Os critérios de aceitação usam o formato GIVEN... WHEN... THEN...
  • Design
    • Inclui seções como diagrama de arquitetura dos componentes, fluxo de dados, modelo de dados, tratamento de erros, estratégia de testes, abordagem de implementação e estratégia de migração
    • Não está claro se essa estrutura é consistente ou varia conforme a tarefa
  • Tarefas (Tasks)
    • Lista de tarefas rastreadas por número de requisito
    • Oferece elementos extras de UI para executar uma tarefa por vez e revisar as mudanças de cada tarefa

• O memory bank do Kiro

  • O Kiro chama o conceito de memory bank de steering
    • O conteúdo é flexível, e o workflow aparentemente não depende da existência de arquivos específicos
  • A estrutura padrão que o Kiro gera ao ser solicitado a criar documentos de steering é product.md, structure.md e tech.md

Spec-kit

• O spec-kit é a versão de SDD do GitHub, distribuída como uma CLI capaz de gerar a configuração do workspace para vários assistentes gerais de programação
• Depois de configurar a estrutura, a interação com o spec-kit acontece por comandos slash do assistente de programação
• Como todos os artefatos ficam diretamente no workspace, ele é a ferramenta mais personalizável entre as três discutidas

• Workflow do spec-kit

  • Workflow: Constituição (Constitution) → 𝄆 Especificação (Specify) → Plano (Plan) → Tarefas (Tasks) 𝄇
  • O conceito de memory bank no spec-kit é um pré-requisito da abordagem orientada por especificação
    • Ele é chamado de constituição (constitution) e contém princípios de alto nível “imutáveis” que devem sempre se aplicar a qualquer mudança
    • É um arquivo de regras muito forte e muito usado no workflow

• Como o spec-kit funciona

  • Em cada etapa do workflow (specify, plan, tasks), ele usa scripts bash e templates para instanciar conjuntos de arquivos e prompts
  • O workflow usa muitos checklists dentro dos arquivos para acompanhar esclarecimentos necessários do usuário, violações da constituição, tarefas de pesquisa etc.
    • Eles funcionam como uma espécie de “definition of done” de cada etapa do workflow (embora não haja 100% de garantia, já que a IA os interpreta)
  • Uma única especificação é composta por vários arquivos
    • Ex.: data-model, plan, tasks, spec, research, api, component e outros 8 arquivos

• A abordagem do spec-kit

  • Inicialmente, o GitHub parece apontar para uma abordagem spec-anchored
    • “Estamos repensando as especificações não como documentos estáticos, mas como artefatos vivos e executáveis que evoluem junto com o projeto; a especificação se torna a fonte compartilhada da verdade”
  • Porém, como o spec-kit cria uma branch para cada especificação gerada, isso sugere que ele trata a especificação como um artefato vivo apenas durante o ciclo da solicitação de mudança, e não durante a vida útil da funcionalidade
  • Discussões da comunidade também apontam essa confusão, e o spec-kit ainda parece ser apenas spec-first, sem realmente ser spec-anchored ao longo do tempo

Tessl Framework

• O Tessl Framework está em beta fechado e, como o spec-kit, é distribuído como uma CLI capaz de gerar a estrutura de workspace e configuração para diferentes assistentes de programação
• Os comandos da CLI também funcionam como servidor MCP

• Características do Tessl

  • É a única das três ferramentas que mira explicitamente uma abordagem spec-anchored e também explora SDD no nível spec-as-source
  • As especificações do Tessl podem servir como o principal artefato mantido e editado, enquanto o código é marcado no topo com o comentário // GENERATED FROM SPEC - DO NOT EDIT
    • No momento, existe um mapeamento 1:1 entre especificação e arquivo de código, ou seja, uma especificação vira um arquivo do codebase
    • Como ainda está em beta e experimentando diferentes versões, isso também pode evoluir para um nível em que uma especificação mapeie para um componente de código com vários arquivos

• Estrutura da especificação no Tessl

  • Tags como @generate e @test instruem o Tessl sobre o que ele deve gerar
  • A seção de API mostra a ideia de definir na própria especificação a interface mínima exposta para outras partes do codebase, garantindo que partes importantes do componente gerado fiquem sob controle total do mantenedor
  • Ao executar tessl build, o arquivo de código JavaScript correspondente é gerado

• O nível de abstração do Tessl

  • Ao posicionar as especificações para spec-as-source em um nível de abstração relativamente baixo por arquivo de código, reduz-se a quantidade de etapas e interpretação necessária por parte do LLM e, portanto, a probabilidade de erro
  • Mesmo nesse nível baixo de abstração, ainda se observa não determinismo ao gerar código várias vezes a partir da mesma especificação
    • O processo de reescrever repetidamente a especificação e torná-la cada vez mais específica para aumentar a reprodutibilidade da geração de código relembra as armadilhas e os desafios de escrever especificações completas e sem ambiguidade

Observações e perguntas

• Um único workflow consegue atender todas as escalas?

  • Kiro e spec-kit oferecem, cada um, um workflow prescritivo único, mas ambos talvez não sirvam bem para a maioria dos problemas reais de programação
  • Não está claro se oferecem variedade suficiente para se adaptar ao tamanho do problema
    • Ao tentar corrigir um bug pequeno com Kiro, o workflow pareceu quebrar uma noz com uma marreta
    • O documento de requisitos transformou um bug pequeno em 4 “histórias de usuário”, com 16 critérios de aceitação no total
  • Ao usar o spec-kit, também ficou incerto para que tamanho de problema ele deveria ser usado
    • Ao testar uma funcionalidade que, em equipes anteriores, seria uma história de 3 a 5 pontos, o número de etapas e a quantidade de arquivos Markdown gerados pelo spec-kit pareceram excessivos para o tamanho do problema
    • No mesmo tempo, daria para implementar a funcionalidade com uma codificação assistida por IA “normal” e com sensação muito maior de controle
  • Uma ferramenta de SDD eficaz precisa oferecer flexibilidade para pelo menos alguns workflows centrais diferentes, cobrindo mudanças de tamanhos e tipos distintos

• Revisar Markdown em vez de código?

  • O spec-kit gera muitos arquivos Markdown para revisar
    • Eles são repetitivos entre si e também repetitivos em relação ao código já existente
    • Alguns já incluem código, o que torna tudo muito verboso e cansativo de revisar
  • No Kiro, há apenas 3 arquivos, e o modelo mental “requisitos > design > tarefas” é mais intuitivo de entender, o que facilita um pouco
    • Ainda assim, o Kiro também é verboso demais para um bug pequeno cuja correção foi pedida
  • Francamente, fica a impressão de que é melhor revisar o código do que todos esses arquivos Markdown
  • Uma ferramenta de SDD eficaz precisa oferecer uma experiência realmente muito boa de revisão de especificações

• Falsa sensação de controle?

  • Apesar de todos esses arquivos, templates, prompts, workflows e checklists, é frequente observar casos em que o agente no fim não segue todas as instruções
  • Janelas de contexto maiores são citadas como um dos fatores que viabilizaram o SDD, mas uma janela maior não significa que a IA entenda corretamente tudo o que está dentro dela
  • Exemplos
    • O spec-kit tinha uma etapa de pesquisa durante o planejamento e fez bastante investigação sobre código existente, mas no fim o agente ignorou que aquilo era a descrição de uma classe já existente e tratou tudo como uma nova especificação, gerando tudo de novo e criando duplicações
    • Além de exemplos em que a IA ignora instruções, também foram vistos agentes que obedecem instruções em excesso, tentando seguir de forma exagerada alguma diretriz específica (por exemplo, um dos artigos da constituição)
  • Pela experiência passada, a melhor forma de controlar o que se constrói são passos pequenos e iterativos; por isso há muito ceticismo sobre a ideia de investir tanto em especificação e design antecipados
  • Uma ferramenta de SDD eficaz deveria aceitar uma abordagem iterativa, mas pacotes de trabalho pequenos parecem quase contrariar a própria ideia de SDD

• Como separar bem especificação funcional e especificação técnica?

  • No SDD, é comum a ideia de fazer de propósito uma separação entre especificação funcional e implementação técnica
    • A aspiração fundamental é que, no fim, a IA preencha toda a solução e todos os detalhes, e que a mesma especificação possa até ser usada com outras stacks tecnológicas
  • Na prática, ao testar o spec-kit, houve muita confusão sobre quando permanecer no nível funcional e quando adicionar detalhes técnicos
    • Tutoriais e documentação também não são consistentes nesse ponto, e existem interpretações diferentes sobre o que seria “puramente funcional”
  • Basta lembrar de quantas histórias de usuário não conseguiram separar direito requisitos e implementação para ver que, como profissão, nosso histórico nisso não é dos melhores

• Quem é o usuário-alvo?

  • Muitas demos e tutoriais de ferramentas de desenvolvimento orientado por especificação incluem coisas como definição de produto e metas de funcionalidade, além de usar termos como “história de usuário”
  • A ideia aqui talvez seja usar a IA como viabilizadora de cross-skilling, para que desenvolvedores participem mais ativamente da análise de requisitos
    • Ou talvez que o desenvolvedor trabalhe em par com alguém de produto dentro desse workflow?
  • Nada disso é explicado de forma explícita, e tudo é apresentado como se fosse natural que o desenvolvedor fizesse toda essa análise
  • Então, para que tipo e tamanho de problema o SDD serve?
    • Provavelmente não para funcionalidades grandes que ainda estão muito pouco claras; nesses casos, com certeza ainda seriam necessárias técnicas mais especializadas de produto e requisitos, além de pesquisa e envolvimento de stakeholders

• Spec-anchored e spec-as-source: estamos aprendendo com o passado?

  • Muitas pessoas traçam paralelos entre SDD e TDD ou BDD, mas especialmente no caso de spec-as-source, outra comparação importante é o MDD (desenvolvimento orientado por modelos)
  • No início da carreira, houve trabalho em alguns projetos que usavam bastante MDD, e testar o Tessl Framework trouxe isso à memória o tempo todo
    • Os modelos no MDD eram basicamente especificações, mas expressas não em linguagem natural, e sim em UML customizada ou DSL textual
    • Para transformar essas especificações em código, eram construídos geradores de código customizados

• Comparação entre MDD e SDD

  • No fim, o MDD não teve sucesso em aplicações de negócio, porque ficava em um nível de abstração incômodo e gerava overhead e restrições demais
  • Por outro lado, os LLMs removem parte desse overhead e dessas restrições do MDD, criando uma nova esperança de que agora seja possível focar em escrever a especificação e gerar o código
  • Com LLMs, você não fica preso a uma linguagem de especificação pré-definida e passível de parsing, nem precisa construir geradores sofisticados de código
    • O preço, claro, é o não determinismo dos LLMs
  • Estruturas parseáveis também tinham a vantagem de oferecer muito suporte ferramental para ajudar quem escreve a especificação a produzir especificações válidas, completas e consistentes — e isso agora se perde
  • Spec-as-source, e até mesmo spec-anchoring, podem acabar reunindo os pontos fracos tanto do MDD quanto dos LLMs: falta de flexibilidade e não determinismo
  • Vale olhar para as tentativas do passado de spec-from-code e aprender com elas ao explorar o desenvolvimento orientado por especificação hoje

Conclusão

• Pessoalmente, ao usar codificação assistida por IA, muitas vezes vale a pena gastar tempo escrevendo com cuidado a forma de especificação que será fornecida ao agente de codificação
  • Por isso, o princípio geral de spec-first certamente tem valor em muitas situações
• As diferentes abordagens para estruturar especificações são muito necessárias e hoje estão entre as perguntas mais frequentes feitas por profissionais
  • “Como estruturar um memory bank?”, “Como escrever bons documentos de especificação e design para IA?”
• No entanto, o termo “desenvolvimento orientado por especificação” ainda não está bem definido e já começou a se diluir semanticamente
  • Recentemente, já se ouve até o uso de “spec” basicamente como sinônimo de “prompt detalhado”

• Avaliação das ferramentas

  • Algumas tentam levar workflows existentes para agentes de IA de forma literal demais, e com isso podem acabar amplificando desafios já conhecidos, como sobrecarga de revisão e alucinações
  • Principalmente nas abordagens mais sofisticadas, que geram muitos arquivos, vem à mente a palavra composta alemã “Verschlimmbesserung” (tornar algo pior ao tentar melhorá-lo)
    • Fica a dúvida se, na tentativa de melhorar, não se está na verdade piorando algo

[aer0700]

Parece parecido com discussões anteriores, como document driven development ou readme driven development.
https://pt.news.hada.io/topic?id=15502

[GN⁺]

Opiniões do Hacker News

• Tenho acompanhado recentemente a tendência de SDD (desenvolvimento orientado por especificação); esse movimento parece racional, mas também passa a sensação de estarmos voltando à era pré-Agile, de especificações funcionais e documentos de design. Não chega a ser totalmente Big Design Up Front, mas parece caminhar cada vez mais para “software funcionando == documentação perfeita”.
  Referência sobre Big Design Up Front, Referência sobre o Manifesto Ágil

  • Especificações funcionais e documentos de design acabam sendo, no fim das contas, uma forma de programar em linguagem natural. Antes, uma pessoa precisava recodificar isso em uma linguagem de programação, mas agora compiladores automatizados como LLMs (grandes modelos de linguagem) começaram a assumir esse trabalho. Com isso, passamos a poder pular uma etapa nesse processo (com taxas de sucesso variáveis).<br /> Já o Agile não se preocupa com qual linguagem o software é feito; a essência está em “eliminar o gerente” e fazer com que os próprios desenvolvedores assumam também o trabalho de gestão. Os 12 princípios tratam com mais detalhe do que os desenvolvedores precisam fazer quando não há gerente

  • Behaviour Driven Design pode produzir “especificações vivas”, assim como Test Driven Design. Desde os critérios de descoberta do domínio até a validação de aprovação nos testes, tudo pode permanecer em uma forma de documentação legível por humanos, ligada diretamente ao test harness para verificar a funcionalidade atual. Assim, você obtém uma especificação claramente validada, colaborativa e iterável por meio de relatórios de BDD, além de cobrir Agile, JIT e YAGNI sem trabalho inicial desnecessário. Não há motivo para voltar ao waterfall

  • Também dá para começar com um design pequeno: escrever uma especificação de uma ou duas páginas, usar um LLM para gerar código e testes, e então ir refinando de forma iterativa. Se você realmente confia 100% em codificação por LLM, então é lógico gerenciar de forma sistemática a entrada das especificações (prompts em inglês). Em vez de descartar os prompts, organizá-los permite reutilizá-los depois ou adicionar restrições extras com clareza<br /> Mas eu ainda fico inseguro em usar LLM em código de produção importante, então tenho experimentado só para sandbox/testes/demos. Uso apenas onde a qualidade do código não é tão crítica

  • O próprio spec-driven development é uma boa ideia. Porém, as implementações atuais simplesmente entregam arquivos markdown não estruturados ao agent e, como o resultado não sai direito, na prática não há reprodutibilidade nenhuma. Se o agente também for escrever a especificação, ela deveria ser estruturada de forma que pudesse ser convertida automaticamente até em código stub e testes. Em vez de deixar tudo só em markdown, se isso fosse integrado com geradores de código, a reprodutibilidade melhoraria muito. Na prática, fazer assim pode reduzir bastante o tempo gasto com geração de código repetitivo

• Ao usar o SpecKit, achei realmente interessante e satisfatório, mas tive dificuldade em encontrar exemplos ou formas de uso mais complexas do mundo real. A maioria dos tutoriais para na instalação básica e em algo no nível de “fazer um app de lista de tarefas”. Gostaria que compartilhassem casos reais de melhoria gradual ou refatoração de codebases legadas, ou como abordar grandes projetos em que spec driven development não foi aplicado desde o começo

  • Eu também senti, usando BDD junto com codificação via CLI, que registrar funcionalidades diretamente em código real é muito mais eficaz do que markdown longo e prolixo. Se for preciso uma checklist para a AI seguir, um arquivo como agents.md já basta. Registrando uma vez aqueles padrões de coding e requisitos não funcionais (NFR), já dá para fazer o agente segui-los com clareza

  • Para usar de verdade, é preciso ler diretamente os templates ou o source code para entender o que realmente está acontecendo. Em projetos assim, acho que isso é até um processo natural

• Quando, depois de apresentar um especialista em delivery com AI vindo da Thoughtworks, começaram a falar de memory banks, me identifiquei na hora. Nós também trabalhamos em ambientes em que “AI é a moda do momento”, e quando o memory bank cresce demais a AI acaba se perdendo e o resultado sai todo bagunçado. No fim, só é realmente aplicável no trabalho real quando alguém que entende completamente o produto lidera a AI diretamente. Já perdi a conta de quantas vezes a AI me enganou; quando uma pessoa a orienta de novo, ela sempre pede desculpas e diz que entendeu, mas isso não muda muita coisa. Também é inviável, na prática, fazer a AI ler e validar a imensidão de documentos que elas mesmas produzem entre si. Dá até a sensação de que seria muito melhor simplesmente trabalhar direto nesse tempo

  • Fico curioso sobre o que exatamente querem dizer com memory bank, e que papel concreto estão tentando atribuir a isso

  • No momento atual, a função de memory mais atrapalha do que ajuda. Se usada sem uma estratégia decente de busca/consulta, ela só amplifica maus resultados. A maioria dos sistemas de memory é projetada para o paradigma de chat único, então em ambientes variados eles só criam problemas. A verdadeira “memória” deveria ser uma “metacognição/default mode network” separada do agente principal, que desenha de forma assíncrona a estrutura da tarefa e o contexto, e então esse metamodelo orienta cada prompt. Ou seja, o certo seria uma “memória baseada em agentes”

  • Também não entendo colocar o título de ‘thought leader’ em lugares como o LinkedIn. Hoje em dia é realmente difícil saber o que esse tipo de título significa

• Quero compartilhar uma experiência recente: nas últimas duas semanas experimentei SpecKit e Claude Code em dois novos projetos. Como desenvolvi ambos sozinho, pude testar sem muita pressão. No primeiro projeto, deixei o SpecKit tocar tudo sozinho; levou 10 dias para concluir todas as tarefas, mas a maioria dos testes do resultado falhou e o build quebrou. Acabei gastando o mesmo tanto de tempo para corrigir os problemas, e o Claude perdia muita credibilidade porque, ao consertar uma coisa, quebrava outra<br /> No segundo projeto, quis iterar em unidades menores. Depois do planejamento com o SpecKit, adicionei slash commands para criar um backlog.md, depois usei plan-sprint para gerar um arquivo com os objetivos da sprint e o detalhamento das tarefas, e implement-sprint para processar tudo de uma vez. Mas mesmo assim o processo não seguia as instruções de implementação: mesmo ajustando várias vezes, às vezes ele não criava testes ou deixava tarefas de fora<br /> Então mudei a configuração de novo e passei a usar subagents dedicados a tarefas específicas, deixando implement-sprint apenas como orquestrador. Assim, eu conseguia revisar o estado do código a cada sprint e a confiabilidade ficou bem maior. Ainda acontece de ele dizer que terminou mesmo com testes falhando, mas continua sendo mais fácil do que revisar tudo manualmente<br /> Minha hipótese atual é que o Claude tem fraqueza em TDD. Ele sempre enfrenta problemas na etapa de escrever testes primeiro. Da próxima vez, pretendo tentar escrever os testes só depois de concluir a implementação. Não é o ideal, mas se isso aumentar a produtividade, talvez ainda seja melhor do que codificar tudo na mão

• Achei interessante que muitas dessas ferramentas estejam alinhadas a uma estratégia de “spec primeiro”, enquanto a forma de manter essas especificações continua meio vaga. Pessoalmente, eu e meu cofounder estamos apostando tudo em “spec as source”. Achamos que tratar a especificação realmente como source é o uso mais interessante, e estamos tentando levar isso adiante, mas fazer isso se firmar na prática é bem difícil. Se alguém tiver experiência ou feedback sobre isso, adoraria ouvir<br /> Se tiver interesse, também peço que testem nosso experimento, specific.dev, e contem o que acharam

  • Se a especificação for realmente o source, então isso significa que a própria especificação precisa ser uma linguagem formal executável (uma linguagem de programação). Caso contrário, especificação é especificação, e source code é source code. No fim, todo mundo continua precisando aprender o que é “bom código” do mesmo jeito

• Quando testei o workflow spec-driven do Kiro, ele despejou uma quantidade absurda de itens na lista de tarefas (mais de 4 subtarefas por tarefa, mais de 12 tarefas no total). O workflow em si não era ruim, mas apagava código de forma imprevisível e não fazia rollback. Parece que, por ter sido feito como IDE, acaba desperdiçando recursos com tratamento de exceções de UI. Em vez de quebrar tudo em partes complicadas, é mais fácil simplesmente iterar e melhorar aos poucos. É como “usar uma marreta para quebrar uma noz”

• Gostei da abordagem de usar slash commands customizados para empacotar a entrada em prompts bem estruturados, e também de injetar como contexto os trechos divididos vindos de agents.md e afins<br /> Mas não gosto quando a tentativa de desatar todos os nós acaba parecendo justamente usar uma marreta para quebrar uma noz, ou seja, gerando mais complexidade. Ainda assim, acho que ficaria mais leve se fosse possível adicionar gerenciamento de contexto de forma seletiva, só quando necessário, com slash commands extras como /experiment, /stub etc. E no fim algo como /wrap-up, um comando dedicado ao fechamento que amarra tudo de uma vez, como um médico revisando tudo ao final de uma cirurgia

• Ao usar o SpecKit, eu sempre ficava com a dúvida: “em que momento todas essas specs vão ser unificadas em uma única fonte real de verdade (ground truth)?” Senti falta total dessa etapa Agora, o que resta é a tarefa de definir e projetar qual deveria ser a aparência de uma spec de comunicação entre humanos e agentes. Estou pensando nisso para concretizar o conceito de “spec anchored” mencionado pela Birgitta

  • Com a chegada da AI, sinto que chegou mesmo a hora de definir esse tipo de padrão. As specs precisam ser formalizadas a ponto de humanos conseguirem lê-las e mantê-las, e também de poderem caber, mesmo que só parcialmente, no contexto do LLM. Precisam ser de um tipo que permita ingerir apenas parte das informações e ainda assim preservar a intenção central e o design, possibilitando trabalho prático de verdade<br /> Vejo a falha de tentativas como UML e Rational Rose no fato de não capturarem a intenção de forma concreta, ficando só em diagramas, então acabavam sendo usadas apenas nas etapas de documentação, manutenção e refatoração. No fim, só ganhavam utilidade depois que o produto já estava lançado, o que as tornava sem sentido<br /> Por isso, agora passei a olhar com mais atenção para abordagens novas como o modelo C4

• Não sei por que SDD virou tendência de repente, mas pessoalmente acho prático simplesmente criar arquivos de especificação para “entender antecipadamente o resultado final” e acompanhar o progresso ao dividir o projeto em partes menores. Não uso nenhuma ferramenta ou framework específico, só arquivos markdown. Não vi muito valor em sistemas mais complexos do que isso

• Quando usei o spec-kit pela primeira vez, fiquei realmente empolgado, mas na prática ele forçava a criação de tarefas até o nível de “construir um robô numa caverna”, e expandia demais coisas que poderiam ser resolvidas só apertando um parafuso. Acabei me cansando de corrigir isso e desisti. Acho que o workflow excessivamente complexo não compensa nem o esforço de ajustar

[jjw9512151]

Na verdade, é simples e prático se você pensar nisso como aplicar em Markdown o que aprendeu em engenharia de software. Basta escrever bem a especificação de requisitos.