Especificações viram o produto no desenvolvimento guiado por IA

Do código para a intenção

Com agentes de IA capazes de gerar componentes, APIs, testes e pull requests, o gargalo do desenvolvimento deixa de ser digitar código e passa a ser a fila: espera, coordenação, ambiguidade, revisões e reconstrução de contexto. A proposta é inverter a lógica tradicional: a especificação do produto vira o artefato central e o código passa a ser apenas uma representação gerada dela. Cada nova funcionalidade entra como um "delta" versionado sobre uma especificação viva, que descreve o que é adicionado, modificado ou removido. Após o deploy, o delta é reincorporado à especificação, evitando a deriva entre documentação e implementação.

Pipeline automatizado e agentes separados

Uma mudança de produto pode afetar site, app, APIs, analytics, texto regulatório e design system. Em vez de simplesmente pedir a um agente "adicione esta funcionalidade", o sistema parte de um delta aprovado e segue um fluxo padronizado: planejamento, implementação, verificação, qualidade e deploy. O trabalho é dividido em três papéis: Planner, que decompõe o delta em tarefas e dependências; Builder, que escreve o código e abre os pull requests; e Verifier, que reconstrói independentemente o comportamento esperado a partir da especificação e compara com o que foi construído. A separação evita que o mesmo contexto leve o agente a errar na implementação e a aprovar o próprio erro.

Onde entram os humanos

O modelo prevê dois portões humanos: aprovação da intenção antes de implementar e decisão final sobre levar a mudança a produção. Tudo entre esses pontos pode ser automatizado. O texto argumenta que prompts são transitórios, enquanto especificações são persistentes e capturam o que a organização acredita que o produto é. Habilidades organizacionais - regras de design system, padrões técnicos e restrições - devem ser codificadas como "skills" reutilizáveis, hierarquizadas abaixo da especificação.

Código descartável, definição durável

A tese final não é que código perdeu importância, mas que ele deixa de ser o único repositório durável do conhecimento do produto. Se intenção, regras de negócio, design e padrões ficam estruturados, a implementação pode ser regenerada ao trocar modelo, framework ou agente. Em produtos com múltiplas superfícies, a verdade do produto fica compartilhada acima da camada de repositórios, permitindo consistência sem exigir monorepo. O artigo conclui que equipes devem parar de pensar em "entregar features" e passar a editar continuamente uma definição de produto.