El software siempre ha escalado la abstracción

10 min de lectura

El trabajo no desapareció. Subió de nivel.

La idea de que el desarrollo de software consiste sobre todo en teclear siempre ha sido un malentendido nacido de mirar la capa equivocada.

Teclear era mucho más penoso antes, desde luego. Había interruptores físicos, instrucciones de máquina, soportes perforados, campos de ancho fijo, mensajes del compilador sin el menor intento de simpatía y suficiente complejidad accidental para convertir un error pequeño en una tarde entera. Quitar esa fricción importaba.

Todavía importa.

Pero cada abstracción que tuvo éxito eliminó una clase de trabajo para que las personas pudieran tomar decisiones más importantes en la capa superior. Los detalles no desaparecieron. Se convirtieron en maquinaria fiable de otra persona, hasta que vuelven a filtrarse y exigen atención.

Los agentes de programación con IA son el ejemplo más reciente. No son ni una ruptura sobrenatural ni un autocompletado elegante. Son una nueva interfaz con la pila. La diferencia importa, sobre todo para las empresas que ahora tratan una demo lograda como prueba de que la responsabilidad sobre el software se ha vuelto opcional.

Zuse hizo de la máquina la interfaz

Konrad Zuse terminó la Z1 en 1938. Era una máquina mecánica libremente programable construida con elementos de conmutación binarios, una unidad aritmética, memoria, entrada y salida, y un lector de programas. La reconstrucción del Deutsches Technikmuseum de Berlín corrige útilmente la historia pulida que la gente se cuenta sobre la informática: antes de que el software se volviera invisible, era dolorosamente físico. La historia de la Z1 en el museo merece la visita por eso.

En ese nivel, quien programaba no podía fingir que la lógica estaba separada de la máquina. La representación de datos, el flujo de control, la memoria, la entrada y la salida estaban lo bastante cerca como para tocarlos. Un programa no era un documento de producto. Era una secuencia explícita de instrucciones para un aparato físico concreto.

No fue una edad de oro. Nadie sensato quiere volver allí.

Fue la línea de base. Cada capa posterior empujó algún detalle de la máquina bajo un vocabulario más útil. Eso es la abstracción cuando hace bien su trabajo: no ocultar la realidad, sino hacer fiable una parte estable de ella para que uno pueda dejar de pensar en ella cada minuto.

COBOL llevó el lenguaje de negocio al código

El comité que se formó en 1959 para crear COBOL quería un lenguaje común de negocio con programas legibles y tanta independencia de la máquina como fuera posible. Era una ambición práctica, no ingenua. El relato del Computer History Museum deja clara la intención: el procesamiento de datos de negocio necesitaba un lenguaje que sobreviviera a una máquina y a un proveedor.

COBOL llevó la conversación hacia arriba. En vez de hablar sobre todo en operaciones de máquina, un programa podía hablar de registros, informes, cuentas y nóminas. Grace Hopper ayudó a definir esa dirección. El resultado se convirtió en uno de los lenguajes más exitosos de la informática de negocio, porque las empresas no funcionan con algoritmos en abstracto. Funcionan con nombres, categorías, reglas, excepciones y libros contables que alguien termina codificando.

La parte importante es lo que no ocurrió.

COBOL no hizo sencillos los sistemas de negocio. Hizo posible expresar mucha más lógica de negocio, a una escala que sobrevivió a equipos, generaciones de hardware y modas de gestión. El código fuente podía parecer más cercano al negocio mientras el sistema real crecía hasta ser una dependencia densa que pagaba salarios, movía dinero y mantenía administraciones en funcionamiento.

La abstracción funcionó. La responsabilidad se desplazó. Un desarrollador ya no necesitaba manejar cada instrucción de máquina, pero seguía teniendo que entender la regla de negocio que sería errónea para diez mil clientes si se interpretaba mal un campo.

Ese es el patrón que no deja de volver.

La orientación a objetos dio nombre a la estructura

Para cuando Simula y después Smalltalk dieron forma a la programación orientada a objetos, el problema había vuelto a desplazarse. Los programas ya no eran difíciles solo porque las máquinas fueran incómodas. Lo eran porque el propio software se había vuelto demasiado grande para la memoria de trabajo de una sola persona.

Simula convirtió las clases y los objetos en conceptos centrales. Smalltalk llevó la idea más lejos con objetos, mensajes y un entorno vivo. Eso no resolvió el diseño. Le dio al diseño un lenguaje mejor.

Un objeto bien elegido puede mantener juntos el estado y el comportamiento. Puede mostrar de qué es responsable una parte del sistema y ocultar detalles de implementación de los que otras partes no deberían depender a la ligera. Es una abstracción útil. Permite a un desarrollador razonar sobre un cliente, una factura, una reserva o una regla de precios sin arrastrar a la vista cada columna de base de datos y cada rama de control.

Y, como las personas son personas, la orientación a objetos también produjo océanos de diagramas de clases decorativos, jerarquías de herencia con forma de árbol familiar de un mal drama real y abstracciones cuya única responsabilidad era convertir un cambio sencillo en tres reuniones.

El abuso no invalida la idea. Demuestra el argumento. Una abstracción más alta da más palanca, incluida la palanca de crear tonterías elaboradas con más rapidez. La capacidad escasa nunca fue conocer la palabra “encapsulación”. Fue decidir qué límite aclara el sistema y cuál solo esconde confusión detrás de un sustantivo respetable.

El trabajo de Ward Cunningham sobre entendimiento compartido forma parte de esta tradición. El objetivo no era producir más vocabulario. Era conseguir que el vocabulario respondiera al trabajo.

Los frameworks retiraron repetición, no criterio

Una vez que los lenguajes, sistemas operativos, bibliotecas y modelos de objetos absorbieron más del antiguo trabajo mecánico, los frameworks fueron a por la repetición.

No conectes cada petición a mano. No construyas cada mapeo de base de datos desde cero. No escribas la misma estructura de autenticación por vigésima vez. No hagas que cada equipo redescubra cómo empaquetar, desplegar, registrar y monitorizar un servicio normal.

Bien. Para eso sirven las herramientas maduras.

La era de los frameworks produjo a veces la misma ilusión que ahora rodea a la IA: si la herramienta se encarga de más, quizá las personas puedan entender menos. Esa lógica nos dio empresas que compraban una pila antes de definir el producto, diagramas de arquitectura tratados como sustituto de la responsabilidad operativa y equipos capaces de crear servicios deprisa pero incapaces de explicar dónde vivía una regla de negocio.

La respuesta útil nunca fue rechazar los frameworks y escribirlo todo desde cero como una asociación de recreación histórica. La respuesta fue reconocer dónde se había movido el trabajo.

Si Spring resuelve la fontanería empresarial rutinaria, la pregunta del desarrollador pasa a ser si el límite del servicio tiene sentido. Si una plataforma cloud resuelve primitivas de infraestructura, la pregunta pasa a ser qué debe ser observable, recuperable, seguro y tener un responsable. Si un framework web resuelve el renderizado y el enrutamiento, la pregunta pasa a ser si el flujo ayuda a una persona real a terminar algo.

La pila sube. Las decisiones son menos, más grandes y más caras cuando salen mal.

Los agentes de IA elevan la interfaz por encima del código

El autocompletado de código ya era una pequeña abstracción: una herramienta adivinaba los siguientes tokens para que el desarrollador tecleara menos. Un agente es cualitativamente distinto porque puede trabajar a lo largo de una tarea. Los agentes de programación modernos pueden leer archivos, buscar en una base de código, consultar documentación, editar código, ejecutar comprobaciones y ajustarse cuando una comprobación falla. La documentación de agentes de VS Code describe ese ciclo sin rodeos.

La nueva unidad de trabajo ya no es solo una línea o una función. Es una intención, unas restricciones y evidencia.

“Añade soporte para esta regla de cliente, conserva el contrato existente, actualiza las pruebas y muéstrame qué ha cambiado” no es una petición de sintaxis. Es una petición para operar en un nivel superior de la pila. El agente realiza una parte de la traducción entre esa petición y el repositorio.

Eso es palanca real.

Por eso la frase “la IA escribe el código, así que ya no necesitamos desarrolladores” es tan infantil. La parte difícil se ha alejado de teclear, no ha desaparecido dentro del modelo. Alguien todavía tiene que decidir si la regla de cliente es coherente, si merece conservarse el contrato existente, si una prueba demuestra comportamiento en vez de ceremonia y si el cambio debe pertenecer al sistema en absoluto.

El agente puede proponer respuestas. No puede hacer responsable a la organización de ellas.

Las pruebas vencen a las instrucciones para los agentes de programación con IA por esta misma razón. Un prompt largo puede describir lo que el equipo espera que ocurra. Una prueba ejecutable da al agente un límite que no puede sortear con palabrería.

El nuevo fracaso es la confianza acelerada

El antiguo modo de fallo era el desarrollo lento. Una empresa podía pasar meses traduciendo una intención vaga mediante reuniones, documentos, tickets, traspasos y código antes de que alguien viera que la premisa era incoherente.

La IA facilita un fallo distinto.

Ahora una persona responsable de operaciones puede describir un flujo de trabajo en una ventana de chat, recibir una pantalla que funciona, conectar una fuente de datos real y demostrar un caso ideal antes de que el comité de dirección termine de nombrar sus subgrupos. Es impresionante. También es el momento en que una organización tiene más tentación de confundir salida visible con comportamiento entendido.

Un flujo de trabajo no deja de ser software porque empezara como una petición de operaciones. En cuanto une datos reales, cambia un registro de cliente o activa una aprobación, alguien es responsable de su comportamiento en producción.

¿Qué ocurre cuando los datos están incompletos?

¿Quién puede cambiar la regla?

¿Cuál es el camino de vuelta?

¿Qué acción necesita aprobación?

¿Qué debe quedar registrado?

¿Cómo sabe el equipo que la versión de mañana sigue haciendo lo que hizo hoy la demo?

Estas preguntas no son restos de un oficio antiguo. Son el trabajo que queda después de que el oficio se haya vuelto más poderoso.

El peligro no es que los agentes de IA produzcan basura. A menudo producen trabajo plausible y útil. El peligro es que lo producen tan deprisa que personas sin un modelo de las consecuencias del software pasan de espectadores a responsables del sistema antes de conocer la diferencia.

La pila necesita personas capaces de pensar por encima de ella

Cada capa de esta historia llevaba una promesa de alivio.

La máquina de Zuse convirtió el cálculo en pasos mecánicos repetibles. COBOL convirtió el procesamiento de negocio en un lenguaje que podía viajar. La orientación a objetos dio nombres y límites a los sistemas complejos. Los frameworks convirtieron tareas técnicas repetidas en convenciones. Los agentes de IA convierten más de la traducción entre intención y código en una conversación ejecutable.

Acepta el alivio. Usa las herramientas. Nadie recibe una medalla por pulir a mano las capas inferiores.

Pero dejemos de cometer el mismo error de gestión cada vez: tratar una abstracción como prueba de que ya no hace falta entender.

Las abstracciones no eliminan la complejidad. La concentran en el punto donde las decisiones se vuelven visibles. El detalle de nivel inferior sigue ahí, esperando el día en que se rompa una suposición. La organización sigue necesitando personas capaces de seguir una petición de negocio a través de código, datos, integraciones, despliegue y consecuencias operativas sin fingir que una de esas capas es problema de otro.

Eso es en lo que se convierten más los desarrolladores serios en la era de los agentes, no menos.

Quien operaba la Z1 tenía que pensar en la máquina. El desarrollador COBOL tenía que pensar en reglas de negocio. El desarrollador orientado a objetos tenía que pensar en límites. El desarrollador asistido por IA tiene que pensar en todo el sistema, y ahora tiene menos excusas para esconderse detrás del teclado.