Puedes externalizar el pensamiento. No puedes externalizar la comprensión.

Lo más claro que ha dicho Karpathy en mucho tiempo es que los LLM no son animales.

Llevamos tres años usando la analogía equivocada. Hablamos de los LLM como hablamos de un niño o de un perro: ha aprendido, ha entendido, se ha equivocado, mejorará con la experiencia. La metáfora se pega porque es cómoda. Te permite tratar al modelo como a una personita y saltarte la parte en la que preguntas qué es en realidad.

El modelo no es una personita. El modelo es un destilado estadístico de texto humano. Comprime todas las regularidades que sobrevivieron al corte de entrenamiento, incluida la regularidad de acertar en casi todo casi siempre. Eso no es comprensión. Es cobertura de patrones a muy alta resolución. Otra cosa, y que falla con patrones propios.

Por qué importa: no copiamos a los pájaros para volar. Construimos algo distinto que también vuela, entendiendo qué era volar de verdad, diferencias de presión sobre una superficie curva y no aletear. La aviación llegó a algún sitio solo cuando dejamos de fingir que el pájaro era la especificación. El argumento de Karpathy es que estamos en el momento equivalente con la inteligencia. Un LLM que «sabe» Python no sabe Python. Conoce la distribución de Python que apareció en la web abierta, ponderada por lo que los humanos escribieron sobre ello, con todo el sesgo que eso implica.

Por eso empuja el término ingeniería de agentes, con la misma seriedad que atravesó el software cuando dejó de ser un oficio y se volvió una disciplina. Especificaciones. Evals. Verificación. La capa intermedia sin glamour.

Tres cosas que este cambio hace concretas.

El vibe coding muere en producción

El vibe coding funciona un sábado por la tarde. Un hackathon, una demo, el primer piloto interno que entusiasma a todos porque la cosa contesta. La ilusión se sostiene hasta el momento en que la usa un desconocido. Entonces la superficie se multiplica por diez, las entradas dejan de parecerse al conjunto de pruebas cuidado, y el sistema empieza a producir salidas seguras de sí mismas que nadie puede rastrear.

Un equipo que entrega agentes sin especificaciones ni evals acumula un tipo concreto de deuda: comportamiento que nadie puede auditar. No deuda técnica. Deuda interpretativa. Cuando algo va mal, la única persona que puede explicar por qué es quien escribió el prompt, y probablemente ni esa, porque el prompt se iteró a ojo. Multiplícalo por una organización y tienes sistemas cuya corrección vive en la cabeza de alguien, sin documentación, sin pruebas de regresión, sin contrato.

Al software le costó treinta años aprender esto con código convencional. Sistemas de tipos, pruebas unitarias, de integración, de contrato, pilas de observabilidad. La disciplina no es divertida pero es lo que permite que el software lo opere gente que no es su autor. Los agentes no están exentos. Si acaso lo necesitan más, porque sus modos de fallo son silenciosos. Una respuesta equivocada que suena correcta es más difícil de detectar que una traza de error.

La disciplina que funciona está tomada del software de siempre. Suites de evals en CI, con los casos de fallo capturados del tráfico real. Prompts de sistema versionados y revisados como código. Esquemas de herramientas tipados. Salidas de modelo validadas contra contratos estrictos que fallan ruidosamente si la forma deriva. Nada de esto es exótico. Es lo que llevan haciendo los ingenieros de backend décadas. La novedad es tener que insistir en que también aplica al componente nuevo.

Las competencias dentadas son riesgo sin medir

La frase que se repite, «hablar a la vez con un doctorado y con un niño de diez años», es la correcta. Un modelo que borda un Leetcode difícil y falla al extraer tres campos de una factura no está «casi». Es una distribución de competencia que no se mapea a ningún perfil humano, y esa es la parte que casi todos los equipos se saltan.

Cuando un ingeniero sénior comete un error, puedes predecir más o menos dónde va a estar. Se despista en las tareas aburridas; sobreingenieriza las simples; discute los requisitos; deja huecos en la documentación. Los errores correlacionan con el tipo de persona que es. Con los LLM la superficie de fallo no correlaciona con nada intuitivo. El mismo modelo que escribió un soneto leerá mal un formato de fecha. El mismo que explicó una arquitectura transformer firmará mal un presupuesto en JSON.

Eso es lo que significa «dentado» en la práctica, y tiene una consecuencia operativa directa: no puedes extrapolar competencia. El rendimiento en las tareas A y B no te dice nada de C. Tienes que medir C aparte. Casi todos los equipos se lo saltan porque medir es caro y la demo convencía.

La disciplina que funciona es mapear lo dentado antes de salir a producción. No «¿funciona el modelo?», que es la pregunta equivocada. La correcta es «¿dónde se derrumba, y el derrumbe es ruidoso o silencioso?». Los derrumbes ruidosos están bien, les construyes un plan B. Los silenciosos son los que te matan, porque para cuando te enteras el sistema lleva semanas equivocándose y los datos de aguas abajo están contaminados.

La disciplina que funciona es correr evals adversarias en las costuras, allí donde la salida de un modelo se convierte en la entrada del siguiente. Datos históricos reservados, entradas patológicas (truncadas, malformadas, multilingües, adversarias), casos límite extraídos de producción. La medida que importa no es si el modelo acierta la entrada; es si sabe cuándo no la acierta. Una incertidumbre bien calibrada vale más que una respuesta bien calibrada.

Un 87,6% en SWE-bench no es tu código

Los números de benchmark sirven para comparar proveedores y no sirven para planificar operaciones. SWE-bench es un conjunto limpio, con issues bien formadas en repositorios populares de código abierto, evaluado por un modelo afinado para la tarea. El 87,6% describe lo que el modelo puede hacer en esas condiciones, no en las tuyas.

Tu código es otra cosa. Las issues las escriben product managers que no hablan ingeniería. El repositorio tiene seis años de contexto sedimentado, migraciones abandonadas, módulos muertos y tres convenciones de nombres compitiendo. Las dependencias son en parte internas y no están documentadas en ningún sitio que un modelo pueda leer. El criterio de éxito es «el cliente deja de quejarse», no «pasa la suite de pruebas».

Esto no es una queja sobre los benchmarks. Los benchmarks tienen su sitio. Es un aviso sobre la extrapolación. Un modelo que saca 87,6% en un conjunto público pulido sacará bastante menos en tu código, y la diferencia no será lineal. Donde pierde es justo donde el contexto importa más: requisitos ambiguos, restricciones en conflicto, código que era correcto por una razón que nadie se molestó en escribir.

La lección a la que vuelvo: la organización es la portadora de la comprensión. La salida del modelo (el diff, la respuesta, el candidato emparejado) es un subproducto. La comprensión vive en las personas, en la documentación, en los conjuntos de evals, en los post mortems. Si dejas que el modelo escriba el código sin que nadie de tu equipo desarrolle la comprensión de por qué ese código es correcto, has construido un sistema que funciona solo mientras funcione el modelo.

Cómo se ve esto un miércoles

Tres hábitos que he visto separar a los equipos que sobreviven a su adopción de IA de los que se atascan en silencio.

Leen lo que el modelo escribe. Suena obvio. Casi todos los equipos dejan de leer al primer mes. La salida parece lo bastante buena, el desarrollador sigue. El efecto acumulado es que nadie del equipo puede ya explicar el sistema, y cuando se rompe, el tiempo de reparación es el tiempo de volver a deducir qué se suponía que hacía. Los equipos que siguen leyendo, aunque sea lento, aunque el 90% de la salida esté bien, son los que conservan el músculo.

Versionan sus prompts como código. Los prompts que van a producción viven en el repositorio, pasan revisión de código, tienen changelog. No existe la situación en la que el prompt es «lo que alguien metió en el panel la semana pasada». Eso es un feature flag sin rastro de auditoría, y va a fallar en el peor momento posible.

Corren evals en cada cambio. No solo en el primer despliegue. Cada cambio de prompt, cada subida de versión de modelo, cada modificación de esquema de herramienta dispara una ejecución contra un conjunto cuidado de tráfico histórico. El conjunto crece según producción va revelando modos de fallo nuevos. Esto no tiene glamour, cuesta tiempo de montaje, y es lo de mayor apalancamiento que puede hacer un equipo. Es también lo que casi todos se saltan porque «funciona» y el coste parece teórico hasta que deja de serlo.

Nada de esto es el futuro. Es el presente, mal repartido.

La tesis que sigue en pie

Puedes externalizar el pensamiento, pero no la comprensión.

El modelo puede hacer el pensamiento: la búsqueda, el borrador, la síntesis, la limpieza. Eso es real, es útil y comprime semanas de trabajo en horas. La comprensión es lo que se queda contigo: saber por qué la respuesta es la que es, qué la cambiaría, dónde se rompe, cómo debería ser la siguiente versión.

Un equipo que externaliza las dos cosas, que deja que el modelo piense y sea lo único que entiende, ha construido una caja negra y ha olvidado dónde puso la llave. Serán productivos durante unos meses, hasta que dejen de serlo, y la recuperación es lenta, porque hay que reconstruir la comprensión desde cero.

Los equipos que ganen los próximos cinco años no son los de adopción de IA más agresiva. Son los que adoptan agresivamente y conservan su comprensión. Usan el modelo para generar, pero leen la salida. Lo usan para redactar especificaciones, pero las revisan. Lo usan para programar, pero revisan los diffs como si los hubiera escrito un júnior. La relación es de supervisión, no de delegación, y la diferencia está en dónde vive la comprensión.

De eso va en realidad la ingeniería de agentes. No de los frameworks, ni de los prompts, ni de las APIs de llamada a herramientas. De la disciplina de seguir siendo más listo que la cosa que has construido.