Todo dev que usa IA no dia a dia já sentiu: a máquina gera código mais rápido do que você consegue revisar. Você pede uma feature, o agente roda por 15 minutos e devolve 2 mil linhas. Você lê as primeiras 50, acha que está bom, e aprova. No fim do dia, você não sabe exatamente o que foi parar na base — e descobre na sexta-feira que uma regra de negócio foi interpretada errada. O problema não é a IA. É a falta de um método de especificação antes de codar. O novo 80/20 do desenvolvimento de software é este: 80% do tempo do dev precisa voltar a ser planejamento e especificação. Só 20% deve sobrar para a execução.
"A execução levava tempo, e esse tempo te fazia refletir. Hoje a IA roda tão rápido que a reflexão simplesmente não acontece mais." — Lucas Montano
O que são RFCs e por que elas voltaram com força
RFC significa Request for Comments — um documento de especificação técnica que descreve o que será construído antes de qualquer linha de código. Cada empresa chama de um nome (especificação técnica, design doc, ADR), mas a estrutura é a mesma: entradas, saídas, eventos, validações, regras de negócio. Na era pré-IA, RFCs eram usadas em times grandes para alinhar equipes. Na era da IA, elas viraram a fonte da verdade que o agente precisa para não alucinar.
Sem uma RFC bem definida, a IA não tem contexto de arquitetura, padrões do projeto ou regras de domínio. Ela gera código que funciona mas viola a estrutura que você levou meses para consolidar. O problema não é falta de capacidade do modelo — é falta de método de quem está no comando.
A inversão do tempo: 80% especificação, 20% código
Lucas Montano, dev e criador de conteúdo, documentou o que programadores que usam IA autônoma estão descobrindo na prática: o tempo gasto mudou de polaridade. Antes, você gastava 80% codando e 20% planejando. Hoje, quem consegue extrair valor real de agentes autônomos gasta 80% do tempo escrevendo especificações e 20% executando. Isso não é teoria — é o que está acontecendo nos times que já rodam agentes 24/7.
- Antes: 20% planejamento → 80% codificação → revisão exaustiva
- Com IA autônoma: 80% especificação (RFCs) → 20% execução pela IA → quality gates automatizados
A implicação é contraintuitiva: quanto mais rápida a IA fica, mais tempo o dev precisa gastar especificando. Porque o gargalo deixou de ser escrever código — e passou a ser garantir que o código gerado corresponde ao que deveria ser feito.
RFCs agnósticas a linguagem: uma especificação, N implementações
Uma das discussões mais produtivas sobre o tema veio de Fabrício Arcanjo, no Stupid Button Club (grupo que Lucas frequenta). A tese dele: especificações técnicas precisam ser agnósticas a linguagem de programação. Focadas em DDD e padrões, não em sintaxe. Com entradas e saídas rigorosamente documentadas, a mesma RFC pode ser implementada em Go, TypeScript, Rust ou .NET por um agente de IA.
Isso elimina a ambiguidade: em vez de um prompt genérico "cria um serviço de notificação", você tem um documento que descreve exatamente quais eventos ele recebe, quais validações aplica e qual resposta espera. A IA transpila a partir da especificação — e o resultado é consistente independentemente da tecnologia escolhida.
O quality gate reverso: quando a IA questiona o dev
Matt Pocock criou uma skill chamada Grill Me — um prompt que instrui o modelo a entrevistar o usuário sobre um plano ou design até que haja entendimento mútuo. Lucas adaptou essa skill para o próprio workflow: em vez de revisar cada linha que a IA gera, ele configurou o agente para questioná-lo sobre regras de negócio durante a geração. A IA pergunta "essa condição cobre o caso em que o usuário não tem permissão?" — e Lucas responde. Se a resposta não está na RFC, ele atualiza a especificação.
O resultado é um quality gate reverso: a IA revisa o entendimento do dev, não o contrário. O dev não precisa ler 10 mil linhas de código por dia — ele precisa estar lúcido sobre as regras que está especificando. Isso é particularmente relevante quando combinado com modo autônomo de agentes como Claude Code: sem esse mecanismo, o dev perde o fio da meada em minutos.
Skills atômicas: cada agente com menos de 70 linhas
Outra contribuição prática do Stupid Button Club veio de Conrado, que está construindo um workforce de agentes especializados. A abordagem dele: em vez de prompts genéricos, criar skills pequenas (menos de 70 linhas) baseadas em especificações técnicas. Um agente é o coder, outro é o QA, outro é o PO. Cada um tem uma skill específica que lê da mesma RFC.
O resultado é que o agente coder roda apenas 10% do pipeline total — os outros 90% são quality gates executados por agentes especializados que validam, testam e revisam. O dev não precisa confiar em um agente monolítico; ele orquestra um time de agentes, cada um com responsabilidade limitada e verificável. É a aplicação do princípio de responsabilidade única ao próprio workflow de IA.
Quality gates que forçam clean code na IA
Uma descoberta prática de Lucas: quando você configura linters com limites duros — tamanho máximo de função, linhas por arquivo, índice de duplicação — a IA começa a modularizar o projeto naturalmente. Não precisa pedir "refatore", não precisa escrever um prompt de arquitetura. A trava no CI/CD força o modelo a pensar em estrutura porque ele sabe que, se gerar uma função de 200 linhas, o quality gate vai reprovar.
Isso funciona porque a IA otimiza para a restrição. Se a restrição é "código que passa no linter", ela aprende a gerar código que respeita as regras. O dev não vira revisor de código — vira definidor de restrições. E é muito mais escalável definir 10 regras de qualidade do que revisar 10 mil linhas por dia.
O paradoxo da informação invertida
Satya Nadella, CEO da Microsoft, publicou recentemente um artigo sobre o "paradoxo da informação invertida" — a ideia de que, quanto mais informação a IA gera, mais importante se torna a capacidade de encontrar a informação certa. Ele listou os pilares que criam confiança entre capital humano e capital de tokens: dados organizados, traces de decisão, evals, adapted weights e memory accumulates.
As RFCs são a materialização prática desse paradoxo no desenvolvimento de software. Elas não substituem evals, quality gates ou testes automatizados — mas são o ponto de partida sem o qual o resto não se sustenta. Sem uma especificação clara do que deveria ser feito, nenhum quality gate sabe o que está validando.
Na prática: como começar a escrever RFCs amanhã
O maior obstáculo não é técnico — é cultural. Nenhum dev gosta de escrever documentação. Lucas foi honesto sobre isso: "nunca fui o dev que gostou de escrever documentos". Mas o que torna as RFCs diferentes da documentação tradicional é que elas são um investimento com retorno imediato: você escreve uma vez, e a IA executa N vezes a partir dela.
- Comece pequeno: uma feature de cada vez. Escreva em Markdown: o que entra, o que sai, regras de negócio, validações.
- Use como system prompt: cole a RFC como contexto do agente. Veja se o código gerado corresponde.
- Itere a RFC, não o código: quando a IA errar, corrija a especificação, não o prompt avulso.
- Adicione quality gates: linter com limites de tamanho, CI/CD com análise estática.
- Adapte o Grill Me: peça para a IA questionar suas decisões de domínio durante a geração.
O dev que domina esse ciclo não precisa escolher entre velocidade e qualidade. Ele especifica rápido, executa mais rápido ainda — e sabe exatamente o que está sendo construído.
Perguntas frequentes
RFC é a mesma coisa que documentação técnica?
Parecida, mas com um propósito diferente. Documentação tradicional descreve o que já existe. RFC descreve o que será construído e pede revisão antes da execução. É especificação prospectiva, não registro retrospectivo.
Quanto tempo leva para escrever uma RFC boa?
Depende da complexidade da feature. Uma RFC de uma tela simples pode ter 2 parágrafos. Uma de integração complexa pode levar algumas horas. O ponto é que esse tempo é recuperado múltiplas vezes quando a IA gera o código certo de primeira.
Preciso usar Markdown ou existe ferramenta específica?
Markdown é o suficiente. O importante é a estrutura: entradas, saídas, regras de negócio, validações, eventos. A ferramenta é secundária — o método é o que importa.
RFC substitui code review?
Não. RFC é pré-código. Code review e quality gates continuam necessários. A diferença é que, com uma RFC boa, o code review valida se o código implementa a especificação — não descobre a especificação durante a revisão.
Isso funciona para time pequeno ou dev solo?
Funciona ainda mais. Em time pequeno, você não tem revisor sobrando. A RFC + quality gates automatizados substituem parte do trabalho que um revisor humano faria — e liberam seu tempo para o que realmente importa.
O dev que domina esse ciclo não precisa escolher entre velocidade e qualidade. Ele especifica rápido, executa mais rápido ainda — e sabe exatamente o que está sendo construído.
