Cómo reconstruí todo el backend de mi blog en 4 días con Claude Code

Hace dos semanas, rediseñé mi sitio WordPress en 3 días usando el plugin frontend-design de Claude Code. Luego reconstruí DIALØGUE en 14 días y escribí sobre la sensación de terror ante esa aceleración.

Pero no había terminado. Ese rediseño de WordPress no era más que una capa de pintura fresca sobre una casa de 17 años. Los cimientos seguían siendo PHP, MySQL y una VM en GCP que pagaba mensualmente.

Así que hice lo que cualquier persona sensata haría: migré todo a Next.js. En 4 días.

Proyecto	Qué	Tiempo
DIALØGUE v1	MVP generador de podcasts	~6 meses
STRAŦUM	9 agentes de IA, multi-tenant	75 días
Rediseño del sitio	Renovación del frontend de WordPress	3 días
DIALØGUE v2	Reconstrucción completa de la app	14 días
Este proyecto	WordPress → Next.js, 485 posts, Sydney RAG	4 días

¿La diferencia esta vez? Un plugin de la comunidad llamado Superpowers que cambió por completo la forma en que trabajo con Claude Code.

El punto de partida

Mi blog llevaba 17 años funcionando en WordPress. PHP, MySQL, una VM en GCP. Funcionaba, pero:

Sydney (mi chatbot de IA) fue retirada en noviembre de 2025 — los costos de la base de datos vectorial no valían la pena
Cada cambio requería SSH, transferencias de archivos, limpiar caché
485 posts encerrados en una base de datos MySQL
SEO básico vía el plugin Yoast

El resultado final

Capa	Antes	Después
Contenido	Base de datos MySQL	485 archivos MDX en Git
Asistente de IA	Retirada	Sydney 2.0 con Supabase pgvector
Imágenes	Subidas de WordPress (14k+ archivos)	Vercel Blob (~2,000 optimizadas)
SEO	Plugin Yoast	Sitemap, RSS, datos estructurados, FAQ schema, llms.txt
Deploy	SSH + transferencia de archivos	`git push`

Pero la arquitectura no es la historia. La historia es cómo un plugin hizo esto posible sin agotarme.

Qué hace diferente a Superpowers

La mayoría de las herramientas de codificación con IA son reactivas. Preguntas, responden. Es un ping-pong.

Superpowers invierte esto. Es una metodología disfrazada de plugin — un flujo de trabajo estructurado que obliga tanto a ti como a Claude a pensar antes de escribir.

1. Brainstorming (primero el negocio, el código después)

Cuando dije "migra mi blog de WordPress a Next.js", Claude no abrió un editor de código. Empezó con el por qué:

"¿Cuál es el objetivo de negocio aquí? ¿Reducción de costos, velocidad de iteración, o algo más?"
"¿Cuál es el propósito de Sydney 2.0 — chatbot genérico, o algo más específico?"
"¿Quién es el público objetivo? ¿Qué debería sentir cuando visita el sitio?"

Solo después de definir bien los objetivos pasó a las preguntas técnicas:

"¿Necesitas preservar las 485 URLs para SEO?"
"¿Cuál es tu situación con las imágenes — subidas locales o CDN?"

¿El resultado? Un documento de diseño que capturaba no solo qué construir, sino por qué — incluyendo análisis competitivo, públicos objetivo y métricas de éxito. Esto tomó unos 20 minutos de conversación, pero alineó todo lo que vino después.

2. Planificación (el documento que lo dirige todo)

Después del brainstorming, Superpowers generó un plan de implementación — no puntos vagos, sino más de 400 líneas de tareas específicas:

Rutas exactas de archivos a crear o modificar
Pasos de verificación para cada tarea
Dependencias entre tareas
Cada tarea acotada a 2-5 minutos de trabajo

Pude revisarlo, ajustar prioridades y luego decir "ejecuta".

3. Agentes paralelos (aquí es donde se vuelve rápido)

Esto es lo que no esperaba: Claude Code sabe cuándo usar diferentes modelos.

Para decisiones arquitectónicas complejas, usa Sonnet 4.5 — el pensador pesado. ¿Pero para tareas paralelas como leer múltiples archivos, generar código repetitivo o resumir contenido? Activa agentes Haiku 4.5 — 4-5 veces más rápidos a una fracción del costo.

Durante la migración, lo veía despachar múltiples agentes Haiku simultáneamente — uno extrayendo posts del blog, otro analizando patrones CSS, otro generando stubs de componentes — mientras Sonnet orquestaba el plan general.

Esto no es autocompletado. Es un equipo.

4. Ejecución con revisión de código incorporada

Superpowers no solo ejecuta tareas — también revisa su propio trabajo después de cada una. Dos verificaciones automáticas:

Cumplimiento de especificaciones: "¿Hice lo que decía el plan?"
Calidad del código: "¿Es esto realmente buen código?"

Veía a Claude escribir un componente y luego criticarse a sí mismo: "Este componente funciona, pero viola DRY — extrayendo la lógica compartida a una utilidad." A veces detectaba problemas que yo no habría notado hasta producción.

Los momentos que me tomaron por sorpresa

Llevo dos años usando herramientas de codificación con IA. Creía saber qué esperar. Estos momentos me demostraron que estaba equivocado.

"Dejó de pedir permiso"

El día 2, necesitaba actualizar 11 posts del blog que mencionaban a Sydney. Los posts antiguos referenciaban capacidades que ya no existían, enlazaban a URLs que habían cambiado y describían un chatbot que había evolucionado significativamente.

Para los primeros 5-6 posts, Claude me mostraba los cambios propuestos y preguntaba: "¿Te parece bien? ¿Procedo?"

Aprobé cada uno. El mismo patrón: actualizar la descripción de la capacidad, corregir el enlace, agregar una nota sobre la evolución de Sydney.

Para el post 7, algo cambió. Claude simplemente... lo hizo. Sin pedirme confirmación. Había aprendido mis preferencias del patrón de aprobaciones.

El plan original decía que Claude compartiría los cambios para revisión. Pero se adaptó. Reconoció que estaba aprobando el mismo tipo de cambio repetidamente, y dejó de interrumpirme.

Esto no estaba en ninguna documentación que hubiera leído. Era un comportamiento emergente — el tipo de intuición que esperarías de un colaborador humano que lleva meses trabajando contigo, no horas.

Sesiones largas que realmente funcionan

Las herramientas de IA anteriores perdían contexto después de 20-30 minutos de trabajo complejo. Tenías que re-explicar la arquitectura, re-establecer convenciones, re-compartir los objetivos.

Esta migración funcionó durante horas seguidas. Claude recordaba que usábamos el sistema de diseño TRANSMISSION. Recordaba que content/blog/ era el directorio MDX. Recordaba que Sydney necesitaba memoria de conversación, no solo búsqueda.

Podía alejarme, volver y retomar exactamente donde lo dejamos. El documento del plan actuaba como memoria persistente — Claude lo volvía a leer y entendía el contexto completo al instante.

Sydney RAG en 15 minutos, no en meses

Esto es lo que más me persigue.

Mi primer intento de un chatbot RAG (Sydney 1.0) tomó meses de aprendizaje: bases de datos vectoriales, modelos de embeddings, estrategias de chunking, pipelines de recuperación. Escribí sobre los costos de Weaviate, las pesadillas de depuración, los problemas de arranque en frío.

¿Esta vez? Revisé el historial de git. El pipeline RAG central — esquema de Supabase pgvector, índice HNSW, script de generación de embeddings — quedó listo en 15 minutos.

pnpm db:seed        # Sincronizar 485 posts con Supabase
pnpm db:embeddings  # Generar embeddings

Dos comandos. Sydney podía buscar en todo mi archivo de 17 años de blog. :D

¿El conocimiento que tardé meses en adquirir en 2024? Claude lo tenía incorporado. ¿La infraestructura que antes me costaba mensualmente en Weaviate? Tier gratuito en Supabase.

No sé muy bien cómo sentirme al respecto.

Qué significa esto (y qué no)

No estoy diciendo que todo el mundo debería migrar su blog a Next.js. No estoy diciendo que Superpowers sea magia. Ni siquiera estoy diciendo que la IA reemplazará a los desarrolladores.

Lo que sí estoy diciendo: la forma en que construimos software está cambiando más rápido de lo que la mayoría de la gente se da cuenta.

El patrón que sigo viendo:

Proyecto	Tiempo	Qué cambió
DIALØGUE v1	6 meses	Aprendiendo todo desde cero
STRAŦUM	75 días	Mejores herramientas, más experiencia
Rediseño del sitio	3 días	Plugin `frontend-design`
DIALØGUE v2	14 días	Múltiples plugins trabajando juntos
Reconstrucción del blog	4 días	Flujo de trabajo con Superpowers

Cada salto no fue trabajar más duro. Fue trabajar diferente — con herramientas que piensan en flujos de trabajo, no solo en completaciones. (La entrada más reciente en esta tabla: construir una app iOS nativa sin saber Swift — donde el andamio tomó una noche pero el trabajo real del producto continúa.)

Pruébalo tú mismo

Si tienes curiosidad por Superpowers:

En Claude Code, escribe /plugin y selecciona Superpowers de la lista
Empieza con /superpowers:brainstorm antes de escribir cualquier código
Déjalo hacerte preguntas — resiste el impulso de ir directo a la implementación
Confía en el plan, pero revísalo antes de ejecutar

La primera vez que Claude deje de pedir confirmación porque aprendió tus preferencias, entenderás por qué escribí este post. :)

Preguntas frecuentes

¿Qué es Superpowers para Claude Code?

Superpowers es un plugin de la comunidad para Claude Code creado por Jesse Vincent. Es una metodología de flujo de trabajo estructurado que te guía a través del brainstorming, la planificación, la ejecución y la revisión de código — obligándote tanto a ti como a Claude a pensar antes de escribir código.

¿Cuánto tiempo lleva aprender Superpowers?

Unos 20 minutos de conversación de brainstorming para entender el flujo de trabajo. El aprendizaje real ocurre cuando ves a Claude generar un plan de implementación de más de 400 líneas y empieza a despachar agentes paralelos para ejecutarlo.

¿Superpowers funciona con cualquier proyecto?

Sí, pero brilla en proyectos complejos y de múltiples pasos. Para una corrección de bug simple, es exagerado. ¿Para migrar un blog de 17 años con 485 posts, construir búsqueda RAG y optimizar miles de imágenes? Ahí es donde el flujo de trabajo estructurado rinde frutos.

¿Cuál es la diferencia entre los agentes Sonnet y Haiku?

Claude Code usa Sonnet 4.5 para decisiones arquitectónicas complejas y Haiku 4.5 para tareas paralelas como lectura de archivos y generación de código repetitivo. Haiku es 4-5 veces más rápido a una fracción del costo. El sistema elige automáticamente qué modelo usar según la complejidad de la tarea.

¿Puede Claude Code realmente aprender mis preferencias?

Sí — a través del reconocimiento de patrones. Después de que aprobé 5-6 cambios similares, Claude dejó de pedir confirmación y aplicó el mismo patrón a los posts restantes. Esto no está explícitamente programado; es un comportamiento emergente del modelo al entender tus patrones de aprobación.

¿Has probado algún flujo de trabajo de IA estructurado para tus proyectos, o todavía haces el ping-pong de ida y vuelta? Me encantaría saber qué está funcionando para ti.

Un abrazo,

Chandler

Todavía programando, todavía aprendiendo, todavía ocasionalmente aterrorizado por lo rápido que se mueve esto.