Claude Code y Codex son agentes, no chats. La diferencia no es de marketing: un chat te devuelve texto que tú pegas; un agente abre tu proyecto, lee los ficheros, escribe, ejecuta las pruebas y vuelve a escribir. Trabaja solo durante minutos.
Qué se le da bien y qué no, midiendo
| Encargo | Cómo sale |
|---|---|
| «Añade un campo al formulario y guárdalo» | Muy bien. Es lo que mejor hace: copiar un patrón que ya existe en tu proyecto y repetirlo bien. |
| «Traduce esta página al inglés» | Bien, y se deja cosas. Los textos salen; lo que se cae es un botón, un identificador o el bloque que no se ve. |
| «Arregla este error» con el error pegado | Muy bien si le pasas el mensaje entero. Con «no funciona» a secas, adivina. |
| «Móntame la web de la farmacia» | Mal. Devuelve algo que parece una web y que hay que rehacer entero, porque no ha decidido nada contigo. |
| «¿Está bien esto?» | Mal. Tiende a decir que sí. Pregúntale qué falla, no si está bien. |
Claude Code o Codex: qué cambia de verdad
Los dos hacen lo mismo y los dos son buenos. Comparar versiones concretas no sirve —lo que hoy hace uno mejor lo hace el otro en tres meses— así que lo útil es saber en qué se parecen, que es en casi todo: los dos se instalan en tu máquina, trabajan dentro de tu carpeta, leen y escriben ficheros, ejecutan comandos y te enseñan lo que han cambiado antes de guardarlo.
Lo que sí conviene mirar al elegir, y no caduca: en qué suscripción entra (es probable que ya pagues una de las dos), si te deja trabajar en tu editor o en la terminal según cómo trabajes, y si puedes dejarle un fichero de instrucciones del proyecto que lea siempre. Lo tercero es lo que más rinde a medio plazo y casi nadie lo usa.
El método: cuatro reglas
-
Una cosa por encargo
«Añade el campo, cambia los colores y arregla el móvil» sale mal en las tres. Y hay una razón que no es de calidad: cuando algo se rompe, con tres cambios juntos no sabes cuál fue. Con uno, sí.
Regla práctica: si el encargo lleva un «y», pártelo.
-
Dile qué hay, no sólo qué quieres
El agente ve los ficheros, pero no sabe qué es importante. «Esta página la usan desde el móvil», «estos datos son de pacientes», «esto ya lo intenté y falló porque…» cambian por completo lo que escribe.
Es la misma pieza que la lección 1 del Nivel 2 llama contexto, y sigue siendo la que más rinde.
-
Pídele que lo compruebe, y mira CÓMO lo comprueba
«Escribe una prueba» es buen encargo. Pero una prueba escrita por quien escribió el código tiene un sesgo evidente, y se manifiesta de una forma muy concreta: comprueba que la función existe, no que acierte.
Eso pasa de verdad y es difícil de ver. En esta web hubo una función de detección que devolvía «falso» SIEMPRE por un fallo de una línea: toda llamada correcta se registraba como error durante semanas. Su prueba estaba en verde — comprobaba que la función estuviera escrita. La regla que salió de ahí: para código que sólo se puede equivocar al ejecutarse, una prueba que lee el fichero no vale. Tiene que ejecutarlo con una entrada y mirar la salida. -
Lee el diff antes de publicar
No el código entero: el diff, que es sólo lo que cambia. Es la única parte del método que no se puede saltar, y normalmente son treinta líneas.
Qué buscas, en este orden:
- Ficheros que no esperabas. Es la señal número uno de que ha «arreglado» algo de camino.
- Borrados. Una línea que desaparece no llama la atención y es lo que más rompe.
- Claves, URLs y correos escritos dentro del código.
- Cifras. Si aparece un número que tú no diste, salió de su memoria — y esta web ya tuvo un céntimo de diferencia repartido por 32 ficheros.
Cinco trampas que no se ven leyendo el código
| Lo que parece | Lo que pasa |
|---|---|
| «Está desplegado, luego se ve» | No. Puede estar publicado y servirse la copia vieja desde una caché, o estar en una pestaña que nadie abre. Ábrelo en el navegador antes de darlo por hecho. |
| «El comentario dice que lo comprueba» | El comentario dice lo que se pretendía. Aquí hubo un endpoint cuyo comentario decía que el servidor validaba el cupo — y no lo validaba nadie. Comprueba el código, no lo que dice de sí mismo. |
| «No dio ningún error» | Los peores fallos no dan error: devuelven un valor plausible. Un borrado que no borra, una traducción que se deja un botón, una cifra que se rellena sola. |
| «Lo he probado y va» | ¿A qué ancho? Casi todo lo de maquetación se rompe a 390 px y se ve perfecto en el portátil donde lo escribiste. |
| «Deshago el cambio» | Un comando que revierte «todo» se lleva por delante lo que no habías guardado. Commitea antes de probar nada raro. |
Qué NO delegar
El fichero que cambia el resultado más que ningún prompt
Un agente de código abre tu proyecto sin saber nada de él. Cada sesión empieza de cero: no recuerda la anterior, no sabe por qué tomasteis una decisión hace tres meses y no sabe qué cosas están prohibidas aquí. Y como no lo sabe, se lo inventa razonablemente — que es la peor forma de equivocarse, porque el resultado parece correcto.
CLAUDE.md, AGENTS.md, según la herramienta) que el agente lee
antes de cada encargo. Es lo que convierte «una IA que escribe código» en «alguien
que conoce este proyecto». Y es, con diferencia, la inversión de una hora que más rinde de
toda esta lección.
# Qué es este proyecto
Web de una farmacia. HTML, CSS y JavaScript sin frameworks, a proposito.
Se despliega en Vercel desde la rama main. Los datos estan en Supabase.
# Reglas que NO se saltan
- Nada de datos de pacientes en el codigo ni en el repositorio.
- Toda tabla nueva lleva RLS y sus CUATRO politicas.
- Las claves van en variables de entorno. Nunca en un fichero del repo.
- El calculo va en /calculos/*.js y no toca el DOM.
# Como se trabaja aqui
- Una rama por cambio. Nunca directo a main.
- Antes de dar algo por hecho: `npm test`.
- Los textos van en espanol, y en ingles solo si existe la pagina /en/.
# Errores que ya hemos cometido (no repetir)
- El borrado de Supabase devuelve exito sin borrar si falta la politica
FOR DELETE. Hay que pedir `.select('id')` y comprobar que vuelve algo.
- Una hoja de estilos cacheada tapaba un arreglo: al tocar el CSS
compartido hay que subir la version del service worker.Cómo se escribe un encargo que sale bien a la primera
Un encargo a un agente de código tiene cuatro partes, y la que casi todo el mundo se deja es la cuarta:
| Parte | Qué es | Si falta |
|---|---|---|
| 1. Qué | El cambio, en una frase | No hay encargo |
| 2. Dónde | El fichero o la zona | Se pone a buscar y toca cosas que no venían al caso |
| 3. Cómo se comprueba | Qué tiene que pasar para darlo por bueno | Te devuelve algo plausible y lo pruebas tú a mano |
| 4. Qué NO toque | Los límites | Refactoriza de paso, y el cambio de dos líneas llega con cuarenta |
// ❌ Lo que sale a la primera
"arregla el formulario de contacto que no va"
// ✅ Lo que ahorra tres vueltas
"En contacto.html el formulario no envia nada: la consola dice 404 al
llamar a /api/contacto. Averigua por que y arreglalo.
Como se comprueba: al enviar con datos validos tiene que aparecer el
mensaje de exito, y con el correo vacio tiene que decirlo antes de
enviar.
No toques el diseno ni el resto de paginas. Si hace falta cambiar algo
fuera de contacto.html o de la funcion, PARA y dime que hace falta."El ciclo de trabajo, y por qué el tamaño del paso lo decide todo
-
Pide un plan antes del código
«Antes de tocar nada, dime qué vas a cambiar y en qué ficheros.» Leer cinco líneas de plan cuesta veinte segundos y te deja corregir el rumbo antes de que haya nada escrito. Es el punto del ciclo donde una frase tuya vale por media hora.
-
Un cambio, un commit
En cuanto algo funciona, se guarda. No al final de la tarde: en cuanto funciona. Así siempre hay un punto bueno al que volver, y volver cuesta un comando en vez de una reconstrucción.
-
Compruébalo tú, siempre
«Ya está arreglado» es una afirmación del agente, no un hecho. Ábrelo en el navegador. Es el paso que más se salta y el que más caro sale: un agente que da por bueno algo que no ha ejecutado no está mintiendo — es que no lo ha mirado.
-
Si va por mal camino, vuelve atrás y reescribe el encargo
No lo corrijas cinco veces seguidas. Cada corrección se apila sobre un malentendido anterior y el resultado acaba siendo un remiendo de remiendos. Descartar y volver a empezar con un encargo mejor es más rápido casi siempre, y siempre sale más limpio.
Revisar un cambio sin saber programar
Esto parece imposible y no lo es. No se trata de entender cada línea: se trata de mirar cinco cosas concretas que se ven sin saber leer código.
| Qué miras | Qué estás buscando |
|---|---|
| Cuántos ficheros toca | ¿Pediste un cambio y ha tocado nueve? Pregunta por qué antes de seguir |
| Si aparece algo que parece una clave | Una cadena larga y rara entre comillas. Nunca. Va en variable de entorno |
| Si hay líneas rojas (borradas) que no esperabas | Borrar es lo único que no se deshace solo. Pregunta por cada bloque rojo que no entiendas |
| Si ha tocado el fichero de dependencias | Ha metido una librería de un tercero. ¿Hacía falta? Casi nunca |
| Si hay una URL nueva | Ábrela. Un enlace inventado tiene exactamente el mismo aspecto que uno bueno (es el fallo que más se repite) |
Cuando se atasca: las tres salidas, por orden
-
Dale el error EXACTO, copiado
No «da error»: el texto entero, con el número de línea si lo hay. La mitad de los atascos se resuelven así, y el otro «sigue sin ir» es la frase que más vueltas gasta sin aportar nada.
-
Pídele que añada trazas y lo ejecute
«Mete
console.logdonde haga falta para ver qué llega, ejecútalo y dime qué sale.» Le obliga a mirar el comportamiento real en vez de razonar sobre el código — que es exactamente lo que hace un programador cuando se atasca. -
Descarta y reescribe el encargo
Si van tres vueltas sin avance, el problema no es el código: es que el encargo no dice lo que hace falta.
git checkout HEAD -- .— con un commit reciente detrás — y vuelta a empezar con lo que has aprendido.
Lo que NO se le pide a un agente de código
| No se le pide | Por qué |
|---|---|
| «Mejora el proyecto» | Sin un objetivo, «mejorar» es reescribir. Vas a recibir cambios en sitios que funcionaban |
| «Aplica esta migración en la base de datos» | Escribir el SQL, sí. Ejecutarlo contra datos reales, no: no hay deshacer |
| «Sube esto a producción» | Publicar es una decisión, no una tarea. Y es gratis reservártela |
| «Métele tests a todo» | Salen cien pruebas que comprueban que el código hace lo que hace. No detectan nada |
| «Actualiza las dependencias» | Es el cambio que más cosas rompe y el que menos se entiende al revisarlo |
Antes de dar esto por aprendido
- Parto el encargo en cuanto lleva un «y».
- Le cuento el contexto, no sólo lo que quiero.
- Miro si la prueba EJECUTA el código o sólo comprueba que exista.
- Leo el diff buscando ficheros inesperados, borrados, claves y cifras.
- Lo abro en el navegador —y a 390 px— antes de darlo por hecho.
- Tengo un fichero de instrucciones del proyecto y apunto ahí cada error.
← Anterior: montar el stack Siguiente: Analytics y Search Console →