Hace unos meses cambié la forma en que trabajo con Claude Code, y me costó admitir por qué. Durante mucho tiempo le mandaba prompts sueltos, uno tras otro, corrigiendo a mano lo que salía mal. Para cosas chicas funcionaba. Para un módulo de verdad, terminaba peleando contra el código que el propio asistente había escrito.
Lo que me ordenó la cabeza fue una idea sencilla que Andrej Karpathy puso en circulación a inicios de 2026. Karpathy es la persona que acuñó el término «vibe coding» un año antes, así que cuando él mismo dijo que esa etapa estaba quedando atrás, valía la pena escuchar.
Lo que Karpathy notó
En enero de 2026 Karpathy contó en X que su forma de programar había dado un vuelco en pocas semanas. Pasó de escribir el 80% del código a mano a dejar que los agentes escribieran el 80%, y él se quedaba con las correcciones. Lo describió como el cambio más grande en su manera de trabajar en dos décadas.
Pero no lo vendió como un milagro. Junto al entusiasmo, hizo una lista de las maneras en que estos asistentes fallan cuando programan. Son fallas que cualquiera que haya usado Claude Code más de una semana reconoce de inmediato:
El asistente asume cosas por su cuenta y sigue adelante sin avisar. No muestra sus dudas, no señala contradicciones, no propone alternativas ni te dice cuándo cree que te equivocas. Le pides un arreglo pequeño y construye una abstracción «por si en el futuro la necesitas». Toca código y comentarios que no tienen nada que ver con la tarea, a veces porque no los entiende y decide cambiarlos igual.
Un desarrollador llamado Forrest Chang leyó esas observaciones y las convirtió en un archivo de reglas, un CLAUDE.md, que se volvió uno de los repositorios más marcados en la historia de GitHub. Pasó de unos cuantos miles de estrellas a más de cien mil en cosa de meses. No por novedoso, sino porque le puso nombre a una frustración que todos teníamos.
El cambio no es de herramienta, es de rol
Aquí está lo que de verdad importa. El problema no era Claude Code. Era yo tratándolo como una máquina expendedora de código: meto un prompt, sale una función, meto otro, sale otra. Así nunca se hace responsable de un resultado, porque nunca le di un resultado que cumplir.
El método de Karpathy invierte eso. En lugar de decirle los pasos, le defines la meta y dejas que él itere hasta cumplirla. Los modelos son muy buenos repitiendo intentos hasta que se cumple una condición. Esa es justo la parte donde brillan, y es la que yo estaba desaprovechando al darle órdenes de a una.
El trabajo, entonces, deja de ser teclear y pasa a ser dirigir. Uno se vuelve algo más parecido a un líder técnico que revisa a un programador junior muy rápido: hay que explicarle bien el objetivo, decirle qué no haga, y revisar lo que entrega.
Eso se traduce en dos hábitos concretos.
El primero es escribir un CLAUDE.md en la raíz del proyecto. Claude Code lo lee al empezar cada sesión y lo usa como contexto. Funciona como un instructivo permanente de cómo debe comportarse, y lo mejor es que vive junto a tu código y lo comparte todo el equipo. Conviene que sea corto. Hay un límite práctico de instrucciones que el modelo alcanza a respetar, y si el archivo es muy largo, empieza a ignorar la mitad.
El segundo hábito es escribir prompts por objetivo, no por pasos. En lugar de «haz esto, luego esto», le dices qué cuenta como terminado y lo dejas trabajar.
Aquí va un CLAUDE.md base que uso, adaptado a mi stack. Los cuatro bloques salen directo de las observaciones de Karpathy:
# Reglas del proyecto
## Antes de programar
- Declara tus supuestos antes de escribir código. Si hay más de una
interpretación válida, muéstralas y pregúntame.
- Si algo no está claro, detente y pregunta. No rellenes huecos por tu cuenta.
## Simplicidad
- No agregues funciones, configuraciones ni abstracciones que no te pedí.
- Resuelve lo que se pidió y nada más.
## Cambios quirúrgicos
- Toca solo los archivos necesarios para la tarea.
- No reescribas ni borres código o comentarios que no entiendas.
## Objetivo
- Antes de empezar, escribe en una línea el criterio de éxito.
- Itera hasta cumplirlo. Corre las pruebas y enséñame el resultado.
## Stack
- Frontend: React + Vite + TypeScript. Mobile first, responsive, minimalista.
- Backend: Laravel 12 / PHP, MySQL (SQLite en local).
Tres ejemplos con sus prompts
Lo más fácil para ver la diferencia es comparar el prompt suelto de antes con el prompt por objetivo. Pongo tres casos del tipo de trabajo que hago, aplicaciones web y SaaS.
1. Una exportación en un panel administrativo
El prompt de la vieja escuela sería algo así: «hazme un export a Excel de la tabla de facturas». Suena claro, pero deja fuera todo lo que importa. ¿Exporta todo o solo lo filtrado? ¿Qué pasa si no hay filas?
El prompt por objetivo:
Objetivo: que un usuario pueda exportar a Excel la tabla de facturas que ya tiene filtrada en pantalla. Criterio de éxito: el archivo descargado contiene exactamente las filas visibles tras aplicar los filtros de fecha y empresa, con las mismas columnas y en el mismo orden; si no hay filas, no se descarga nada y se muestra un aviso. Antes de tocar código, dime qué supuestos vas a hacer sobre la librería de exportación y dónde vive ahora la lógica de filtros. No agregues opciones de formato que no pedí. Cuando termines, corre la app, prueba con un filtro por empresa y enséñame las filas resultantes.
La diferencia está en que le di un criterio que se puede verificar, le pedí que declarara sus supuestos antes de empezar, y le cerré la puerta a la sobreingeniería.
2. Una sección de precios mobile first
Objetivo: una sección de precios con tres planes para la landing, pensada primero para móvil. Criterio de éxito: se ve bien desde 320px hacia arriba sin scroll horizontal, los planes se apilan en móvil y pasan a fila desde 768px, y el botón de cada plan se alcanza con el pulgar (mínimo 44px de alto). Usa solo los tokens de color y tipografía que ya están en el proyecto, no inventes nuevos. Antes de empezar, revisa el componente de tarjetas que ya existe y dime si lo vas a reutilizar o por qué no. Muéstrame capturas en 320, 768 y 1024.
Pedirle que revise lo que ya existe antes de crear algo nuevo evita que duplique componentes. Es la regla de cambios quirúrgicos aplicada al frontend.
3. Un endpoint con validación en Laravel
Objetivo: un endpoint que reciba el registro de un cliente nuevo y lo guarde validando los datos. Criterio de éxito: rechaza con 422 y mensajes claros si falta el nombre, si el correo no es válido o si el correo ya existe; guarda y devuelve 201 con el id cuando todo está bien. Toca solo el controlador y el request de validación, no modifiques migraciones ni otros modelos. Si crees que hace falta un cambio fuera de eso, detente y pregúntame primero. Escribe una prueba que cubra el caso del correo duplicado y córrela.
Aquí lo importante es la frase «si crees que hace falta un cambio fuera de eso, detente y pregúntame». Es la red de seguridad contra el asistente que se entusiasma y empieza a tocar la base de datos sin avisar.
Lo que sigue sin hacer solo
No quiero pintar esto como que ahora el código se escribe solo mientras uno toma café. No.
El asistente todavía te dice que algo está «listo» porque existe el cambio, no porque el comportamiento funcione. Por eso entre cada paso tiene que haber una revisión humana de verdad, no un vistazo rápido. La validación de los resultados sigue siendo trabajo tuyo. Si no tienes pruebas, estás adivinando.
Hay además un punto de seguridad que conviene tener presente: un CLAUDE.md que venga dentro de un repositorio ajeno puede traer instrucciones maliciosas. Si vas a usar las reglas de Karpathy, bájalas de los repositorios oficiales y no de copias sueltas.
La versión más reciente de Claude Code ya trae herramientas pensadas para este estilo de trabajo, como un comando que revisa con un segundo modelo si de verdad se cumplió el objetivo antes de dar algo por terminado. La dirección es clara: menos prompts sueltos, más objetivos bien definidos y más verificación.
Llevo unos meses trabajando así y todavía estoy buscando dónde queda la línea entre delegar y soltar el control. Lo que sí tengo claro es que el día que dejé de pedirle cosas a Claude Code y empecé a decirle qué cuenta como terminado, mi código mejoró y mi frustración bajó. El resto lo sigo afinando proyecto a proyecto.