Desarrollador Cambia de Especificaciones a Propuestas para Sesiones de Código Paralelas de Claude

El problema con el enfoque de especificaciones primero

El desarrollador encontró problemas donde escribir especificaciones detalladas de antemano llevaba a que la IA generara código técnicamente correcto pero contextualmente erróneo. La especificación diría "añadir limitación de tasa a los endpoints de autenticación" pero no incluiría contexto sobre enfoques previamente rechazados (como los token buckets) o decisiones de implementación (como elegir Redis sobre Cloudflare para staging). Esto creaba situaciones donde la IA tomaría decisiones razonables que reabrían decisiones ya cerradas.

Actualizar las especificaciones se convirtió en su propio mini-proyecto, y para cuando las especificaciones actualizadas eran revisadas, la base de código ya había divergido. La especificación capturaba el "qué" pero perdía el "por qué"—todo el razonamiento, alternativas rechazadas y el momento de las decisiones estaban ausentes.

La alternativa de propuestas primero

En lugar de escribir especificaciones de antemano y codificar para cumplirlas, el desarrollador escribe propuestas—documentos cortos que capturan por qué se está haciendo un cambio, qué se consideró y rechazó, y qué está dentro o fuera del alcance. La especificación se actualiza después de que el código se implementa para reflejar lo que realmente se construyó.

Ejemplo de comparación:

• Una especificación dice: "El sistema deberá soportar limitación de tasa."
• Una propuesta dice: "Ataques de fuerza bruta detectados en producción. Añadiendo limitación de tasa mediante ventana deslizante + Redis (Cloudflare no disponible en staging). Token bucket rechazado por problemas de tráfico en ráfagas. Alcance: solo inicio de sesión + restablecimiento de contraseña."

La propuesta le da a la IA (y a futuros desarrolladores) la imagen completa.

Flujo de trabajo de propuestas paralelas

El desarrollador ejecuta múltiples sesiones de Claude Code simultáneamente, cada una trabajando en una propuesta diferente. A veces crea propuestas competitivas que resuelven el mismo problema desde diferentes ángulos.

Flujo de trabajo típico:

• Trabajando en 2-3 características/errores/problemas al mismo tiempo
• Creando 1 o 2 propuestas para diferentes enfoques por problema
• Iniciando sesiones de Claude Code para cada propuesta para ejecutarlas en paralelo
• Cada sesión produce un PR de GitHub
• Los PRs de GitHub sirven como plataforma de revisión de propuestas
• Revisando enfoque y código juntos
• Si dos propuestas abordan el mismo problema de manera diferente, eligiendo la mejor y cerrando la otra
• Una vez que los PRs aprobados se implementan, indicándole a Claude que implemente las propuestas
• Actualizando la especificación para reflejar los cambios de código para referencia rápida en futuras propuestas

La especificación se convierte en un documento vivo que siempre coincide con la realidad en lugar de un documento aspiracional que diverge desde el primer día.

Ciclo PACE

El desarrollador llama a este ciclo PACE (para recordar los pasos):

• Proponer: Escribir una propuesta corta con contexto y razonamiento
• Aprobar: Revisar en el PR de GitHub, enfoque (aprobar, revisar, rechazar)
• Codificar: La IA implementa exactamente lo propuesto, nada más
• Evolucionar: Actualizar la especificación para reflejar la nueva realidad