Durante bastante tiempo pensé que planificar era el paso que se hacía cuando ya no quedaban ganas de programar. Abrir el editor y empezar a escribir código se siente como avanzar; abrir un documento y escribir qué se va a hacer se siente como retrasar el momento de avanzar de verdad. Con el tiempo he cambiado de opinión, no por convicción teórica, sino por la cantidad de trabajo que he tenido que rehacer cuando me he saltado ese paso.

La sensación de avance frente al avance real

Escribir código da una sensación inmediata de progreso: hay líneas nuevas, hay una pantalla que antes no existía y ahora sí. Esa sensación es real, pero no siempre corresponde con progreso hacia el objetivo correcto. He empezado más de una función sin tener claro del todo qué casos debía cubrir, y a mitad de camino me he dado cuenta de que la estructura que había elegido no encajaba con un caso que había pasado por alto. En ese punto, seguir programando no es avanzar, es acumular trabajo que habrá que deshacer.

Planificar antes no elimina la incertidumbre, pero reduce mucho la probabilidad de descubrir ese tipo de sorpresas a mitad de la implementación, cuando ya hay código construido encima de una base equivocada.

Qué significa planificar, en la práctica

No hablo de documentos largos ni de diagramas exhaustivos. Para la mayoría de cambios, planificar significa responder por escrito, antes de tocar el código, a un puñado de preguntas concretas: qué problema exacto resuelve este cambio, qué partes del sistema toca, qué casos límite existen, y cómo voy a saber que el resultado es correcto. Si puedo responder a esas cuatro preguntas en pocos minutos, la planificación ya ha cumplido su función, aunque nunca llegue a ser un documento formal.

Para cambios más grandes —los que tocan varias pantallas o varias partes del backend a la vez— sí merece la pena algo más estructurado, del tipo de un pequeño registro de decisión que explique por qué se elige un enfoque y qué alternativas se descartaron. No por burocracia, sino porque dentro de unos meses no voy a recordar por qué descarté la opción evidente, y esa memoria escrita ahorra tener que volver a pensarlo desde cero.

Ejemplo práctico

Antes de empezar a programar la separación entre coordenada privada y coordenada de presentación que uso en el mapa de pesca, dediqué un rato a escribir, sin código todavía, cómo se calcularía esa representación pública, qué endpoints la necesitarían y qué pasaría con los puntos que ya existían en la base de datos con el modelo anterior. Ese ejercicio, que no llevó más de media hora, me hizo ver que necesitaba una migración de datos antes de tocar el código de la API, un paso que probablemente habría descubierto a mitad de la implementación si hubiera empezado directamente por el endpoint.

Media hora de planificación evitó reescribir una parte del trabajo que, sin ese paso previo, habría hecho en el orden equivocado.

Cuándo la planificación deja de ayudar

Planificar tiene un límite claro: en algún punto, la única forma de saber si un enfoque funciona de verdad es probarlo con código real. Alargar la fase de planificación para intentar prever cada detalle antes de escribir una sola línea es tan improductivo como saltársela por completo. Para tareas pequeñas y bien entendidas, la planificación puede consistir literalmente en una frase mental antes de empezar; forzar un proceso más pesado ahí solo añade fricción sin beneficio.

Cómo dejo constancia de lo planificado

Una planificación que solo existe en la cabeza tiene la misma fragilidad que cualquier decisión no escrita: se olvida, se distorsiona con el tiempo, o simplemente no está disponible para revisarla cuando hace falta. Para cambios de cierto tamaño, dejo un registro corto de la decisión tomada y de las alternativas que descarté, con el motivo del descarte en una frase. No necesita formato elaborado; un archivo de texto sencillo cumple la función.

Ese registro se vuelve especialmente útil cuando, meses después, alguien —incluido yo mismo— se pregunta por qué el sistema funciona de una manera y no de otra manera que parece igual de razonable a primera vista. Sin esa nota, la respuesta honesta sería "no me acuerdo"; con ella, la respuesta está a un archivo de distancia.

Errores que he cometido con esto

El más frecuente ha sido planificar de más en tareas pequeñas y de menos en tareas grandes, justo al revés de lo que convenía. También he caído en escribir un plan y no volver a mirarlo mientras programaba, lo que anula buena parte de su utilidad: el valor de un plan no está solo en escribirlo, está en usarlo como referencia mientras se avanza y corregirlo si la realidad del código lo contradice.

Conclusión

Nada de esto significa que la planificación deba ocupar más tiempo que la propia implementación, ni que haya que tener todas las respuestas antes de escribir la primera línea. Significa simplemente adelantar las preguntas que, si no se responden antes, se van a responder de todos modos durante la implementación, solo que entonces con código ya escrito de por medio y con más presión para llegar a una respuesta rápida en lugar de una respuesta buena.

Planificar antes de programar no es un paso burocrático ni una forma de posponer el trabajo real. Es, en la mayoría de los casos, la forma más barata de descubrir pronto un problema que de otro modo aparecería más caro y más tarde. Esta misma disciplina es la que aplico, ya con la herramienta abierta, al escribir instrucciones claras en Cursor, como cuento en qué debe incluir un buen prompt para Cursor IDE.