Autoresearch no propone solo automatizar pruebas de entrenamiento: plantea una nueva división del trabajo entre humanos y agentes, en la que la persona reescribe la estrategia y la IA reescribe el código para investigar sin descanso.
Andrej Karpathy ha convertido una idea que hasta hace poco sonaba a ciencia ficción en un repositorio mínimo, ejecutable y, sobre todo, conceptualmente muy provocador. Su proyecto autoresearch empaqueta un sistema de investigación autónoma sobre modelos de lenguaje en una versión autocontenida, de una sola GPU y de apenas unas 630 líneas de código para el núcleo de entrenamiento. La propuesta, presentada en GitHub como una derivación simplificada de nanochat, no consiste solo en dejar que un agente toque hiperparámetros mientras un humano observa. Va bastante más allá: el agente modifica el código de entrenamiento, lanza experimentos de cinco minutos, mide si mejora la pérdida de validación, conserva o descarta cambios y repite el ciclo en bucle, mientras el humano deja de tocar el .py y pasa a iterar sobre el archivo de instrucciones, program.md.
Esa inversión del flujo de trabajo es lo que vuelve el proyecto especialmente interesante. En el esquema clásico, el investigador humano toca el código, ajusta arquitectura, optimizador y lotes, lanza pruebas, compara resultados y decide la siguiente hipótesis. En autoresearch, Karpathy propone separar las capas: el humano diseña la “organización de investigación” a través del prompt o programa; el agente se encarga de la ejecución experimental sobre train.py. El README lo explica sin rodeos: el agente edita el archivo de entrenamiento; la persona itera sobre program.md, que funciona como una especie de skill ultraligera para orientar el trabajo autónomo.
La imagen que acompaña el proyecto ayuda a entender la ambición. Se ve una gráfica titulada “Autoresearch Progress: 83 Experiments, 15 Kept Improvements”, con una escalera descendente en la métrica de validación BPB, donde cada punto representa una ejecución completa de entrenamiento de exactamente cinco minutos. Los experimentos descartados aparecen en gris; los retenidos, en verde; y la línea muestra la mejor trayectoria acumulada. Más que una simple curva de optimización, la visualización sugiere otra cosa: una narrativa de progreso autónomo, donde el sistema explora configuraciones, aprende cuáles mejoran y construye una secuencia de pequeñas ganancias sin intervención humana continua. Esa estética de laboratorio automatizado es deliberada y forma parte del encanto del proyecto. La propia introducción del repositorio, con tono medio épico y medio paródico, presenta la investigación de frontera como el dominio futuro de enjambres de agentes autónomos corriendo sobre “megastructuras de cómputo en los cielos”.
Conviene subrayar que, pese al tono juguetón, autoresearch no es una ocurrencia vacía. El repositorio está diseñado para funcionar con reglas bastante concretas. Solo hay tres archivos que realmente importan: prepare.py, que contiene constantes fijas, preparación de datos y utilidades; train.py, que es el único archivo que el agente puede modificar; y program.md, que contiene las instrucciones de alto nivel para el agente. El sistema está construido para que cada carrera de entrenamiento dure exactamente cinco minutos de reloj, excluyendo arranque y compilación, y para medir el resultado en val_bpb —validation bits per byte—, una métrica que Karpathy destaca como comparable entre cambios arquitectónicos y no dependiente del tamaño del vocabulario.
Ese diseño tiene implicaciones importantes. La primera es metodológica: fijar una ventana de cinco minutos convierte cada experimento en una unidad estandarizada. Según el propio README, eso permite esperar aproximadamente 12 experimentos por hora y en torno a 100 experimentos durante una noche, siempre en función de la plataforma concreta. La ventaja es doble: por un lado, todos los cambios que haga el agente pueden compararse bajo el mismo presupuesto temporal; por otro, el sistema no busca el mejor modelo en abstracto, sino el mejor modelo posible bajo ese tiempo de entrenamiento y sobre ese hardware. Es una forma muy pragmática de plantear la investigación: no optimizar una teoría universal, sino optimizar una trayectoria local de mejora dentro de restricciones reales de cómputo.
La segunda implicación es más estratégica. Autoresearch no automatiza solo una tarea concreta, sino una forma de trabajar. El agente tiene permiso para cambiar arquitectura, hiperparámetros, optimizador, tamaño de lote y otros elementos del entrenamiento dentro de train.py. El humano, en cambio, deja de tocar el centro experimental y pasa a actuar como diseñador del entorno cognitivo del agente. Dicho de otra manera: la persona deja de ser ejecutor de pruebas y se convierte en arquitecto de una organización de investigación artificial. Esa es probablemente la idea más potente del proyecto, porque desplaza el valor humano desde la manipulación directa del código hacia el diseño de las reglas, prioridades y estilos de búsqueda del sistema.
Por eso el proyecto puede leerse como un pequeño manifiesto sobre la próxima etapa de la ingeniería con IA. La pregunta ya no sería solo “¿qué puede programar el agente?”, sino “¿cómo diseñamos agentes capaces de investigar indefinidamente y cada vez mejor?”. En el texto que acompaña el lanzamiento, Karpathy lo formula de forma explícita: el objetivo es ingenierizar agentes para que hagan el progreso de investigación más rápido posible, indefinidamente y sin implicación propia. Esa frase resume una intuición que empieza a extenderse en muchas capas del sector: el rendimiento de la IA ya no depende solo del modelo base, sino del bucle de realimentación que une prompting, ejecución, evaluación y selección de mejoras. En autoresearch, ese bucle queda cristalizado en una estructura mínima y visible. El agente prueba; la métrica juzga; el historial de Git conserva.
Aquí entra en juego otro elemento central: Git como memoria de investigación autónoma. El agente trabaja sobre una rama de funcionalidades, acumula commits a medida que encuentra mejores configuraciones y conserva únicamente aquellas modificaciones que mejoran la métrica final. En ese detalle hay una intuición elegante. En lugar de pensar la IA como una caja negra que “hace cosas”, Karpathy la sitúa dentro de una disciplina de software conocida, trazable y legible: ramas, diffs, commits, historial de iteraciones. Eso no elimina la complejidad, pero sí la convierte en algo auditable. La investigación deja de ser una serie de pruebas desperdigadas y pasa a ser una secuencia versionada de hipótesis y resultados.
El carácter “mínimo” del repositorio también es una declaración de principios. El README insiste en que no hay entrenamiento distribuido, configuraciones complejas ni dependencias externas aparte de PyTorch y unos pocos paquetes pequeños. Una GPU, un archivo, una métrica. Esta reducción del sistema a una forma casi pedagógica cumple dos funciones. La primera es facilitar que otros lo prueben durante un fin de semana, que es precisamente como Karpathy lo presenta. La segunda es hacer visible el mecanismo conceptual sin enterrarlo bajo capas de infraestructura industrial. Autoresearch no intenta ser el sistema definitivo de investigación autónoma, sino una demostración compacta de cómo podría empezar ese futuro.
Por eso el proyecto se mueve en una frontera curiosa entre experimento serio, juguete de élite y pieza cultural del momento IA. Karpathy lo define con ironía como “part code, part sci-fi, and a pinch of psychosis”. La fórmula no es casual. El repositorio tiene algo de artefacto narrativo: dramatiza una idea muy presente hoy en la comunidad técnica, la de que la investigación y el desarrollo pueden convertirse en procesos parcialmente autoacelerados por agentes que iteran sin descanso. Pero, al mismo tiempo, ofrece suficiente concreción como para que no quede en metáfora. Hay código, hay instrucciones, hay métrica, hay historial y hay un camino reproducible de arranque.
La relación con nanochat también importa. El repositorio se presenta como una versión reducida del núcleo de entrenamiento de ese proyecto, destilada a una implementación de una sola GPU. Eso sitúa autoresearch en una tradición muy reconocible del ecosistema Karpathy: construir sistemas didácticos, compactos y transparentes para explicar ideas complejas de entrenamiento y uso de modelos de lenguaje. Solo que aquí el foco ya no está en enseñar al humano cómo entrenar un modelo, sino en mostrar cómo un agente puede encargarse de buena parte de esa exploración si se le diseña el entorno correcto.
Hay además un aspecto que merece atención desde el punto de vista organizativo. En el README, Karpathy sugiere que la versión por defecto de program.md es un baseline bare bones, una base mínima, y deja caer con claridad que lo interesante será iterar sobre ese archivo para encontrar el “código de organización de investigación” que logre el progreso más rápido. La expresión es muy reveladora. No habla solo de prompts ni de instrucciones. Habla de “research org code”, como si el equipo de investigación se hubiera convertido en software. Esa formulación apunta hacia una idea poderosa: el know-how ya no residirá solo en hiperparámetros o arquitecturas, sino en cómo se programa a los agentes para cooperar, probar, decidir y corregirse.
Esa visión conecta con una tendencia más amplia de la IA contemporánea: la transición desde herramientas que asisten a tareas hacia sistemas que orquestan bucles completos de trabajo. En lugar de pedirle a un modelo que redacte un texto o sugiera código, se le pide que formule hipótesis, modifique un archivo, ejecute un experimento, lea una métrica, conserve o revierta cambios y vuelva a empezar. No estamos todavía ante investigación científica plenamente autónoma, pero sí ante un embrión de flujo agentivo mucho más cercano a un laboratorio automatizado que a un simple copiloto. Autoresearch importa precisamente porque condensa esa transición en un formato entendible y replicable.
Naturalmente, también conviene leer el proyecto con cierta distancia crítica. El propio README deja claro que el código ha sido probado sobre una sola NVIDIA GPU, concretamente una H100, y que el repositorio no pretende resolver por ahora el soporte general para CPU, MPS u otras plataformas, aunque ofrece recomendaciones para quienes quieran hacer forks y adaptarlo a hardware más pequeño. También subraya que los resultados no serán comparables entre distintos equipos, precisamente porque el presupuesto se fija en tiempo de pared y no en número de pasos abstractos. Eso limita la universalidad del benchmark, pero es coherente con la filosofía local del proyecto: optimizar el progreso sobre una plataforma concreta, no establecer una tabla global.
El README incluso ofrece recomendaciones bastante terrenales para quienes quieran rebajar el sistema a máquinas menos potentes: usar datasets de menor entropía como TinyStories, bajar el tamaño de vocabulario, reducir MAX_SEQ_LEN y ajustar otros parámetros para acomodarse a ordenadores mucho más modestos. Ese detalle es importante porque muestra que, detrás de la puesta en escena futurista, hay una intención real de que la comunidad juegue, adapte y extienda el sistema. Autoresearch no se presenta como una demo cerrada, sino como un repositorio abierto para experimentar con distintas combinaciones de prompts, agentes y condiciones de cómputo.
La dimensión cultural del proyecto quizá sea, al final, tan relevante como la técnica. Karpathy está empaquetando en un solo gesto varias obsesiones del momento: el auge de los agentes, la automatización del trabajo intelectual, la importancia de los bucles de evaluación, la ingeniería de prompts como sistema y la fascinación casi mitológica por laboratorios donde el progreso se produce mientras los humanos duermen. La gráfica con 83 experimentos y 15 mejoras retenidas, el tono de ciencia ficción del README y la idea de “jugar el fin de semana” con un repositorio autónomo forman parte de una estética más amplia: la de una informática que ya no quiere solo programar máquinas, sino diseñar poblaciones de agentes capaces de programar, probar y optimizar por nosotros.
Visto así, el interés de autoresearch no depende tanto de que hoy mismo transforme la investigación de frontera como de que hace visible un cambio de paradigma. La unidad básica del trabajo ya no es el script, sino el bucle autónomo. La intervención humana ya no se mide solo en líneas de código escritas, sino en la calidad del marco de decisión que se entrega al agente. Y la investigación deja de parecerse a una secuencia lineal de hipótesis humanas para acercarse a una exploración continua donde el papel del humano es diseñar el sistema que explora.
Ahí es donde el proyecto adquiere más profundidad. No propone simplemente “usar IA para investigar”, algo que el sector lleva tiempo haciendo. Propone convertir la propia investigación en una capacidad operativa agentiva, con memoria, criterio de selección, ritmo fijo y acumulación de mejoras. Es una diferencia importante. Porque una cosa es que un modelo ayude a un científico; otra muy distinta es que una red de prácticas, prompts, reglas y agentes empiece a comportarse como un laboratorio semiindependiente. Autoresearch no es todavía eso en plenitud, pero sí es una maqueta muy clara de cómo podría arrancar ese camino.
En ese sentido, el proyecto se entiende mejor no como una promesa cerrada, sino como una pregunta abierta lanzada al ecosistema: si ya podemos dejar a un agente modificando código de entrenamiento, ejecutando pruebas de cinco minutos y reteniendo mejoras en una rama de Git, ¿qué parte del trabajo de investigación seguirá siendo intervención humana directa y qué parte pasará a ser diseño de organizaciones autónomas? Karpathy no ofrece una respuesta definitiva. Ofrece algo quizá más útil: un repositorio pequeño, operativo y suficientemente sugestivo como para que esa pregunta deje de ser teórica.
