O gargalo do vibe coding não é produzir código
Em 1975 Fred Brooks escreveu que somar gente a um projeto atrasado o atrasa mais. Simulei a lei com times assistidos por IA e ela não foi superada, foi amplificada. O que muda é onde o gargalo fica.
A lei que ninguém revogou
Em 1975, Fred Brooks publicou que adicionar pessoas a um projeto atrasado o atrasa ainda mais. A explicação dele era de comunicação: cada pessoa nova acrescenta canais, e canais custam tempo de todo mundo.
Cinquenta anos depois, a promessa do desenvolvimento assistido por IA parece o contrário disso. Se cada pessoa escreve três a cinco vezes mais código por hora, somar gente deveria somar entrega. É a conta que todo fornecedor de IA está fazendo agora, em público.
Fiz a conta até o fim. Simulei um aplicativo de treze módulos construído com vibe coding por times de 1, 2, 3, 5, 8 e 13 pessoas.
O que a simulação devolveu
| Pessoas | Semanas |
|---|---|
| 1 | 14 |
| 2 | 8,5 |
| 3 | 6 |
| 5 | 5 |
| 8 | 5,5 |
| 13 | 7,5 |
De 1 para 3, o ganho é real e grande. De 3 para 5, ele fica marginal. De 5 para 8, o projeto fica mais lento. Com 13 pessoas o resultado é quase o mesmo que com 2.
Antes de discutir a causa, o aviso que essa tabela merece: isso é simulação, não medição de times reais. O que ela vale é o formato da curva, não a semana exata em nenhuma linha.
Por que a curva vira
O motivo é estrutural, e ele não tem nada a ver com a qualidade do modelo.
Cada pessoa com um agente gera de três a cinco vezes mais código por hora do que um desenvolvedor sem um. Com treze pessoas, o volume de saída equivale ao de quarenta a cinquenta desenvolvedores.
Mas a capacidade de revisar, integrar e testar continua presa ao número de humanos no time. Ela não foi multiplicada por nada.
Então o que cresce dos dois lados é assimétrico: mais gente produz mais código, mais código produz mais conflito de merge, mais divergência de padrão arquitetural e mais tempo gasto coordenando, integrando e jogando trabalho fora. Na simulação com treze pessoas, boa parte do código produzido é descartada, e a eficiência individual desaba para uma fração do potencial.
O gargalo do vibe coding nunca foi produção de código.
É absorção de código.
O número que sai disso
O ponto ótimo da simulação ficou consistente em três pessoas, e três não é um número mágico: é o número de domínios naturalmente independentes daquele projeto.
É essa a regra prática, e ela é dimensionamento, não ferramenta:
O número ideal de pessoas em um projeto assistido por IA é igual ao número de domínios independentes do sistema.
Acima disso não se compra paralelismo. Compra-se overhead de integração, e ele consome exatamente o ganho que justificou a contratação.
O que fazer com isso
A conclusão útil não é contratar menos por contratar menos. É que o trabalho de decompor o sistema em domínios independentes passou a ser o trabalho de dimensionamento do time. Antes era arquitetura; agora é também orçamento.
E é aqui que a curva encontra o resto do método. Se o gargalo é absorção, tudo que reduz o custo de absorver vale mais do que tudo que aumenta a produção: convenções que tornam a revisão previsível, contratos que fazem a integração falhar cedo, gates que reprovam por máquina o que um humano teria de ler. Um harness bem construído não faz o agente escrever mais. Faz o que ele escreveu custar menos para entrar.
Brooks estava certo há cinquenta anos. A lógica é a mesma. O que mudou foi a escala em que ela se manifesta, e a velocidade com que se chega ao teto.