Me encanta esto del agentic coding (programación agéntica). Es muy atractivo en muchos sentidos.

Desde que escribí aquella entrada original del blog han pasado un montón de cosas en el mundo de Claude:

• Claude Code
• MCP
• etc

He recibido cientos (wat) de correos de gente contándome sus flujos de trabajo y cómo han usado el mío para sacar provecho. He impartido charlas en varias conferencias y dado algunas clases sobre codegen. También he descubierto que los ordenadores se empeñan en corregir “codegen” a “codeine”. ¡Quién lo diría!

El otro día hablaba con una amiga sobre cómo estamos totalmente jodidos y la IA nos va a quitar el curro (ya hablaré de eso en otra entrada). Ella me dijo: «Deberías escribir un post sobre Claude Code».

Aquí vamos.

Claude Code salió ocho días después de que publicara mi entrada original sobre el flujo de trabajo y, como predije, dejó gran parte de ella obsoleta. Desde entonces migré de Aider a Claude Code y no he vuelto a mirar atrás. Sigo apreciando Aider —tiene su momento— pero Claude Code me resulta bastante más útil ahora mismo.

Claude Code es potentísimo y carísimo.

Mi flujo de trabajo sigue siendo casi el mismo de antes:

• Charlo con gpt-4o para afinar la idea.
• Uso el mejor modelo de razonamiento que encuentre para generar la spec. Hoy es o1-pro o o3 (¿es o1-pro mejor que o3 o solo me lo parece porque tarda más?).
• Con ese modelo genero los prompts. Usar un LLM para crear prompts es un truco precioso. También hace que los boomers se enfaden.
• Guardo spec.md y prompt_plan.md en la raíz del proyecto.
• Después le paso a claude lo siguiente:

1. Open **@prompt_plan.md** and identify any prompts not marked as completed.
2. For each incomplete prompt:
    - Double-check if it's truly unfinished (if uncertain, ask for clarification).
    - If you confirm it's already done, skip it.
    - Otherwise, implement it as described.
    - Make sure the tests pass, and the program builds/runs
    - Commit the changes to your repository with a clear commit message.
    - Update **@prompt_plan.md** to mark this prompt as completed.
3. After you finish each prompt, pause and wait for user review or feedback.
4. Repeat with the next unfinished prompt as directed by the user.

La magia de este prompt es que revisa el prompt_plan.md, busca lo que aún no está marcado como completado y aborda la siguiente tarea pendiente. Hace commit con git, actualiza el plan con lo que ya está listo y, al terminar, se planta para pedirte que continúes. 🤌

Entonces me relajo y me limito a escribir yes mientras claude trabaja. Pide feedback y la magia sucede.
Y muchos más clics de Cookie Clicker.

Esto funciona de lujo. Hay un par de superpoderes que puedes incorporar a tu proceso y que ayudan muchísimo.

Programación defensiva

Pruebas

Las pruebas y el desarrollo guiado por pruebas (TDD) son imprescindibles. Te recomiendo comprometerte de verdad con una práctica sólida de TDD.

Yo odiaba el TDD. Se me daba fatal y sentía que estaba perdiendo el tiempo. Estaba equivocado, lol. Lo reconozco: durante las últimas décadas metimos un montón de pruebas en nuestras empresas y proyectos. La mayoría se añadieron DESPUÉS de terminar el núcleo. Esto está bien para humanos.

ESTO ES MALO PARA LOS ROBOTS.

A los robots les encanta el TDD. En serio, lo devoran.

Con TDD tu colega robot escribe la prueba y el mock; en el siguiente prompt conviertes el mock en código real. Y al robot le chifla. Es el antídoto más efectivo que he encontrado contra las alucinaciones y la deriva de alcance de los LLM. Les ayuda muchísimo a mantenerse enfocados.

Linting

Soy fan del linting. Es una gozada. Ruff es maravilloso, Biome está genial y Clippy es divertido (y el nombre es top).

Por alguna razón los robots disfrutan ejecutando un buen linter.

Tenerlo configurado para que se ejecute todo el rato mantiene muchos bugs a raya y deja el código más mantenible y legible. Ya lo sabes.

Añade un formatter decente y todo queda precioso.

Hooks de pre-commit

La auténtica magia está en meter todas estas tareas en un hook de pre-commit. Recomiendo el paquete de Python pre-commit. Puedes instalarlo con uv tools install pre-commit, crear un archivo .pre-commit-config.yaml chulo y ¡bam! Cada vez que intentes hacer commit correrá pruebas, comprobación de tipos, linting, etc., para asegurarse de que tu código sea A+++ y volvería a aprobar cada vez.

Esto es un truco buenísimo para trabajar con Claude Code. El robot QUIERE hacer commit sí o sí. Así que cuando le pides que escriba código y luego haga commit (como arriba), hará cambios salvajes, hará commit, inevitablemente lo fastidiará todo y luego tendrá que arreglarlo.

Y es fantástico porque no atasca tus GitHub Actions con montones de linting, formato y comprobaciones de tipos que fallan porque el robot estaba de malas.

Algo curioso de claude es que NO PUEDE, ni a tiros, aprender a usar uv correctamente. Si te descuidas hará pip install a lo loco. Y si le ordenas usar uv, se limitará a hacer uv pip install. Igual la AGI no llega en junio… qué pena.

CLAUDE.md y comandos

Son dos añadidos muy simples que permiten sacar muchísimo más partido.

Le tomé prestado un CLAUDE.md a mi colega Jesse Vincent, que se pegó un currazo brutal para dejarlo ultra robusto. Está de lujo. Incluye, por ejemplo:

• una versión ligera de la big daddy rule
• instrucciones sobre cómo hacer TDD
• pautas de estilo sobre mi forma de programar

@clint configuró su CLAUDE.md para que lo llame MR BEEF y ahora toda nuestra documentación suelta perlas de MR BEEF: «If you’re stuck, stop and ask for help—MR BEEF may know best.» Mientras escribía esto, decidí que mi CLAUDE.md me llame “Harp Dog”. Es una feature, no un bug.

Los comandos también son muy prácticos. Puedes ver algunos de los míos en mis dotfiles aquí.

Antes los usaba mucho más, pero siguen siendo una forma estupenda de sacar partido a prompts recurrentes. Además, puedes pasar argumentos. Por ejemplo, en mi comando para issues de GitHub le pasas el número de issue que quieres que claude mire: /user:gh-issue #45

claude ejecutará entonces el prompt definido en el archivo gh-issue.md.

También puedes colocar estos comandos en el directorio del proyecto y crear un CLAUDE.md personalizado ahí. Yo lo hago para tener comandos específicos de Hugo, Rust, Go o JavaScript según el proyecto.

“Continue”

A veces me siento como ese pájaro con la cabeza oscilante que Homer puso a pulsar la tecla “y”: solo escribo “continue” o pulso la flecha arriba y pego el mismo prompt.

La mayoría de los planes tienen entre 8 y 12 pasos. Suelo terminar un desarrollo greenfield (desde cero) en 30–45 min sin importar la complejidad aparente o el lenguaje.

Se lo contaba a mi amigo Bob y no me creía. Le dije: «Nómbrame algo que construir y un lenguaje: ¡veamos!»

Él soltó: «Vale. Un intérprete de BASIC en C».

No era lo ideal. No sé C, tampoco sé realmente escribir un intérprete y, francamente, me da igual. Pero qué rayos.

Seguí los pasos de arriba y Claude Code lo bordó. Tenemos un intérprete de BASIC que funciona. La primera versión estuvo lista en una hora. Luego la pulí un par más y quedó bastante decente. ¿La habría lanzado en 1982? Probablemente no. Puedes ver el prompt_plan.md aquí.

El equipo

Todo nuestro equipo usa ahora Claude Code. Seguimos más o menos el proceso anterior, con bastantes retoques personales.

Estamos logrando una cobertura de pruebas muchísimo mayor que nunca. Tenemos mejor código y parece ser tan eficaz como el código horrible que escribíamos antes. Es divertido pasear la vista y ver Claude Code corriendo en Ghostty, en la terminal de VS Code, en la terminal de Zed y trasteando con notebooks de Python.

Alguien con un montón de tokens, por favor, ayúdame a presupuestar esto. Mi familia se muere.

Gracias

A todas las personas que siguen enviándome correos: es divertidísimo y un placer conocer vuestros flujos de trabajo y proyectos. Lo agradezco un montón. ¡Seguid enviándolos!