Algo está acontecendo nas comunidades de developers agora mesmo que vale a pena observar — não porque seja uma crise, mas porque é um sinal.
Duas conversas distintas correm em paralelo pelo Reddit, Hacker News e Substacks de desenvolvimento. Parecem não ter relação. Não é assim.
O experimento do r/programming
Em 2 de abril, r/programming — uma das maiores comunidades de programação do Reddit, com milhões de membros — anunciou uma proibição temporária de todo conteúdo relacionado a LLMs até o final de abril. Os mods enquadraram isso como um problema de sinal-para-ruído: as discussões sobre LLMs tinham deslocado tudo mais, e queriam ver como a comunidade ficaria sem elas.
A proibição não cobre IA em geral — machine learning, análises técnicas e discussões de arquitetura continuam permitidos. O que se corta especificamente é o fluxo constante de anúncios de modelos, threads de “a IA vai me substituir?” e how-tos de vibe-coding.
Um developer que escreveu sobre a proibição deixou claro: a proibição é um sintoma, não uma solução. O sinal real é que as comunidades de developers estão se fragmentando por linhas de experiência de uma forma que um fórum de propósito geral com milhões de membros não consegue conter. Os seniors querem profundidade. Os juniors querem direção. Nenhum dos dois está conseguindo o que precisa.
Essa é uma leitura mais honesta que “os seniors são luditas”. Os developers com experiência passaram anos construindo sistemas reais antes dos LLMs existirem, e estão vendo a qualidade das conversas se deteriorar em tempo real.
O discurso do código escrito à mão
Separado disso — mas não coincidentemente — um argumento se tornou viral em Substacks e comunidades dev: “todos os melhores programadores que conheço estão começando a escrever código à mão de novo.”
O argumento não é que as ferramentas de IA sejam inúteis. É mais específico que isso. Ainda em meados de 2025, mesmo developers que adotaram IA com entusiasmo reconheciam que passavam mais tempo reescrevendo o código gerado do que se o tivessem escrito do zero — os modelos simplesmente não davam conta em muitos casos. Isso mudou para alguns workflows. Mas a preocupação com o que fica para trás não desapareceu.
O termo que continua aparecendo é “slopification” — codebases fáceis de gerar mas dolorosas de manter. Funções que funcionam mas que ninguém entende completamente. Dependências que ninguém escolheu conscientemente. Testes que passam mas não testam o correto.
Não é uma posição marginal. Em fevereiro, uma nota de fundo descrevia como developers que tinham ficado maravilhados com as ferramentas de coding autônomo durante as férias de inverno voltaram profundamente inquietos — não porque as ferramentas não funcionassem, mas porque funcionavam, de formas que geravam perguntas incômodas sobre o que realmente significa entender o código que se assina.
O retorno ao código à mão não é nostalgia. É uma resposta a um problema concreto: quando uma codebase é majoritariamente gerada por IA, a propriedade é difusa, e o debugging se torna arqueologia.
O monolito voltou (de novo)
Enquanto isso, outro thread circulou e ressoou com milhares do que estão chamando de “engenheiros cansados”: um artigo sobre deletar microsserviços em favor de um monolito modular.
O clima em 2026 não é “os microsserviços falharam”. É exaustão: cansados de perseguir um bug por cinco serviços para o que deveria ter sido um fix simples, cansados de deployments que requerem reuniões de coordenação, cansados de que “eventual consistency” se torne “eventual confusão”.
O insight que a indústria re-aprendeu é que monolito não significa código desorganizado. Um monolito bem estruturado tem limites de módulos claros e interfaces definidas entre componentes — o que está sendo chamado de “monolito modular” — e entrega os benefícios organizacionais da separação sem o overhead operacional de sistemas distribuídos.
Os exemplos que continuam aparecendo: Shopify roda uma das maiores plataformas de e-commerce do mundo sobre um monolito Rails. A famosa história de redução de custos do Prime Video veio da consolidação, não de continuar dividindo.
Por que essas duas conversas são na verdade uma só
Aqui está o fio que as conecta.
As ferramentas de IA aceleram o output. Isso é real e não vai mudar. Mas a aceleração é assimétrica — é muito mais fácil gerar código do que entendê-lo, debugá-lo e mantê-lo. Os microsserviços fizeram a mesma promessa em 2018: mais flexibilidade, equipes mais ágeis. O que muitos times obtiveram foi complexidade distribuída que não estavam equipados para operar.
Tanto o backlash ao vibe-coding quanto o retorno do monolito são reações à mesma dinâmica de fundo: dívida técnica que se acumulou mais rápido que a capacidade do time para lidar com ela.
Os developers que estão se opondo ao slop gerado por IA não se opõem à IA. Se opõem à lacuna entre “foi publicado” e “entendemos o que publicamos”.
O que isso significa para times dev na América Latina
Essa conversa se aplica de forma diferente para times que operam com menos people, orçamentos mais apertados e infraestrutura operacional mais limitada — o que descreve a maioria das empresas da América Latina fora do tier-1 de startups.
Se seu time de 5-8 engenheiros adotou microsserviços porque era isso que o circuito de conferências empurrava em 2022, o argumento do monolito modular provavelmente é mais relevante aqui do que em San Francisco. O mesmo com o código gerado por IA: o gargalo para um time pequeno não é gerar features. É entender e manter o que já existe.
O sinal dessas conversas comunitárias não é “não usem ferramentas de IA”. É “usem-nas com um olho posto no que acontece seis meses depois que shippen”.
O meta-ponto
A proibição do r/programming, o discurso do código à mão e o cansaço com os microsserviços estão todos apontando para a mesma coisa: a indústria está ficando mais honesta sobre a lacuna entre velocidade e compreensão.
Isso não é uma crise. É uma correção saudável — e provavelmente vai produzir melhores ferramentas, melhores práticas e melhores perguntas do que tínhamos um ano atrás.