Cómo programo con IA: mi flujo real con Claude Code

Programo con IA todos los días. No como ayuda puntual: como parte del flujo.

Aquí está cómo lo hago de verdad, con lo que funciona y lo que me ha salido mal.

Lo primero: escribir el contexto una vez

El error más caro que cometí al principio fue explicar el proyecto de nuevo en cada conversación.

Ahora cada repositorio mío tiene un fichero CLAUDE.md en la raíz. Es un documento que el modelo lee al empezar y que contiene lo que un desarrollador nuevo necesitaría en su primer día:

• Los comandos. Cómo se arranca, cómo se compila, cómo se comprueba.
• La arquitectura. Qué hay en cada carpeta y por qué.
• Las decisiones que no se tocan. En mi web, por ejemplo, hay una regla que dice que siempre se navega con el Link que respeta el idioma, nunca con un enlace normal. Eso arregló un fallo de SEO que ya había cometido una vez.
• Las trampas. Cosas que parecen bien y rompen el build.

El fichero de mi web personal ocupa unas dos páginas. Cuesta media hora escribirlo bien. Se amortiza en la segunda sesión.

Lo importante no es que sea largo. Es que contenga lo que no se deduce leyendo el código.

Cómo encargo el trabajo

Un encargo mal hecho da código que compila y no sirve. Un encargo bien hecho es la mitad del trabajo.

Yo lo hago en tres partes.

Qué quiero conseguir, en resultado, no en pasos. "Quiero que la ficha de proyecto muestre la galería en móvil sin cargar las imágenes grandes" es mejor que "añade un componente de galería".

Dónde vive eso, en ficheros concretos. Si le digo dónde mirar, no se inventa una estructura paralela.

Qué no puede romper. Aquí es donde más gano. "No cambies el marcado del h1", "no añadas dependencias nuevas", "esto tiene que seguir generándose de forma estática en los cuatro idiomas".

Esa tercera parte es la que casi nadie escribe. Es la que evita el 80% de los desastres.

Lo que le doy y lo que no

Después de un año largo haciendo esto tengo una división bastante clara.

Se lo doy entero:

• Traducir un componente a otro idioma o adaptar textos a cuatro locales.
• Cambios repetitivos en muchos ficheros. Renombrar, migrar una API, aplicar un patrón nuevo en veinte sitios.
• Escribir la primera versión de algo que ya he hecho antes: un formulario, una tabla con filtros, un endpoint CRUD.
• Leer código ajeno y explicármelo. Aquí es donde más tiempo me ahorra y menos riesgo hay.
• Tests y comprobaciones que yo escribiría con desgana.

No se lo doy:

• Decidir la arquitectura de datos. Cómo se aísla la información de una empresa de la de otra en Savia lo decidí yo, en papel, antes de escribir una línea.
• Nada que toque seguridad o permisos sin que yo lo revise línea a línea.
• La parte del diseño donde hay criterio. Un modelo te da una interfaz correcta. La diferencia entre correcta y buena la sigues poniendo tú.

La regla que uso: si no sabría revisar el resultado, no lo delego. La IA no es un sustituto de entender lo que estás haciendo. Es un multiplicador de lo que ya entiendes.

El build es el juez

Esta parte la considero la más importante de todo el artículo.

Mi web no tiene tests. Tiene algo que en la práctica funciona igual de bien: el comando de compilación genera de forma estática todas las páginas en los cuatro idiomas. Si falta una traducción, si un JSON está mal cerrado, si una ruta no existe, el build falla.

Así que la instrucción permanente es: no me digas que está hecho hasta que el build pase.

Esto cambia el trabajo por completo. Sin una comprobación automática, revisar el código generado te cuesta más que haberlo escrito. Con ella, tú miras el resultado y la máquina se encarga de lo mecánico.

Escribir se abarató. Comprobar no. Y ahora hay mucho más que comprobar.

Por eso, cuando empiezo un proyecto nuevo, lo primero que monto es la forma de verificarlo. Antes que la primera funcionalidad.

Ir por partes

Un encargo grande da resultados malos. Divido siempre.

Un ejemplo real, la sección de blog de esta misma web:

1. Leer los ficheros de contenido y sacar sus metadatos. Comprobar que salen los ocho artículos.
2. La página de listado, sin diseño fino. Comprobar que se ve.
3. La página de artículo con el markdown renderizado.
4. Metadatos, canonical y hreflang. Comprobar en el HTML generado.
5. Sitemap y datos estructurados.
6. Diseño.

Cada paso se revisa antes del siguiente. Si el paso 3 salió torcido, lo arreglo ahí. No después de haber montado seis capas encima.

Cuando algo se tuerce mucho, prefiero empezar la conversación de cero con el contexto corregido antes que discutir. Insistir sobre una conversación larga que ya fue por mal camino casi nunca sale barato.

Lo que me ha salido mal

Por si sirve de aviso.

Aceptar código que no entendía. Compilaba, hacía lo que le pedí, y dos semanas después no sabía por qué estaba escrito así. Ahora, si no puedo explicar por qué funciona, lo reescribo hasta poder.

Dejar que reorganizara carpetas por su cuenta. Un cambio que pedí en un componente acabó tocando ocho ficheros. Todo correcto. Ninguno de esos ocho era el que yo quería tocar. Desde entonces acoto el alcance por escrito.

Confiar en dependencias sugeridas. Un paquete que resuelve el problema puede estar sin mantener desde hace tres años. Eso lo miro yo, siempre.

Lo que ha cambiado de verdad

No es que escriba más código. Es que llego a acabar cosas que antes dejaba a medias.

El trabajo aburrido tiene un coste mayor que el tiempo que ocupa: es el que hace que dejes proyectos sin terminar. Cuando esa parte deja de doler, terminas más.

La otra cosa que ha cambiado es qué me diferencia. Escribir el código ya no es lo escaso. Saber qué hay que construir, para quién y por qué, sí.

Antes de sustituir profesiones, la IA está sustituyendo tareas. Merece la pena saber cuáles son las tuyas.