Parte 1 - Como o método de construção de produto está mudando - Spec-Driven Development SDD

A IA está democratizando a construção de software da mesma forma que internet democratizou distribuição e isso muda fundamentalmente onde PMs, Designers e Devs gastam seu tempo: menos na execução (que será cada vez mais automatizada), mais no planejamento e especificação.

Parte 1 - Como o método de construção de produto está mudando - Spec-Driven Development SDD
Photo by Art Institute of Chicago / Unsplash

Internet democratizou distribuição. Qualquer um publica música no Spotify, vende livro na Amazon, posta vídeo no YouTube. Gravadoras perderam controle sobre artistas. Editoras não ditam mais quem publica. Locadoras viraram Netflix. A internet destruiu barreiras de acesso ao mercado.

Mas construir a plataforma? Isso sempre foi território de quem sabe código. Você pode ser criador de conteúdo facilmente — basta gravar e subir. Mas criar o YouTube, o Spotify, o Instagram? Isso exige time técnico, anos de desenvolvimento, investimento pesado.

IA está mudando isso agora. E não é exagero.

Uma menina de 6 anos criou um app funcional usando Cursor, gravou o processo e postou no YouTube. Rackspace completou 52 semanas de modernização de software em 3 semanas usando Kiro, ferramenta de desenvolvimento guiada por especificação da AWS. Shopify e Google começaram a contratar PMs que fazem protótipos funcionais — não wireframes, mas código rodando.

Se até uma criança consegue construir software com IA, quem já trabalha construindo produtos digitais precisa se transformar radicalmente. E a transformação não é "usar IA como copilot". É muito mais profunda: muda fundamentalmente onde PMs, Designers e Devs gastam seu tempo.

Menos na execução. Mais no planejamento e especificação.

Construção sempre foi a parte difícil — até agora

Criar conteúdo é relativamente fácil. Você escreve um livro, grava uma música, filma um vídeo. Se tiver talento e sorte, distribui sem fricção. Mas criar a plataforma que distribui esse conteúdo? Totalmente diferente.

YouTuber vs construir o YouTube. Músico independente vs construir o Spotify. Vendedor na Amazon vs construir a Amazon. São realidades opostas.

Construir software sempre exigiu três coisas: conhecimento técnico profundo (desenvolvedores experientes, arquitetos, engenheiros), estrutura pesada (servidores, bancos de dados, infraestrutura de deploy), e processos complexos (metodologias ágeis, gestão de backlog, controle de qualidade). Mesmo com no-code e low-code crescendo nos últimos anos, essas ferramentas têm limitações óbvias. Você consegue fazer landing page e formulário simples, mas não consegue construir plataforma robusta com lógica de negócio complexa.

Fluxo Discovery e Delivery - Internet revolucionou distribuição, IA revoluciona construção

IA muda isso completamente. Não é só automação de tarefas repetitivas. É construção guiada por especificação, onde você descreve o que quer e a IA gera implementação funcional. O caso da Rackspace não é isolado — é tendência. Empresas estão descobrindo que, com especificações bem escritas, IA consegue gerar código de qualidade em fração do tempo que um time levaria.

Implicação direta: qualidade técnica vira commodity. O que qualquer pessoa consegue fazer rápido com IA deixa de ser diferencial. Escrever CRUD, scaffold de APIs REST, testes automatizados padrão — tudo isso será gerado. A velocidade de execução técnica deixa de ser gargalo.

E se execução não é mais o gargalo, o que vira diferencial? Decisão.

Eficácia mata eficiência — e sempre matou

Empresas não morrem porque executam mal. Morrem porque decidem errado. Construir rápido o produto errado é desperdício de dinheiro. Entregar com qualidade algo que ninguém quer é fracasso eficiente.

O diagrama de Stacey (ou Cynefin, se preferir) ilustra isso bem. Problemas vivem em quatro zonas: caótico (não sabemos o que não sabemos), complexo (vemos causa e efeito mas não conseguimos replicar), complicado (dá pra analisar e resolver com expertise), e óbvio (todo mundo concorda com a solução).

A maior parte do trabalho de produto deveria acontecer na zona caótica e complexa — tirando decisões de lá e trazendo para o conhecido. Escolher qual problema resolver. Definir qual oportunidade explorar. Entender se vale a pena investir em determinada direção. Priorizar entre dez coisas urgentes e escolher a certa.

Mas o que acontece na prática? Times gastam energia brutal na zona óbvia. Refinamento de backlog, escrita de histórias, reuniões intermináveis sobre estimativa de esforço. Transformação digital dos últimos anos focou nisso: como fazer melhor, como entregar mais rápido, como ter processo mais eficiente.

Ninguém resolveu o problema de escolher certo. Frameworks ágeis ajudaram na eficiência (fazer certo), não na eficácia (decidir certo). E eficácia sempre foi mais importante.

IA automatiza a zona óbvia. Geração de código, execução de testes, deploy automatizado — tudo isso vai ser cada vez mais rápido e confiável. O que não pode ser automatizado? Decisão sobre o que construir. Priorização de problemas. Escolha de oportunidades. Definição de solução que realmente entrega valor.

E aqui entra mudança de papel das disciplinas.

Valor acontece no uso — e isso muda tudo

Produtos físicos transmitem valor de várias formas. Manufatura exclusiva (alumínio especial do iPhone que só a Apple consegue), distribuição diferenciada (experiência de compra na loja da Apple), posse como status (ter iPhone sempre foi statement social, menos hoje mas ainda existe). Empresas imbúem valor no produto através desses três vetores.

Produto digital funciona diferente. Valor só é percebido durante experiência de uso. Não antes. Não na compra. Não na embalagem bonita. Quando usuário abre o app e consegue resolver o problema dele — aí acontece percepção de valor. Se não consegue, percebe que desperdiçou tempo.

Essa diferença tem implicação direta: quem cuida da experiência de uso é quem realmente entrega valor em produto digital. E quem cuida disso? Designer. Não como decorador de interface, mas como pensador de solução.

PM traz problema. Dev realiza tecnicamente. Mas quem pensa em como resolver o problema dado o contexto de produto, usuário, negócio e tecnologia? Designer. Quem define jornada, fluxos, causas e efeitos entre ações do usuário e comportamento do produto? Designer.

Designers perderam muito tempo com burocratização de processo. Discovery de quatro meses, Design Thinking ritualizado, frameworks que viraram checklist. Mas agora, com IA automatizando execução visual e geração de código, designer volta ao que sempre deveria ter sido: dono da solução.

PM também muda. E aqui mora polêmica necessária.

PM não é estratégico. Não é executivo. É tático. E isso não é diminuição — é clareza de papel.

Estratégia vem de C-level, diretoria, investidores. Eles decidem direção da empresa, mercados a atacar, problemas grandes a resolver. Se Petlove decide atender elefantes além de cachorros, essa decisão não nasce de PM. Nasce de visão estratégica de negócio.

Execução vem do time — designers, devs, QA. Eles constroem, testam, entregam. Definem como implementar tecnicamente, quais bibliotecas usar, como estruturar código.

PM fica no meio. Tático. Pega decisão estratégica e transforma em plano executável. Orquestra contexto entre áreas. Garante que o que foi construído se conecta com o objetivo de negócio. Prioriza backlog não sozinho, mas ajudando empresa a priorizar problemas certos.

E aqui está a mudança crucial: PM não deveria escrever histórias de usuário.

Soa radical, mas pense no fluxo. Para escrever história, PM precisa conversar com designer (entender jornada, fluxos, interface), conversar com tech lead (validar viabilidade técnica, entender esforço), escrever critérios de aceitação sem ser quem vai executar, e depois apresentar tudo isso em reunião de refinamento para o time validar.

PM vira intermediário. Perde tempo escrevendo algo que quem vai executar terá que reinterpretar. Seria mais eficiente se designer + dev definissem solução e critérios juntos, e PM trouxesse apenas contexto: o que precisa ser resolvido e por quê.

PM define O QUÊ e POR QUÊ. Designer + Dev definem COMO. Essa separação não é nova — sempre foi o ideal. Mas agora, com IA acelerando execução, não dá mais para manter intermediação desnecessária. PM precisa focar em orquestrar contexto, não em escrever histórias que outros vão executar.

E desenvolvedores? Também mudam.

Devs que ficam só codando perdem espaço. "Código é a documentação" vira passivo técnico quando IA precisa de contexto explícito. Tech leads precisam documentar arquitetura, decisões técnicas, padrões obrigatórios. Não apenas para humanos lerem — mas para IA entender e seguir.

Além disso, devs precisam virar "engenheiros de IA". Não apenas usar Copilot ou Cursor, mas entender profundamente como criar agentes, orquestrar contexto, validar outputs da IA. Empresas vão preferir ter agentes bem configurados do que contratar mais devs para tarefas repetitivas.

E aqui entra o ponto mais importante de todos: se todos esses papéis estão mudando, o workflow também muda.

Upstream vs Downstream — o novo equilíbrio de trabalho

Processo clássico de produto tem dois grandes momentos. Upstream (discovery, planejamento, especificação) e downstream (construção, teste, deploy, monitoramento). Até agora, times gastavam 70% do tempo no downstream. Codificando, testando, corrigindo bugs, fazendo deploy, monitorando produção.

IA está invertendo isso. Se downstream vai ser cada vez mais automatizado, onde o humano vai gastar tempo? Upstream.

Equilíbrio no processo - IA diminui complexidade do Delivery, aumentando foco no Discovery

Mas atenção: upstream não é aquele discovery de três meses onde time fica em sala de reunião botando post-it na parede. Discovery virou termo banalizado. As pessoas acham que discovery serve para descobrir qual problema resolver. Não. Problema já vem definido — de uma camada superior, de negócio, de estratégia.

Discovery serve para descobrir como resolver o problema e não descobrir qual é o problema.

Se o problema já veio, o que acontece no upstream? Planejamento de solução. Especificação de como o produto deve se comportar. Definição de arquitetura técnica. Quebra de épicos em histórias executáveis. Criação de contexto rico que alimenta IA durante execução.

Ferramentas como Cursor, Windsurf e Claude Code já permitem que PMs façam protótipos funcionais. Não wireframe no Figma — código rodando, com backend mockado, jornada completa testável. Google e Shopify já contratam PMs que fazem isso. Por quê? Porque validação fica mais rápida. PM testa hipótese antes de envolver designer e dev. Se funciona, aí sim time entra para construir versão de produção.

Esse movimento não é exceção. É tendência. E quem não se adaptar fica para trás.

Mas tem um detalhe crítico que todo mundo esquece: IA não trabalha no vácuo. IA precisa de contexto. E contexto não surge do nada.

Especificação volta porque IA precisa de contexto — e contexto precisa ser orquestrado

Aqui está a tese central: IA só escala se tiver contexto histórico, presente e futuro. Sem contexto, IA alucina, gera código desconexo, cria bugs sutis que só aparecem em produção.

Contexto tem três dimensões:

  • Passado: por que o produto foi construído dessa forma, quais decisões foram tomadas, quais alternativas foram descartadas
  • Presente: como o produto funciona agora, quais são as regras de negócio ativas, onde está cada funcionalidade
  • Futuro: o que vai ser construído, em qual ordem, por que essa priorização

Problema: contexto não pode ser tácito. Não pode estar só na cabeça do tech lead, do PM, do designer. Conhecimento tácito não alimenta IA. Conversa de corredor não vira input para agente. Decisão tomada em Slack e esquecida não ajuda.

Contexto precisa ser explícito, estruturado, versionado, atualizado. E tem um nome para isso: especificação.

Especificação não é novidade — já foi protagonista antes

IEEE 830, padrão de 1984 para Software Requirements Specification, era rigoroso. Cada requisito funcional, cada constraint de performance, cada interface externa documentada. A spec era contrato explícito entre o que deveria ser construído e o que seria entregue. Indústrias críticas — aviação, medicina, energia nuclear — não brincam em serviço. Documentavam tudo. Código tinha que provar compliance.

Problema? Era waterfall puro. Meses especificando tudo antes de escrever primeira linha de código. Quando terminava spec, metade dos requisitos já tinha mudado. Estrutura era sólida (unambiguous, verifiable, traceable), mas processo era rígido demais.

Aí veio Agile e jogou bebê fora com água do banho. "Documentação é desperdício, prefira código funcionando." Funcionou para muita coisa. Equipes ficaram mais ágeis, entregas aceleraram. Mas com o tempo, outro problema foi gerado: conhecimento tácito. Tudo na cabeça do time. Onboarding demorado. Refactoring arriscado. Sem specs atualizadas, código que ninguém entendia direito.

User Stories tentaram equilibrar. "Como [usuário], eu quero [funcionalidade], para que [objetivo]." Era documentação leve, evolutiva, focada em valor. Mas ainda precisava de acceptance criteria detalhados. E esses critérios? São especificações. Só que espalhadas em histórias individuais em vez de documento centralizado.

Enquanto isso, algumas áreas nunca abandonaram especificação. OpenAPI (ex-Swagger) virou padrão para APIs. Você define endpoints, schemas, autenticação, rate limits num arquivo YAML/JSON. A partir disso, gera documentação interativa, client SDKs, testes automáticos. É spec-as-source para APIs. O contrato é a spec. Código implementa. Se código divergir, ferramentas detectam.

Infrastructure as Code (Terraform, CloudFormation) fez o mesmo para infraestrutura. Spec define estado desejado. Código é gerado e aplicado automaticamente. Você não edita servidor manualmente, edita spec e aplica.

O que mudou agora? IA democratizou essa abordagem para código de aplicação inteira. Não só APIs. Não só infra. Qualquer feature pode ser especificada e ter código gerado. IA fecha o gap que sempre existiu entre "documentar intenção" e "gerar implementação".

E não é buzzword. GitHub lançou SpecKit, toolkit open source para spec-driven development. AWS lançou Kiro, IDE agentica onde você escreve especificações estruturadas (requirements.md, design.md, tasks.md) e IA gera código a partir disso. O caso da Rackspace não foi vibe coding — foi spec-driven development. Eles escreveram especificações detalhadas e IA executou modernização em velocidade impossível para time humano.

A diferença crítica: não é waterfall. Spec não é documento morto escrito no início e esquecido. É base de conhecimento viva, versionada, atualizada continuamente. Quando produto evolui, spec evolui. Quando decisão muda, spec reflete. IA consulta spec toda vez que gera código, toda vez que cria teste, toda vez que precisa entender comportamento esperado.

Especificação vira fonte de verdade. Não "aquele Word perdido no Google Drive que ninguém abre há meses". Fonte de verdade ativa, consultada, mantida.

E isso muda o que cada disciplina precisa entregar.

Especificação não é burocracia — é investimento em autonomia

Você já gasta tempo explicando contexto para dev novo, relembrando decisões de arquitetura, discutindo por que certas escolhas foram feitas. Esse conhecimento existe, só não está estruturado de forma útil.

SDD reorganiza documentação para servir como input direto para IA. Sem especificação atualizada, IA não tem contexto. Gera código que ignora padrões, quebra convenções, força retrabalho manual. Com especificação estruturada — Constitution definindo regras imutáveis, PRD explicando visão, FRD detalhando comportamento, SAD documentando decisões técnicas — IA consulta tudo antes de gerar código.

Resultado: código que segue padrões, respeita arquitetura, se conecta com contexto. Menos correção manual, mais autonomia para IA, mais tempo do time focando em decisão estratégica.

Próximo artigo explica como estruturar esse sistema. Os três níveis de Spec-Driven Development (spec-first, spec-anchored, spec-as-source), componentes necessários (Constitution, PRDs, FRDs, SADs), frameworks disponíveis no mercado (SpecKit, Kiro, Agent-os), e como decidir qual abordagem faz sentido para seu time. E no terceiro, explico como criar ou modificar um para aplicação real no seu time.

Por enquanto, entenda: especificação volta ao centro não como waterfall, mas como contexto vivo que alimenta IA. É a diferença entre ter IA como assistente burro e ter IA como colaborador informado.

E essa diferença vale milhões.

Referências

Frameworks e ferramentas:

Cases e dados:

Artigos complementares:

Compartilhe este post