Algo está pasando en las comunidades de developers ahora mismo que vale la pena mirar — no porque sea una crisis, sino porque es una señal.
Dos conversaciones distintas corren en paralelo por Reddit, Hacker News y Substacks de desarrollo. Parecen no tener relación. No es así.
El experimento de r/programming
El 2 de abril, r/programming — una de las comunidades de programación más grandes de Reddit, con millones de miembros — anunció un ban temporal a todo el contenido relacionado con LLMs hasta fin de abril. Los mods lo enmarcaron como un problema de signal-to-noise: las discusiones sobre LLMs habían desplazado todo lo demás, y querían ver cómo quedaba la comunidad sin ellas.
El ban no cubre IA en general — machine learning, breakdowns técnicos y discusiones de arquitectura siguen permitidos. Lo que se corta específicamente es el flujo constante de anuncios de modelos, threads de “¿la IA me va a reemplazar?” y how-tos de vibe-coding.
Un developer que escribió sobre el ban lo dijo con claridad: el ban es un síntoma, no una solución. La señal real es que las comunidades de developers se están fragmentando por líneas de experiencia de una forma que un foro de propósito general con millones de miembros no puede contener. Los seniors quieren profundidad. Los juniors quieren dirección. Ninguno de los dos está consiguiendo lo que necesita.
Esa es una lectura más honesta que “los seniors son luditas”. Los developers con experiencia llevan años construyendo sistemas reales antes de que los LLMs existieran, y están viendo deteriorarse la calidad de las conversaciones en tiempo real.
El discurso del código escrito a mano
Separado de esto — pero no coincidentemente — un argumento se volvió viral en Substacks y comunidades dev: “todos los mejores programadores que conozco están empezando a escribir código a mano de nuevo.”
El argumento no es que las herramientas de IA sean inútiles. Es más específico que eso. Todavía a mediados de 2025, incluso desarrolladores que adoptaron la IA con entusiasmo reconocían que pasaban más tiempo reescribiendo el código generado que si lo hubieran escrito desde cero — los modelos simplemente no daban la talla en muchos casos. Eso cambió para algunos workflows. Pero la preocupación por lo que queda atrás no desapareció.
El término que sigue apareciendo es “slopification” — codebases fáciles de generar pero dolorosas de mantener. Funciones que andan pero que nadie entiende del todo. Dependencias que nadie eligió conscientemente. Tests que pasan pero no prueban lo correcto.
No es una posición marginal. En febrero, una nota de fondo describía cómo developers que habían quedado maravillados con las herramientas de coding autónomo durante las vacaciones de invierno volvieron profundamente inquietos — no porque las herramientas no funcionaran, sino porque sí funcionaban, de formas que generaban preguntas incómodas sobre qué significa realmente entender el código que uno firma.
El regreso al código a mano no es nostalgia. Es una respuesta a un problema concreto: cuando un codebase es mayoritariamente generado por IA, la ownership es difusa, y el debugging se convierte en arqueología.
El monolito volvió (de nuevo)
Mientras tanto, otro thread circuló y resonó con miles de lo que están llamando “ingenieros cansados”: un artículo sobre borrar microservicios a favor de un monolito modular.
El clima en 2026 no es “los microservicios fallaron”. Es agotamiento: cansados de perseguir un bug por cinco servicios para lo que debería haber sido un fix simple, cansados de deployments que requieren reuniones de coordinación, cansados de que “eventual consistency” se convierta en “eventual confusión”.
El insight que la industria re-aprendió es que monolito no significa código desordenado. Un monolito bien estructurado tiene límites de módulos claros e interfaces definidas entre componentes — lo que se está llamando “monolito modular” — y entrega los beneficios organizacionales de la separación sin el overhead operativo de los sistemas distribuidos.
Los ejemplos que siguen apareciendo: Shopify corre una de las plataformas de e-commerce más grandes del mundo sobre un monolito Rails. La famosa historia de reducción de costos de Prime Video vino de consolidar, no de seguir dividiendo.
Por qué estas dos conversaciones son en realidad una sola
Acá está el hilo que las conecta.
Las herramientas de IA aceleran el output. Eso es real y no va a cambiar. Pero la aceleración es asimétrica — es mucho más fácil generar código que entenderlo, debuggearlo y mantenerlo. Los microservicios hicieron la misma promesa en 2018: más flexibilidad, equipos más ágiles. Lo que muchos equipos obtuvieron fue complejidad distribuida que no estaban equipados para operar.
Tanto el backlash al vibe-coding como el regreso del monolito son reacciones a la misma dinámica de fondo: deuda de ingeniería que se acumuló más rápido que la capacidad del equipo para manejarla.
Los developers que están empujando contra el slop generado por IA no se oponen a la IA. Se oponen a la brecha entre “se publicó” y “entendemos lo que publicamos”.
Qué significa esto para equipos dev en LatAm
Esta conversación aplica diferente para equipos que operan con headcounts más chicos, presupuestos más ajustados e infraestructura operativa más limitada — que describe a la mayoría de las empresas de LatAm fuera del tier-1 de startups.
Si tu equipo de 5-8 ingenieros adoptó microservicios porque eso era lo que empujaba el circuit de conferencias en 2022, el argumento del monolito modular probablemente pega más acá que en San Francisco. Lo mismo con el código generado por IA: el bottleneck para un equipo chico no es generar features. Es entender y mantener lo que ya existe.
La señal de estas conversaciones comunitarias no es “no usen herramientas de IA”. Es “úsenlas con un ojo puesto en qué pasa seis meses después de que shippen”.
El meta-punto
El ban de r/programming, el discurso del código a mano y el cansancio con los microservicios están apuntando todos a lo mismo: la industria se está volviendo más honesta sobre la brecha entre velocidad y comprensión.
Eso no es una crisis. Es una corrección saludable — y probablemente va a producir mejores herramientas, mejores prácticas y mejores preguntas de las que teníamos hace un año.