Blog / Fred Brooks, 1975, e o retrocesso que a IA está causando no desenvolvimento
Fred Brooks, 1975, e o retrocesso que a IA está causando no desenvolvimento
Por Marcos Henrique Corrêa · carreira ·
Antes de entrar nas decisões técnicas específicas de cada camada do marck0101 — arquitetura, segurança, performance — vale essa pausa conceitual.
Em 1975, Fred Brooks — engenheiro da IBM que liderou o projeto do sistema operacional OS/360 — escreveu uma frase que resume até hoje um dos erros mais comuns em gestão de projetos de software: "nove mulheres não fazem um bebê em um mês." A ideia: colocar mais gente num projeto atrasado não divide o trabalho proporcionalmente. Multiplica a quantidade de gente que precisa se comunicar entre si.
Por que mais gente pode deixar o projeto mais lento, não mais rápido
Brooks notou algo contraintuitivo: cada pessoa nova não soma produtividade de forma direta. Ela também soma uma rede inteira de novas conexões de comunicação. Com duas pessoas, existe uma linha de comunicação. Com dez, existem quarenta e cinco. Cada reunião de alinhamento fica mais complexa. Cada decisão exige mais gente concordando. E o tempo que seria gasto escrevendo código vira tempo gasto sincronizando entendimento. O resultado, muitas vezes, é um projeto que parece uma colcha de retalhos: pedaços escritos por pessoas diferentes, com estilos diferentes, decisões que não conversam entre si — porque ninguém segurou o contexto inteiro na cabeça.
Cada pessoa a mais não soma produtividade — soma conexões de comunicação, que crescem muito mais rápido que o time.
O retrocesso que a IA está causando
Essa observação de 1975 ajuda a explicar algo que está acontecendo agora, quase cinquenta anos depois — só que ao contrário. Nos primórdios do desenvolvimento de software, uma única pessoa geralmente tinha que entender de tudo: banco de dados, frontend, backend, hospedagem, teste. Não porque isso fosse o ideal — porque a especialização ainda não existia. Os times eram pequenos e as ferramentas, primitivas.
Com o tempo, a complexidade cresceu e a indústria respondeu exatamente como Brooks preveria: especializando. Surgiram times de frontend, backend, DevOps (infraestrutura e deploy), QA (teste) e DBA (banco de dados). Cada papel aprofundou um pedaço, porque nenhuma pessoa sozinha dava conta de manter o contexto de tudo com qualidade.
Agora, com IA assistindo em cada uma dessas camadas, o pêndulo está voltando. Uma pessoa só está de novo escrevendo frontend, backend, configurando banco, subindo infraestrutura e escrevendo teste — como nos primórdios, só que com ferramentas muito mais poderosas. Em certo sentido, a IA está resolvendo o problema que Brooks descreveu, mas de um jeito que ele provavelmente não imaginaria: em vez de coordenar várias pessoas especializadas, elimina a necessidade de coordenação nenhuma. Uma pessoa só segura o sistema inteiro de novo.
Mas será que as pessoas estão preparadas pra isso?
Essa é a pergunta que fica. A especialização não existia só porque faltava ferramenta. Existia porque cada camada — um banco de dados bem modelado, uma infraestrutura segura, um frontend acessível, um teste que realmente cobre o caso de uso — exige um tipo de julgamento que leva tempo pra desenvolver. A IA acelera a execução de cada camada. Mas não substitui sozinha o julgamento de saber se aquele índice de banco vai aguentar escala, se aquela decisão de arquitetura vai virar dívida técnica, se aquele teste realmente cobre o caso que importa.
O risco do "generalista com IA" não é não conseguir produzir. É produzir rápido demais em camadas onde a pessoa nunca desenvolveu olho crítico pra avaliar o resultado. É exatamente por isso que a disciplina que descrevo mais adiante nesta série, no post sobre QA, importa mais, não menos: testar não só o que é novo, mas confirmar que o resto do sistema continua de pé. Numa equipe especializada, o revisor de código, o DBA, o time de QA pegavam o que uma pessoa sozinha deixava passar. Com um generalista assistido por IA, esse segundo par de olhos desaparece — e cabe à própria disciplina da pessoa substituir o que antes vinha garantido pela estrutura da equipe.
Brooks escreveu sobre os limites de coordenar gente demais. O desafio de hoje é o oposto: coordenar sozinho tudo que antes precisava de várias pessoas, e desenvolver, numa única cabeça, o julgamento que antes vinha de times inteiros especializados.
É com esse pano de fundo que valem as decisões específicas que tomei em cada camada do marck0101 — a primeira delas, a própria arquitetura do sistema.