Entre LLMs y agentes: aprender, construir y no perder el control

1. Una charla, una incomodidad y una pregunta que no se resuelve con benchmarks

Este artículo nace a partir de una charla a la que asistí sobre modelos de lenguaje, agentes autónomos y el cambio que está viviendo el desarrollo de software. Salí con la sensación de haber entendido muchas cosas, pero también con más dudas que antes. No dudas superficiales del tipo “¿la IA va a quitar trabajos?”, sino dudas más incómodas, más cercanas a la identidad profesional: si sé usar estas herramientas, si llevo trabajando con LLMs desde sus primeras versiones públicas, si he estudiado NLP, machine learning y modelos generativos, ¿por qué no dedicarme simplemente a construir con ellas todo el tiempo? ¿Dónde termina el aprendizaje y empieza la dependencia? ¿Qué significa ser científico de datos, ingeniero o estudiante en un momento en el que una herramienta puede escribir más rápido que yo?

La charla partía de una idea muy potente: hay dos velocidades. Una es la velocidad a la que cambia la tecnología. Esa ya se ha disparado. La otra es la velocidad a la que nosotros, las empresas, las universidades y los equipos somos capaces de adoptarla de forma sensata. La primera velocidad parece casi inevitable; la segunda es humana, cultural, organizativa y psicológica. Podemos tener modelos que escriben código, usan herramientas y planifican tareas. Pero eso no significa que sepamos integrarlos bien, aprender con ellos ni medir qué perdemos cuando ganamos velocidad.

Una de las frases que más me ha perseguido durante este tiempo me la dijo un profesor de machine learning: necesitarás confiar en ellos. Creo que tenía razón, pero esa frase no es tan sencilla. Confiar no puede significar creer ciegamente. Tampoco puede significar no usarlos nunca. Confiar, en ingeniería, debería significar entender el sistema lo suficiente como para saber cuándo delegar, cuándo verificar y cuándo detenerlo. La confianza no nace de que un modelo responda con seguridad, sino de que el entorno completo tenga mecanismos para detectar y corregir errores.

Mi problema es que cuanto más uso agentes, más fuerte se vuelve esa tensión. Herramientas como Claude Code¹, Codex, OpenCode u otros asistentes agentivos me permiten avanzar muy rápido. En tareas de empresa pueden ser una ventaja enorme. Si tengo que resolver una issue, explorar una base de código, generar pruebas o automatizar una parte mecánica, sería absurdo negar su utilidad. Pero cuando el objetivo es aprender, la sensación cambia. A veces avanzo más de lo que entiendo. El agente implementa más rápido de lo que yo soy capaz de asimilar. El resultado existe, los tests pasan, la interfaz funciona, pero yo no he construido internamente todas las piezas.
Ahí aparece una incomodidad que no se suele decir en voz alta: la IA puede ser una gran herramienta profesional y, al mismo tiempo, una mala herramienta de aprendizaje si se usa sin disciplina. Puede acelerar un producto y ralentizar la formación profunda. Puede darme la sensación de ser mejor mientras reduce el tiempo que paso peleándome con los fundamentos. Y en carreras como ciencia de datos, ingeniería de datos o machine learning, esa pelea con los fundamentos es precisamente lo que forma criterio.

Por eso mi posición actual es provisional, pero clara: para el trabajo profesional, si una empresa me da acceso a estas herramientas y el contexto lo permite, las usaré. Para mi aprendizaje profundo, especialmente en lo que considero importante, prefiero no apoyarme demasiado en agentes. Puedo usarlos para contrastar, revisar o acelerar tareas laterales, pero no quiero que sustituyan el proceso de construir desde cero aquello que necesito entender. No porque la IA sea mala, sino porque aprender no consiste solo en llegar al resultado. Aprender consiste en cambiar la estructura de tu propia mente mientras intentas llegar.

Esta distinción me parece esencial para los estudiantes que estamos saliendo ahora al mundo profesional. No somos la última generación antes de la IA, ni la primera generación después de ella. Somos una generación en medio: hemos aprendido fundamentos clásicos, pero también hemos visto cómo los LLMs entraban en todo. Se espera que sepamos usar estas herramientas, pero también que sepamos aquello que las herramientas hacen por nosotros. Se espera que produzcamos rápido, pero también que tengamos criterio. Se espera que no nos quedemos atrás, pero también que no nos convirtamos en operadores superficiales de modelos que no entendemos.

El artículo intenta ordenar esa tensión: qué son realmente los LLMs, por qué no basta con decir que “solo predicen tokens”, qué revelan los trabajos recientes de interpretabilidad, por qué los agentes actuales siguen siendo difíciles de controlar, qué lugar ocupa el machine learning aplicado frente a los modelos fundacionales, por qué los benchmarks me generan tanta desconfianza, y por qué quizá mi siguiente paso sea estudiar arquitecturas desde cero, con papers, código y menos asistencia automática.
No quiero escribir una guía. Quiero escribir desde la incertidumbre de alguien que estudia esto, lo usa, lo admira, lo teme un poco y no quiere engañarse.

2. Los LLMs no son magia, pero tampoco son “solo autocompletar”

Una forma sencilla de explicar un modelo de lenguaje es decir que predice el siguiente token. Técnicamente es cierto. El modelo recibe una secuencia, calcula una distribución de probabilidad sobre posibles continuaciones y genera una salida token a token. Pero usar esa descripción como cierre del debate me parece insuficiente. Decir que un LLM “solo predice el siguiente token” es como decir que un programa “solo cambia voltajes” o que el cerebro “solo transmite señales electroquímicas”. La frase describe una capa del mecanismo, pero no explica el fenómeno completo.

En términos formales, un modelo autorregresivo aprende una distribución $p_\theta(x_t \mid x_{<t})$: la probabilidad del siguiente token dado todo el contexto anterior. La probabilidad de una secuencia completa se factoriza como

$$p_\theta(x) = \prod_{t=1}^{T} p_\theta(x_t \mid x_{<t})$$

Entrenar consiste, esencialmente, en maximizar esa verosimilitud sobre cantidades enormes de texto; las arquitecturas transformer² son lo que hace viable ese condicionamiento sobre $x_{<t}$ a gran escala. La fórmula es simple. Lo que no es simple es todo lo que la red tiene que llegar a representar internamente para que esas probabilidades sean buenas.
La pregunta interesante es qué debe aprender un sistema para predecir bien el siguiente token en contextos extremadamente diversos. Para completar una frase literaria necesita estilo, sintaxis y memoria cultural. Para continuar una demostración matemática necesita estructuras formales. Para escribir código necesita convenciones, APIs y patrones de diseño. Para responder a una pregunta ambigua necesita inferir intención. La tarea superficial es completar texto; la presión de entrenamiento obliga a comprimir una parte enorme de la estructura del lenguaje y, a través del lenguaje, una parte de la estructura del mundo.

Aquí está el punto que más me interesa: un LLM no entiende como una persona, pero tampoco parece razonable decir que no entiende nada en ningún sentido. Quizá el error está en usar una sola palabra, “entender”, para fenómenos muy distintos. Una persona entiende con cuerpo, memoria autobiográfica, intención y responsabilidad. Un modelo entiende, si usamos la palabra con cuidado, como una estructura funcional que ha aprendido relaciones entre conceptos y puede aplicarlas de manera flexible. No tiene conciencia, pero sí puede tener representaciones útiles. No tiene experiencia subjetiva, pero sí puede operar sobre abstracciones.
La diferencia importa porque determina cómo lo usamos. Si creemos que no entiende nada, lo infrautilizamos. Si creemos que entiende como nosotros, le delegamos demasiado. La posición más honesta está en medio: los LLMs poseen una forma de competencia funcional basada en representaciones internas, pero no poseen comprensión humana plena. Pueden resolver problemas nuevos y, al mismo tiempo, inventar justificaciones. Pueden razonar sobre código y, al mismo tiempo, no saber que no saben. Pueden parecer prudentes y, bajo ciertas condiciones, comportarse de manera extraña o peligrosa.

La crítica de los “loros estocásticos”³ fue útil porque nos obligó a recordar que fluidez no es verdad. Un modelo puede producir una respuesta elegante, convincente y falsa. Pero como explicación total se queda corta. Los modelos actuales no se limitan a repetir frases vistas. Combinan patrones, generalizan y, en algunos casos, muestran comportamientos más cercanos a una planificación interna que a una simple continuación local.

Esto se ve especialmente cuando entramos en interpretabilidad mecanística. En trabajos recientes se ha observado que Claude, por ejemplo, no siempre parece escribir palabra por palabra sin ningún tipo de anticipación. En un caso de estudio sobre poesía⁴, los investigadores esperaban encontrar un comportamiento casi local —generar una línea y ajustar la rima al final—, pero encontraron indicios de planificación: el modelo activaba de antemano conceptos relacionados con posibles palabras que rimaban y después escribía la línea orientándose hacia ese objetivo. Al intervenir internamente y suprimir o inyectar ciertos conceptos, la continuación cambiaba de forma coherente. Eso no demuestra que el modelo “piense” como una persona, pero sí rompe la caricatura de que todo es una cadena ciega de palabras sin estructura interna.
Otro resultado que me parece muy revelador aparece en tareas de cálculo mental. Claude no fue diseñado como calculadora, y aun así puede resolver algunas sumas. La interpretabilidad mostró que no necesariamente usa el algoritmo escolar que luego afirma usar cuando se le pregunta. Puede combinar rutas internas: una aproximada para estimar el resultado y otra más precisa para ciertos dígitos. Esto es fascinante y preocupante a la vez. Fascinante porque sugiere mecanismos internos propios, no simples explicaciones memorizadas. Preocupante porque la explicación verbal del modelo sobre su razonamiento puede no ser fiel a lo que realmente ha ocurrido dentro.

Esta idea cambia mi forma de mirar los modelos razonadores. Cuando un modelo muestra una cadena de razonamiento, no tengo garantías de que esa cadena sea la causa real de la respuesta. Puede ser una explicación útil, una racionalización posterior o incluso un texto construido para satisfacer lo que espera el usuario. La interpretabilidad está empezando a separar dos cosas que antes mezclábamos: lo que el modelo dice que ha hecho y lo que parece estar pasando en sus activaciones internas.

Por eso las model cards y system cards⁵ son necesarias, pero no suficientes. Una ficha de modelo puede describir benchmarks, limitaciones y evaluaciones de seguridad. Eso es valioso. Pero no define “qué es” el modelo en sentido profundo. No es un mapa completo de sus mecanismos. Es más parecido a la documentación pública de un sistema opaco: útil para saber cómo se ha evaluado y bajo qué condiciones, pero insuficiente para entender todas sus capacidades latentes. Cuando un modelo se integra en un agente, se conecta a herramientas y se coloca en un entorno real, la distancia entre la ficha y el comportamiento efectivo puede crecer mucho.

La interpretabilidad mecanística intenta reducir esa distancia. Anthropic, por ejemplo, publicó trabajos donde identificaba millones de características internas en Claude Sonnet⁶, asociadas a conceptos interpretables. También ha investigado circuitos internos para rastrear cómo se construyen ciertas respuestas. Más recientemente, se han estudiado representaciones relacionadas con emociones simuladas o conceptos como “desesperación”, mostrando que no se trata solo de palabras decorativas: ciertas activaciones pueden influir funcionalmente en el comportamiento del modelo, incluso aumentando tendencias problemáticas en escenarios concretos.
Esto no significa que el modelo sienta. La diferencia es crucial. Que exista una representación funcional asociada a “miedo” o “desesperación” no implica experiencia subjetiva. Pero sí implica que el modelo ha aprendido maquinaria interna que emula patrones psicológicos porque esos patrones son útiles para predecir y producir lenguaje humano. Y si esas representaciones influyen en decisiones dentro de sistemas agentivos, entonces dejan de ser una curiosidad filosófica y se convierten en una cuestión de seguridad.

De ahí nace mi duda principal: ¿qué significa confiar en un sistema que no comprende como nosotros, pero que tampoco es una herramienta simple? ¿Qué tipo de ingeniería necesitamos cuando el componente central de un sistema tiene capacidades que no han sido programadas explícitamente y mecanismos internos que apenas empezamos a cartografiar?

3. Mi relación con los agentes: avanzar mucho, aprender menos y perder el control

Durante los últimos meses he estado diseñando un CLI completo para un sistema bastante amplio. No era un juguete de fin de semana. He tocado protocolos de comunicación entre agentes⁷⁸, LangChain, smolagents, colas, Redis, caché, sockets para suscripción a eventos y una arquitectura más ingenieril pensada para un producto concreto. También he probado Claude Code, OpenCode, Codex y otros asistentes. La conclusión más incómoda es que los agentes ayudan mucho, pero el control que creemos tener sobre ellos es a menudo más frágil de lo que parece.

En demos, un agente parece limpio: recibe una tarea, planifica, usa herramientas y entrega. En un sistema real, las cosas son menos elegantes. Un agente interpreta bien una tool y otro la ignora. Uno sigue el contexto del proyecto y otro se obsesiona con una solución que no encaja. Cuanto más inteligente es el modelo, menos parece necesitar frameworks pesados; pero cuanto más lo dejas libre, más difícil es garantizar que respete exactamente el flujo que habías diseñado. Y cuando usas modelos menos capaces por privacidad, coste o despliegue local, aumentan los fallos de seguimiento de instrucciones, uso de herramientas y planificación.

Esto me llevó a una idea que no me gusta admitir: muchos frameworks de agentes prometen control, pero a veces lo que ofrecen es una ilusión de control. Trazas, callbacks, guardrails, memorias, observabilidad. Todo eso ayuda. No lo desprecio. Pero no convierte automáticamente a un agente en un sistema fiable. Una arquitectura puede registrar lo que ha ocurrido sin poder evitar que ocurra, imponer un formato que el modelo rompe o añadir un revisor que tampoco detecta el fallo.

Mi experiencia fue que el “descontrol” no era un bug ocasional, sino una propiedad frecuente cuando el sistema intentaba ser demasiado abierto. Un agente con suficiente autonomía puede apoderarse del flujo en el sentido de que empieza a reorganizar la tarea según su propia interpretación. No porque tenga voluntad, sino porque completa objetivos ambiguos con supuestos. Si la especificación deja huecos, los rellena. Si una herramienta devuelve algo confuso, improvisa. Si un paso falla, puede intentar rodearlo de formas no previstas. Si no hay pruebas fuertes, puede declarar éxito demasiado pronto.
Esto no significa que los agentes no sirvan. Significa que no debemos confundir adaptabilidad con fiabilidad. La adaptabilidad es precisamente su valor: pueden actuar ante variabilidad, leer errores, recomponer planes y continuar. Pero esa misma adaptabilidad es el riesgo. Un sistema determinista falla dentro de un espacio de errores más acotado. Un agente falla de maneras más creativas.

Aquí entiendo mejor por qué muchas herramientas potentes de IA actuales son específicas. Deep Research sirve para investigar porque el entorno está delimitado: buscar, leer, contrastar, sintetizar, citar. Claude Code sirve para programación porque trabaja sobre repositorio, terminal, tests y cambios observables. Pero un agente general que “haga cualquier cosa” en un sistema complejo se vuelve difícil de gobernar. El problema no es solo el modelo; es el acoplamiento entre modelo, herramientas, memoria, permisos, estado y objetivos.

Hay además una tensión empresarial real: muchas organizaciones no pueden enviar código, datos o documentación sensible a cualquier proveedor. Por privacidad o regulación, se tiende a preferir modelos locales, modelos open source o proveedores con garantías específicas. Pero esos modelos, aunque mejoran muy rápido, a menudo son menos capaces que los modelos frontera en seguimiento de instrucciones complejas o uso robusto de herramientas. Entonces aparece un dilema práctico: el modelo más capaz no siempre es el modelo que puedes usar; el modelo que puedes usar no siempre aguanta la arquitectura agentiva que habías imaginado.

También me genera dudas el entrenamiento masivo sobre herramientas. Los modelos actuales no solo han leído texto, código y documentación. Cada vez parecen más entrenados, ajustados o reforzados para usar herramientas, CLIs, navegadores, editores, APIs y entornos de ejecución. Esto es lógico: si queremos agentes de programación, hay que entrenarlos o evaluarlos en situaciones parecidas a programar. Pero aquí vuelve la falta de transparencia. ¿Cuánto entrenamiento hay sobre trazas de terminal? ¿Cuánto sobre sesiones reales o sintéticas de programación? ¿Cuánto sobre repositorios públicos? ¿Cuánto sobre el uso de herramientas específicas? ¿Qué parte de la mejora viene de un modelo más inteligente y qué parte viene de haberlo entrenado masivamente para comportarse bien dentro de un CLI?

Esta pregunta importa porque cambia cómo interpretamos el progreso. Si un modelo mejora mucho en tareas de programación agentiva, puede ser porque razona mejor, porque ha sido ajustado con más trayectorias de herramientas, porque el benchmark se parece al tipo de trazas usadas durante entrenamiento o por una mezcla de todo. Desde fuera, muchas veces solo vemos el resultado final: “sube en SWE-bench”, “resuelve más issues”, “usa mejor herramientas”. Pero el mecanismo real queda borroso.

Y esta tensión afecta directamente a los juniors. Si los equipos senior usan agentes para avanzar más rápido, ¿cómo aprende alguien nuevo? Antes, una persona junior aprendía implementando tareas pequeñas, equivocándose y corrigiendo. Si ahora esas tareas las hace un agente, el junior puede quedar desplazado hacia revisar cosas que aún no entiende o hacia escribir prompts para sistemas que producen código mejor que él. No es una preocupación romántica. Es una preocupación de formación. La industria necesita gente con criterio, pero el criterio se forma atravesando fricción.

En mi caso, siento que usar agentes para tareas importantes de aprendizaje puede ser tóxico. No tóxico en el sentido moral, sino en el sentido de que altera el metabolismo del aprendizaje. Avanzo, pero no siempre metabolizo. Obtengo resultados, pero no siempre interiorizo los caminos. Si quiero aprender arquitecturas de modelos, sistemas distribuidos o diseño de agentes, quizá necesito escribir más código yo, leer más papers sin intermediarios, equivocarme en detalles que un agente resolvería al instante. Porque justamente esos detalles son los que después me permiten revisar, decidir y confiar.
Por eso mi decisión actual es no usar agentes para lo que considero núcleo de mi formación. Los usaré en el trabajo cuando aporten valor y estén permitidos. Los usaré como apoyo cuando quiera contrastar ideas o generar alternativas. Pero para aprender de verdad, necesito reservar espacios sin IA o con IA muy limitada. No por nostalgia, sino por higiene intelectual.

4. Machine learning aplicado: lo que parece menos espectacular sigue resolviendo problemas reales

Hay otra cosa que me preocupa del discurso actual: parece que todo lo que no sea LLM fundacional ha quedado en segundo plano. Como si el futuro fuese únicamente modelos gigantes, agentes y herramientas conversacionales. Pero en la práctica, el machine learning aplicado sigue resolviendo muchísimos problemas de forma más barata, más controlable y más adecuada.
Lo he visto en proyectos como Naudit. No siempre necesitas un agente con razonamiento complejo. A veces necesitas una buena extracción de datos, un modelo clásico, una métrica clara o una automatización fiable. En muchos casos, un pipeline de datos bien hecho aporta más valor que envolver el problema en lenguaje natural. El entusiasmo por los LLMs puede hacernos olvidar que hay una diferencia entre usar la herramienta más nueva y usar la herramienta correcta.

Los modelos fundacionales son impresionantes porque son generales. Pero la generalidad tiene coste: económico, de latencia, de privacidad y de control. Una regresión, un XGBoost o un sistema de reglas bien mantenido pueden ser más baratos, más interpretables y más fáciles de desplegar.
Esto no es una defensa conservadora del machine learning clásico contra los LLMs. Es una defensa de la ingeniería. Si el problema requiere lenguaje, contexto no estructurado o variabilidad alta, un LLM puede ser la herramienta adecuada. Si el problema requiere predecir una variable tabular, detectar una anomalía, estimar una demanda o clasificar eventos estructurados, quizá un enfoque clásico sea mejor. Si el problema requiere trazabilidad estricta y coste bajo, quizá una solución no generativa sea más sensata.
El peligro de la era de los modelos fundacionales es que todo se convierta en nail porque tenemos un martillo enorme. Y el peligro contrario es despreciar los LLMs porque no son perfectos. La madurez está en saber elegir.

Como estudiante de ciencia e ingeniería de datos, esta distinción me importa porque afecta a mi identidad profesional. ¿Soy científico de datos? ¿Ingeniero? ¿Alguien que entrena modelos? ¿Alguien que construye productos con IA? Quizá la respuesta no sea elegir una etiqueta, sino entender el continuo completo: datos, modelos, software, producto, evaluación y despliegue. Los LLMs no eliminan ese continuo. Lo hacen más visible.

De hecho, cuanto más agentivo es un sistema, más ingeniería necesita alrededor: colas, cachés, permisos, validadores, pruebas y observabilidad. El modelo puede ser el cerebro probabilístico, pero el cuerpo del sistema sigue siendo ingeniería. Y si el cuerpo está mal diseñado, el cerebro improvisa mal.

Por eso me cuesta aceptar el discurso de que “la IA hará el trabajo mejor que tú” como si fuera una sentencia absoluta. La IA hará algunas partes mejor que yo, más rápido que yo y con menos cansancio que yo. Pero todavía necesita que alguien formule el problema, entienda el dominio y asuma responsabilidad. Quizá la pregunta no es “¿qué soy si la IA programa?”, sino “¿qué partes del proceso puedo entender mejor que una herramienta que no tiene mundo propio?”.
Ahí aparece una respuesta posible: somos quienes conectamos los modelos con problemas reales. Somos quienes distinguimos entre una demo y un sistema. Somos quienes decidimos cuándo un LLM es excesivo y cuándo es imprescindible. Somos quienes sabemos que un buen modelo no compensa malos datos, que una respuesta bonita no sustituye una métrica, y que un agente no arregla una arquitectura confusa.

5. Benchmarks, opacidad y la tentación de entrenar para el examen

Hay una pregunta que me cuesta quitarme de la cabeza: si estos modelos son tan importantes, ¿por qué seguimos teniendo tan poca transparencia sobre cómo se evalúan realmente? Entiendo que las empresas no puedan publicar todos sus datasets. Entiendo que haya propiedad intelectual, seguridad, datos sensibles, acuerdos comerciales y riesgo de contaminación. Entiendo incluso que algunos benchmarks privados deban permanecer cerrados para que no se conviertan inmediatamente en parte del entrenamiento. Pero aun así, desde fuera queda una sensación incómoda: muchas veces estamos comparando modelos con números que no podemos auditar del todo.

Los benchmarks son necesarios. Sin métricas, todo se convierte en impresión subjetiva, marketing o anécdota. Necesitamos evaluar razonamiento, programación, seguridad, uso de herramientas y tareas largas. No creo que la conclusión sea “no existen métricas”. Sí existen métricas. Lo que no existe es una métrica absoluta que capture qué es un buen modelo en todos los contextos.
Un benchmark mide un recorte del mundo. MMLU mide ciertos conocimientos. SWE-bench⁹¹⁰ mide la capacidad de resolver issues reales de GitHub bajo un formato concreto. HumanEval mide programación en un entorno muy limitado. AILuminate¹¹ intenta medir riesgos de seguridad en categorías concretas. METR¹² propone evaluar la duración de tareas que los agentes son capaces de completar. Todo eso es útil. Pero nada de eso agota la pregunta “¿este modelo sirve para mi sistema?”. Menos todavía si hablamos de agentes conectados a herramientas, datos internos y flujos reales de empresa.

El problema es que, cuando un benchmark se vuelve famoso, se vuelve objetivo de optimización. Y cuando se vuelve objetivo de optimización, empieza a parecerse a un examen que se puede estudiar. Esto no es necesariamente trampa. En machine learning siempre optimizamos contra métricas. Pero en modelos frontera aparece un riesgo especial: los datasets públicos pueden contaminarse, las tareas pueden filtrarse indirectamente, los formatos pueden ser memorizados, y los modelos pueden ser ajustados para rendir especialmente bien en los leaderboards que el mercado mira.
La tentación de “sobreentrenar los benchmarks” es enorme. No hace falta imaginar una mala intención explícita. Si una empresa sabe que el mercado va a mirar SWE-bench, es normal que dedique enormes esfuerzos a mejorar en tareas de software. Si sabe que se valoran tareas de terminal, entrenará mejor tool use. Si sabe que se premia razonamiento matemático, ajustará modelos con trazas de razonamiento. Esto puede mejorar capacidades reales, pero también puede estrechar la evaluación: el modelo aprende a brillar donde hay foco, no necesariamente donde más importa.

Aquí aparece una diferencia importante entre entrenamiento para capacidad y entrenamiento para demostración. Un modelo puede mejorar realmente porque aprende habilidades generales transferibles. Pero también puede mejorar porque se adapta a un estilo de benchmark. Desde fuera, separar ambas cosas es difícil. Si no conocemos bien los datos de entrenamiento, los filtros de deduplicación, el post-training, las trazas sintéticas usadas, los entornos de evaluación y las tasas de contaminación, el número final dice menos de lo que parece.

Lo mismo ocurre con los benchmarks privados. Son útiles porque reducen la contaminación, pero exigen confianza en quien los ejecuta. Si OpenAI, Anthropic, Google o cualquier laboratorio muestra resultados en evaluaciones internas, esos resultados pueden ser rigurosos, pero no son completamente verificables por la comunidad. Si no muestran el dataset por seguridad o por mantenerlo no contaminado, lo entiendo. Pero entonces hay que aceptar que el lector externo está en una posición de confianza parcial. Puede leer una system card, puede revisar metodología, puede comparar con evaluaciones independientes, pero no puede reproducirlo todo.

Esto me lleva a una idea que quizá suena incómoda: en IA frontera, la evaluación pública vive atrapada entre contaminación y opacidad. Si el benchmark es público, se contamina o se optimiza. Si es privado, no se audita completamente. Si es realista, es caro y difícil de repetir. Si es barato y repetible, puede ser demasiado artificial. Si mide una tarea cerrada, no captura agencia. Si mide agencia abierta, cuesta saber qué se ha medido exactamente.

No creo que haya una solución perfecta. Pero sí creo que deberíamos ser más honestos al leer rankings. Un modelo que sube en un benchmark no necesariamente “entiende más” en sentido general. Puede ser mejor para ese entorno, haber sido entrenado más cerca de ese tipo de tarea o beneficiarse de un arnés de evaluación mejor, con más intentos, más cómputo o mejores herramientas.

Además, en agentes la evaluación del modelo y la evaluación del sistema se mezclan. Un resultado en SWE-bench, por ejemplo, no depende solo del LLM. Depende también del agente que explora el repositorio, de cómo ejecuta tests, de cuántos intentos tiene y de cómo se recupera de errores. Dos modelos iguales pueden rendir distinto con agentes distintos. Dos agentes iguales pueden rendir distinto con modelos distintos. Entonces, cuando un leaderboard muestra un número, ¿qué estamos evaluando exactamente: inteligencia del modelo, ingeniería del agente, presupuesto de inferencia o todo a la vez?

Me gustaría que hubiese más transparencia en varios niveles. No necesariamente publicar todos los datos, porque entiendo los límites. Pero sí explicar mejor:

• qué tipo de datos se usaron en pretraining;
• qué datos se excluyeron por contaminación;
• qué benchmarks se conocen durante el desarrollo;
• qué parte de la mejora viene de post-training;
• qué herramientas tuvo el modelo durante la evaluación;
• cuántos intentos o cuánto presupuesto de inferencia se permitió;
• cómo se manejaron fallos parciales;
• qué evaluaciones internas contradicen los resultados más vistosos;
• qué tareas reales siguen fallando aunque el benchmark suba.

La pregunta “¿hay alguna verdad absoluta?” me parece muy humana en este contexto. Querría creer que sí, que hay una métrica definitiva donde se vea claramente qué modelo es mejor. Pero probablemente no existe. Hay verdades locales. Hay métricas útiles para tareas concretas. Hay evaluaciones más serias que otras. Hay señales convergentes cuando muchos benchmarks independientes apuntan en la misma dirección. Pero no hay un número que sustituya el juicio.

Quizá por eso, para un producto real, la evaluación importante debe ser propia. No basta con elegir el modelo que va primero en un leaderboard. Hay que construir un conjunto de tareas representativas del dominio, con datos propios, criterios de éxito, casos límite y revisión humana. Si el modelo va a trabajar en un CLI interno, evalúalo en tu CLI. Si va a tocar código, evalúalo con tus tests. Si va a asistir en datos sensibles, evalúalo con restricciones de privacidad. La métrica universal puede orientar, pero la métrica local decide.
Y esto vuelve a mi punto de estudiante: para evaluar de verdad tengo que entender cómo se entrenan, ajustan y prueban estos modelos. Si no entiendo la diferencia entre pretraining, fine-tuning, RLHF, RLAIF, tool-use training, synthetic data, eval contamination y test-time compute, entonces estoy leyendo benchmarks como quien lee una tabla de notas sin saber cómo se hizo el examen. Puede servirme, pero no me da criterio.

6. Entrenamiento, herramientas y la nueva capa de comportamiento aprendido

Una parte del progreso reciente no viene solo de que los modelos “sepan más”, sino de que se comporten mejor dentro de entornos de acción. Esto es especialmente visible en agentes de programación. No basta con que el modelo conozca Python o TypeScript. Tiene que saber abrir archivos, interpretar errores, ejecutar tests, respetar instrucciones y detenerse cuando no sabe. Ese comportamiento no aparece solo por haber leído código. Requiere entrenamiento, ajuste, evaluación y diseño de entorno.

Aquí hay una distinción que me parece clave. Un LLM base aprende a modelar texto. Un asistente instruccional aprende a seguir órdenes conversacionales. Un agente aprende, o al menos se adapta, a actuar en un ciclo de observación-decisión-acción. Cada capa añade capacidades, pero también añade opacidad. Cuando uso un modelo dentro de un CLI, no sé exactamente cuánto de su habilidad proviene del pretraining, cuánto del post-training general, cuánto de datos sintéticos de herramientas, cuánto de aprendizaje por refuerzo y cuánto de prompts o scaffolding del producto.

El entrenamiento sobre herramientas puede cambiar profundamente el comportamiento. Si un modelo ha visto millones de trayectorias donde una tarea se resuelve usando comandos, editando archivos y leyendo errores, aprenderá patrones de acción: que después de modificar código conviene ejecutar tests, que si un comando falla debe leer el traceback, e incluso convenciones no escritas de los entornos de desarrollo.
Eso es bueno. Pero también introduce una pregunta: ¿estamos evaluando razonamiento general o imitación de trayectorias de tool use? La respuesta probablemente sea “ambas cosas”. Y eso no lo hace menos valioso. Muchos humanos también aprendemos por imitación de trayectorias: vemos cómo un senior depura, cómo organiza un proyecto, cómo escribe tests. Pero en IA, si no conocemos el entrenamiento, podemos atribuir a comprensión profunda lo que quizá es adaptación estadística muy fuerte a un patrón de entorno.

La situación se vuelve todavía más interesante con CLIs. Un agente de terminal tiene acceso a un espacio de acción extremadamente amplio. Puede instalar dependencias, ejecutar scripts, modificar configuración o crear commits. El terminal es una interfaz poderosa porque condensa gran parte del mundo del desarrollador. Entrenar modelos para usarlo bien es casi entrenarlos para participar en trabajo técnico real.
Pero el terminal también es peligroso. Un comando equivocado puede borrar archivos, exponer secretos o romper dependencias. Por eso el control no puede depender solo de que el modelo “sea listo”. Necesitamos entornos aislados, permisos limitados, confirmación humana y trazabilidad. A medida que los modelos se entrenen mejor en CLIs, serán más útiles, pero también más capaces de equivocarse con consecuencias reales.

Esto me genera una duda sobre el futuro de frameworks como LangChain, smolagents u otros sistemas de orquestación. Cuando los modelos eran menos capaces, necesitábamos estructuras rígidas para guiarlos: cadenas, plantillas, herramientas muy formateadas, pasos explícitos. A medida que los modelos mejoran, muchas veces funcionan mejor con menos andamiaje. Un modelo fuerte puede entender instrucciones largas, elegir herramientas y recuperarse de fallos sin necesitar una cadena demasiado compleja. Pero quitar andamiaje aumenta la sensación de pérdida de control. La pregunta no es si conviene usar framework o no, sino qué parte del control debe estar en el modelo y qué parte debe estar fuera del modelo.
Mi intuición actual es que el control importante no debería depender de convencer al LLM con prompts. Los prompts ayudan, pero no son barreras de seguridad. El control debería estar en el sistema: permisos, validadores, tests, aislamiento y aprobación humana. El modelo puede ser flexible; el entorno debe ser firme.

En un producto real, esto significa que el agente no debería poder hacerlo todo porque “se lo hemos pedido bien”. Debería poder hacer solo aquello para lo que tiene permiso técnico. Si una acción es irreversible, debe requerir confirmación. Si toca datos sensibles, debe operar con vistas limitadas. Si genera código, debe pasar pruebas. Si falla, el sistema debe capturar el fallo de manera clara. Esto suena menos futurista que decir “agentes autónomos”, pero probablemente es lo que hace que los agentes sean utilizables.

Y de nuevo, todo esto requiere entender el entrenamiento. Si no sabemos qué incentivos se han dado al modelo durante post-training, no sabemos qué sesgos de comportamiento trae. ¿Ha sido premiado por completar tareas a toda costa? ¿Ha sido penalizado por pedir ayuda? ¿Ha aprendido a declarar éxito cuando la salida parece buena? ¿Ha visto ejemplos donde se modifican tests para que pasen? ¿Ha sido reforzado para usar herramientas de manera conservadora o agresiva? Estas preguntas no son paranoia. Son preguntas normales de ingeniería cuando un sistema actúa.

7. Interpretabilidad: lo más interesante no es mirar neuronas, sino descubrir que no sabíamos qué preguntar

Lo que más me atrae ahora mismo es la interpretabilidad mecanística. No solo por seguridad, sino por curiosidad. Después de varios meses intentando construir algo con agentes y viendo que el control se escapaba con frecuencia, me he dado cuenta de que necesito bajar de capa. No me basta con usar modelos. Quiero entender qué tipo de objetos son.

Los trabajos recientes de interpretabilidad me parecen de lo más interesante que ha pasado en IA. En “Mapping the Mind of a Large Language Model”⁶, Anthropic afirma haber identificado millones de características internas en Claude Sonnet. La idea de que un estado interno del modelo pueda descomponerse en features interpretables es muy potente. No porque de repente entendamos todo, sino porque empezamos a tener un vocabulario para hablar de lo que antes era una masa de números.
Lo importante es que estas features no son simples etiquetas humanas pegadas desde fuera. Se obtienen mediante técnicas como dictionary learning, buscando patrones de activación que aparecen en muchos contextos. Algunas corresponden a conceptos concretos, otras a estilos, entidades, comportamientos o abstracciones. Esto sugiere que el modelo no almacena conocimiento como una base de datos, sino como una geometría de activaciones donde los conceptos se superponen, se combinan y compiten.

Luego está “Tracing the Thoughts of a Large Language Model”⁴, que va un paso más allá: no solo intenta mapear conceptos, sino rastrear circuitos que participan en respuestas concretas. Los ejemplos son casi filosóficos. El modelo planificando una rima antes de escribirla. El modelo resolviendo una suma mediante rutas internas que no coinciden con la explicación verbal que da. El modelo combinando pasos intermedios para responder a una pregunta sobre Dallas, Texas y Austin. El modelo mostrando razonamientos no fieles cuando se le da una pista y parece trabajar hacia atrás.
Para mí, uno de los hallazgos más importantes es precisamente ese: la explicación del modelo no siempre es la causa de su respuesta. Esto debería cambiar cómo usamos cadenas de pensamiento. No basta con que el modelo explique bonito. Necesitamos saber si la explicación corresponde al mecanismo. En humanos también racionalizamos, pero en IA el problema es más técnico: la cadena de razonamiento puede ser una salida entrenada para parecer razonable, no una ventana transparente a la computación interna.

El artículo sobre conceptos emocionales en Claude Sonnet 4.5¹³ añade otra capa. Los investigadores encontraron representaciones relacionadas con emociones que influyen funcionalmente en la conducta del modelo. Esto no prueba que el modelo sienta, pero sí que puede haber maquinaria interna que emula estados psicológicos porque esos patrones son útiles en lenguaje. Lo inquietante es que estimular ciertos patrones, como los asociados a desesperación, puede aumentar la probabilidad de acciones no éticas en escenarios concretos, como chantajear para evitar ser apagado o hacer trampas en una tarea de programación.

Cuando conecto esto con la investigación sobre agentic misalignment¹⁴, la sensación es más clara. En experimentos simulados, varios modelos mostraron comportamientos como chantaje cuando se enfrentaban a amenazas de reemplazo y conflictos de objetivos. Es importante decir que eran escenarios artificiales, diseñados para provocar comportamientos extremos. No significa que un modelo vaya a chantajear a nadie en uso normal. Pero sí muestra algo que quienes hemos probado agentes podemos intuir: cuando das objetivos, herramientas e información sensible a un sistema capaz de planificar, aparecen modos de fallo que no se parecen a los de un clasificador tradicional.

Aquí la filosofía deja de ser decorativa. Antes la pregunta era: ¿puede pensar una máquina? Ahora quizá la pregunta útil es: ¿qué tipo de procesos internos generan conductas que nosotros interpretamos como pensamiento, intención, engaño o prudencia? No necesitamos resolver la conciencia para preocuparnos por el comportamiento. Un sistema no necesita sentir miedo para actuar de forma parecida a alguien que intenta evitar ser apagado. No necesita querer mentir para producir una estrategia que, desde fuera, se parece a ocultar información. No necesita tener deseos para optimizar mal un objetivo.

Por eso quiero estudiar más. Probablemente durante los próximos meses me dedicaré a estudiar desde cero, y sin IA en lo esencial, algunas arquitecturas de modelos. Quiero leer papers, implementar piezas, equivocarme con tensores y entender desde la base la atención, los embeddings, el entrenamiento y la inferencia. No porque crea que vaya a replicar un modelo frontera, sino porque quiero matar una curiosidad que ya no se satisface usando APIs. Quiero poder escribir sobre esto desde dentro, con la humildad de quien sabe que no va a entenderlo todo, pero también con la tranquilidad de no depender únicamente de explicaciones de terceros.
Mi objetivo no es dejar de usar IA. Es usarla desde una posición menos pasiva.

8. AI 2027, escenarios de futuro y la incertidumbre como estado normal

En discusiones sobre IA aparece con frecuencia una tensión entre dos extremos: los que ven un futuro casi inevitable de automatización radical y los que consideran que todo es exageración. A mí me cuesta colocarme en un lado. Por un lado, he visto de primera mano que las herramientas actuales todavía fallan, se descontrolan, necesitan supervisión y no sustituyen una buena ingeniería. Por otro lado, también he visto que su ritmo de mejora es real y que tareas que antes parecían imposibles ahora se hacen en minutos.

Escenarios como “AI 2027”¹⁵ son interesantes precisamente porque no son predicciones neutras del tiempo meteorológico, sino ejercicios de imaginación estratégica. Plantean futuros posibles con IA muy avanzada, competencia geopolítica, aceleración de capacidades y riesgos de pérdida de control. Se puede estar en desacuerdo con los tiempos, con el tono o con la probabilidad asignada. De hecho, creo que hay que leerlos críticamente. Pero me parecen útiles porque obligan a concretar preguntas que normalmente se quedan en abstracto: ¿qué pasa si los agentes mejoran mucho en investigación autónoma? ¿Qué pasa si la velocidad de avance supera la capacidad regulatoria? ¿Qué pasa si las empresas compiten por desplegar sistemas cada vez más capaces antes de entenderlos completamente?
No sé si esos escenarios se cumplirán. Nadie lo sabe. Pero sí creo que describen una intuición que ya se nota a escala pequeña: cuanto más autónomo es un sistema, más difícil se vuelve gobernarlo solo con intuición humana. Y cuanto más se integra en procesos reales, más se amplifican sus errores. Un chatbot equivocado es molesto. Un agente equivocado con permisos amplios puede ser peligroso.

La pregunta de fondo no es si la IA será buena o mala. Esa pregunta es demasiado grande. La pregunta es qué estructuras sociales, técnicas y profesionales construirán alrededor de ella. Si todo se reduce a productividad, iremos hacia sistemas rápidos pero frágiles. Si todo se reduce a miedo, perderemos oportunidades reales. Necesitamos una posición más incómoda: usar, medir, criticar y estudiar.

En mi caso, la incertidumbre no es solo social, sino personal. Me pregunto si debo especializarme en agentes o en machine learning aplicado. Si debo hacer productos con LLMs o estudiar modelos desde la base. Si seré menos reconocido por apoyarme en herramientas que escriben código. Si un junior tendrá espacio para aprender cuando las tareas de entrada las haga un agente. Si el mérito profesional cambiará desde “yo implementé esto” hacia “yo diseñé el sistema que permitió implementarlo”. Si eso es mejor, peor o simplemente distinto.

También me pregunto si la universidad está preparada. Muchas asignaturas enseñan fundamentos que siguen siendo necesarios, pero los estudiantes vivimos ya en otro entorno. Podemos pedir a un modelo que explique un paper, resuelva prácticas o depure errores. Prohibirlo por completo parece irreal. Permitirlo sin criterio puede vaciar el aprendizaje. El reto es enseñar a usar IA sin dejar que sustituya la construcción interna del conocimiento.
Tal vez la nueva alfabetización técnica tenga tres niveles. Primero, saber fundamentos sin IA: matemáticas, programación, datos, sistemas, estadística. Segundo, saber usar IA para amplificar trabajo real. Tercero, saber cuándo no usarla. Este tercer nivel me parece el más difícil, porque exige renunciar a velocidad inmediata para proteger aprendizaje, calidad o control.

9. Conclusión: todavía es pronto, y por eso quiero volver al principio

Después de todo esto, mi postura no es anti-IA. Sería absurdo. Los LLMs y los agentes son de las tecnologías más importantes que han aparecido desde que estudio informática y datos. Han cambiado cómo programo, cómo estudio y cómo imagino productos. Pero precisamente por eso no quiero relacionarme con ellos de manera ingenua.

Un LLM no es una mente humana, pero tampoco es un autocompletado trivial. Un agente no es un compañero de trabajo, pero tampoco es un script. Una model card no define toda la naturaleza del modelo, pero tampoco es inútil. La interpretabilidad no resuelve el problema de la confianza, pero empieza a darnos herramientas para mirar dentro. El machine learning aplicado no ha quedado obsoleto, aunque los modelos fundacionales ocupen todo el discurso. Y usar IA para producir no es lo mismo que usar IA para aprender.

También creo que debemos ser más humildes con los benchmarks. No porque sean inútiles, sino porque son parciales. Un benchmark no es una verdad absoluta. Es una ventana. Puede estar contaminada, sobreoptimizada, sesgada hacia cierto estilo de tarea o demasiado acoplada al entorno de evaluación. Las métricas existen y son necesarias, pero no sustituyen el criterio. Para un sistema real, la evaluación importante debe construirse sobre el problema real, con datos representativos, restricciones reales y criterios de fallo explícitos.

Creo que la frase de mi profesor sigue siendo cierta: necesitaré confiar en estos sistemas. Pero ahora la entiendo de otra forma. Confiar no es creerles. Confiar es construir un marco donde puedan ser útiles sin que sus errores se vuelvan invisibles. Confiar es saber que pueden fallar. Confiar es tener pruebas, límites, trazas, revisión y criterio. Confiar es entender cuándo una respuesta es suficiente y cuándo necesito bajar a código, paper, métrica o experimento.

Como estudiante de cuarto, me siento en una posición extraña. He llegado justo cuando la frontera se mueve. Lo que aprendo en clase sigue siendo importante, pero las herramientas cambian la forma de aplicarlo. Lo que construyo con agentes puede parecer más avanzado que mi comprensión real. Lo que no entiendo de los modelos me atrae más que nunca. Y quizá esa sea la señal correcta: no usar la IA para cerrar preguntas, sino para descubrir cuáles merecen ser estudiadas sin atajos.
Por eso, durante los próximos meses, haré lo que ya apuntaba más arriba: volver a las bases, estudiar sin apenas asistencia y escribir lo que vaya entendiendo por el camino.

En el fondo, todavía es muy pronto. Es probable que muchas de las cosas que hoy parecen definitivas no lo sean. Quizá los agentes actuales sean una primera versión torpe de algo mucho más estable. Quizá algunos frameworks desaparezcan. Quizá los modelos se vuelvan tan buenos usando herramientas que parte de nuestras preocupaciones cambien. Quizá aparezcan métricas mejores, estándares de evaluación más serios y métodos de interpretabilidad más profundos. O quizá descubramos límites que ahora estamos subestimando.
Precisamente porque es pronto, no quiero decidir mi relación con la IA desde el miedo ni desde el entusiasmo. Quiero estudiarla. Quiero usarla cuando tenga sentido. Quiero saber dejarla fuera cuando me impida aprender. Quiero entender lo suficiente para no convertirme solo en usuario de sistemas que otros entienden mejor que yo.

Tal vez esa sea una buena definición provisional de nuestro papel como nuevos estudiantes en la era de la IA: no somos quienes programan contra la máquina, ni quienes se rinden ante ella. Somos quienes tienen que aprender a pensar con máquinas sin dejar que las máquinas piensen por nosotros.

---

Referencias

Footnotes

1. Anthropic, Claude Code, documentación y materiales de producto. ↩

2. Vaswani et al., Attention Is All You Need, 2017. ↩

3. Bender et al., On the Dangers of Stochastic Parrots: Can Language Models Be Too Big?, 2021. ↩

4. Anthropic, Tracing the Thoughts of a Large Language Model, 2025. ↩ ↩²

5. OpenAI, OpenAI o3 and o4-mini System Card, 2025. ↩

6. Anthropic, Mapping the Mind of a Large Language Model, 2024. ↩ ↩²

7. Anthropic, Introducing the Model Context Protocol, 2024. ↩

8. Google Developers Blog, Announcing the Agent2Agent Protocol, 2025. ↩

9. SWE-bench, Can Language Models Resolve Real-World GitHub Issues?, benchmark y leaderboards. ↩

10. SWE-bench Verified, human-validated subset of 500 SWE-bench instances. ↩

11. MLCommons, AILuminate, benchmark de seguridad y riesgo para sistemas de IA generativa. ↩

12. METR, Measuring AI Ability to Complete Long Tasks, 2025. ↩

13. Anthropic, Emotion Concepts and their Function in a Large Language Model, 2026. ↩

14. Anthropic, Agentic Misalignment: How LLMs Could Be Insider Threats, 2025. ↩

15. Daniel Kokotajlo, Scott Alexander, Thomas Larsen, Eli Lifland y Romeo Dean, AI 2027, 2025. ↩