178 — IA para programación y modernización

← Clase anterior · Índice de la parte · Clase siguiente →

Parte: 14 — Frontera, investigación y proyectos integradores
Nivel: frontera · Horas estimadas: 6
Laboratorio: agent · Estado: EXECUTABLE_CORE

🎯 Propósito

Comprender ia para programación y modernización dentro de la evolución de la inteligencia artificial, implementar un experimento mínimo verificable y distinguir qué parte constituye evidencia frente a una afirmación todavía no comprobada.

📚 Resultados de aprendizaje

Al finalizar podrás:

  1. Explicar ia para programación y modernización usando los conceptos coding agents, tests, migration, legacy.
  2. Ejecutar el laboratorio con una semilla explícita y revisar su contrato JSON.
  3. Identificar al menos un supuesto, una limitación y un riesgo de aplicación.
  4. Comparar el enfoque con la etapa anterior de la ruta de aprendizaje.
  5. Producir una evidencia reproducible y una conclusión que no exceda los datos.

🧩 Conceptos centrales

coding agents, tests, migration, legacy

🗺️ Ubicación en el mapa de la IA

La programación es el dominio donde los LLM encontraron antes su encaje económico: el código tiene un verificador natural (compilar, ejecutar tests) que convierte la generación probabilística en un bucle con señal de corrección. Hereda de los LLM y el fine-tuning (partes 6-7) y de la agentica con herramientas (parte 9), y es el banco de pruebas de la computación en tiempo de inferencia (clase 175): muestrear muchas soluciones y filtrar por tests es test-time compute aplicado. La modernización de sistemas legados es su frontera económicamente más pesada.

📖 Fundamentos

🤖 De autocompletar a agente

Tres generaciones con contratos distintos:

  1. Autocompletado (Codex, 2021, arXiv:2107.03374): dado un prefijo (docstring, firma), el modelo genera la continuación. Evaluación: funciones aisladas (HumanEval: 164 problemas con tests unitarios ocultos).
  2. Chat/instrucción: el modelo dialoga sobre código, explica y refactoriza; el humano integra. La evaluación se vuelve difusa (no hay harness automático).
  3. Agente de código (SWE-bench, 2023, arXiv:2310.06770): dado un issue real de GitHub y el repositorio completo, el agente debe localizar los archivos, editar, ejecutar tests y producir un parche. Se acepta si pasan los tests de la corrección real (FAIL_TO_PASS) sin romper los existentes (PASS_TO_PASS).

El salto de 1→3 cambia la dificultad: HumanEval mide síntesis local de ~10 líneas; SWE-bench exige navegación de repos de cientos de miles de líneas, comprensión de convenciones y edición multiarchivo. Los primeros sistemas puntuaban <2 % en SWE-bench cuando ya superaban 90 % en HumanEval.

📐 La métrica pass@k

Con generación estocástica, "¿funciona?" es una probabilidad. pass@k = P(al menos 1 de k muestras pasa todos los tests). El estimador insesgado (Chen et al., 2021): se generan n ≥ k muestras, c de ellas correctas, y

pass@k = 1 − C(n−c, k) / C(n, k)

(elegir k muestras y que ninguna sea correcta, complementado). Calcular ingenuamente 1 − (1 − c/n)^k sesga el resultado; la fórmula combinatoria es exacta.

🔁 El bucle del agente de código

repetir hasta presupuesto:
  1. LOCALIZAR   buscar archivos/símbolos relevantes al issue (grep, mapa del repo)
  2. PROPONER    editar código (parche mínimo, no reescritura)
  3. VERIFICAR   compilar + ejecutar tests (los previos y los del issue)
  4. LEER SEÑAL  traceback/diff → siguiente iteración
aceptar solo si: tests nuevos pasan Y tests previos siguen pasando

La calidad del sistema depende menos del modelo que del harness: qué contexto se recupera, qué tests existen, cómo se limita el radio de la edición. Sin tests, el bucle degenera en "parece correcto", que es precisamente lo que no se puede auditar. La industria llamó a esta capa harness engineering (OpenAI, 2026); la ecuación Agente = Modelo + Harness que introduce la clase 113 tiene aquí su caso de uso más maduro.

📋 Spec-driven development: la especificación como contrato

Cuando el agente de código es capaz de ejecutar el bucle completo, el cuello de botella se desplaza a la entrada: ¿qué le pedimos exactamente? Spec-driven development (SDD) responde convirtiendo la especificación en el artefacto principal del trabajo:

1. SPEC      qué debe hacer el cambio, con criterios de aceptación VERIFICABLES
             (idealmente: tests que hoy fallan y deberán pasar)
2. PLAN      el agente propone descomposición y archivos afectados; el humano revisa
             ANTES de que exista código
3. IMPLEMENT el agente ejecuta el plan unidad por unidad, verificando cada una
4. VERIFY    la spec se re-evalúa completa: criterios de aceptación + regresiones

Tres observaciones para no comprar el término sin crítica. Primera: SDD es un subconjunto de context engineering — la spec es el contexto de más alta señal que existe, porque define éxito de forma verificable (compárese con FAIL_TO_PASS de SWE-bench: un benchmark de agentes es una spec ejecutable). Segunda: la objeción "¿no es waterfall con IA?" es parcialmente justa; SDD funciona cuando la spec puede escribirse antes (correcciones, migraciones, features acotadas) y estorba en exploración genuina, donde el bucle iterativo de la sección anterior es el flujo correcto. Tercera: la spec desactualizada es deuda nueva — si el código diverge de la spec y nadie la corrige, el próximo agente implementará contra un contrato falso. La modernización de legado (siguiente sección) es SDD en su forma extrema: los tests de caracterización son la spec, extraída del comportamiento real.

🏚️ Modernización de legado

El caso económico dominante: migrar COBOL/Java 6/Python 2 a plataformas mantenibles. El principio (Feathers): legacy code = código sin tests. El flujo asistido por IA:

  1. Tests de caracterización: generar tests que fijan el comportamiento ACTUAL (incluidos bugs), no el deseado — son la red antes de tocar nada.
  2. Traducción por unidades pequeñas con equivalencia verificada contra esos tests.
  3. Revisión humana de todo lo que toque I/O, dinero, fechas o concurrencia, donde la equivalencia semántica entre lenguajes es más traicionera.

La IA acelera los pasos 1-2; el riesgo es traducir "lo que parece que hace" en lugar de "lo que hace": una migración sin tests de caracterización no es modernización, es reescritura con esperanza.

🧮 Ejemplo trabajado

Un modelo genera n = 5 soluciones para un problema; c = 2 pasan los tests.

pass@1 = 1 − C(3,1)/C(5,1) = 1 − 3/5 = 0.40
pass@3 = 1 − C(3,3)/C(5,3) = 1 − 1/10 = 0.90

comprobación ingenua para k=3: 1 − (1 − 0.4)³ = 1 − 0.216 = 0.784  ≠ 0.90

La fórmula ingenua subestima porque muestrea "con reemplazo" soluciones que en realidad son un conjunto fijo. Lectura práctica: con 40 % de aciertos por muestra, basta muestrear 3 veces y filtrar por tests para llegar al 90 % — si y solo si existen tests que hagan de filtro. Ese "si" es todo el asunto.

📊 Propiedades y comparación

Nivel Benchmark típico Unidad de trabajo Verificación Falla característica
Autocompletado HumanEval (pass@k) Función aislada Tests unitarios ocultos Memorizar el benchmark
Chat de código Evaluación humana Fragmento/explicación Juicio del programador Plausible pero incorrecto
Agente de repo SWE-bench (% resuelto) Issue real + repo FAIL_TO_PASS + PASS_TO_PASS Parche que sobreajusta al test
Migración legado Suites de caracterización Módulo/sistema Equivalencia conductual Traducir la intención, no el comportamiento 
flowchart LR
    I[Issue + repo] --> L[Localizar<br/>archivos y símbolos]
    L --> P[Proponer parche]
    P --> V{Compila y<br/>pasan tests?}
    V -->|traceback| L
    V -->|Sí| G{Tests previos<br/>intactos?}
    G -->|No: regresión| P
    G -->|Sí| A[Parche candidato]
    A --> H[Revisión humana]

⚠️ Errores conceptuales frecuentes

  1. "90 % en HumanEval ≈ 90 % de un programador." HumanEval mide funciones aisladas de decenas de líneas; los mismos modelos puntuaban <2 % en SWE-bench. El benchmark define qué se midió; extrapolar entre niveles no es válido.
  2. "pass@k se calcula como 1−(1−c/n)^k." El estimador correcto es el combinatorio 1 − C(n−c,k)/C(n,k); el ingenuo está sesgado (ver ejemplo).
  3. "Si los tests pasan, el parche es correcto." Los tests son una muestra del contrato: un agente puede sobreajustar al test (hardcodear el caso) o romper comportamiento no cubierto. De ahí PASS_TO_PASS y la revisión humana.
  4. "La IA puede migrar el sistema legado leyendo el código." Sin tests de caracterización no hay definición ejecutable de 'equivalente'; la traducción plausible es el modo de fallo más caro de la modernización.
  5. "La contaminación no importa si el benchmark es público." Al contrario: repos y soluciones públicos entran al pretraining; por eso existen variantes verificadas y con corte temporal (p. ej. SWE-bench Verified) y hay que mirar la fecha de los issues frente al corte del modelo.

🚀 Del aprendizaje a la operación

Para operar un asistente/agente de código real faltan: sandbox de ejecución aislado (el agente ejecuta código arbitrario), política de secretos (el repo contiene credenciales que no deben llegar al contexto), telemetría de tasa de aceptación y de regresiones post-merge (la métrica que importa no es pass@k sino "parches revertidos por 100 fusionados"), y límites de radio: un agente que puede editar CI/CD o dependencias necesita revisión obligatoria — el bucle editar-testear no cubre ataques de cadena de suministro.

🧪 Laboratorio

python lab.py

El laboratorio llama a ai_evolution.labs.run_lab("agent"). Esta decisión evita 183 implementaciones divergentes: cada clase tiene un entrypoint propio, pero los motores didácticos se prueban como una biblioteca común.

🔍 Evidencia esperada

📓 Notebooks

📝 Evaluación

Criterio Peso
Comprensión conceptual 25 %
Ejecución reproducible 25 %
Interpretación basada en evidencia 25 %
Riesgos, límites y mejora propuesta 25 %

Consulta assessment.md para preguntas y criterio de aceptación.

⚠️ Errores comunes

Síntoma Causa probable Corrección
El código corre, pero no hay conclusión Se confundió ejecución con aprendizaje Explica qué demuestra y qué no demuestra
El resultado cambia sin explicación No se registró semilla o configuración Conserva semilla, versión y parámetros
Se promete uso real Se extrapoló desde una demo educativa Declara entorno, datos, límites y revisión humana
Se copia una métrica aislada No existe baseline ni costo de error Añade comparación y criterio de decisión

❓ Preguntas frecuentes

¿Debo usar una API comercial?
No. El núcleo funciona localmente. Las extensiones LIVE se documentan por separado.

¿El laboratorio representa una implementación industrial?
No por sí solo. Enseña el contrato y el patrón; producción exige integración, seguridad, observabilidad, pruebas y operación.

¿Dónde profundizo?
Revisa las especializaciones enlazadas en el README raíz y la ruta siguiente.

🔗 Referencias

📜 Papers que fundamentan esta clase

Bloque generado por python scripts/link_papers_to_classes.py. La fuente es papers/catalog/papers.json.

Paper Año Qué desbloqueó Miniatura
P51 · SWE-bench: ¿pueden los modelos resolver incidencias reales de GitHub? 2023 Cambia el criterio de evaluación: no si el código parece bien, sino si los tests del repositorio real pasan. notebook

Cada ficha explica el problema anterior, la matemática mínima, los límites y los errores de atribución más frecuentes. Para leerlas con método: cómo leer un paper de IA · anexos matemáticos.

📚 Bibliografía de apoyo

Bloque generado por python scripts/link_sources_to_classes.py. Cada obra lleva su localizador verificado en sources/bibliography.json.

Los papers dicen de dónde salió el mecanismo. Estas obras lo desarrollan con el espacio que una clase no tiene: teoría completa, demostraciones y ejercicios.

Obra Edición Localizador Papel en esta clase
Russell, Stuart J. y Norvig, Peter — Artificial Intelligence: A Modern Approach 4.ª · 2020 ISBN 9780134610993 · web de la obra obra de referencia de la parte 14 · capítulo sobre el futuro de la IA
Goodfellow, Ian, Bengio, Yoshua y Courville, Aaron — Deep Learning 2016 ISBN 9780262035613 · web de la obra obra de referencia de la parte 14 · límites de los métodos actuales

⬅️ Clase anterior

177 — Privacidad diferencial y aprendizaje federado

➡️ Siguiente clase

179 — IA para ciberseguridad y defensa

📝 Evaluación completa

❓ Preguntas

  1. Define ia para programación y modernización sin usar una marca o framework como definición.
  2. Explica la relación entre coding agents, tests, migration, legacy.
  3. Ejecuta lab.py dos veces con la misma semilla. ¿Qué debe conservarse?
  4. Identifica una afirmación permitida y una afirmación exagerada sobre el resultado.
  5. Propón una prueba negativa o un caso límite.

🏆 Reto verificable

Amplía el resultado del laboratorio con una clave student_extension que incluya:

✅ Criterio de aceptación