SDD, Harness, Agentic Engineering: Quando O Nome Vira Ruído

Faça um teste rápido. Peça para três pessoas do seu time definirem "spec-driven development". Depois peça para definirem "harness engineering" e "agentic engineering". Se as respostas se sobrepuserem, se contradisserem ou virarem "ah, é tipo a mesma coisa", você acabou de encontrar o problema central do desenvolvimento com IA em 2026.

A indústria está inventando nomes para práticas mais rápido do que consegue definir o que esses nomes significam. Cada semana surge um termo novo para algo que, olhando de perto, já tinha nome, ou que ainda nem estabilizou o suficiente para merecer um.

Isso tem um custo concreto. Quando o vocabulário fica borrado, a decisão de adoção fica borrada junto. Você compra um rótulo achando que está comprando uma disciplina. E rótulo não entrega software.

O Nome Disso É Semantic Diffusion

Existe um termo para esse fenômeno, e ele é mais antigo que a IA: semantic diffusion. Acontece quando uma expressão se populariza tão rápido que o significado vai se diluindo a cada repetição, até a palavra significar coisas diferentes para cada pessoa que a usa.

Já vimos esse filme. "Ágil" virou guarda-chuva para qualquer coisa, de cerimônia de daily até cortar documentação. "DevOps" virou cargo, ferramenta, cultura e departamento ao mesmo tempo. "Microsserviços" virou desculpa para distribuir o que não precisava ser distribuído. Em todos os casos, o termo sobreviveu, mas a precisão morreu.

Com IA, o ciclo está mais rápido e mais perigoso. Mais rápido porque a barreira para criar e divulgar uma "metodologia" caiu: hoje uma pessoa com um agente lança uma ferramenta, um manifesto e um nome de marca num fim de semana. Mais perigoso porque estamos tomando decisões de arquitetura e processo em cima desses termos enquanto eles ainda nem assentaram.

O resultado é um vocabulário inflado onde quase tudo soa revolucionário e quase nada está definido. E líder técnico que decide com base em palavra inflada acaba comprando hype no lugar de prática.

O Caso Vibe Coding: Ninguém Disse Isso

O exemplo mais didático é o do próprio "vibe coding". O termo nasceu com Andrej Karpathy em 2025, e ele foi explícito sobre o escopo: vibe coding servia para projeto de fim de semana, protótipo descartável, brincar com uma ideia. Era um modo de operar onde você nem olha o código direito, só vai na conversa com o modelo até funcionar.

Repare no detalhe que quase todo mundo ignorou: quem cunhou o termo nunca o propôs como metodologia de produção. O escopo estava claro desde o início, throwaway, exploratório, sem garantias.

Aí a semantic diffusion fez o trabalho dela. "Vibe coding" escapou do contexto original e virou rótulo para qualquer uso de IA em código, inclusive em sistema sério. Daí nasceu o pânico de que "vibe coding em produção é irresponsável", combatendo uma coisa que o autor jamais defendeu. A indústria criou um espantalho a partir de um termo que ela própria distorceu.

E foi contra esse espantalho que surgiu o "salvador". Se vibe coding virou sinônimo de caos, então precisava existir o oposto disciplinado. Entra em cena o spec-driven development, vendido como o método sério que substitui a bagunça. O problema é que a história não é tão limpa assim.

SDD: Nome Novo, Prática Velha?

Spec-driven development tem uma definição razoavelmente clara: a especificação versionada, e não o código, é a fonte de verdade. O time escreve um spec detalhado do que o sistema deve fazer, deriva um plano de implementação, quebra em tarefas pequenas e só então gera o código, com humanos e agentes trabalhando contra esse spec.

Lendo assim, um dev experiente franze a testa. Especificação como fonte de verdade, requisitos antes de código, plano antes de implementação: isso tem nome há décadas. Os céticos foram diretos ao ponto, chamando SDD de "waterfall com uma mão de tinta nova" e de "mesmos padrões, novo hype". A crítica não é gratuita. Boa parte do que se descreve como SDD é, de fato, prática de engenharia que já existia sob outros rótulos.

Tem um argumento ainda mais afiado: muita gente usa o spec como controlador de build, um documento que dirige o agente, quando o valor real de um spec sempre foi servir de instrumento de alinhamento e auditoria entre pessoas. Usado como controle, o spec vira o roteiro rígido que o waterfall já tinha. Usado como alinhamento, ele faz o que boa documentação sempre fez. A diferença não está no nome, está no propósito.

Então SDD é só hype reciclado? Não exatamente. E é aqui que a conversa fica interessante, porque a resposta honesta não é nem "é revolução" nem "é waterfall disfarçado".

O Que De Fato Mudou

O que mudou não foi o conceito. Foi a economia de executá-lo.

Escrever spec detalhado sempre foi caro e, pior, sempre teve um retorno duvidoso, porque o spec envelhecia mais rápido que o código e ninguém o mantinha. A promessa de "spec como fonte de verdade" esbarrava num fato teimoso: manter spec e código em sincronia manualmente é trabalho que ninguém quer fazer. Por isso a prática, sob qualquer nome, sempre degradava.

A IA mudou essa conta. Quando um agente consegue ler o spec e gerar implementação de forma rápida e barata, o loop spec-para-código deixa de ser fricção e vira alavanca. O spec passa a ser executável na prática, não só no discurso. Times relatam ordens de magnitude menos ciclos de "joga fora e regenera" quando partem de um spec bem feito, em vez de ir no prompt solto. Há casos documentados de features que levariam dezenas de horas saindo em poucas, quando escritas como spec primeiro.

Ou seja: a ideia é velha, a viabilidade é nova. SDD não inventou especificação. Ele se tornou possível em velocidade competitiva porque a infraestrutura de IA amadureceu o suficiente para fechar o loop. Isso é uma mudança real e merece atenção. Só não é a mudança que o nome sugere.

Confundir "a infra ficou madura" com "descobrimos uma metodologia nova" é exatamente o tipo de erro que a semantic diffusion provoca. E quem decide adoção precisa enxergar essa diferença.

O Mapa Borrado: Harness, Context, Agentic

SDD não está sozinho no vocabulário inflado. Ao redor dele orbita um conjunto de termos que se sobrepõem de forma desconfortável.

Harness engineering fala dos controles em volta do agente: o que guia o comportamento antes da geração e o que dá feedback depois para auto-correção. Context engineering, sobre o qual já escrevi aqui, fala do ambiente informacional que o agente enxerga: arquivos, regras, índices, recuperação sob demanda. Agentic engineering é usado como termo guarda-chuva para "a disciplina de construir software orquestrando agentes". E SDD fala de spec como fonte de verdade.

Agora a pergunta honesta: onde um termina e o outro começa? Um spec bem feito é context engineering? O harness inclui o spec ou o spec é insumo do harness? Agentic engineering engloba todos os três ou é só um nome maior para a mesma coisa? Se você não consegue traçar essas fronteiras com clareza, não é porque você não entendeu. É porque as fronteiras genuinamente ainda não foram desenhadas pela indústria.

E aqui mora o risco real. Quando os termos se confundem, o time adota um pacote inteiro de práticas sob um único rótulo da moda, sem distinguir o que está realmente ajudando do que é cerimônia. Você implementa "SDD" e leva junto um monte de overhead que talvez não precisasse, ou pula context engineering achando que já está coberto pelo spec. A indistinção do vocabulário vira indistinção da prática.

Vocabulário borrado não é só um problema estético de gente chata. É um problema operacional, porque a granularidade com que você nomeia é a granularidade com que você consegue decidir.

Por Que Isso Te Custa Caro

Imagine a cena, comum em 2026. Liderança lê em três lugares que "spec-driven development é o futuro" e decide adotar. O time pega um framework qualquer de SDD, instala, e passa a escrever spec para tudo, inclusive para mudanças triviais que um prompt resolveria.

O resultado previsível: a rigidez do waterfall volta pela porta dos fundos. Cerimônia de spec onde não precisava, lentidão em tarefas pequenas, gente preenchendo documento para satisfazer o processo em vez de alinhar entendimento. O time adotou o rótulo sem a discriminação que tornaria a prática útil. Comprou a palavra inflada.

O erro espelhado também acontece. Time traumatizado com a burocracia ouve que "vibe coding é morte" e decide que qualquer uso ágil de IA é irresponsável, perdendo justamente a parte exploratória onde a IA mais brilha. Joga fora o protótipo rápido junto com o caos.

Os dois erros têm a mesma raiz: decidir com base no rótulo, não na prática que o rótulo deveria descrever. Quando o nome vira ruído, ele para de informar a decisão e passa a substituí-la. Você acha que está escolhendo uma abordagem, mas está só seguindo uma palavra da moda.

A semantic diffusion cobra esse preço de forma silenciosa, em overhead, em oportunidade perdida e em discussões ideológicas que poderiam ser conversas técnicas sobre o problema concreto à frente.

Spec Como Controle Versus Spec Como Alinhamento

Se há uma distinção que vale resgatar de toda essa confusão, é essa: para que serve o spec.

Spec como controlador de build é o spec que existe para dirigir o agente. Você escreve para a máquina executar. Nesse uso, o spec compete com o código, fica caro de manter, e a tentação é tratá-lo como roteiro fechado. É aqui que SDD de fato se aproxima do waterfall: requisito travado na frente, implementação subordinada atrás.

Spec como instrumento de alinhamento é o spec que existe para sincronizar entendimento entre pessoas, e secundariamente guiar o agente. Você escreve para o time concordar sobre o que está sendo construído e por quê. Nesse uso, o spec faz o que boa documentação de decisão sempre fez: reduz ambiguidade, registra intenção, serve de âncora quando o contexto evapora.

A diferença parece sutil, mas determina se SDD vai te ajudar ou te enrijecer. O mesmo artefato, com o mesmo nome, produz resultados opostos dependendo do propósito. E nenhum framework, nenhuma ferramenta, nenhum manifesto resolve isso por você. É uma escolha que o time precisa fazer conscientemente, e que o rótulo "SDD" sozinho não captura.

Por isso insistir no nome é tão pouco útil. Duas equipes dizendo "fazemos SDD" podem estar fazendo coisas que se contradizem. O que importa não é se você "faz SDD". É se o seu spec alinha pessoas ou só amarra o build.

Perguntas Que Cortam O Ruído

Como decidir sem se afogar no vocabulário? Trocando perguntas de rótulo por perguntas de mecânica.

Em vez de "devemos adotar SDD?", pergunte: para esta classe de tarefa, escrever a intenção antes reduz retrabalho ou só adiciona cerimônia? A resposta muda conforme o tamanho e o risco da mudança, e essa é exatamente a discriminação que o rótulo apaga.

Em vez de "isto é harness ou context engineering?", pergunte: o que o agente precisa saber antes de agir, e como ele recebe feedback depois? Os termos importam menos que os dois mecanismos concretos por trás deles.

Em vez de "vibe coding é aceitável?", pergunte: este código vai ser mantido? Se for descartável, velocidade sem entendimento é racional. Se for viver em produção, não é. A pergunta sobre manutenção corta mais do que qualquer debate sobre o nome.

E a pergunta que desinfla qualquer termo novo: o que exatamente isto faz que a prática anterior não fazia? Se a resposta for honesta e específica, ótimo, há substância. Se a resposta for vaga ou circular, você está diante de semantic diffusion, e o termo está te custando clareza em vez de te dar.

Essas perguntas têm uma vantagem: funcionam independente de qual será o próximo nome da moda. E vai ter um próximo, garantido.

Vocabulário É Responsabilidade De Quem Escreve E Lidera

Tem uma parte desconfortável aqui, especialmente para quem produz conteúdo técnico, e eu me incluo. Boa parte da semantic diffusion é alimentada por quem escreve sobre tecnologia. Cada post que usa um termo novo de forma frouxa, cada thread que infla um conceito para ganhar atenção, cada "isto muda tudo" empurra o significado um pouco mais para o ruído.

Quem escreve e quem lidera time tem uma responsabilidade concreta: ser preciso de propósito. Definir o termo antes de usar. Dizer o que ele não é, não só o que ele é. Resistir à tentação de adotar a palavra da semana só porque ela está rendendo engajamento. E, principalmente, separar "isto é novo" de "isto tem nome novo".

Para tech lead, isso vira prática de equipe. Quando alguém traz um termo da moda para a discussão, vale a pausa: o que você quer dizer com isso, em mecânica concreta? Não para humilhar quem trouxe, mas para garantir que a decisão seja sobre a prática, não sobre a palavra. Glossário compartilhado, mesmo informal, vale mais que qualquer framework adotado às pressas.

A maturidade de um time com IA não se mede por quantos termos da moda ele usa. Se mede pela clareza com que ele distingue o que está realmente fazendo. Em 2026, falar menos buzzword e definir melhor o que se faz já é uma vantagem competitiva silenciosa.

Principais Aprendizados

Semantic diffusion é a diluição do significado de um termo conforme ele se populariza; com IA, o ciclo está mais rápido e mais caro.
Vibe coding foi proposto para projetos descartáveis; virou espantalho ao ser distorcido para significar qualquer uso de IA.
SDD não é conceito novo: spec e requisito existem há décadas; o que mudou foi a infra de IA tornar o loop spec-para-código viável em velocidade competitiva.
Termos como harness, context e agentic engineering se sobrepõem; a indistinção do vocabulário vira indistinção da prática.
O custo é real: adotar pelo rótulo traz a rigidez do waterfall ou o medo de explorar, dependendo do erro.
A distinção que importa: spec como controle de build enrijece; spec como instrumento de alinhamento ajuda.
Decida por mecânica, não por nome: pergunte o que a prática faz que a anterior não fazia.

Conclusão

O desenvolvimento com IA está produzindo prática nova de verdade. Só que está produzindo, junto, uma enxurrada de nomes que correm na frente do entendimento. A graça e o perigo do momento é que as duas coisas vêm misturadas, e separar uma da outra é trabalho de quem decide.

SDD, harness engineering, agentic engineering, vibe coding: não são vazios, mas também não são o que o brilho do nome promete. Por trás de cada um há uma mecânica concreta que ou ajuda no seu contexto ou não. Essa mecânica é o que merece sua atenção. O rótulo é só embalagem, e embalagem não mantém sistema.

Quando o nome vira ruído, a saída não é decorar o nome mais rápido. É voltar à pergunta que nenhum buzzword responde por você: o que, exatamente, isto resolve?

SDD, Harness, Agentic Engineering: Quando O Nome Vira Ruído

SDD, Harness, Agentic Engineering: Quando O Nome Vira Ruído

O Nome Disso É Semantic Diffusion

O Caso Vibe Coding: Ninguém Disse Isso

SDD: Nome Novo, Prática Velha?

O Que De Fato Mudou

O Mapa Borrado: Harness, Context, Agentic

Por Que Isso Te Custa Caro

Spec Como Controle Versus Spec Como Alinhamento

Perguntas Que Cortam O Ruído

Vocabulário É Responsabilidade De Quem Escreve E Lidera

Principais Aprendizados

Conclusão

Fontes e Referências

Receba os artigos mais relevantes da semana, sem quebrar seu ritmo de leitura

eltonjose