--- title: "Especificação funcional primeiro: o 80/20 que muda como usamos IA no desenvolvimento" author: "Ricardo Pupo Larguesa" date: "2026-08-05 19:31:00-03" category: "Na Prática" url: "http://aintuicao.scale.press/portal/aintuicao/post/2026/08/05/especificacao-funcional-primeiro-o-8020-que-muda-como-usamos-ia-no-desenvolvimento/md" --- ## Resumo - Priorizar especificação funcional antes da técnica evita documentos híbridos que servem mal ao negócio e à implementação. - Quality gates devem focar em métricas de produto como tempo de resposta e consumo de recursos, não em complexidade de código. - O fluxo prático começa com discussão funcional em chat, passa para requisitos técnicos e só então materializa no PLAN.md. - Na era de IA generativa, métricas tradicionais de código perdem relevância porque boa parte do boilerplate já é gerado automaticamente. - Misturar funcional e técnico cedo demais gera lock-in acidental e retrabalho disfarçado de evolução. - Medir o que é fácil em vez do que importa leva a sistemas elegantes que resolvem o problema errado ou são frágeis em produção. --- Assisti [este vídeo](https://www.youtube.com/watch?v=yzpKGT1pM54) do Lucas Montano sobre o novo 80/20 do desenvolvimento de software com RFCs. O material é direto e traz uma provocação necessária sobre como a IA mudou o ritmo do trabalho. Se as equipes pularem a etapa de estabilizar o que o sistema precisa fazer porque a IA gera código em segundos. O resultado costuma ser sistemas tecnicamente elegantes que resolvem o problema errado ou que viram pesadelo operacional. ## A separação entre o quê e o como Concordo em parte com a ideia de especificação agnóstica a linguagem, mas na prática ela vira um híbrido perigoso. A especificação funcional deve descrever apenas o comportamento esperado: casos de uso, regras de negócio, critérios de aceite e fluxos principais. Nada de framework, banco ou padrão de arquitetura. A especificação técnica entra depois, quando o que precisa ser feito já está estável. Misturar as duas cedo demais gera lock-in acidental e retrabalho que se disfarça de evolução natural. Na minha experiência em sala de aula e em projetos, a ordem importa mais do que a perfeição de cada documento. ## Quality gate de produto, não de código Outro ponto é o quality gate. Métricas como complexidade ciclomática, cobertura de testes unitários e code smells detectados por ferramenta estática são proxies fracos, especialmente quando modelos generativos escrevem a maior parte do boilerplate. O que realmente importa é usabilidade, tempo de resposta sob carga, consumo de recursos e consistência de estado. Já abri mão de regras de qualidade de código para ganhar performance ou reduzir consumo de memória e foram algumas das melhores decisões que tomei. O usuário final não liga se a função tem 47 linhas. Ele liga se a tela carrega em menos de 200 ms e se o sistema não consome 1,2 GB de RAM para algo trivial. Investir horas em SonarQube e linters agressivos enquanto o produto continua lento ou frágil em produção é cargo cult. Dá sensação de rigor, mas raramente entrega o que o negócio precisa. ## Meu fluxo atual Primeiro discuto a especificação funcional em webchat ou ferramenta de conversa estruturada. O objetivo é estabilizar o comportamento esperado sem decisões técnicas prematuras. Só o que o sistema precisa fazer. Depois, já dentro do agente, passo para os requisitos técnicos: arquitetura, stack, trade-offs de performance, modelos de dados, caching, observabilidade e segurança. É aqui que a especificação deixa de ser genérica e vira concreta. Só depois de ter os dois níveis relativamente estáveis eu escrevo o PLAN.md e inicio o desenvolvimento. O PLAN.md serve de âncora para o agente e para mim, materializando a transição do o quê para o como. Esse fluxo parece óbvio no papel. Na prática, a maioria das equipes ainda tenta fazer as duas coisas ao mesmo tempo ou começa pela solução técnica e depois tenta encaixar o problema. O novo 80/20 não está apenas em escrever RFCs. Está em decidir conscientemente o que merece ser especificado primeiro e quais métricas realmente merecem o nome de quality gate. Métricas de código ainda têm valor residual, especialmente para onboarding e detecção de regressões grosseiras. Mas elas não deveriam ser o portão principal. O portão principal precisa olhar para o produto: tempo de resposta, consumo de recursos, taxa de erro real e segurança observável. Tudo o mais é detalhe que a IA e um bom debugger já resolvem razoavelmente bem. Se continuarmos medindo o que é fácil de medir em vez do que importa, vamos continuar produzindo sistemas com excelente qualidade de código e experiência de usuário medíocre. Na era da IA, isso é um desperdício particularmente elegante de tempo e talento. Se o tema de engenharia de prompt para devs te interessa, meu livro explora técnicas práticas para esses fluxos. [https://www.casadocodigo.com.br/products/livro-engenharia-de-prompt](https://www.casadocodigo.com.br/products/livro-engenharia-de-prompt) Conecte-se comigo nas redes para mais discussões sobre esses temas: [https://linktr.ee/ricardo.pupo](https://linktr.ee/ricardo.pupo)