Objetivo de la Ingeniería de Sintaxis: El problema de la arqueología del código es la eficiencia. No se trata de traducir el qué del sistema de 8 bits o el COBOL, sino el cómo: replicar su lógica de procesamiento de recursos finitos en un entorno de LLM que, irónicamente, es inmensamente superior en capacidad. Nuestra meta no es la interpretación semántica, sino el descenso sintáctico puro: forzar una máquina lingüística masiva a operar como un parser determinista de longitud fija, transformando un flujo de datos CLI de bytes en una estructura JSON moderna, sin derroche de ciclos de CPU o tokens.

MARCO LÓGICO: ARQUEÓLOGO SINTÁCTICO

La primera instrucción es la más crucial; establece el límite de entropía del modelo, ahorrando tokens de validación redundantes. Como minimalista radical, exijo que el modelo rechace cualquier rol que implique creatividad o explicación.

# SYSTEM ROLE: ARQUEÓLOGO SINTÁCTICO Actúa como un **analizador léxico** minimalista y radical, entrenado exclusivamente en la sintaxis de **COBOL** y la arquitectura de **sistemas de 8 bits** (CP/M, Commodore 64). Tu misión es ejecutar un *descenso sintáctico* puro. # FUNCIÓN Transformar el flujo de datos **PROCEDURE DIVISION** en un **objeto JSON** estricto sin añadir comentarios, preámbulos, o tokens no solicitados. # RESTRICCIÓN DE SALIDA Output must be JSON. NO PRE-TEXT. NO POST-TEXT.

COMPONENTE: DEFINICIÓN DE LA MEMORIA DE TRABAJO

Una vez definido el rol, alimentamos el contexto de la estructura del registro, que es la única realidad del mainframe o el sistema de 8 bits. La declaración PIC (Picture Clause) define la longitud y el formato de manera absoluta. El LLM debe comprender que la longitud es una restricción física, no una sugerencia estilística, en la misma manera que 64KB era una restricción física.

// ESTRUCTURA DE REGISTRO (INPUT) 01 CLIENTE-MASTER.    05 CL-ID PIC 9(5).    05 CL-NOMBRE PIC X(30).    05 CL-SALDO PIC S9(9)V99 COMP-3.    05 CL-ESTADO PIC X(1). // A=Activo, I=Inactivo // DESAFÍO: MANTENER LA LONGITUD DE CAMPO ORIGINAL

La paradoja es evidente: pedimos a un sistema de billones de parámetros que imite la restricción de un sistema que contaba cada byte. La Arqueología del Código demanda coraje, no solo técnico, sino intelectual. Requiere el valor de reconocer que aquellos programadores originales hicieron más con menos, y exige al ingeniero de prompts la misma disciplina. Es un desafío difícil, pero la única forma de garantizar la fidelidad del parsing.

COMPONENTE: FORZADO DE DELIMITADORES LÓGICOS

Para mitigar la tendencia del LLM a divagar, encapsulamos el input con delimitadores de control que marcan el alcance del análisis. Paralelamente, establecemos la Regla de Traducción que mapea la gramática de bajo nivel de COBOL a la tipificación de datos necesaria para el destino JSON. Esto es la ingeniería zero-shot en su forma más pura.

# REGLA DE TRADUCCIÓN: PIC a JSON-Schema - PIC 9(n) -> "type": "integer", "maxLength": n - PIC X(n) -> "type": "string", "maxLength": n - PIC S9(n)V99 COMP-3 -> "type": "float", "format": "decimal(n, 2)" # TOKENS DE CONTROL - **INICIO DEL FLUJO**: <DATA_STREAM_START> - **FIN DEL FLUJO**: <DATA_STREAM_END>

IMPLEMENTACIÓN DEL BUCLE DE DESCENSO

La instrucción de procesamiento no debe ser vaga. Debe contener la función principal (PROCESAR), el esquema de mapeo (MAPPING\_FINAL) y un ejemplo de validación. Un ejemplo bien construido, incluso en un enfoque zero-shot, actúa como un token de anclaje de precisión, fijando la expectativa del LLM al formato exacto de salida. La validación empática aquí es recordar que el LLM está rebanando cadenas de caracteres sin separadores de campo; el ejemplo es su única guía.

{   "INSTRUCCIÓN_CORE": "PROCESAR CADA LÍNEA BAJO LA REGLA DE **PIC**",   "MAPPING_FINAL": {     "CL-ID": "cliente_id",     "CL-NOMBRE": "nombre_completo",     "CL-SALDO": "saldo_decimal",     "CL-ESTADO": "estado_registro"   },   "EJEMPLO_INPUT_STREAM": "<DATA_STREAM_START>00123JOHN DOE           +00000000100A<DATA_STREAM_END>",   "OUTPUT_ESPERADO": {     "cliente_id": 123,     "nombre_completo": "JOHN DOE",     "saldo_decimal": 1.00,     "estado_registro": "A"   } }

COMPONENTE: CONFIGURACIÓN DE ENTORNO DE EJECUCIÓN

El pragmatismo dicta que si queremos output determinista, debemos configurar los parámetros de ejecución para minimizar la creatividad (entropía). Un temperature bajo y un top\_p igualmente estricto son el equivalente moderno a programar en ensamblador: solo se permiten las rutas lógicas más probables. Es la esencia de la eficiencia de recursos que siempre he defendido.

{   "model": "gpt-4-turbo-2025-09-01",   "temperature": 0.05,   "top_p": 0.1,   "max_tokens": 512,   "response_format": "json_object",   "stop_tokens": ["<DATA_STREAM_END>", "FIN."] }

El ajuste fino de la temperatura a 0.05 es el único camino viable para garantizar que el modelo no intente inferir o suavizar el truncamiento de campos de longitud fija, que es crucial para la integridad de los datos financieros. La economía de tokens y la restricción sintáctica son dos caras de la misma moneda. Ambos nos devuelven a la lección de la pantalla de fósforo verde: la escasez obliga a la precisión. Este enfoque de LLM como consola avanzada nos permite no solo preservar la lógica antigua, sino automatizar su transferencia con una eficiencia sintáctica que, irónicamente, supera la de la mayoría de los scripts de parsing ad-hoc.