La insensatez de la «programación en lenguaje natural» (1978)
Las interfaces en lenguaje natural para programar están reavivando un sueño de larga data que Edsger Dijkstra consideró fundamentalmente equivocado en 1978. Los comentaristas contraponen su énfasis en la precisión de los lenguajes formales con los grandes modelos de lenguaje actuales, señalando que la IA ahora puede convertir solicitudes vagas en inglés en código funcional, pero sigue heredando la ambigüedad del lenguaje natural, la falta de garantías y la dependencia de la supervisión humana. Muchos ven a los LLMs menos como “compiladores de lenguaje natural” y más como desarrolladores junior estocásticos o agentes, útiles para acelerar el trabajo y elevar los niveles de abstracción, pero no para reemplazar los lenguajes de programación tradicionales, las especificaciones o la ingeniería de software cuidadosa.
Alcance de la “Programación en Lenguaje Natural”
- Muchos sostienen que el ensayo sigue siendo aplicable: el lenguaje natural es informal, ambiguo e inadecuado como representación primaria de un programa.
- Varios comentaristas subrayan que la “programación en lenguaje natural” de hoy en realidad es delegación en lenguaje natural a un agente que luego escribe código convencional.
- Una minoría sostiene que la crítica original es “irrelevante” porque el lenguaje natural ahora sirve como una capa de abstracción más que se compila en lenguajes formales.
¿LLMs: compiladores, desarrolladores o algo más?
- Postura fuerte: los LLMs no reemplazan a los compiladores; reemplazan (o complementan) a los desarrolladores de software que traducen especificaciones informales a código.
- Otros ven a los LLMs como un nuevo tipo de intérprete para un lenguaje poco especificado (prompts), es decir, una forma de programación, pero con semántica probabilística.
- Debate sobre si el prompting es realmente “programación” o solo dar instrucciones a otra entidad parecida a un programador.
Determinismo, semántica y fiabilidad
- Varios comentarios distinguen entre canales de compilación deterministas y salidas de LLMs estocásticas y sensibles al contexto.
- Algunos objetan que los humanos también son no deterministas en la práctica, pero otros insisten en que la estocasticidad es una noción distinta y más fuerte que la mera variación.
- Hay consenso en que los compiladores y los sistemas de tipos ricos siguen siendo esenciales para garantías semánticas, pruebas y controles de seguridad sobre el código generado por LLMs.
Especificaciones, reuniones y comprensión de sistemas
- Varias anécdotas destacan que el trabajo real depende de aclarar especificaciones vagas en lenguaje natural, ya lo hagan humanos o agentes.
- Los usuarios de negocio a menudo tienen dificultades incluso con la configuración en lenguaje natural; el “pensamiento de sistemas” y la habilidad de especificar siguen siendo raros y cruciales.
- Los agentes carecen de contexto del mundo real (infraestructura, restricciones organizativas, responsabilidad), lo que limita la automatización completa del papel de analista/ingeniero.
Código, prompts y fuente de verdad
- Muchos insisten en que el lenguaje en el control de versiones (Java/Python/etc.) determina en qué está “programado” el sistema, independientemente de cómo se produjo ese código.
- Algunos prevén que, con el tiempo, los prompts o las conversaciones se traten como artefactos primarios, lo que plantea cuestiones de mantenibilidad y licencias de código abierto.
- La salida de los LLMs se compara con cualquier generador de código de uso puntual: la mantenibilidad y la reproducibilidad siguen siendo problemas.
Experiencias empíricas y excepciones de nicho
- Los usuarios informan éxito haciendo “vibe coding” de aplicaciones mediante agentes, pero señalan que se pasan por alto requisitos no funcionales, detalles de infraestructura y errores sutiles.
- Inform7 y la redacción legal se citan como ejemplos de lenguajes cuasi naturales: legibles pero aun así altamente restringidos, lo que subraya lo difícil que es la verdadera programación en lenguaje natural.