El flujo de desarrollo con IA Brainstorm → Plan → Cook → Ship (con AgentKit)

por Jasmine, una desarrolladora que ejecuta exactamente este bucle brainstorm-plan-cook-ship con Claude Code y AgentKit en trabajo real de producción.

La mayoría de los artículos de "trucos para programar con IA" te entregan una pila de prompts y te desean suerte. Eso no es un flujo de trabajo: es una bolsa de trucos. Lo que de verdad mueve la aguja es un pipeline repetible: las mismas fases, en el mismo orden, con una puerta de verificación en cada parada. Este es ese pipeline, ejecutado de principio a fin sobre una función real, con los comandos exactos de cada fase.

¿Qué AgentKit? (no el OpenAI AgentKit)

Una aclaración rápida, porque el nombre choca. El AgentKit de este artículo es el kit para Claude Code en agentkit.best (20% de descuento por el enlace): un paquete de skills, agents y slash commands que manejas por la CLI ak. Antes se llamaba "Claude Kit" (la CLI ck se renombró a ak).

No es el OpenAI AgentKit (Agent Builder, ChatKit y el Connector Registry), lanzado el 6 de octubre de 2025. Misma palabra, producto completamente distinto. Si llegaste aquí buscando la herramienta de OpenAI para construir agents de chat, no es esta: aquí hablamos de un flujo de codificación disciplinado sobre Claude Code. ¿Del todo nueva en Claude Code? Empieza por aquí primero.

Por qué un flujo con nombre le gana al prompt improvisado

Cuando simplemente vas conversando a través de una función, aparecen tres modos de fallo una y otra vez. Primero, el contexto se llena: para cuando Claude está metido a fondo en la implementación, ya olvidó la mitad de lo que acordaron al principio. Segundo, Claude "parece terminado" sin verificar: reporta éxito, ejecutas el código y no funciona. Tercero, el alcance se desvía: pediste un rate limiter y te llegó un rate limiter más una refactorización de tres archivos que no venían al caso.

La solución es un pipeline que separa pensar de hacer y pone una puerta de comprobación en cada parada. La propia guía de Anthropic apunta en la misma dirección: la documentación de buenas prácticas de Claude Code (consultada el 2026-08-09) recomienda un bucle explore → plan → code → commit y, lo más importante, te dice que "le des a Claude una forma de verificar" su salida. El brainstorm-plan-cook-ship es la mejora operativa de ese consejo: en vez de acordarte de promptar cada fase a mano, conviertes cada fase en un comando con un artefacto definido y una puerta definida. Los mismos principios, menos disciplina exigida a ti, más consistencia en lo que sale. Eso es lo que lo hace un flujo de codificación con IA repetible y no una sesión con suerte.

Hay un segundo beneficio, más sutil: cada fase con nombre es una frontera de contexto natural. El Brainstorm produce un resultado corto, no una transcripción; el Plan produce un archivo que entregas a una sesión nueva; el Cook trabaja a partir de ese archivo; el Ship revisa en un contexto limpio. Como cada fase pasa un artefacto pequeño y duradero en lugar de una conversación inflada, esquivas por completo el fallo de "el contexto se llena": el modelo que hace el Cook nunca tiene que recordar todo el brainstorm, solo el plan que le dieron. El prompt improvisado no puede lograr esto, porque todo vive en un único hilo que no para de crecer.

Las 4 fases de un vistazo

Aquí está el bucle entero en una tabla: qué produce cada fase, el comando y la puerta que tiene que pasar antes de que avances. Todo lo de abajo no es más que esta tabla ampliada con ejecuciones reales.

Fase 1 - Brainstorm: fija el resultado antes de tocar el código

El objetivo del brainstorm es aburrido a propósito: convertir una intención difusa ("añadir login") en un resultado aceptado con criterios de aceptación, y comparar un par de enfoques antes de que nadie escriba una línea. Saltarse esto es la razón por la que tantas sesiones de IA producen código seguro de sí mismo y equivocado: el modelo optimizó para un objetivo que en realidad nunca acordaste.

Con AgentKit, ejecuta:

/ak:brainstorm add a Google OAuth callback route to the API

Te entrevista: qué significa "terminado", restricciones, no-objetivos y los criterios de aceptación. Terminas con un resultado corto y por escrito que de verdad aprobaste, no con un muro de código.

El equivalente en Claude Code a secas es el plan mode. Empieza la sesión en modo solo lectura para que no pueda editar nada mientras piensas:

claude --permission-mode plan
# or toggle plan mode mid-session with Shift+Tab

Luego pídele que te entreviste antes de proponer nada: "Hazme preguntas de aclaración hasta que puedas enunciar el resultado y los criterios de aceptación, y entonces detente." La diferencia es que AgentKit lo entrega como un comando repetible con un formato de salida consistente; Claude Code a secas te obliga a conducir la entrevista tú misma cada vez.

Regla de decisión para esta fase: si no puedes decir en una frase cómo es el "terminado", no estás lista para planificar, y mucho menos para cocinar.

Fase 2 - Plan: convierte el resultado en una especificación

El plan convierte el resultado aceptado en una especificación escrita y autocontenida: los archivos que vas a tocar, las interfaces, lo que queda explícitamente fuera de alcance y —la parte que todos se saltan— cómo se verificará el cambio de extremo a extremo. Un plan preciso rinde mucho más que ver la implementación desfilar por la pantalla, porque un buen plan es lo que de verdad revisas; el código solo lo sigue.

/ak:plan implement the OAuth callback per the brainstorm outcome

AgentKit produce un archivo de plan por fases que puedes leer, editar y conservar. Cuando el plan necesita entender primero código desconocido, delega la investigación a un subagent scout para que tu contexto principal quede limpio:

/ak:scout # investigates the codebase, reports back without editing

Si tienes dudas sobre por qué un subagent se encarga del rastreo en vez del agente principal —o cómo encajan a su alrededor las skills, los hooks y MCP— desglosé las piezas en skills vs subagents vs hooks vs MCP. En Claude Code a secas obtienes el mismo efecto con el plan mode más editar el plan propuesto ahí mismo (usa Ctrl+G para abrirlo en tu editor) antes de dejar que continúe.

Esto es desarrollo guiado por especificación en miniatura: escribe la spec, acuerden sobre ella, y la implementación se vuelve una checklist en lugar de un juego de adivinanzas. La señal de que tu plan es lo bastante bueno para cocinar es simple: otra persona de ingeniería (o una sesión nueva de Claude Code) podría ejecutarlo sin hacerte una sola pregunta. Si todavía necesita tus comentarios en vivo para tener sentido, aún no es un plan; es una idea en bruto, y cocinar a partir de una idea en bruto es como se desvía el alcance.

Fase 3 - Cook: implementa con puertas de verificación

El cook es donde se escribe el código, pero el punto entero es que el bucle cierra en una comprobación que pasa, no en que Claude diga "terminado". Ejecutas el plan y lo emparejas con tests para que cada parada tenga su puerta.

/ak:cook # implements the approved plan, phase by phase
/ak:test # runs the test suite; failures feed back into the loop

El patrón que importa: dale al modelo una forma de probar que el cambio funciona antes de cantar victoria. Eso significa correr los tests, correr el build o hacer diff de una captura de pantalla, con la salida a la vista. Si usas Claude Code a secas, monta la misma puerta con un Stop hook o el comando /goal para que la sesión no pueda darse por terminada hasta que una condición concreta pase. Con esa puerta en su sitio, incluso puedes usar /goal para correr el bucle cook-review-ship toda la noche.

Dos hábitos evitan que el cook se descarrile. Corrige el rumbo pronto —pulsa Esc para interrumpir un giro equivocado, o /rewind para retroceder— en vez de dejar que cave un hoyo más hondo. Y ejecuta /clear entre tareas sin relación, para que el contexto viejo no se filtre al cambio siguiente. Para cualquier cosa peliaguda (un test inestable, un bug desconocido), desprende un subagent que investigue, para que el hilo principal siga enfocado en entregar la función.

Fase 4 - Ship: revisa, luego el PR

Esta es la regla que asciende el ship de "commitea y reza" a algo en lo que confiarías en un equipo: el revisor que califica el trabajo no es el que lo escribió. Un modelo que acaba de pasar una hora convenciéndose de que el código es correcto es el peor juez posible de ese código. Así que primero revisas en un contexto nuevo.

/ak:code-review # a fresh reviewer grades the diff against the plan

Esto lanza una pasada adversarial: un subagent revisor (o una sesión limpia) que lee el diff contra el plan original y busca regresiones, criterios de aceptación olvidados y bordes descuidados. Solo después de que da el visto bueno abres el PR:

/ak:ship # conventional commit + PR via gh

AgentKit escribe un conventional commit y abre el pull request por la CLI gh. El equivalente crudo es correr /code-review en una sesión nueva y luego gh pr create tú misma. Opcionalmente cierra el bucle con /ak:journal para capturar las decisiones que tomaste: tu yo del futuro le agradecerá a tu yo del presente cuando vuelvas a mirar por qué el callback se construyó así.

El bucle completo en una función real (de extremo a extremo)

Juntémoslo en una función pequeña y real: añadir una ruta de callback de Google OAuth a una API existente. Aquí están los cuatro artefactos, lado a lado, tal como se apilan de verdad en una ejecución.

1. Brainstorm → un resultado de dos líneas: "Añadir GET /auth/google/callback que intercambia el code por tokens, crea/vincula al usuario y establece una cookie de sesión. No-objetivos: sin rotación de refresh token, sin nueva UI." Aceptación: un nuevo test de integración pasa y un login manual completa el ciclo.
2. Plan → un archivo de plan por fases: qué archivo de ruta, el helper de intercambio de token, el módulo de sesión que reutiliza, el manejo de error para un consentimiento denegado, la lista de lo que queda fuera de alcance y el test exacto a escribir.
3. Cook → el diff: la nueva ruta, el helper, un nuevo test de integración, conectado al código de sesión existente, con la ejecución del test pasando antes de detenerse.
4. Ship → una revisión nueva atrapa una cosa (el camino de consentimiento denegado devolvía un 500 en vez de redirigir), eso se corrige, y luego se abren un conventional commit y el PR.

Sobre el tiempo: el ahorro visible no viene de que el modelo teclee más rápido, viene de no rehacer trabajo. Como el resultado se fijó en la fase 1 y el plan se revisó en la fase 2, el cook de la fase 3 rara vez divaga, y la revisión de la fase 4 atrapa el único defecto real antes de que llegue a un revisor humano o a la CI. El bucle caro de la codificación improvisada —construir lo equivocado, descubrirlo tarde, deshacerlo— es exactamente lo que las puertas previenen. Una función de este tamaño podría haber llevado un par de sesiones dispersas de prompt-and-pray; pasada por el pipeline, es una única pasada enfocada con un PR limpio al final.

Nota honesta sobre dónde la persona todavía importa: el modelo nunca decide el resultado —lo decido yo, en la fase 1— y el hallazgo de la revisión en la fase 4 es justo el tipo de juicio que no quieres automatizar por completo. El flujo quita el trabajo pesado y las trampas del "parece terminado"; no te quita a ti.

Cuándo saltarse fases (no sobreprocesar un typo)

Este marco se gana su lugar en trabajo multiarchivo, desconocido o de enfoque incierto. Es exagerado para un arreglo de una línea. La regla de decisión que uso:

Si puedes describir todo el diff en una frase, sáltate el brainstorm y el plan: ve directo al cook. Arreglar un typo, subir una versión, renombrar una variable: hazlo y ya (y aun así deja que un test confirme que nada se rompió).

Echa mano del pipeline completo cuando cualquiera de estas sea cierta: el cambio abarca varios archivos, no conoces bien esa zona del código, hay más de un enfoque razonable, o un error es caro de deshacer. Todo el arte está en ajustar el peso del proceso al riesgo: un proceso pesado en un cambio trivial es su propia clase de desperdicio.

AgentKit vs hacer esto con Claude Code a secas

Déjame ser clara, porque aquí es donde la honestidad importa: no necesitas AgentKit para ejecutar este flujo. El brainstorm-plan-cook-ship funciona con Claude Code a secas. Puedes construir tus propios slash commands, escribir tus propias skills y montar tus propios Stop hooks para reproducir cada puerta descrita arriba. Mucha gente buena de desarrollo hace justo eso.

Lo que AgentKit te da es la versión prearmada y con opinión: los comandos /ak:*, 108+ skills y 45 agents (17 de ingeniería + 28 de marketing) ya montados y probados, para que te saltes las semanas de construir y mantener tu propio kit. También funciona con GitHub Copilot, no solo con Claude Code. Quién lo necesita: gente que quiere el flujo ya y prefiere no volverse autora de herramientas a tiempo parcial. Quién no: gente que disfruta construir su propia biblioteca de comandos, o cuyas necesidades son lo bastante acotadas como para que dos comandos a medida basten. Si estás sopesando opciones, lo comparé con el resto del campo en cómo se compara AgentKit con las alternativas.

Limitaciones & opinión honesta

Ninguna herramienta está libre de compensaciones, y fingir lo contrario echaría por tierra el propósito de este artículo.

• Curva de aprendizaje. Aún necesitas saber Claude Code primero. AgentKit acelera un flujo; no te enseña los fundamentos. Si Claude Code en sí es nuevo para ti, apréndelo antes de apilar un kit encima.
• El precio es en USD y es un costo real: el Engineer Kit y el Marketing Kit son $99 cada uno, el bundle es $149 (el sitio no lista una cuota recurrente para los kits), y hay garantía de devolución de dinero, aunque el sitio no indica una duración específica, así que no supongas ninguna.
• Confusión entre suscripción y pago único. Los kits son de pago único; la Desktop App aparte es una suscripción anual ($19/año). Fácil de confundir: lee el checkout con cuidado.
• Algo de solapamiento. Algunas skills duplican cosas que quizá ya programes por tu cuenta. El valor está en la curaduría y en el pegamento del flujo, no en que cada skill sea novedosa.

FAQ

¿Qué es el flujo brainstorm-plan-cook-ship?

Es un flujo de desarrollo con IA repetible de cuatro fases: brainstorm (fijar el resultado y los criterios de aceptación), plan (escribir una especificación autocontenida), cook (implementar más tests hasta que pasen) y ship (una revisión adversarial en un contexto nuevo, luego abrir un PR). Operativiza el consejo explore-plan-code-commit de Anthropic en comandos con nombre y una puerta de verificación en cada fase.

¿Necesito AgentKit para usar este flujo?

No. El flujo corre en Claude Code a secas: construirías tus propios slash commands, skills y Stop hooks para lograr las mismas puertas. AgentKit es la versión prearmada que trae esos comandos (/ak:brainstorm, /ak:plan, /ak:cook, /ak:ship) para que no tengas que montarlos tú misma.

¿Es AgentKit lo mismo que OpenAI AgentKit?

No. Este AgentKit es el kit para Claude Code en agentkit.best, manejado por la CLI ak (antes Claude Kit / ck). OpenAI AgentKit es un producto distinto (Agent Builder, ChatKit, Connector Registry) lanzado el 6 de octubre de 2025. Mismo nombre, herramientas sin relación.

¿Cuáles son los comandos exactos de cada fase?

Brainstorm: /ak:brainstorm. Plan: /ak:plan (con /ak:scout para investigar el código). Cook: /ak:cook más /ak:test. Ship: /ak:code-review y luego /ak:ship, con un /ak:journal opcional para capturar decisiones.

¿Funciona también con GitHub Copilot?

Sí. AgentKit da soporte tanto a Claude Code como a GitHub Copilot, así que la misma estructura de flujo está disponible si tu equipo usa Copilot en vez de Claude Code.

¿AgentKit es de pago único o suscripción?

Los kits (Engineer $99, Marketing $99, bundle $149) son de pago único: el sitio no lista una cuota recurrente para ellos e incluye actualizaciones de por vida de los kits. La Desktop App aparte es una suscripción anual ($19/año). Se cobran de formas distintas, así que revisa qué estás comprando realmente.

Conclusión + consigue el kit

Ese es el bucle entero: brainstorm para fijar el resultado, plan para escribir la spec, cook para implementar detrás de un test que pasa, y ship después de que un revisor nuevo dé el visto bueno. Fases con nombre, un comando cada una, una puerta en cada parada: eso es lo que convierte sesiones con suerte en un flujo de desarrollo con IA repetible. Ejecútalo con Claude Code a secas, o sáltate el ensamblaje y usa los comandos prehechos.

¿Quieres el desglose completo antes de comprar? Lee primero qué incluye AgentKit.