Uno de los cambios más grandes que tuve con respecto a mi forma tradicional de programar es que ahora paso mucho tiempo en fase de planning. Antes no era necesario, con un poco de idea de qué tenía que hacer y las intuiciones que desarrollé sobre arquitectura y requerimientos durante los años, podía planear un poco y lanzarme a programar e ir resolviendo problemas poco a poco.

Los LLMs necesitan de la mayor claridad posible antes de ponerse a trabajar, esto hace que pase mucho más tiempo a priori definiendo qué se va a hacer. Dependiendo del tamaño o complejidad de la tarea, tengo tres modos de planear.

Oneshot

Para cosas muy simples ("cambiale el color a esto"), directamente se lo pido a Claude y listo. Intento ser lo más claro posible dentro de un prompt único y ya.

Suelo hace one shots sobre todo con cosas de mantenimiento, por ejemplo hacer rebase, pedirle que saque algunos warnings que aparecen en los logs y cosas por el estilo, también cuando quiero hacer cambios mínimos en algo que ya está funcionando, instalar alguna dependencia, etc.

Más allá de algo que se pueda determinar en una oración, se necesita más infraestructura, porque sino Claude Code (u otro agente), no tiene suficiente claridad y puede hacer cualquier cosa.

Plan Mode

Para tareas intermedias uso el Plan Mode de Claude Code. El truco que encontré para lograr un workflow de definición de requerimientos eficiente es decirle:

"Ask me questions, one by one, start with the first one."

Esto hace que Claude me pregunte una cosa a la vez en lugar de tirarme un bloque de preguntas. Es mucho más natural y me permite responder en forma concreta sin tener que andar cuidándome de mandar el mensaje en lugar de hacer una nueva línea.

Cada cambio de modelo me sorprende más el nivel de detalle de las preguntas, y cómo estas conversaciones a menudo me llevan a arquitecturas que son mejores que las que venía pensando.

Muchas veces hace preguntas para las que no tengo una respuesta concreta, y le pido que investigue y me de sugerencias, esto funciona súper bien.

Eventualmente, las respuestas se consolidan en el plan que genera Claude Code, y después lo ejecuta.

A veces, si quiero conservar la discusión porque estuvo buena, le pido que me cree un archivo markdown en docs con todas las preguntas y las respuestas que dí.

Speckit para tareas complejas

Para cosas más complejas hago varias sesiones de preguntas y las voy escribiendo en un documento SPEC.md. Después utilizo este documento para alimentar Speckit.

Speckit tiene un workflow completo de generación de documentos de especificación: specify → clarify → plan → tasks → analyze. Funciona muy bien para cosas complejas que quiero que queden documentadas en el repositorio.

Una vez que llego al analyze y está todo en orden (leyendo todo y validando que esté bien), hago un commit del spec y creo el PR antes de correr implement. Esto es para tener un checkpoint rápido donde resetear si el implement hace cualquiera y hay que volver a correr clarify.

Cuando durante el implement veo que el spec no era lo suficientemente específico y Claude hace cualquier cosa, hago un revert y paso por otro loop de clarify. Si sólo se desvía un poco, le pido que lo arregle y repare el spec para que coincida.

Antes solía hacer ADRs¹ (también pidiéndole a Claude Code que los escriba), pero ahora estoy quedándome más con el uso de specs como especificaciones ejecutables más que llenar el repo de documentación de arquitectura, total puedo referenciar las specs como fuente de verdad sobre la arquitectura.

Decidir qué modo usar

No se si tengo una heurística muy definida de cuándo usar cada modo, calculo que tengo un sentido desarrollado durante los años del tamaño relativo de una tarea.

Para mvps muy chicos uso plan mode, pero si quiero hacer una app un poco más compleja de un saque, uso speckit, y para proyectos grandes depende del tamaño de la tarea y si pienso que en el futuro tener el spec me va a ser útil.

Markdown como interfaz principal

Algo que descubrí es que los archivos markdown son la mejor interfaz para interactuar con Claude Code.

Por ejemplo, le digo a Claude que me explique cómo funciona tal o cual parte del código. Si estoy satisfecho con esa descripción, la guardo en un archivo en docs/ o como CLAUDE.md en el directorio que contiene el feature. Después puedo referenciarla sin necesidad de pasar por toda la investigación de nuevo.

Es como cachear conocimiento. El agente investiga, documenta, y después puedo referenciar esa documentación en futuras conversaciones.

Los agentes de code review también generan reportes en markdown que después puedo referenciar. Todo termina siendo archivos de texto que puedo versionar, buscar y reutilizar.

Lo que viene

Con las especificaciones definidas, el siguiente paso es ejecutar. Pero Claude Code no es un único agente monolítico: es un sistema extensible con agentes especializados, skills que podés invocar, y comandos que automatizan tareas repetitivas.

En el próximo post voy a contar cómo uso los diferentes agentes de Claude Code, cómo creo mis propios skills, y cómo automatizo tareas con comandos personalizados.

---