Del texto al proceso: compilación, interpretación y tiempo de ejecución
Cuando un agente te dice «la compilación (build) ha terminado sin errores», ¿qué ha quedado demostrado realmente y qué sigue sin comprobarse? Muchos errores de aceptación ocurren por confundir el hecho de que un programa esté bien formado y traduzca sin fallos con el hecho de que funcione correctamente cuando recibe datos reales en ejecución.
Objetivos y conocimientos previos
Partiendo de Lenguajes formales, aprenderás cómo el texto del código fuente se transforma en instrucciones ejecutables, cuál es la diferencia crítica entre tiempo de construcción/compilación (build time) y tiempo de ejecución (runtime), y cómo evaluar los paquetes o bibliotecas externas que un agente incorpora a tu proyecto.
Del texto legible por humanos a la ejecución
El procesador de una máquina no lee directamente los archivos de texto de tu proyecto. Para que el código se ejecute, debe pasar por un proceso de traducción y preparación que varía según el entorno:
- Código Fuente y Dependencias (Texto formal escrito en archivos del proyecto)
- Fase de Construcción / Verificación Estática (Análisis de sintaxis, tipos y empaquetado / compilación)
- Proceso en Tiempo de Ejecución / Runtime (El programa corre en memoria atendiendo entradas y datos reales)
Aunque las herramientas emplean distintas estrategias técnicas —compilar todo el programa a un archivo ejecutable antes de arrancarlo, interpretarlo mediante un programa anfitrión, o combinar ambos métodos traduciendo al vuelo (Just-In-Time)—, para dirigir el desarrollo lo esencial es distinguir los dos momentos del ciclo de vida del programa:
| Momento | Qué ocurre aquí | Qué tipo de errores se detectan | Qué NO puede saber todavía |
|---|---|---|---|
| 1. Tiempo de construcción / compilación (Build / Compile Time) | Se analiza el código en seco, sin usuarios reales: se comprueba que la gramática sea válida, que los módulos importados existan y que los contratos de tipos coincidan entre sí. | Errores sintácticos, llamadas a funciones inexistentes, tipos incompatibles entre módulos, archivos que faltan en el proyecto. | No sabe si la base de datos de producción responderá, si el usuario enviará una lista vacía ni si la fórmula de negocio elegida era la que tú querías. |
| 2. Tiempo de ejecución (Runtime) | El programa ya está en marcha dentro de un proceso con memoria asignada, recibiendo entradas externas, leyendo configuraciones y comunicándose con la base de datos y la red. | Fallos de conexión, permisos denegados, divisiones por cero con datos reales, condiciones de carrera y errores lógicos del modelo. | Si un fallo llega aquí sin haber sido previsto, lo sufre directamente el usuario o la integridad de los datos. |
Las tres clases de fallos que debes distinguir al auditar al agente
Cuando pides evidencias al agente, clasifica siempre los resultados en estos tres niveles:
- Fallos estáticos (de sintaxis o de tipos): El código ni siquiera respeta las reglas formales del lenguaje o contradice los tipos declarados. Superar esta barrera (que el proyecto compile y pase el verificador de tipos) es el requisito mínimo indispensable, nunca la prueba final de que el producto funciona.
- Fallos de ejecución (Runtime crashes o excepciones no controladas): El programa compila bien, pero se rompe al correr ante una situación real (por ejemplo, intenta leer un archivo que no existe o dividir entre cero cuando una actividad tiene cero reservas).
- Fallos semánticos o lógicos: El programa compila sin avisos y corre sin lanzar ningún error técnico, pero hace lo contrario de lo que exige el negocio (por ejemplo, al cancelar una reserva suma 1 a las plazas ocupadas en lugar de restar 1).Ningún compilador detecta por sí solo un fallo de negocio si tú no defines pruebas sobre las reglas del dominio.
Dependencias y bibliotecas externas: reutilizar con criterio
Ningún sistema actual se construye desde cero absoluto. Los proyectos utilizan:
- Biblioteca estándar del entorno: capacidades ya incluidas en la plataforma base (manejar fechas, leer archivos, comunicarse por HTTP).
- Paquetes o dependencias de terceros: módulos creados por otras personas o empresas que se descargan e integran en el proyecto (por ejemplo, para conectar con una base de datos, validar esquemas o generar documentos).
Cuando trabajas con un agente de IA, debes vigilar especialmente el uso de dependencias externas por tres razones:
- Riesgo de paquetes inventados o innecesarios: Un modelo de IA puede sugerir instalar una biblioteca externa enorme para una tarea trivial de cinco líneas, o incluso citar un nombre de paquete que no existe o que quedó abandonado hace años.
- Desajuste de versiones: Una biblioteca pudo cambiar su contrato entre su versión
3y su versión4. Si el agente escribe código recordando la versión antigua mientras el proyecto tiene instalada la versión nueva, fallará en construcción o en ejecución. - Superficie de mantenimiento y seguridad: Cada dependencia externa que añades es código ajeno que se ejecuta con los mismos permisos que tu propio programa. Cuantas menos dependencias innecesarias tenga un sistema y mejor documentadas estén las elegidas, más fácil será mantenerlo y adaptarlo.
Practica
Un agente termina una tarea en tu sistema de facturación y te entrega este informe:
«He añadido una biblioteca externa para calcular impuestos y he actualizado el módulo de cobros. He ejecutado la verificación de tipos y la compilación de producción (build) y han terminado con 0 errores. Por tanto, el cálculo de impuestos y el cobro ya están verificados y listos».
- Explica con precisión qué demuestra que la compilación y los tipos hayan pasado con 0 errores, y enumera tres cosas críticas del módulo de cobros e impuestos que esa comprobación no ha puesto a prueba en absoluto.
- ¿Qué preguntas le harías al agente para justificar si realmente hacía falta instalar una biblioteca externa nueva solo para aplicar un porcentaje de impuesto?
- Si decides conservar esa biblioteca externa, ¿qué información debes verificar en su documentación oficial vigente antes de aceptarla?
Criterio de comprensión: debes distinguir que superar el build solo prueba coherencia sintáctica y de tipos estáticos, pero no verifica la exactitud de la regla matemática de impuestos, ni las transacciones de cobro en tiempo de ejecución, ni el comportamiento ante fallos; además, debes cuestionar la necesidad de la dependencia externa y exigir verificar su vigencia y versión.
Profundiza con IA
Aquí tienes mi respuesta al informe del agente sobre compilación, tiempo de ejecución y dependencias: [tu respuesta]. Evalúa mi criterio. Luego ponme un ejemplo concreto de un cambio en el código que pasaría sin ningún problema el compilador y el verificador de tipos, pero que causaría un desastre en tiempo de ejecución cuando dos clientes intenten pagar a la vez.
Siguiente lectura
Sabemos cómo un programa se construye y se convierte en un proceso en ejecución. Pero en una aplicación moderna no hay un único proceso corriendo en un solo lugar: una parte se ejecuta en el navegador o teléfono del usuario y otra parte en tus servidores. Cerramos el curso con Entornos de ejecución: cliente, servidor y aislamiento.