Tem um tipo de comentário no LinkedIn que parece apenas um desabafo, mas é um diagnóstico. Esses dias li um que me deu um pequeno gatilho. O autor descrevia, em três frases curtas, algo que eu já tinha visto de perto:
Demitiram os devs engenheiros que pensam porque 'custa caro', pra contratar mais barato dev operador de máquina e pagar assinatura de IA.
Não tem desespero na frase. Não tem ironia. Só a descrição do que está acontecendo, dentro das empresas dele e dos colegas dele. E me lembrou imediatamente de um lugar onde trabalhei alguns anos atrás.
A empresa que queria menos engenharia
Era uma empresa grande. Vou economizar nos detalhes que não importam pro argumento.
O que eu lembro com mais nitidez é a tensão política diária entre a área de negócios e a área de tecnologia. Não era discussão sobre prioridade. Era uma fricção crônica. Cada vez que um dev levantava um risco, uma dívida técnica ou uma fragilidade de integração, alguém do outro lado da mesa interpretava aquilo como obstáculo. "Vocês complicam tudo. Vocês são o gargalo."
Não era o erro técnico que estava em jogo. Era a posição política de cada área. Quem falava de risco era visto como o chato da reunião, quem prometia velocidade era o herói, e a métrica de sucesso era o quanto a tecnologia conseguia parecer invisível.
Nesse jogo, qualquer dev com critério era visto como um problema. Porque esse tipo de dev faz as perguntas que ninguém quer encarar.
No fim das contas, tive meu contrato encerrado.
A história não acaba aqui de forma satisfatória. Pelo que sei, o sistema continuou tendo os mesmos problemas depois. Mas sem ninguém na sala chamando atenção pra decisões ruins.
Brooks já tinha avisado em 1975
A maior parte das pessoas que conhece The Mythical Man-Month lembra do livro pela frase mais famosa: "adicionar gente a um projeto atrasado o atrasa ainda mais". É verdade, e é importante. Mas reduzir Brooks a isso é perder o ponto.
Fred Brooks escreveu o livro depois de gerenciar o desenvolvimento do OS/360 na IBM nos anos 60. Ele viu de perto o que acontece quando uma indústria inteira tenta aplicar a lógica da manufatura a um trabalho que não é produção em linha de montagem. A tese do livro não é sobre prazo, e sim sobre uma confusão conceitual que estava sendo cometida sistematicamente naquela época, e que ele esperava que parasse.
Não parou.
O software está mais para um processo artesanal do que para a fabricação de peças iguais numa linha de produção. Cada problema é específico, e cada projeto carrega um contexto específico que está nas cabeças de quem trabalha nele. Quando você trata desenvolvedor como unidade fungível, como engrenagem que dá pra trocar, você não está otimizando. Está implodindo as bases que fazem o produto existir.
Cinquenta anos atrás isso já era óbvio pra qualquer um que tivesse parado pra observar. Brooks descreveu o padrão, deu nome às coisas, e o padrão sobreviveu intacto. Provavelmente porque a tentação é antiga. Buscar previsibilidade é o natural de qualquer projeto minimamente organizado e rentável. Mas daí achar que essa previsibilidade se traduz em produtividade uniforme entre todos os devs, em todos os contextos, é devaneio.
A nova métrica é o token
A IA generativa não inventou essa fantasia. Ela só deu a ela uma nova roupagem, muito mais descolada.
Antes era linhas de código por dia, depois ponto por sprint, depois vazão por engenheiro. Agora pode ser tokens por mês. A coisa muda de nome mas a lógica continua a mesma: tentar enquadrar julgamento humano dentro de um número que cabe num dashboard.
E o discurso público acompanha. Em 2024, num dos maiores eventos de tecnologia do país, um consultor subiu ao palco do Febraban Tech e disse, em voz alta, pra um auditório que aplaudiu, que "não precisamos mais da TI" e que "Scrum Master é um inútil". A fala viralizou na comunidade de devs. O conteúdo dela importa menos do que o que ela revela: existe uma audiência inteira, sentada em cadeiras com café cortesia, pronta pra aplaudir esse tipo de visão.
Pra essa audiência, a IA não é apenas uma nova ferramenta. É a luz no fim do túnel de uma queixa antiga.
O que a IA resolve, e o que ela não resolve
Antes que isso vire ataque genérico contra a IA, que não é o que eu penso e nem o que esse texto está propondo, vale distinguir as coisas.
Existe um tipo de trabalho que a IA realmente acelera, e até mesmo quem não é dev consegue operacionalizar. Um ajuste numa página de campanha de vendas, que precisa ir ao ar ainda hoje, um script pra automatizar uma tarefa chata que ocupa horas de seu dia, um componente prototipado em meia hora ou um texto de interface traduzido para três idiomas. Coisas pontuais, reversíveis e de baixo risco. Pra esse tipo de demanda, a IA tirou atrito de forma brutal, e isso é ótimo.
Mas existe outro tipo de demanda, e é a maior parte do desenvolvimento. Sistemas com vinte anos de legado em cima, regras de negócio acumuladas sem revisão, integrações com terceiros que mudam contrato sem aviso. Aqui decisão errada agora vira problema caro lá na frente.
Aqui a velocidade não deve ser a única métrica. Cada mudança deve ser acompanhada de muito critério. É necessário entender o problema antes de sair escrevendo, saber qual sugestão da IA aceitar e qual recusar, reconhecer quando um código que parece certo está, na verdade, criando uma armadilha pra próxima sprint. E enquanto isso, documentar uma decisão de forma que alguém daqui a dois anos consiga entender por que ela foi tomada.
A IA não substitui isso. Ela pode amplificar o potencial de quem tem (e foi exatamente esse o argumento do meu artigo anterior), mas quando você tira o profissional com critério da equação, a IA não fica no lugar. O que fica é o caos, com a ilusão momentânea de produtividade.
A mesma fantasia, vista de fora
Em maio de 2026, o Papa Leão XIV publicou a primeira encíclica do seu pontificado. Chama-se Magnifica Humanitas e trata, em noventa páginas, dos impactos da inteligência artificial sobre o trabalho, a verdade e a dignidade humana.
Eu não estou trazendo o documento aqui pelo lado religioso. Trago pelo lado historiográfico, porque a escolha de timing diz mais do que o texto em si.
O documento foi assinado em 15 de maio, que é exatamente o aniversário de 135 anos da Rerum Novarum, encíclica de Leão XIII publicada em 1891 pra responder à Revolução Industrial e à condição dos operários nas fábricas que estavam surgindo na época. Não é coincidência. O Papa Leão XIV está dizendo, de forma polida, que a Igreja vê uma analogia direta entre o que aconteceu com o trabalhador industrial no fim do século XIX e o que está acontecendo com o trabalhador cognitivo no início do século XXI.
Você não precisa concordar com o resto do magistério católico pra reconhecer que esse diagnóstico tem peso. Quando uma instituição de quase dois mil anos, que historicamente leva tempo pra dizer qualquer coisa, decide nomear um padrão e cravar um paralelo histórico explícito com uma revolução anterior, é sinal de que alguma coisa está acontecendo na escala da civilização, não só no mercado.
E o que a Igreja está nomeando é exatamente o mesmo padrão que Brooks descreveu dentro do mundo técnico em 1975: a vontade gerencial de reduzir o trabalhador a unidade controlável, agora em escala maior. Antes era o músculo na linha de montagem. Agora é a capacidade de decidir, criar e julgar.
Brooks viu de dentro do mundo técnico em 75. A encíclica está olhando de fora em 2026. Quando duas tradições assim diferentes apontam pro mesmo lugar, vale prestar atenção.
Isso não é um levante do Agile Hippie
Vale separar explicitamente duas vertentes extremadas que coexistem na gestão de equipes de TI, porque é fácil confundir.
Do controle, já gastei meu francês aqui. Não vou repetir. Mas existe uma vertente muito oposta, que vive entre o underground e a contra-cultura: o Agile Hippie. É a versão de Agile que confunde flexibilidade com ausência de processo. Aqui estimar vira "tentativa de controle", prazo vira "pressão desnecessária", documentar vira "ferramenta de micro-gerenciamento". Sobra retrospectiva e acolhimento de emoções. Falta software funcional e vendável.
Objetivos claros, prioridades e prazos negociados não são os vilões da história. É o básico pra um projeto dar certo. Qualquer construção de software com mais de uma pessoa, ou com restrição de prazo e escopo, precisa disso. Isso é Agile feito de maneira séria, com formas razoáveis de acompanhar o andamento.
E vale separar uma coisa que se confunde fácil: estimar não é reduzir. Um dashboard como retrato do momento, como instrumento de tendência ou planejamento é saudável. Qualquer empresa que constrói algo precisa decidir prioridade, prazo, custo e acompanhar para saber se isso está acontecendo conforme o esperado. Agora achar que realidade pode ser reduzida a uma planilha de cálculo é uma tentativa de controle absoluto.
Essa acaba sendo a mesma gestão que perdeu a noção e que olha pro time e enxerga linha de produção em vez de gente pensando. E que, quando a IA não entrega o resultado esperado, conclui que o problema é o dev — "gastamos X em token e o time não conseguiu entregar no prazo" — como se prazo, complexidade e qualidade fossem variáveis que se ajustam ao orçamento de IA por mágica. Isso não é gestão de software. É uma fantasia industrial reciclada.
Argumento de mercado, não de moral
A defesa do dev com critério não é uma posição nostálgica. Não estou pedindo pra gente voltar pra 2014. A IA veio pra ficar, vai ficar cada vez melhor, e quem se recusa a usá-la com método está, como argumentei no artigo anterior, do lado errado da história.
O argumento é simples, e é de mercado.
Valor em software nunca veio de velocidade de digitação. Vem de gente que entende contexto, simplifica problema, pesa trade-off e assume responsabilidade. Nada disso centraliza num dashboard, cabe num prompt ou se terceiriza sem perda. É um tipo de trabalho intrinsecamente distribuído entre as cabeças das pessoas que conhecem o sistema vivo.
O gestor que tenta espremer esse tipo de profissional pra fora do time achando que está cortando custo está, na prática, destruindo a base do valor do produto. Ele só não percebe imediatamente porque o efeito tem latência. Demora algumas semanas ou meses. Mas chega. E quando chega, é bem mais caro.
A boa notícia, pra quem está lendo isso preocupado com o próprio futuro, é que esse efeito de latência já está sendo cobrado em algumas empresas. As que apostaram cedo no "vamos só usar IA e cortar engenharia" estão começando a ver a conta. E elas vão precisar de gente que sabe consertar.
Esse profissional, o que tem critério, conduz IA sem terceirizar julgamento, entende negócio e técnica ao mesmo tempo e sabe quando dizer não, não é abundante. É raro. E está sendo pago bem agora, hoje, no presente.
Pra quem tá com medo
Se você está começando a carreira agora, ou tentando se reposicionar, e está com medo do que a IA vai fazer com o seu lugar no mercado: faz sentido. A régua mudou. Mas não é o fim do mundo.
O profissional que vai ser mais valorizado do que nunca é o que sabe usar IA como ferramenta de ampliação sem deixar de ser o autor do trabalho. Ele mantém o critério, o contexto e a responsabilidade nas próprias mãos, e entende que software não é uma esteira de pequenas tarefas reversíveis: é o resultado das consequências de muitas decisões já tomadas.
Isso não se aprende sozinho. E não se aprende vendo curso de prompt mágico no YouTube. Se aprende com prática, com gente mais experiente mostrando os trade-offs reais.
A Academia do Ruby existe pra isso. Não pra te preparar pra um futuro hipotético em que tudo vai dar certo se você esperar a poeira baixar. Mas pra te formar, agora, no tipo de profissional que o mercado já está pagando bem por não conseguir encontrar, e que vai continuar pagando enquanto essa escassez durar.
Ainda não há comentários. Seja o primeiro a comentar!