Por qué usar IA para planificar antes de programar cambia todo

Cuando algo sale mal en un proyecto de software, la reacción instintiva es culpar al stack: "debí haber usado otro framework", "este lenguaje no escala", "necesito refactorizar todo". Pero en la mayoría de los casos, el problema no vive en el código. Vive antes del código.

El verdadero problema es que empezaste a programar sin un plan claro. Sin saber exactamente qué construyes, por qué lo construyes así, ni cómo las piezas encajan entre sí. Y cuando intentas resolver eso sobre la marcha, mientras ya tienes 30 archivos abiertos y tres ramas sin mergear, es demasiado tarde.

Este artículo explora una idea que está cambiando la forma en que los desarrolladores modernos trabajan: usar inteligencia artificial no para escribir código más rápido, sino para pensar mejor antes de abrir el editor. Verás cómo la planificación asistida por IA puede convertirse en un activo estratégico del proyecto, guardado en archivos Markdown versionables que sirven como documentación, contexto para agentes y base para automatizaciones.

Si programas, usas IA en tu día a día, o simplemente sientes que tus proyectos siempre terminan siendo más caóticos de lo que deberían, esto es para ti.

El problema invisible: programar sin rumbo

Las preguntas que nunca deberías estar haciéndote a mitad del proyecto

Imagina esta escena: llevas tres días programando una feature nueva. Has creado componentes, configurado rutas, conectado APIs. Pero ahora, mirando tu editor, empiezas a hacerte preguntas incómodas:

"¿Esto realmente va aquí o debería estar en otro módulo?"
"¿Y si después tengo que cambiar toda esta lógica?"
"¿Por qué estoy repitiendo el mismo patrón en cinco archivos distintos?"
"¿Por qué siento que avanzo pero no llego a nada concreto?"

Estas preguntas son síntomas de falta de planificación, no de falta de habilidad técnica. Y lo peor: el editor de código no las va a resolver por ti. De hecho, mientras más archivos crees, más visible se vuelve el caos estructural.

El mito del "código primero, planificación después"

Existe una idea romántica en el mundo del desarrollo: el programador solitario que se sienta frente a la pantalla en blanco y, línea a línea, va descubriendo la arquitectura perfecta de forma orgánica. Suena bien en una película, pero en la realidad eso lleva a:

Refactors infinitos: cambias el diseño cada semana porque "ahora sí entendiste cómo debería ser".
Código acoplado: todo depende de todo porque no definiste fronteras claras entre módulos.
Documentación inexistente: si ni tú sabías qué estabas construyendo, ¿cómo lo vas a explicar después?
Burnout silencioso: trabajas muchas horas pero sientes que no avanzas porque no hay una visión clara del resultado final.

El problema no es que no sepas programar. El problema es que estás resolviendo dos problemas a la vez: qué construir y cómo construirlo. Y el cerebro humano no es bueno multitareas en ese nivel de abstracción.

La solución: planificar antes, ejecutar después

Las preguntas que deberías hacerte antes de escribir una sola línea

Antes de abrir tu IDE, antes de crear el primer archivo, responde esto con claridad:

¿Qué voy a construir exactamente?
No "una app", no "un sistema". Describe el resultado final en términos concretos: "una app que permite a usuarios subir archivos, organizarlos en carpetas y compartirlos con permisos granulares".
¿Cuál es el resultado esperado?
¿Qué hace que este proyecto esté "terminado"? ¿Qué features son core y cuáles son nice-to-have?
¿Qué pasos necesito para llegar ahí?
Divide el proyecto en fases lógicas: setup inicial, auth, CRUD básico, features avanzadas, optimización.
¿Qué puede fallar en el camino?
¿Qué dependencias externas tienes? ¿Qué partes del proyecto son riesgosas o desconocidas?
¿Qué herramientas voy a usar?
Stack tecnológico, servicios externos, APIs, librerías clave.

Responder estas preguntas no requiere armar diagramas UML complejos ni escribir documentos de 50 páginas. A veces basta con una lista de pasos que van surgiendo mientras imaginas el proyecto.

Por ejemplo:

Proyecto: Dashboard de analítica para creadores

Features core:
- Login con Google/GitHub
- Dashboard principal con métricas visuales
- Vista de histórico (últimos 30 días)
- Exportar datos a CSV
- Sistema de notificaciones básico

Fases:
1. Setup: Next.js + Supabase + auth
2. Base de datos: schema de users, metrics, exports
3. UI: dashboard con gráficos (recharts)
4. Backend: endpoints para fetch de métricas
5. Features extras: notificaciones, exportación

Riesgos:
- Performance con datasets grandes (>100k rows)
- Rate limits en APIs externas
- Diseño responsive complejo en gráficos

Esto, que te tomó 5 minutos escribir, puede ahorrarte horas de retrabajo más adelante.

Cómo la IA cambia el juego en la fase de planificación

La mayoría usa IA para código, pero su poder está antes del código

Aquí es donde entra la parte interesante. La mayoría de los desarrolladores usa IA (ChatGPT, Claude, Copilot, etc.) para:

Generar boilerplate rápido.
Autocompletar funciones.
Debuggear errores.

Eso está bien, pero es usar un Ferrari solo para ir al supermercado. El verdadero valor de la IA moderna está en su capacidad para ayudarte a pensar antes de codear.

Qué puede hacer la IA en la fase de planificación

1. Dividir un problema grande en pasos pequeños

Le das a la IA una idea general ("quiero un marketplace de freelancers") y ella puede descomponerlo en:

Auth (usuarios y freelancers)
Perfiles públicos
Sistema de propuestas
Chat interno
Pagos (integración con Stripe)
Reviews y ratings
Panel de admin

Esos pasos pueden convertirse directamente en tareas, sprints o módulos de tu proyecto.

2. Detectar huecos o inconsistencias en tu idea

Le describes tu proyecto y la IA puede responder:

"¿Cómo manejas usuarios que quieren ser tanto clientes como freelancers? ¿Consideraste un sistema de verificación de identidad? ¿Qué pasa si un freelancer no entrega a tiempo?"

Preguntas que te ahorran rediseños futuros.

3. Proponer una estructura general del proyecto

Basándose en tu stack, puede sugerirte:

/src
  /app          # Next.js app router
  /components   # React components
  /lib          # Utils y helpers
  /hooks        # Custom hooks
  /services     # API calls
  /types        # TypeScript types
  /styles       # Global styles

Y justificar por qué esa estructura tiene sentido para tu caso de uso.

4. Ayudarte a decidir por dónde empezar

En lugar de quedarte paralizado pensando "¿empiezo por el backend o el frontend?", la IA puede sugerirte un camino crítico:

"Empieza por el auth y la base de datos. Sin usuarios, no puedes testear nada más. Luego el dashboard básico. Después las features secundarias."

El caso de Cursor y el modo "Spec"

De "coding mode" a "spec mode": un cambio de paradigma

Algunos editores modernos como Cursor (basado en VS Code pero con IA nativa) ya están implementando esta filosofía.

Cursor tiene dos modos:

Coding mode: le pides cosas y la IA las va haciendo sin mucho rumbo. Es rápido, pero puede volverse caótico.
Spec mode: primero le pides que arme una planificación exhaustiva, y la IA va creando múltiples archivos Markdown con la estructura del proyecto.

En el spec mode, la IA resuelve:

Qué se va a construir.
Cómo debería funcionar cada parte.
Qué componentes lo forman.
Qué pasos son necesarios y en qué orden.

Una vez que esa "spec" (especificación) está clara, entonces la IA puede generar enormes cantidades de código coherente, porque ya tiene el mapa completo del proyecto.

El resultado no es solo código que funciona, sino un proyecto con dirección desde el inicio.

Markdown: el formato subestimado que lo cambia todo

Por qué Markdown se ha vuelto el estándar de planificación en proyectos con IA

Hay algo curioso pasando en el ecosistema de desarrollo moderno: Markdown dejó de ser solo un formato para READMEs. Ahora es el formato estándar para documentar, planificar y comunicarte con agentes de IA.

¿Por qué Markdown?

Es texto plano: fácil de versionar con Git.
Es legible por humanos y por IA.
Puede convertirse a HTML, PDF, slides, documentación web.
Soporta código embebido, listas, tablas y enlaces.
Es el formato nativo de herramientas como Notion, Obsidian, GitHub.

Cómo convertir tu planificación en un activo del proyecto

Imagina que tienes un archivo SPEC.md en la raíz de tu proyecto que contiene:

# Especificación del Proyecto: TaskFlow

## Objetivo
Aplicación de gestión de tareas con colaboración en tiempo real.

## Stack
- Frontend: React + TypeScript + Vite
- Backend: Node.js + Express + PostgreSQL
- Real-time: Socket.io
- Auth: Clerk

## Arquitectura
- Monorepo con Turborepo
- Separación client/server
- API RESTful + WebSockets

## Features Core
1. Auth (Google, GitHub, email)
2. Workspace (teams, proyectos)
3. Tableros Kanban (drag & drop)
4. Asignación de tareas
5. Notificaciones en tiempo real

## Fases de Desarrollo
### Fase 1: Setup (semana 1)
- Configurar monorepo
- Setup de DB y migraciones
- Auth básico

### Fase 2: CRUD (semana 2-3)
- Crear/editar/eliminar tasks
- Tableros básicos
- UI responsive

### Fase 3: Colaboración (semana 4)
- WebSockets
- Notificaciones
- Asignación múltiple

## Consideraciones
- Offline-first: usar local storage como cache
- Performance: virtualización en listas grandes
- Seguridad: validación de permisos en cada endpoint

Este archivo ahora sirve como:

Documentación del proyecto: cualquier desarrollador nuevo puede leerlo y entender qué se está construyendo.
PRD (Product Requirements Document): los requerimientos están explícitos.
Contexto para IA: cada vez que abres una sesión nueva con tu modelo, le pasas este archivo y ya sabe de qué va el proyecto.
Guía para refactors: cuando decidas cambiar algo, puedes actualizar la spec primero y luego el código.
Base para tareas: puedes conectar este archivo con herramientas como Linear, Jira o Notion para generar tareas automáticamente.

El proyecto AGENTS.md

Existe una iniciativa llamada AGENTS.md que propone un estándar para que los proyectos tengan un archivo específico pensado para agentes de IA.

La idea es que AGENTS.md contenga:

Descripción del proyecto.
Stack y dependencias.
Estructura de carpetas.
Convenciones de código (estilos, patrones).
Comandos útiles (build, test, deploy).
Contexto de decisiones de diseño.

Este archivo puede ser leído por agentes como Claude, ChatGPT, o herramientas especializadas tipo Cline, Sweep, Aider, y otros asistentes de código, para que entiendan el proyecto sin necesidad de que lo expliques una y otra vez.

MCPs: conectar tu planificación con el mundo exterior

Qué son los MCPs (Model Context Protocol)

Los MCPs (Model Context Protocol) son una forma estandarizada de conectar modelos de IA con plataformas externas como:

Notion
Linear
Jira
GitHub
Google Drive
Slack

En lugar de que tú tengas que copiar/pegar manualmente tareas de tu spec a tu gestor de proyectos, puedes decirle a la IA:

"Lee mi archivo SPEC.md y crea las tareas correspondientes en Linear, organizadas por fases."

La IA se conecta vía MCP a Linear, lee tu planificación, interpreta las fases y crea automáticamente:

Epics por fase.
Issues por feature.
Dependencias entre tareas.
Fechas estimadas.

Todo esto sin que toques la interfaz de Linear manualmente.

Ejemplo de flujo con MCPs

Escribes tu planificación en SPEC.md.
Le pides a Claude (con MCP de Notion activado): "Crea una página en Notion con esta spec y genera una tabla de tareas".
Claude lee el archivo, lo estructura en Notion y genera una tabla con checkboxes.
Luego le pides: "Ahora sincroniza esto con Linear usando etiquetas por prioridad".
Claude conecta a Linear vía MCP y crea los issues correspondientes.

Todo esto en minutos, sin salir de tu editor.

Cómo implementar este flujo en tu próximo proyecto

Paso 1: Define tu idea en texto plano

Antes de tocar código, abre un archivo vacío (puede ser PLAN.md o SPEC.md) y escribe:

Qué quieres construir.
Para quién.
Qué problema resuelve.
Qué hace la app (features principales).
Qué no hace (scope claro).

No necesitas ser formal. Escribe como si le explicaras la idea a un amigo desarrollador.

Paso 2: Pásalo por IA para refinarlo

Toma ese texto y pásaselo a ChatGPT, Claude o tu modelo favorito con un prompt tipo:

"Aquí está mi idea de proyecto. Ayúdame a:

Dividirlo en fases claras.

Detectar posibles problemas o decisiones que debo tomar antes de empezar.

Proponerme una estructura de carpetas inicial.

Sugerirme un roadmap de 4 semanas."

La IA va a devolverte un documento mucho más estructurado.

Paso 3: Guárdalo como Markdown en tu repo

Crea el archivo en la raíz del proyecto:

my-project/
├── SPEC.md
├── README.md
├── src/
├── package.json
└── ...

Este archivo vive junto a tu código. Lo versionas con Git. Lo actualizas cada vez que cambias decisiones importantes.

Paso 4: Úsalo como contexto en cada sesión con IA

Cada vez que retomes el proyecto y necesites ayuda de IA:

"Este es mi proyecto [pega link a SPEC.md]. Quiero implementar la feature X. ¿Por dónde empiezo?"

La IA ya tiene el contexto completo. No tienes que re-explicar el proyecto desde cero.

Paso 5: Expándelo con el tiempo

Conforme el proyecto crece, actualiza el archivo:

Añade decisiones de arquitectura que tomaste.
Documenta por qué elegiste cierta librería.
Registra problemas que resolviste y cómo.

Así, SPEC.md se convierte en la memoria viva del proyecto.

Beneficios reales de planificar con IA

1. Menos estrés, más claridad

Cuando sabes exactamente qué vas a construir, el estrés baja drásticamente. No porque escribas menos código, sino porque sabes hacia dónde apuntas.

2. Menos retrabajo

Si detectas un problema de diseño antes de escribir 500 líneas de código, te ahorras refactorizar esas 500 líneas.

3. Mejor comunicación con el equipo

Si trabajas en equipo, tener un documento claro de qué se está construyendo elimina ambigüedades. Todos leen el mismo plan.

4. Más fácil retomar el proyecto después de meses

¿Alguna vez volviste a un proyecto viejo y no recordabas qué hacía o por qué lo estructuraste así?

Con un buen SPEC.md, solo lo lees y te re-contextualizas en minutos.

5. La IA no pierde contexto

Si cambias de modelo (de ChatGPT a Claude, por ejemplo), solo le pasas el archivo y ya está al día. No dependes de que "recuerde" conversaciones anteriores.

Herramientas y recursos útiles

Editores con IA nativa

Cursor: VS Code con IA integrada, modo spec.
Windsurf (Codeium): Similar a Cursor, enfocado en agentes.
Zed: Editor ultrarrápido con soporte para IA.

Modelos recomendados para planificación

Claude 3.5 Sonnet: Excelente para razonamiento largo y planificación estructurada.
GPT-4: Muy bueno en contexto largo y generación de documentación.
Gemini 1.5 Pro: Gran ventana de contexto (hasta 2M tokens), ideal para proyectos grandes.

Herramientas de MCPs

Cline: Agente de código con MCPs integrados.
Aider: CLI para trabajar con IA y Git.
Sweep: Bot de GitHub que lee issues y genera PRs.

Conclusión: programar no es solo escribir código

Programar no es sentarse frente al editor y escribir líneas hasta que algo funcione. Eso es implementar. Programar, en su sentido más amplio, es:

Pensar.
Decidir.
Anticipar problemas.
Diseñar soluciones.
Comunicar ideas.

Y solo después de todo eso: escribir código.

La inteligencia artificial, usada correctamente, puede potenciar todas esas fases previas al código. Puede ayudarte a dividir problemas, proponer arquitecturas, detectar inconsistencias y generar documentación que vive junto a tu proyecto.

La próxima vez que empieces un proyecto:

Abre un archivo Markdown vacío.
Escribe qué quieres construir, cómo y por qué.
Pásaselo a una IA para refinarlo.
Guarda ese archivo en tu repo.
Úsalo como guía y actualízalo constantemente.

Ese archivo, aunque "solo sea texto", puede ser la diferencia entre un proyecto que avanza con claridad y uno que se vuelve un caos sin rumbo.

Porque al final, el mejor código no es el que se escribe más rápido. Es el que se escribe con intención clara desde el inicio. ```