Assisti este vídeo 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
Conecte-se comigo nas redes para mais discussões sobre esses temas: https://linktr.ee/ricardo.pupo