El recurso más escaso

La historia de la ingeniería de software suele contarse como un desfile de tecnologías: habitaciones enteras, mainframes, PC, Internet, la nube y ahora la IA. Es una historia ordenada, prolija y, en buena medida: engañosa. Ordena los hechos y hoy me interesa profundizar en por qué aparecieron justo entonces y en ese orden.

Hace un tiempo vengo abordando otra manera de mirarla, y me resulta más útil:  entender la evolución del software como el movimiento del recurso más escaso. En cada momento hay un cuello de botella (un único recurso que limita todo lo demás) y alrededor de él estoy viendo que se reorganiza el sistema entero: el hardware, los lenguajes, las herramientas, las metodologías y hasta (al menos en la industria del software) la forma de estructurar las empresas.

Podes seguir leyendo si te interesa profundizar esta mirada…

Las innovaciones no ganan por ser mejores

Solemos suponer que una tecnología se impone porque es superior. Pero la superioridad, por sí sola, no explica todo. Muchas ideas excelentes llegaron demasiado temprano y murieron; otras, mediocres, se volvieron estándar. Lo que decide no es la calidad intrínseca, sino si esa innovación destraba/libera/resuelve el problema dominante de su época.

Una herramienta se vuelve indispensable cuando ataca el cuello de botella del momento. Y cuando ese cuello de botella se desplaza (porque se resolvió, o porque cambió la economía del problema) la herramienta que reinaba deja de alcanzar. No falla: simplemente deja de ser la palanca que más importa. Ese es el patrón que también noto fue ocurriendo los últimos 70 años.

Si esto es cierto, la pregunta correcta frente a cada innovación es “¿qué recurso escaso libera?”.

El desplazamiento del cuello de botella

Mirada así, la historia tiene una dirección clara. El cuello de botella no se movió al azar: fue ascendiendo de nivel, desde lo más físico hacia lo más abstracto.

Primero fue la máquina. Después, el programador individual. Más tarde, el equipo. Luego, la empresa entera. Y en los últimos años, algo todavía menos tangible: el conocimiento colectivo y el contexto.

Cada vez que el recurso escaso sube un escalón, obliga a rediseñar todo lo que quedó debajo. No es que las herramientas viejas se rompan; es que el problema que resolvían dejó de ser el problema. Vale la pena recorrer esos escalones, porque el último, donde estamos parados hoy, solo se entiende a la luz de los anteriores.

Cuando la máquina era el recurso escaso

Al principio, lo caro era la computadora. El tiempo de máquina se racionaba; un mainframe valía una fortuna y se compartía entre departamentos enteros. En ese mundo, todo servía a la economía de la máquina.

Se programaba en ensamblador, y después en FORTRAN o COBOL, no por comodidad sino para producir programas correctos que aprovecharan cada ciclo de un hardware costosísimo. Se trabajaba por lotes porque el acceso a la máquina era el bien escaso: uno esperaba su turno, entregaba el trabajo y recibía el resultado horas después. Hasta la organización reflejaba esa restricción: un centro de cómputos centralizado, con la máquina en el medio y las personas orbitando a su alrededor.

El costo dominante estaba en el hardware. Y mientras eso fue verdad, la ingeniería consistió, sobre todo, en no desperdiciar máquina.

Cuando el cuello de botella fue el programador

Entonces ocurrió algo que lo cambió: el hardware se abarató aceleradamente (ley de Moore). Las minicomputadoras primero, la PC después, hicieron que la máquina dejara de ser el recurso escaso. Por primera vez, lo caro pasó a ser la persona que la operaba.

El cuello de botella se desplazó al programador individual, y todo el sistema se reorganizó para hacerlo más productivo. Los lenguajes subieron otro escalón de abstracción (de BASIC hacia lenguajes cada vez más expresivos, hasta llegar a Python) para que una persona pudiera escribir más, con menos error y en menos tiempo. Apareció el IDE: primero un editor pegado a un compilador, después entornos que integraban depuración, autocompletado y todo lo necesario para que el desarrollador no perdiera minutos en fricción accesoria. La pregunta que ordenaba el diseño de herramientas era simple: ¿dónde pierde tiempo el desarrollador?

Se optimizó a la persona porque la persona era lo escaso.

Cuando el problema pasó a ser el equipo

Pero el software creció. Dejó de ser un programa que una persona podía sostener en la cabeza y pasó a ser un sistema demasiado grande para una sola mente. Y ahí apareció un límite nuevo: coordinar a varias personas trabajando sobre lo mismo.

Buena parte de lo que asociamos con la ingeniería madura nació como respuesta a este cuello de botella. La orientación a objetos (de Smalltalk a C++ a Java a .NET) y las encapsulaciones (módulos librerías frameworks) fueron entre otras cosas, una forma de partir la complejidad en piezas para que distintos equipos pudieran trabajar en paralelo sin pisarse. El control de versiones surgió para que muchas manos tocaran el mismo código sin destruirlo. Y cuando la coordinación empezó a fallar de manera sistemática, la solución tuvo nombre propio: agile, esa constatación incómoda de que los proyectos grandes se atrasaban, se pasaban de presupuesto y a veces fracasaban rotundamente .

El costo ya no estaba en la máquina ni en el individuo. Estaba en el espacio entre las personas.

Cuando lo difícil fue coordinar con el negocio

El salto siguiente fue de escala. Ya no se trataba de coordinar un equipo, sino muchos equipos, muchos sistemas y muchas dependencias a la vez. Y acá aparece una de las ideas que más me interesan de toda esta historia: las metodologías no cambian porque alguien inventa una mejor. Cambian porque el cuello de botella organizacional se movió y la forma de coordinar existente dejó de funcionar.

Waterfall no fracasó por torpeza; fracasó porque suponía un mundo predecible que había dejado de existir. En 1986, Takeuchi y Nonaka describieron en Harvard Business Review equipos que funcionaban más como un scrum de rugby que como una posta de relevos: avanzando juntos, superponiendo etapas, aprendiendo sobre la marcha. De ahí, años después, salió Scrum. Extreme Programming atacó la misma tensión desde la ingeniería. Lean trajo la obsesión por el flujo y el desperdicio. DevOps derribó el muro entre construir y operar. Platform Engineering apareció cuando coordinar a decenas de equipos volvió a ser el límite.

Cada una de esas prácticas resolvió un problema de coordinación, flujo de información, velocidad de aprendizaje y autonomía. Ninguna era “mejor” en abstracto. Cada una fue la respuesta a un cuello de botella organizacional puntual. La nube, mientras tanto, hizo con la infraestructura lo que la PC había hecho con la máquina: la sacó de la lista de recursos escasos.

Cuando lo escaso pasa a ser “comprender”

Y así llegamos al presente, que solo tiene sentido a la luz de todo lo anterior.

Durante décadas, escribir código fue una de las actividades caras del proceso. La IA la volvió, en buena medida, abundante y casi gratuita. Generar un componente, un test, una primera versión de casi cualquier cosa dejó de ser el trabajo difícil. Y si producir código deja de ser el cuello de botella, entonces el recurso escaso volvió a moverse.

Lo que se volvió escaso es comprender el contexto. No el código en sí, sino todo lo que lo rodea y le da sentido: la arquitectura, el negocio, las decisiones históricas y por qué se tomaron, las dependencias, los riesgos, la documentación y, sobre todo, el conocimiento tácito que casi nunca está escrito en ningún lado. Ese escalón intermedio ya venía asomando desde antes: el conocimiento colectivo de la organización, eso que el sistema entero sabe pero que ninguna persona posee por completo.

Las herramientas ya empezaron a acusar el cambio. Copilot todavía era, sobre todo, un acelerador de escritura. Cursor y los agentes empiezan a ser otra cosa: instrumentos para navegar, entender y operar sobre un proyecto entero. El IDE está dejando de ser una herramienta para editar archivos y se está convirtiendo, silenciosamente, en una herramienta para comprender sistemas. La próxima generación de herramientas probablemente se dedique menos a generar código y más a construir y compartir contexto.

Crear y Mantener no son la misma actividad

Hay una distinción que esta transición vuelve urgente y que, sin embargo, seguimos ignorando en la práctica.

Crear software y mantener software son actividades cognitivamente distintas. Crear (lo que a veces llamamos greenfield) es diseñar, inventar, experimentar, escribir sobre una hoja en blanco. Mantener (brownfield) es lo contrario: comprender algo que ya existe, investigar por qué está hecho así, diagnosticar, reducir riesgo antes de tocar. Una mira hacia el futuro; la otra, hacia el pasado.

Y sin embargo hoy hacemos ambas con prácticamente el mismo IDE, como si fueran la misma tarea. ¿Tiene sentido que el entorno para inventar algo nuevo sea idéntico al entorno para entender y sostener un sistema de diez años?

Me arriesgo a una hipótesis: algunos van a divergir. El entorno de trabajo del ingeniero va a dejar de organizarse alrededor del editor de archivos y va a empezar a organizarse alrededor de aquello que hoy es escaso (objetivos, incidentes, arquitectura, conocimiento). Algo más parecido a un Engineering Workspace que a un editor de archivos, por más inteligente que se vuelva. Y es probable que crear y mantener terminen teniendo espacios especializados, porque exigen modos de pensar distintos.

El mismo patrón, en las organizaciones

Hasta acá hablé de software, pero el patrón excede al software. La evolución técnica y la evolución de las empresas siguen la misma lógica, porque las dos responden al mismo tipo de pregunta: ¿qué es lo escaso ahora?

Cuando fabricar era difícil, las empresas se rediseñaron alrededor de la optimización industrial. Cuando programar era difícil, invirtieron en lenguajes y herramientas. Cuando coordinar era difícil, adoptaron Agile y rediseñaron sus equipos. Y hoy, cuando lo difícil es comprender sistemas complejos y decidir bien dentro de ellos, el problema vuelve a ser, como al principio, organizacional.

Esta es, para mí, la implicancia más importante de toda la historia. Si el código se abarata y el contexto se encarece, la ventaja competitiva se muda del acto de producir al acto de comprender y decidir. Y comprender y decidir no son propiedades de una herramienta: son propiedades de una empresa (de cómo distribuye información, cuánta autonomía les da a sus equipos, qué tan rápido aprende, cómo conserva y hace circular lo que sabe).

Dicho de otra manera: la próxima frontera no la van a ganar los equipos que escriban más código, sino las organizaciones que sepan elevar su capacidad colectiva de entender lo complejo y actuar sobre eso con criterio.

La historia del software no es la historia de las computadoras

Bajo esta mirada, si tuviera que quedarme con una sola idea, sería esta: la historia del software es la historia del desplazamiento del recurso más escaso.

Vale la pena recorrerla una vez más, despacio, porque el recorrido es el argumento. Primero optimizamos máquinas. Después, programadores. Más tarde, equipos. Luego, organizaciones enteras. Y hoy empezamos a optimizar algo mucho más difícil de nombrar: el conocimiento y el contexto. Cada capa no reemplazó a la anterior; la absorbió y subió un escalón.

Por eso conviene desconfiar de quien anuncia que la IA “termina” con la ingeniería. No la termina. Le mueve el centro, una vez más, hacia arriba. Y ese movimiento tiene dos caras que, me parece, conviene mirar juntas.

La primera es incómoda. Buena parte de lo que se vuelve prescindible es, justamente, lo que todavía ocupa el centro de nuestra formación: la ejecución mecánica, el procedimiento, la producción manual de cada pieza. No desaparece la profesión, pero sí se erosiona el tramo del oficio que durante años aprendimos a confundir con el oficio entero. Y esa parte, la más fácil de enseñar y la más fácil de evaluar, es también la primera que la IA esta absorbiendo.

La segunda cara es más luminosa, y equilibra a la primera. A medida que ese tramo se abarata, lo que se eleva es la ingeniería misma. No la ingeniería como acto de escribir, sino como acto de resolver: comprender el problema, elegir con criterio, diseñar la solución y hacerse cargo del resultado. El centro de gravedad de la profesión se corre hacia ahí, hacia la ingeniería de las soluciones. Y cuando eso ocurre a escala, deja de ser una cuestión individual y se vuelve, como vimos, una cuestión de negocios.

Si la hipótesis es correcta, esta evolución consiste en subir un escalón: correr el centro desde producir la solución código hacia comprender y diseñar la solución en un contexto cambiante. Dicho de la forma más simple que encuentro: dejar de enamorarnos de la herramienta para volver a enamorarnos del problema que vinimos a resolver.