Estamos entrando en una etapa peligrosa del desarrollo

Durante años, la industria hizo un esfuerzo enorme por reducir el costo de producir software.

Y, honestamente, lo logró.

Hoy construir cosas es absurdamente más rápido que hace algunos años. Tenemos frameworks cada vez más sofisticados, Cloud Providers, contenedores, pipelines de CI/CD, observabilidad, generación automática, asistentes de código, despliegues automatizados y ahora también modelos de IA integrados prácticamente en cualquier parte del flujo de desarrollo.

Nunca fue tan fácil levantar infraestructura. Nunca fue tan fácil conectar servicios. Nunca fue tan fácil escribir código.

Pero mientras todo eso ocurría, otra cosa empezó a crecer en silencio: el costo de comprender los sistemas que estamos construyendo.

Y sinceramente, creo que ahí es donde está empezando a aparecer uno de los problemas más importantes de esta etapa del desarrollo moderno.

La complejidad no desapareció, simplemente cambió de lugar.

La complejidad no desapareció

Durante mucho tiempo, gran parte de la complejidad del software era bastante explícita. Si algo era difícil, normalmente podíamos verlo.

Digo, había lógica complicada, infraestructura difícil de mantener, sistemas monolíticos enormes, código desorganizado o integraciones dolorosas. La complejidad estaba ahí, visible, y muchas veces hasta era incómoda.

Pero el ecosistema moderno empezó a mover gran parte de esa complejidad hacia otro lugar: las abstracciones.

Y ojo, abstraer complejidad no es algo malo. De hecho, probablemente sea una de las bases más importantes de toda la ingeniería de software.

El problema empieza cuando comenzamos a encadenar capas y capas de herramientas que abstraen otras herramientas que, a su vez, abstraen capas anteriores.

Ahí el sistema empieza a verse simple desde afuera… hasta que algo falla. Y cuando eso pasa, de repente aparecen cosas que muchas veces ni siquiera estaban visibles para el equipo:

• retries automáticos
• workers distribuidos
• tracing
• eventos asincrónicos
• proxies
• balanceadores
• circuit breakers
• cachés
• configuraciones internas del framework
• comportamiento oculto de infraestructura cloud

Es decir: la complejidad no desapareció, sólo quedó escondida detrás de capas cada vez más cómodas.

Y eso cambia muchísimo la forma en la que construimos, debuggeamos y mantenemos software.

Nunca fue tan fácil producir código

Hace algunos años, muchas decisiones técnicas tenían una fricción natural.

Crear un servicio nuevo llevaba tiempo, integrar infraestructura requería investigar bastante. De hecho, levantar ambientes completos no era trivial.

Incluso escribir grandes cantidades de código llevaba tiempo.

Y aunque muchas veces eso era molesto, tenía un efecto secundario interesante (y positivo): nos obligaba a pensar más antes de introducir complejidad al sistema.

Hoy gran parte de esa fricción prácticamente desapareció. Con unas pocas líneas podemos levantar una infraestructura completa, ni hablar de generar APIs o integrar servicios externos. Incluso cosas un tanto más complicadas, como configurar y desplegar pipelines o conectar modelos de IA. En definitiva, podemos generar cientos de líneas automáticamente.

Otra vez: eso no es necesariamente algo malo. El problema es otro. Reducir el costo de construir también reduce el costo de introducir complejidad.

Y muchas veces esa complejidad entra muchísimo más rápido de lo que el equipo llega a comprenderla realmente.

Porque producir software ya no es el principal cuello de botella, sino que el problema es entender lo que estamos produciendo.

La productividad visible se volvió una métrica dominante

Hay otro cambio que vengo notando, bastante interesante por cierto, ocurriendo en paralelo.

La industria empezó a premiar muchísimo la velocidad visible, y no estoy muy de acuerdo. Entiendo que parte de visibilizar lo que hacemos en el día a día es importante a nivel equipo.

Ahora, cuando eso se transforma en una presión, puede afectar a la calidad de lo que se hace. Con esto me refiero a tickets cerrados, PRs generadas, despliegues apurados.

Por eso digo, está bien, pero no siempre. Hay que entender que muchas de las tareas más críticas para mantener sistemas sanos son invisibles.

Entender profundamente una arquitectura no genera un screenshot para LinkedIn, así como eliminar complejidad no siempre produce una feature nueva.

Reducir deuda técnica rara vez se siente “productivo” en el corto plazo, o refactorizar correctamente puede llevar semanas sin mostrar demasiado hacia afuera. Estamos optimizando brutalmente la velocidad de construcción, mientras que nos enfocamos mucho menos la comprensión del sistema. Y eventualmente eso empieza a notarse.

El problema ya no es solamente escribir software

Durante años, gran parte de la dificultad del desarrollo estaba en producir código.

Obviamente, hoy eso cambió muchísimo, incluso escribir código ya no es el principal cuello de botella en muchos equipos.

Lo que pasa es que, así como es tan fácil escribir el código por la IA, no solemos prestarle tanta atención.

Encima ahora, y en parte es muy bueno, cada vez nos especializamos más pero en menos cosas.

Así es como tenemos personas que entienden Kubernetes, otras que que entienden CI/CD. Personas abocadas al dominio de negocio, especialistas en infraestructura cloud, etc, pero nadie entiende completamente todo el flujo end-to-end.

Si no tenemos a alguien que pueda explicar con claridad todo el comportamiento del sistema completo, vamos a tener consecuencias.

La IA no creó este problema

LPretendo dejar en claro mi postura, porque sería muy fácil sumarme a decir “la IA está arruinando el desarrollo”. Sinceramente, no creo que ese sea el verdadero problema.

La industria ya venía moviéndose hacia sistemas cada vez más abstractos, distribuidos y complejos mucho antes de que aparecieran los asistentes de código.

Lo que hizo la IA fue otra cosa: acelerar todavía más la capacidad de producir software, lo cual vuelve todavía más visible una tensión que ya existía.

Como decíamos, generar código nunca fue el único desafío de los sistemas complejos, insisto. El problema aparece después:

• Cuando nadie entiende por qué algo funciona
• Cuando aparecen edge cases inesperados
• Cuando una integración rompe otra
• Cuando producción empieza a comportarse distinto
• o cuando el sistema crece más rápido que la comprensión del equipo

A lo que voy, es que la IA puede reducir muchísimo el tiempo necesario para escribir código, pero no necesariamente reduce el costo de entender la arquitectura, el costo de operar sistemas complejos, el costo de mantener coherencia, el costo de debuggear producción o el costo de comprender el impacto real de los cambios.

De hecho, en algunos casos, puede acelerar todavía más la generación de complejidad accidental.

Estamos entrando en una etapa distinta

Creo que, al contrario de lo que muchos piensan, una de las transformaciones más grandes que estamos viviendo no es tecnológica, sino cultural.

Durante mucho tiempo, aprender desarrollo implicaba entender cómo funcionaban las cosas internamente. Hoy, significa aprender a usar herramientas que abstraen otras herramientas.

Y otra vez: eso no es necesariamente malo.

Sólo pongamos una alerta en cuando la capacidad de producir empieza a crecer mucho más rápido que la capacidad de comprender, porque eventualmente los sistemas llegan a un punto (y doy fe de esto por mi experiencia) donde nadie quiere tocarlos, cada cambio genera miedo, la complejidad operacional se dispara y mantener el sistema empieza a costar muchísimo más que construirlo

Tal vez el problema no sea que estamos construyendo software demasiado complejo. Tal vez el problema es que empezamos a naturalizar trabajar sobre sistemas que nadie entiende completamente.

Y quizás esa sea una de las señales más peligrosas de esta etapa del desarrollo moderno.