Método de IA en tres capas de Karpathy: qué dijo realmente

El video de YouTube de 13 minutos de Austin Marchese, publicado el 9 de junio de 2026, presenta una forma práctica de trabajar con Claude. En él, Marchese dice que el método de Karpathy “se puede desglosar en tres capas simples”. Entender qué ideas vienen de Karpathy y cuáles agregó Marchese vuelve el consejo más fácil de evaluar y de usar.

Karpathy cofundó OpenAI, fue director de IA en Tesla y acuñó la expresión “vibe coding” para construir software describiéndoselo a una IA. Marchese se basó en la charla informal de Karpathy con Stephanie Zhan, socia de Sequoia Capital, en el evento AI Ascent 2026 de la firma. Karpathy publicó un resumen y una transcripción editada en su blog el 30 de abril. Las especificaciones, la revisión de lo que produce la IA y la inversión en tu propio setup aparecen en la conversación. Él nunca los agrupa en capas.

La mayor parte del método sobrevive al contraste con la grabación, y las partes que Karpathy no dijo vale la pena usarlas igual. La versión popular también se salta su mejor ejemplo, y apenas insinúa la idea que explica por qué funciona la capa intermedia.

Cada capa, rastreada hasta su fuente

La especificación lleva contexto que la IA no puede ver

Karpathy sacó el tema de las especificaciones cuando Zhan le preguntó qué habilidades humanas ganan valor a medida que la IA hace más del trabajo. Su respuesta empezó con los agentes, esas herramientas de IA que ejecutan por su cuenta trabajos de varios pasos, como escribir y probar software. Dijo que ahora mismo los agentes son como pasantes, y que “las personas tienen que estar a cargo de esta especificación, de este plan”. Luego agregó:

“En realidad ni siquiera me gusta el modo plan… obviamente es muy útil, pero creo que aquí hay algo más general, donde tienes que trabajar con tu agente para diseñar una especificación que sea muy detallada”.

El modo plan es una configuración de Claude Code y de herramientas de programación similares, en la que la IA redacta un plan para que lo apruebes antes de cambiar cualquier cosa. Karpathy quiere más detalle del que contiene un plan. Sugirió que la especificación podría ser “básicamente la documentación”, con la persona a cargo de la supervisión y de las categorías de alto nivel, mientras los agentes rellenan los huecos.

Su mejor ejemplo vino de MenuGen, una pequeña app que construyó y que convierte la foto del menú de un restaurante en imágenes de los platillos. Los usuarios inician sesión con Google y compran créditos mediante Stripe, el servicio de pagos. Su agente emparejaba cada compra con una cuenta comparando las dos direcciones de correo. Los clientes pueden pagar con un correo distinto al que usaron para iniciar sesión, y cualquiera que lo hiciera pagaría por créditos que nunca recibiría. Karpathy tuvo que insistir en que todo se vinculara a un ID de usuario permanente.

La implementación pasó por alto la posibilidad de que un mismo cliente usara dos direcciones de correo. Una especificación es donde corresponde ese requisito, y una prueba con direcciones distintas de inicio de sesión y de pago es la forma de comprobar que el sistema lo maneja.

Los pasos de Marchese para escribir una especificación son prácticos, y ninguno viene de Karpathy:

• Pídele a la IA que te entreviste sobre el objetivo antes de redactar cualquier cosa. “Crea el reporte de fin de mes” es una tarea. El objetivo es la decisión que ese reporte debe impulsar.
• Mantén cada especificación pequeña, con un punto de control donde revises el resultado antes de que arranque la siguiente parte. Entregar todo el trabajo de una vez y esperar un producto terminado es lo que Marchese llama trabajar en cascada.
• Lee línea por línea la especificación que redacta la IA, y dile que te haga confirmar cada decisión clave.

El verificador: la IA es más fuerte donde el trabajo se puede revisar

Esta capa tiene las raíces más profundas en los propios textos de Karpathy. En una entrada de blog de noviembre de 2025 titulada Verifiability, argumentó que el software tradicional automatiza lo que puedes especificar, mientras que la IA automatiza lo que puedes verificar. Una tarea cuenta como verificable cuando un modelo puede intentarla muchas veces y cada intento se puede calificar automáticamente. Por eso la IA ha mejorado más rápido en matemáticas y en código, donde las respuestas se pueden revisar, y se queda atrás en trabajos que dependen del contexto y del sentido común.

En AI Ascent dio su ejemplo más reciente de esa desigualdad, a la que llama irregularidad (jaggedness):

“Quiero ir a un autolavado a lavar mi auto, y está a 50 metros. ¿Debería conducir o debería caminar? Y los modelos de última generación hoy te dirán que camines porque está muy cerca”.

El auto, por supuesto, tiene que estar en el autolavado. “¿Cómo es posible que un modelo de última generación pueda refactorizar una base de código de 100,000 líneas o encontrar vulnerabilidades de día cero, y sin embargo me diga que camine al autolavado?”, preguntó. Su respuesta fue que las personas necesitan seguir involucradas y tratar estos sistemas como herramientas.

La misma charla explica por qué no sirve rogarle a un modelo. Karpathy describe estos modelos como fantasmas más que como animales: simulaciones estadísticas sin ninguno de los impulsos que empujan a una persona a esforzarse más bajo presión. “Si les gritas, no van a trabajar mejor ni peor”, dijo. “Es más bien desconfiar de eso e irlo descubriendo con el tiempo”. Marchese cambia el fantasma por un bibliotecario robot que responde con los libros que tiene y que, cuando falta el libro correcto, se inventa algo con toda seguridad. Es una buena imagen para explicarle la idea a un equipo, y es de él, no de Karpathy.

Las tres revisiones de Marchese convierten esa desconfianza en una rutina:

• Escribe los criterios de aprobación antes de que empiece el trabajo. En un reporte, nombra la decisión que debe sustentar y la evidencia que necesita cada recomendación. Exigir cierto número de secciones puede ayudar a la presentación, pero un reporte puede cumplir ese requisito y aun así errar en la decisión.
• Considera un segundo modelo de IA como crítico cuando ayude a detectar una debilidad concreta. Karpathy propuso esa idea para la escritura, donde no hay una única respuesta correcta: “puedes imaginar tener un consejo de jueces LLM”. Que dos modelos coincidan no demuestra que una afirmación sea verdadera. Contrasta los hechos con las fuentes y usa pruebas directas para los resultados que se puedan comprobar. El segundo modelo es opcional: aporta valor solo si detecta errores importantes que los controles existentes no encuentran.
• Conecta la IA a una señal del mundo real. En un sitio web, verifica tanto la disponibilidad como la tarea del cliente: carga la página, completa una reservación y revisa su comprobante. En un reporte, concilia sus cifras con los registros de origen antes de comparar periodos.

Boris Cherny, creador de Claude Code, ofrece un consejo práctico en la misma línea. En un hilo de enero de 2026, su consejo fue “darle a Claude una forma de verificar su trabajo”, algo que calificó como “probablemente lo más importante para obtener grandes resultados de Claude Code”. Agregó que “si Claude tiene ese ciclo de retroalimentación, multiplicará por 2-3x la calidad del resultado final”. La cifra es su propia estimación y no proviene de ningún estudio publicado. Para elegir un sistema de IA, prueba casos representativos de tu trabajo que se hayan reservado fuera del desarrollo. Indica cuántos casos probaste, qué errores importan y la incertidumbre del resultado. Una muestra pequeña elegida por comodidad no basta para establecer fiabilidad, como explicamos en qué mide realmente una evaluación de IA.

El entorno lleva tu setup a cada conversación

Cuando le preguntaron qué separa a un programador mediocre que usa estas herramientas de uno totalmente nativo en IA, Karpathy dijo que se trata de “sacarle el máximo provecho a las herramientas disponibles, usar sus funciones e invertir en tu propio setup”. Lo comparó con la forma en que los programadores siempre han ajustado sus editores de código. Marchese convierte eso en un taller que construyes una vez y sigues mejorando, para que cada nueva conversación arranque con tus reglas y tu material de referencia ya en su lugar.

La parte de esta capa sobre la que Karpathy ha escrito en detalle es su base de conocimiento personal. “Cuando leo un artículo, tengo mi wiki construyéndose a partir de esos artículos”, dijo en AI Ascent. “Me encanta hacerle preguntas”. Publicó la idea como una nota el 4 de abril de 2026, escrita para pegarse directamente en una herramienta de IA. En ella, una IA lee los documentos que juntas y construye con ellos páginas de resumen enlazadas. Él llama a este patrón una LLM Wiki. Un modelo grande de lenguaje (LLM) es la tecnología detrás de ChatGPT y Claude.

El patrón tiene tres capas propias. Las fuentes en bruto entran sin tocarse, y la IA las lee pero nunca las edita. A partir de ellas, la IA escribe y mantiene la wiki, un conjunto de páginas enlazadas. La tercera capa, el esquema, es un archivo de instrucciones que le dice a la IA cómo está organizada la wiki. Sobre la wiki, Karpathy escribe: “Tú la lees; el LLM la escribe”. Si has visto “las tres capas de Karpathy” descritas como fuentes, wiki y esquema, quien lo escribió estaba describiendo esta nota.

Ese esquema es el mismo tipo de archivo que ancla la versión de esta capa de Marchese, que tiene cuatro partes:

• Un archivo de instrucciones permanentes. Claude Code lee un archivo llamado CLAUDE.md al inicio de cada conversación, y Codex, la herramienta de programación de OpenAI, lee uno llamado AGENTS.md. Pon ahí los valores por defecto que de otro modo repetirías, como “Antes de construir algo de varios pasos, incluye un plan de verificación”.
• Una carpeta de referencia organizada de modo que la IA pueda encontrar lo que necesita; su versión de la base de conocimiento de Karpathy.
• Instrucciones guardadas para trabajos recurrentes, que Claude llama skills. Su regla general es escribir una para cualquier cosa que planees hacer repetidamente, y corregirla cada vez que se quede corta.
• Límites estrictos para todo aquello en lo que un error resulte costoso.

Los límites necesitan más que una frase en ese archivo. Una línea que le pide a la IA no tocar una carpeta es una solicitud, y el modelo puede ignorarla. Claude Code también admite hooks, pequeñas verificaciones que la herramienta ejecuta antes de que la IA edite un archivo, y un hook puede bloquear la edición por completo. Marchese clasifica el trabajo en tres cajas: lo que la IA siempre hace por su cuenta, lo que debe preguntar primero y lo que nunca hace.

La comprensión se queda contigo

La mayoría de los artículos cierran con “puedes delegar tu pensamiento, pero no puedes delegar tu comprensión”, y así terminó también la charla de Karpathy. Presentó la frase como un tuit que “me voló la cabeza”, así que las palabras son de alguien más. Explicó por qué se le quedaron: “Me estoy volviendo el cuello de botella incluso para saber qué estamos tratando de construir, por qué vale la pena hacerlo y cómo dirigir a mis agentes”.

Cada capa depende de esa comprensión. No puedes escribir la especificación sin conocer el objetivo real, ni juzgar el resultado sin saber cómo se ve algo bueno, ni fijar límites sin saber qué errores no puede absorber tu negocio.

El texto de Karpathy sobre la charla muestra el método en un trabajo pequeño. Le dio a un modelo de IA sus entradas de blog y tuits recientes, y luego le pidió convertir la transcripción en un resumen y en una versión depurada. Leyó ambas antes de publicar y reportó que el resultado “se lee bien, sin errores flagrantes”. Su propia escritura fue el entorno, los dos resultados que pidió fueron la especificación, y su lectura fue el verificador.

Pon las tres capas a trabajar en un solo reporte

Aquí va una configuración ilustrativa para un reporte semanal de ventas. Su función es ayudar a un gerente de ventas a decidir qué oportunidades necesitan atención, en lugar de simplemente resumir la actividad.

Ahora prueba un caso incómodo: el CRM dice que el siguiente paso está vencido, pero la última nota indica que el cliente movió la reunión a la próxima semana. Un reporte que pide un seguimiento urgente se dejó llevar por el campo de fecha y se perdió el contexto. La corrección es conciliar los registros en conflicto y marcar el campo desactualizado, no hacer que la recomendación suene más pulida.

Guarda ese caso junto con la configuración y revísalo en la siguiente ejecución. Así tienes un objetivo concreto, una falla que puedes reconocer y una mejora duradera a las instrucciones. Esa es una aplicación útil del método, sin importar de quién sea el nombre que aparezca en el marco.

Fuentes

• Andrej Karpathy, resumen de Sequoia Ascent 2026, con una transcripción editada, 30 de abril de 2026
• Andrej Karpathy: From Vibe Coding to Agentic Engineering w/ Stephanie Zhan, grabación de la charla informal de AI Ascent 2026
• Andrej Karpathy, Verifiability (“Verificabilidad”), 17 de noviembre de 2025
• Andrej Karpathy, llm-wiki, 4 de abril de 2026
• Austin Marchese, Stop Prompting Claude. Use Karpathy’s Method Instead. (“Deja de darle prompts a Claude. Usa el método de Karpathy”), 9 de junio de 2026
• Boris Cherny, hilo sobre cómo obtener grandes resultados con Claude Code, enero de 2026