Teoría — De autocompletar a agentes

En el capítulo has visto a Nadia explicarle a Tomás, con un folio y un boli, cómo funciona la máquina que escribió el commit del riego fantasma — y descubrir, por el camino, que había huecos en su propia explicación. Esta teoría es ese folio, pasado a limpio y con las fuentes en la mano. Al terminarla deberías poder hacer lo que hizo Tomás: reconstruir la explicación con tus palabras, detectar dónde se rompe, y usarla para predecir qué se le dará bien y qué se le dará mal a un modelo. Esa capacidad de predicción — no la jerga — es lo que distingue a quien entiende la herramienta de quien la usa de oído.

Qué hay dentro de la caja: el modelo

Un modelo de lenguaje grande (LLM, Large Language Model) es, despojado de marketing, una función matemática gigantesca que hace una sola cosa: dada una secuencia de texto, calcula una distribución de probabilidad sobre cuál puede ser el siguiente fragmento. Todo lo demás — el chat, el código, los agentes — se construye encima de esa única operación, repetida.

Vamos por piezas, definiendo cada término la primera vez:

Tokens. El modelo no trabaja con letras ni con palabras, sino con tokens: fragmentos de texto de un vocabulario fijo (decenas de miles de piezas: palabras frecuentes enteras, trozos de palabras raras, símbolos). «Válvula» pueden ser dos o tres tokens; def suele ser uno. Todo lo que entra y sale del modelo es una secuencia de tokens. Este detalle aparentemente menor explica comportamientos reales: los modelos son torpes contando letras o haciendo aritmética dígito a dígito porque no ven letras ni dígitos: ven tokens.

Pesos. El modelo es una red neuronal — en concreto, desde 2017, una arquitectura llamada transformer — con miles de millones de pesos: números ajustados durante el entrenamiento. Entrenar consiste en mostrarle billones de tokens de texto (libros, webs, y muchísimo código público) y ajustar los pesos para que prediga cada vez mejor el token siguiente en esos textos. El resultado es una compresión estadística monumental de lo que la humanidad ha escrito. Cuando Tomás dijo «ha leído millones de textos y ha aprendido qué palabras suelen seguir a qué palabras», estaba siendo exacto — con la precisión añadida de que ese «suelen seguir» captura regularidades tan profundas (sintaxis, semántica, patrones de razonamiento, idioms de programación) que el resultado se parece muchísimo a comprender.

Ventana de contexto. El modelo no tiene memoria entre llamadas. Cada vez que le pides algo, recibe todo lo que debe saber en una única entrada: la ventana de contexto, con un tamaño máximo (hoy, del orden de cientos de miles de tokens). Tu pregunta, las instrucciones, el código adjunto, la conversación previa — todo va dentro, cada vez. Es una idea que reaparecerá constantemente en este curso: el modelo solo sabe lo que está en sus pesos (el pasado general del mundo) o en su contexto (tu presente particular). La regla que de verdad gobernaba las tandas de Los Alcores — la que el equipo está a punto de descubrir — no estaba en ninguno de los dos sitios. Ese fue, matemáticamente, el accidente del 14 de marzo.

Muestreo y no determinismo. El modelo produce, para cada posición, probabilidades — no una respuesta. «Después de fix: normalize schedule viene timezones con probabilidad 0,41, to con 0,18…». Convertir esas probabilidades en texto exige elegir, y esa elección se llama muestreo: se sortea el siguiente token según sus probabilidades, con un parámetro — la temperatura — que gradúa cuánto azar se admite (a temperatura 0 se elige casi siempre el más probable; a temperatura alta, la lotería se abre). Consecuencia capital: el mismo prompt puede producir respuestas distintas. No es un defecto de implementación: es la naturaleza de la pieza. Cuando en el capítulo 4 veas al agente de Nadia resolver el mismo problema dos veces por dos caminos distintos, estarás viendo esto. Y cuando en la sección 6 el equipo descubra que «probarlo una vez» no prueba nada, también.

Dos aclaraciones de rigor que un ingeniero debe tener afiladas. Primera: incluso a temperatura 0 los sistemas reales no son perfectamente reproducibles (por detalles de cálculo en paralelo y por las actualizaciones del propio servicio), así que la regla práctica es tratar toda salida de un LLM como no determinista. Segunda: de «predice el token siguiente» no se deduce «no razona» — se deduce «no te fíes de la palabra razonar sin medirla». La frontera entre continuar bien un texto y razonar es genuinamente incómoda, y la posición del ingeniero no es zanjarla en un bar, sino conocer el mecanismo y medir el comportamiento en su caso concreto.

De predictor a asistente. Entre el predictor crudo y el asistente que conoces media un segundo entrenamiento (ajuste con ejemplos de instrucciones bien seguidas y con preferencias humanas) que convierte «continúa este texto» en «responde a esto con ayuda». No cambia la naturaleza de la pieza; cambia sus modales.

La ola: fechas que conviene tener ordenadas

La historia reciente cabe en una línea de tiempo corta, y tenerla ordenada te protege del vértigo de «todo pasa a la vez»:

• 2017. Investigadores de Google publican Attention Is All You Need (arXiv:1706.03762), el artículo que introduce el transformer. Todo lo que sigue es esta arquitectura, escalada.
• 2021. GitHub lanza la vista previa de Copilot: autocompletado de código con un LLM, dentro del editor. La primera experiencia masiva de «la máquina escribe y yo acepto».
• Noviembre de 2022. ChatGPT. La interfaz de chat convierte el predictor en fenómeno de masas y, para los programadores, en un compañero al que pegarle trozos de código y errores.
• 2023–2024. Los modelos aprenden a usar herramientas (llamar a funciones, ejecutar comandos) de forma fiable. Es el paso técnico que faltaba para el siguiente escalón.
• 2024–2026. Los agentes: sistemas donde el modelo, en bucle, decide qué herramientas usar para completar una tarea — leer ficheros, editar, ejecutar tests, abrir un pull request. Claude Code, Codex, y la categoría entera a la que pertenecía el Autopilot de Corvus. La anatomía exacta de ese bucle la abriremos en la sección 4; quédate ahora con la definición: autocompletar sugiere texto; un agente persigue un objetivo usando herramientas, y por eso puede tocar el mundo.

De autocompletar a agentes hay un salto cualitativo que el capítulo dramatiza: Copilot podía sugerirte una línea equivocada que tú tecleabas o no; un agente con permisos puede investigar un test flaky, escribir un fix, mergearlo y desplegarlo mientras duermes. La potencia y el riesgo crecen juntos porque ambos vienen de lo mismo: la máquina ya no está dentro de tu gesto de aceptar o rechazar.

Qué dicen los datos (y no el marketing)

Aquí viene la parte de esta sección donde más seniors descubren cosas, porque el ruido ambiente es ensordecedor y los estudios serios dicen cosas más interesantes — y más incómodas — que el ruido.

SWE-bench, o la curva que mide cada vez menos. El benchmark de referencia para agentes de programación es SWE-bench (presentado en ICLR 2024): se le da al sistema una issue real de un repositorio open source de Python y se comprueba si su parche pasa los tests reales del proyecto. La curva de resultados es la imagen más citada del sector: en 2023, los mejores modelos resolvían en torno al 2%; Devin anunció ~14% en 2024; a final de 2024 se rozaba el 50%; durante 2025, el 75–80%; y en agosto de 2026 los mejores sistemas publican cifras cercanas al 97% en la variante Verified. Impresionante — y aquí el ingeniero saca la lupa. La variante Verified son 500 tareas seleccionadas, públicas desde 2024: han tenido años para filtrarse a los datos de entrenamiento (contaminación) y para que los sistemas se optimicen contra ellas. La prueba del algodón llegó con SWE-bench Pro (arXiv:2509.16941), un conjunto nuevo, más duro y protegido contra contaminación: los mismos modelos que superaban con holgura el 70% en Verified cayeron a cifras en torno al 23% al salir. Moraleja doble, y las dos mitades importan: la mejora real en tres años es extraordinaria y el número concreto de un benchmark envejece mal — la curva es real, pero cada punto mide un poco menos que el anterior. Cuando alguien te venda un porcentaje, pregunta siempre: ¿sobre qué conjunto, de qué año, con qué riesgo de contaminación?

METR, o la brecha entre sentirse rápido y serlo. En julio de 2025, la organización de evaluación METR publicó el resultado del primer ensayo controlado aleatorizado serio sobre desarrolladores expertos: 16 programadores veteranos de proyectos open source grandes, 246 tareas reales de sus propios repositorios, asignadas al azar con o sin asistencia de IA (arXiv:2507.09089). Resultado: con IA tardaron de media un 19% más. Lo demoledor no es el número, sino el contraste con la percepción: antes del estudio esperaban ir un 24% más rápido; después de terminarlo, creían haber ido un 20% más rápido — mientras el cronómetro decía lo contrario. Ojo al alcance, que el propio METR subraya: desarrolladores expertos en código que conocían íntimamente, con las herramientas de principios de 2025; no dice que la IA ralentice a todo el mundo en todo. Lo que sí establece, y es oro, es que la sensación subjetiva de productividad con estas herramientas no es un instrumento de medida fiable. Recuerda el panel de Corvus: «312 horas de ingeniería ahorradas». ¿Medidas cómo?

DORA, o el amplificador. DORA, el programa de investigación sobre rendimiento en entrega de software, aporta la vista de conjunto: su informe de 2024 encontró que un aumento del 25% en adopción de IA se asociaba con una caída del throughput (−1,5%) y de la estabilidad de entrega (−7,2%); el de 2025 (~5.000 encuestados) matiza el cuadro — adopción del 90%, más del 80% percibe más productividad, el throughput pasa a positivo, pero la inestabilidad persiste y en torno al 30% declara confiar poco o nada en el código generado. Su síntesis es la más útil del sector: la IA es un amplificador — las organizaciones con buen flujo (tests, CI, revisión, despliegue frecuente) amplifican sus virtudes; las caóticas amplifican su caos. Producir código más deprisa, si tu cuello de botella es la revisión o la fiabilidad, solo agranda la cola delante del cuello de botella. Vega con Corvus era exactamente eso: velocidad amplificada sobre un sistema cuya teoría nadie poseía.

Stack Overflow 2025, o el termómetro del oficio. La encuesta anual (decenas de miles de desarrolladores) pinta la relación madura, no la luna de miel: el 84% usa o planea usar IA, pero la favorabilidad cae al 60% (doce puntos menos que en 2024), la desconfianza en la exactitud (46%) supera ya a la confianza (33%), un 66% se declara frustrado con soluciones «casi correctas, pero no del todo», y un 45% afirma que depurar código generado lleva más tiempo. Ese «casi correcto» es la firma característica del riesgo de esta herramienta, y la razón profunda — la veremos en la sección 3 — por la que el criterio humano no baja de precio.

«Vibe coding»: el origen exacto de un término maltratado

Pocas expresiones se han deformado tan deprisa, así que fijemos el original. El 2 de febrero de 2025, Andrej Karpathy (cofundador de OpenAI, ex-director de IA de Tesla) tuiteó:

«There's a new kind of coding I call 'vibe coding'… I 'Accept All' always, I don't read the diffs anymore… It's not too bad for throwaway weekend projects.» («Hay un nuevo tipo de programación que llamo "vibe coding"… Le doy a "Aceptar todo" siempre, ya no leo los diffs… No está mal para proyectos desechables de fin de semana.» — traducción propia; tuit citado íntegro por Simon Willison, 19-3-2025.)

Fíjate en las dos mitades: no leer el código, y el ámbito — proyectos desechables. Willison propuso la definición de trabajo que usaremos: vibe coding es construir software con un LLM sin revisar el código que escribe. De donde se sigue su corolario, que desarma la mitad de las discusiones de barra: usar IA intensivamente no es vibe coding si lees, entiendes y respondes del resultado — y el vibe coding no es pecado si el proyecto es genuinamente desechable. El pecado es de categoría: tratar como desechable lo que no lo es. El Autopilot mergeando de madrugada en el sistema que gobierna las válvulas de Paca era vibe coding institucionalizado sobre infraestructura crítica — con la agravante de que ni siquiera había un humano al que preguntarle si había leído el diff.

Para llevar

• Un LLM es un predictor de tokens: solo sabe lo que hay en sus pesos (el pasado general) o en su ventana de contexto (tu presente). Lo que no esté en ninguno de los dos sitios — como la hora de acequia — no existe para él.
• La salida es muestreo sobre una distribución: no determinista por naturaleza. Trata así toda salida de LLM, y desconfía de cualquier «lo probé y funciona» en singular.
• Es máximamente fiable en lo que más se parece a su entrenamiento (el fix canónico de zonas horarias) y máximamente peligroso donde tu caso contradice el patrón general — que es exactamente donde vive el valor de tu negocio.
• La evidencia seria (METR, DORA, Stack Overflow) converge: la sensación de velocidad no es medida; la IA amplifica el flujo que ya tienes, bueno o malo; y el modo de fallo típico es lo «casi correcto».
• Los benchmarks envejecen: cifra sin conjunto, año y control de contaminación no es un dato, es publicidad.
• Vibe coding (Karpathy, 2025) es no leer el código, y nació acotado a proyectos desechables. La decisión de ingeniería no es «IA sí o no»: es qué merece revisión — y en este curso, todo lo que toca agua la merece.

Para profundizar

• A. Karpathy, Software 2.0 (Medium, 2017) — el ensayo que anticipó el cambio de paradigma antes de que fuera evidente.
• S. Willison, Not all AI-assisted programming is vibe coding (simonwillison.net, marzo 2025) — la aclaración terminológica que deberías poder recitar.
• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (metr.org, julio 2025; arXiv:2507.09089) — léelo entero, incluida la sección de límites: es una clase magistral de honestidad metodológica.
• DORA, State of AI-assisted Software Development 2025 (dora.dev) — libre; la vista organizacional que complementa a METR.
• Stack Overflow Developer Survey 2025 (survey.stackoverflow.co) — datos abiertos para tus propias gráficas.
• Jimenez et al., SWE-bench (ICLR 2024) y el contraste con SWE-bench Pro (arXiv:2509.16941) — el par perfecto para aprender a leer benchmarks con lupa.