Torras.ai

Durante la mayor parte de la historia de la ingeniería de software, el progreso ha seguido un patrón claro: la abstracción reemplaza a la mecánica.

Comenzamos programando las máquinas de la manera más literal posible. Los primeros desarrolladores escribían instrucciones de máquina directamente, manipulando registros y direcciones de memoria. Era poderoso, pero cognitivamente costoso. Cada detalle debía ser gestionado manualmente.

El lenguaje ensamblador abstrajo el binario puro en instrucciones simbólicas. No eliminó la complejidad, pero la hizo manejable.

 mov eax, [price]
 sub eax, [tax]
 mov [net_amount], eax

Luego llegaron los lenguajes de alto nivel. Entre los primeros estuvieron Fortran y COBOL, cada uno representando un salto conceptual significativo. Fortran permitió a los ingenieros expresar fórmulas matemáticas de una manera más cercana a cómo ya razonaban sobre ellas. COBOL intentó algo aún más ambicioso: buscó acercar la programación al lenguaje de los negocios.

Una instrucción típica de COBOL podría leerse así:

SUBTRACT TAX FROM PRICE GIVING NET-AMOUNT

En lugar de la expresión más compacta que verías en muchos lenguajes posteriores:

net_amount = price - tax;

Los creadores de COBOL creían que si los programas se parecían al inglés, los usuarios de negocios podrían leerlos e incluso escribirlos más fácilmente. Fue un intento temprano de reducir la brecha entre la intención humana y la ejecución de la máquina.

Sin embargo, COBOL no era inglés. Era un Lenguaje Formal diseñado para parecerse al inglés. Seguía siendo rígido, determinista y atado a la sintaxis. Los humanos aún tenían que adaptarse a la estructura de la máquina. La abstracción redujo la carga cognitiva de la programación de bajo nivel, pero no eliminó la capa de traducción entre la intención y la implementación.

Esa capa de traducción ha definido la profesión de la ingeniería de software durante décadas.

Intención Declarativa: El Caso de SQL

Hubo otro momento importante en esta evolución que a menudo se pasa por alto: la llegada de SQL.

Structured Query Language (SQL) fue diferente de la mayoría de los lenguajes de programación que lo precedieron. Era declarativo. En lugar de decirle al sistema cómo recuperar los datos —qué índices recorrer, qué bucles ejecutar, qué uniones calcular primero— el desarrollador simplemente describía qué datos necesitaba.

 SELECT name, balance 
 FROM accounts 
 WHERE balance > 1000;

Esto fue un cambio de abstracción profundo. El ingeniero expresaba la intención. El motor de la base de datos decidía el plan de ejecución.

En ese sentido, SQL estaba más cerca del Lenguaje Natural que la mayoría de los lenguajes procedimentales. Se leía casi como inglés. Se centraba en describir el resultado deseado en lugar de prescribir la secuencia de operaciones necesarias para lograrlo.

Y sin embargo, a pesar de su accesibilidad, SQL nunca se convirtió realmente en un lenguaje para usuarios de negocios. Siguió siendo técnico. Escribir consultas correctas requería entender esquemas, relaciones, implicaciones de rendimiento, normalización, indexación y comportamiento transaccional. La abstracción simplificó la ejecución, pero no eliminó la necesidad de experiencia.

SQL fue una demostración temprana de que describir qué en lugar de cómo es poderoso. Pero la capa de traducción seguía existiendo. Los humanos aún tenían que pensar en una sintaxis estructurada y formal. El sistema optimizaba la ejecución, pero no interpretaba la intención ambigua.

La Capa de Traducción

Tradicionalmente, construir software ha requerido un proceso de conversión:

1. Un problema de negocio se expresa en lenguaje natural.
2. Un desarrollador traduce esa descripción en requisitos estructurados.
3. Esos requisitos se traducen en código.
4. La máquina ejecuta ese código.

El valor central del desarrollador ha residido durante mucho tiempo en esta capacidad de traducción. El conocimiento de la sintaxis, la familiaridad con los frameworks y el recuerdo de funciones de librerías eran parte de hacer esa traducción eficiente y precisa.

Sin embargo, la llegada de los grandes modelos de lenguaje ha comenzado a alterar esta dinámica de manera fundamental.

Hoy, es posible escribir algo como:

 Diseña un sistema modular de procesamiento de pagos con operaciones idempotentes, 
 registro de auditoría, lógica de reintentos con retroceso exponencial, 
 y pruebas de integración que simulen fallos de red. 
 Debe seguir la arquitectura y convenciones existentes de la aplicación, 
 incluyendo el mismo estilo de código, elección de frameworks, patrones de base de datos
 (ORM, migraciones, transacciones), stack de logging/observabilidad, 
 enfoque de configuración y prácticas de despliegue. Reutiliza librerías 
 y utilidades existentes siempre que sea posible, y evita introducir nuevas 
 dependencias a menos que sea estrictamente necesario. 

Esto no es código. Es intención estructurada.

Y sin embargo, un sistema de IA capaz puede transformar esa intención en andamiaje, casos de prueba e incluso patrones arquitectónicos en segundos.

Esto no es simplemente automatización de código repetitivo. Es automatización de la traducción.

El Cambio en la Escasez

Cada capa de abstracción cambia lo que es escaso.

Cuando los compiladores se volvieron confiables, memorizar instrucciones de ensamblador dejó de ser valioso. Cuando los frameworks maduraron, escribir código de infraestructura a mano dejó de ser un diferenciador.

Ahora, a medida que los sistemas de IA generan código sintácticamente correcto y a menudo estructuralmente sólido, la escasez vuelve a moverse.

Las habilidades valiosas incluyen cada vez más:

• Articulación precisa de los requisitos
• Descomposición de sistemas complejos en componentes manejables
• Definición explícita de restricciones y casos límite
• Razonamiento arquitectónico
• Evaluación crítica del resultado generado
• Disciplina en pruebas y validación

Memorizar sintaxis o recordar detalles oscuros de APIs se vuelve menos central, porque esas tareas están cada vez más automatizadas.

Esto no elimina la necesidad de un conocimiento técnico profundo. Al contrario, amplifica la importancia del juicio. Los ingenieros aún deben comprender las implicaciones de rendimiento, los compromisos de seguridad, los riesgos de concurrencia y los límites del sistema. Pero el acto mecánico de escribir código ya no es el único cuello de botella.

La intención se convierte en el activo duradero.

El Inglés como Capa de Programación

Decir que el inglés se está convirtiendo en una capa de programación no significa que los lenguajes formales desaparezcan. Los compiladores, los runtimes y los entornos de ejecución siguen operando sobre código estructurado.

Más bien, el inglés —o más precisamente, el lenguaje natural estructurado— se está convirtiendo en la capa de abstracción más alta por encima de los lenguajes de programación tradicionales.

El flujo cada vez se ve así:

 Intención (lenguaje natural)
 → Generación estructurada (IA)
 → Código formal
 → Ejecución por la máquina

En este modelo, el código se convierte en un artefacto intermedio. Puede ser regenerado, refactorizado y optimizado automáticamente. Lo que permanece estable es la definición del problema y la claridad de las restricciones.

La calidad del sistema final depende menos de la capacidad del desarrollador para recordar la sintaxis y más de su capacidad para describir qué debe hacer el sistema, bajo qué condiciones, con qué garantías y frente a qué modos de fallo.

El lenguaje natural se vuelve ejecutable no porque sea inherentemente preciso, sino porque los sistemas de IA se han convertido en intérpretes capaces.

¿Quién construirá software ahora?

Este cambio plantea una pregunta más profunda que cómo deben formarse los ingenieros. Plantea la cuestión de quién programará.

Si los sistemas de IA pueden traducir la intención estructurada en software ejecutable, ¿podrán finalmente los usuarios de negocio construir directamente lo que necesitan? ¿Se volverá el lenguaje natural lo suficientemente preciso como para que los expertos de dominio puedan describir sistemas sin intermediarios?

La historia sugiere cautela. COBOL intentó acercar la programación al lenguaje de negocios. SQL permitió a los usuarios describir qué datos querían en lugar de cómo recuperarlos. Ambos fueron cambios de abstracción significativos, y sin embargo ambos siguieron siendo herramientas técnicas. La capa de traducción no desapareció; simplemente se movió.

Quizás esta vez sea diferente. Quizás los sistemas de IA absorberán suficiente complejidad como para permitir que los usuarios no técnicos operen de forma segura en un nivel más alto de abstracción.

O quizás los profesionales técnicos seguirán siendo esenciales —no como mecanógrafos de sintaxis, sino como diseñadores de restricciones, arquitectos de sistemas y guardianes de la corrección.

Aun si el inglés —o cualquier otro lenguaje natural, en realidad— se convierte en la capa de abstracción más alta, en algún lugar debajo, COBOL seguirá procesando transacciones, los compiladores seguirán optimizando instrucciones y el código formal seguirá ejecutándose de manera determinista.

Las abstracciones evolucionan. La infraestructura persiste. El valor se mueve hacia arriba.

Si la IA democratiza la programación por completo o simplemente eleva el rol de los ingenieros a una capa superior, solo el tiempo lo dirá.