Cómo unimos producto e ingeniería con agentes en Mercadona Tech (con repo open-source)
(GSD + Mercadona User Story Toolkit + Superpowers)
Cuarto artículo de la serie Desarrollo de productos con agentes. Lo que estamos probando en Mercadona Tech, qué funciona, qué todavía falla, y cómo lo replicas en tu equipo. Repo open-source incluido.
El cuello de botella ya no es ejecutar código
Llevamos meses repitiendo lo mismo desde distintos ángulos: el cuello de botella ya no es escribir el código.
Con un agente bien dirigido, un ingeniero senior puede convertir una user story bien definida en una pull request con tests en verde en un fin de semana. El problema es que el agente solo es tan bueno como la user story que le das. Y antes de la user story, hay un PRD. Y antes del PRD, hay decisiones de roadmap. Y nadie te explica cómo se conecta todo eso sin contradicciones.
En Mercadona Tech estamos probando un pipeline que junta tres herramientas: GSD para roadmap y planificación, el Mercadona User Story Toolkit para definir y priorizar stories, y Superpowers para implementar con TDD. La hipótesis: si los tres hablan entre sí con un contrato claro, el flujo de “idea de producto” a “PR mergeada” se vuelve fluido sin perder rigor.
No es definitivo. Llevamos unas pocas semanas probándolo, no años. Tenemos la sensación de que funciona — el código sale más limpio, las stories aterrizan mejor en producción, hay menos rework. Pero no tengo números aún, así que esto es un playbook en pruebas. Lo publico hoy con un repo open-source para que más equipos lo prueben y lo mejoremos entre todos.
A quién sirve esto y a quién no
El pipeline está diseñado para equipos que tienen el problema de separación de responsabilidades entre producto y desarrollo:
PMs que escriben PRDs y necesitan convertirlos en stories sin perder fidelidad
Ingenieros que reciben stories y quieren implementarlas con disciplina (TDD, code review, verificación)
Equipos donde la consistencia entre planning y ejecución tiene un equilibrio delicado — ROADMAPs que mienten, specs obsoletas, estados desincronizados
Si tu equipo es muy pequeño (1-3 personas), probablemente esto sea un overkill. Para equipos pequeños, Superpowers solo, con su skill de brainstorming, es suficiente: la persona que define producto es la misma que lo implementa o están muy cerca, y un solo agente puede acompañar el flujo completo. La separación de responsabilidades aquí es artificial. Mi recomendación honesta para un equipo de tres es: instala Superpowers, brainstormea la feature, escribe un plan con /superpowers:writing-plans, ejecuta con TDD, y ya. Sin GSD. Sin Mercadona User Story Toolkit. Vendrán cuando necesites coordinar más roles, mantener documentación o trabajar en funcionalidades más complejas en equipos más grandes.
Si tu equipo tiene PMs separados de Eng y trabaja en features de tamaño medium-large (varias stories, varias semanas, objetivos por Q), aquí es donde este pipeline puede brillar.
El pipeline en una imagen
Tres fases. Dos de PM, una de Eng. La separación entre las dos primeras es deliberada: planificación, roadmapping y definición de JTBDs y User Stories son trabajos distintos, con metodologías distintas.
Fase 1 — GSD (PM): roadmap multi-fase, decisiones de scope, especificación de cada fase con requirements falsables. Output: el directorio .planning/ con PROJECT.md, REQUIREMENTS.md, ROADMAP.md, y por cada fase SPEC.md y PLAN.md.
Fase 2 — Mercadona User Story Toolkit (PM): transforma el plan de GSD en stories de calidad. Empieza con /from-gsd que produce un PRD sintético, lo completa el PM con research (entrevistas Mom Test), genera JTBDs, escribe stories con scoring 6D, las valida y prioriza en batches anti-waterfall.
Fase 3 — Superpowers (Eng): recibe el batch de stories y las implementa con TDD subagent-driven. Cada commit lleva el ID de requirement (feat: implement DETECT-01...). Tests verdes, code review, PR mergeada.
Y para cerrar el círculo: un puente. gsd-bridge es un CLI que detecta los REQ-IDs en los commits y actualiza automáticamente STATE.md, PLAN.md, ROADMAP.md y genera VERIFICATION.md. Sin él, los artefactos de GSD divergen de la realidad del código en cuanto la implementación arranca.
Esa es la idea. Ahora vamos a por el detalle.
Por qué tres herramientas y no una
La pregunta razonable es: ¿por qué no usar solo Superpowers para todo? Ya tiene brainstorming, writing-plans, executing-plans. ¿Para qué meter GSD y Mercadona User Story Toolkit en medio?
Porque cada herramienta está optimizada para un trabajo distinto, y mezclar trabajos en una sola herramienta produce resultados mediocres en todos.
GSD está optimizado para roadmap multi-fase. Tiene noción de fases con dependencias, success criteria, requirements falsables, y un ciclo de planning con verificación iterativa. Si intentas reproducir eso con Superpowers solo, acabas con un plan único gigantesco que no captura bien la cadencia trimestral del producto. Si pides a GSD que ejecute, ahí también flojea — su gsd-execute-phase no aplica TDD por defecto y tiende a generar código que pasa los tests pero no encajaría en una code review exigente.
El Mercadona User Story Toolkit está optimizado para definir stories con criterio de PM y unir ambos mundos. Es la pieza que traduce y asienta lo que sale de GSD con lo que entre a Superpowers. Quality gate del PRD, research Mom Test, JTBDs con evidencia, antipatrones detectados (fake stories, stories grandes mal divididas), priorización con cinco lentes ponderadas anti-waterfall. Esto es trabajo de PM con metodología propia, no de un copiloto general. Pedirle a Superpowers que escriba stories sin esta capa termina en tareas técnicas disfrazadas de user stories.
Superpowers está optimizado para ejecución disciplinada. TDD obligatorio (test-driven-development skill), subagent-driven para paralelizar tareas independientes, verification-before-completion para no mentir sobre el estado del código. La cultura de ingeniería de Mercadona Tech exige TDD y buenas prácticas. Superpowers se alinea perfectamente; GSD no fue diseñado con esa disciplina como requisito.
La separación es por especialización, no por dogma. Cada agente está afilado para un rol concreto, y el contrato entre ellos es lo que hace que el conjunto funcione.
Working backwards: el modelo mental que mejor encaja
Hay una metodología que llevo años admirando y que pocos equipos ejecutan bien: el Working Backwards de Amazon. La idea es radicalmente simple: antes de construir nada, el equipo escribe el press release del producto terminado y un FAQ de seis páginas que cualquier ejecutivo pueda leer y entender. Si no consigues articular el producto en ese formato — quién es el cliente, qué problema resuelve, cómo sabremos que ha funcionado — no estás listo para empezar. Bill Carr y Colin Bryar lo cuentan en detalle en Working Backwards (2021), y aunque la práctica original está pensada para humanos escribiendo narrativas en seis páginas, la lógica subyacente es la mejor modelo mental que conozco para trabajar con agentes.
Este pipeline es, en el fondo, una versión ejecutable de Working Backwards. Las correspondencias son directas:
GSD obliga a escribir PROJECT.md, REQUIREMENTS.md y SPEC.md con acceptance criteria falsables antes de pisar código. Es la disciplina del PR/FAQ: definir el resultado deseado en términos verificables antes de empezar la implementación. Si el acceptance criteria no se puede testear, GSD no te deja avanzar.
El Mercadona User Story Toolkit exige completar el PRD con JTBDs basados en entrevistas Mom Test. Es la customer obsession de Amazon — empezar por el cliente con evidencia, no con un buyer persona inventado.
El quality gate del PRD se niega a continuar si hay GAPs no resueltos. Es el equivalente a “no pasamos a build hasta que el PR/FAQ esté aprobado”. El agente no construye sobre un brief que miente: si falta una métrica baseline o una cita literal de cliente, el toolkit lo marca como GAP explícito y exige resolverlo.
La priorización en batches anti-waterfall replica la lógica de Amazon de equipos pequeños que entregan valor end-to-end por iteración, en lugar de “infra primero, UI después, valor al final”.
Lo que este pipeline aporta sobre el Working Backwards original es mecanizar el rigor. La metodología de Amazon depende mucho de la cultura: si el equipo no se compromete a escribir el PR/FAQ con honestidad, la disciplina se pierde rápido. Aquí los agentes son los guardianes — la skill se niega a inventar números, exige acceptance criteria testeables, y bloquea avance si las stories no derivan de evidencia real.
Esto importa especialmente cuando hay agentes de implementación de por medio: un agente no tiene contexto de negocio, solo ve la spec que le pasas. Si la spec es vaga, el código será vago. Si la spec inventa números, el código optimizará para números inventados. Working Backwards minimiza ese riesgo forzando claridad en la entrada.
Mi conclusión tras semanas de uso: si vas a orquestar agentes de planning con agentes de implementación, no hay modelo mental que encaje mejor que Working Backwards. Outcomes articulados con precisión, evidencia antes de hipótesis, narrativa antes de slides, falsabilidad antes de optimismo. Sin esa disciplina, los agentes producen volumen sin dirección.
Walkthrough: facetas en el buscador SearchMO
Veamos un ejemplo sencillo de como funciona todo el flujo:
Volvamos al buscador de la tienda de Mercadona, ya que hemos observado que cuando un cliente busca “café” — query ambigua porque hay molido, en grano, soluble, descafeinado no tenemos forma de desambigüar si intención de búsqueda. En este caso trans toda la fase de research vemos que tiene sentido añadir facetas inline a nuestro buscador. — la app le ofrecerá chips de filtro debajo del search bar para que afine sin tener que escribir más.
El walkthrough completo está en el repo. Aquí cuento solo lo esencial.
Fase 1 — GSD: roadmap y especificación
El PM arranca con /gsd-new-project. La conversación produce:
.planning/
├── PROJECT.md # contexto + core value + key decisions
├── REQUIREMENTS.md # 16 REQ-IDs, v1 vs v2, out of scope
├── ROADMAP.md # 3 fases con success criteria
└── phases/01-faceted-search/
├── SPEC.md # 7 requirements falsables (current → target → acceptance)
└── 01-01-PLAN.md # tasks granulares por REQ-IDLo importante de los artefactos GSD: cada requirement tiene un acceptance criteria concreto y testeable. No es “mejorar la búsqueda”; es “test con 50 queries (25 ambiguas, 25 específicas) — clasificador acierta ≥90%”. Esto se traduce directamente a tests más adelante.
Fase 2 — Mercadona User Story Toolkit: del plan al backlog
El paso clave aquí es /from-gsd., el cual lee todo el contenido de .planning/ y produce un PRD sintético:
$ /from-gsd
✓ PRD sintético generado: prd-from-gsd.md
Secciones rellenas desde GSD: 7
Secciones marcadas como GAP: 7
GAPs típicos a completar tras /research:
- 1.2 Farolas (cuantitativo)
- 1.3 Penumbras (cualitativo)
- 2.2 Aspectos Financieros
- 2.3 Métricas baseline → target
- 3.5 FAQsAquí pasa algo importante. El PRD sintético es fiel pero incompleto. GSD captura roadmap, scope y specs falsables — eso se mapea bien al PRD. Pero GSD no captura métricas con baseline, citas literales de clientes, ni ROI estimado. Esos huecos se marcan como GAPs explícitos que el PM completa después del research, no antes. La skill se niega a inventar números. Si tu PRD generado dice [⚠️ Pendiente: definir métrica con datos reales] es porque GSD no sabe esa métrica y tú tampoco la has aportado todavía.
El PM completa los GAPs con /research, que diseña entrevistas Mom Test y, tras realizarlas, sintetiza JTBDs:
## JTBD-01: Refinar búsqueda ambigua sin esfuerzo extra
Job principal: Cuando busco un producto y la consulta es ambigua, quiero
refinar el resultado sin tener que pensar palabras adicionales, para llegar
al producto correcto sin perder tiempo ni frustrarme.
Evidencia cuantitativa: 12% queries ambiguas, 28% search abandon
(vs 16% en específicas), 4.2s tiempo a primer click (vs 2.1s).
Evidencia cualitativa: "Cuando busco 'café' me sale de todo y no sé cuál
pillar" — cliente recurrente, sesión de discovery 22-abr.
Confianza en el JTBD: Alta (5/5 entrevistas)/stories convierte los JTBDs en user stories con scoring 6D, /validate-stories detecta antipatrones, /split-stories divide stories grandes, y /prioritize agrupa en batches anti-waterfall:
Batch 1 — Backend mínimo viable end-to-end (Stories 1+2)
Batch 2 — UI funcional con orden básico (Stories 3+4)
Batch 3 — Telemetría y validación (Story 5)Cada batch entrega valor por sí solo. El batch 1 (backend solo) ya permite validar el algoritmo via API antes de invertir en UI. El batch 3 cierra el loop de medición. Nada de “infra primero, valor al final”.
Fase 3 — Superpowers: ejecución TDD
El PM pasa el batch 1 al ingeniero, que arranca Superpowers con /superpowers:writing-plans. La skill lee las stories + los acceptance criteria del SPEC.md y produce un plan de implementación TDD: pasos, tests a escribir antes del código, criterios de verificación.
Después, /superpowers:test-driven-development ejecuta el ciclo rojo → verde → refactor en cada step:
# Test rojo
def test_query_with_high_dispersion_is_classified_ambiguous():
top_k_results = [...]
classifier = SearchClassifier(threshold=AmbiguityThreshold(3, 0.10))
result = classifier.classify(top_k_results)
assert result == QueryClassification.AMBIGUOUS
# Implementación mínima → test verde → refactor solo si emerge una smellPara batches con tareas independientes, /superpowers:subagent-driven-development dispara subagentes en paralelo (un subagente para el clasificador, otro para el generador de facetas). Más rápido pero más caro en tokens — volveremos a eso.
Cada commit referencia el REQ-ID:
feat(search): implement DETECT-01 + DETECT-02 + DETECT-03 ambiguity classifier
feat(search): implement FACET-01 + FACET-02 facet generator
feat(search): implement FACET-03 + FACET-04 ordering by usage and frequency
feat(search): integrate facets into /search endpoint
test(search): add load test verifying p99 ≤195ms with facets enabledTests verdes, code review pasada, PR mergeada. El ingeniero ha terminado.
Y aquí es donde sin un puente, la cosa se rompe, veámoslo en siguiente sección.
El problema de orquestación
Este es el problema más subestimado de unir planning y ejecución con agentes con herramientas distintas como GSD y Superpowers, y el que más nos costó resolver.
Cuando GSD planifica pero Superpowers ejecuta, los artefactos de GSD se quedan obsoletos en cuanto los commits empiezan a entrar. STATE.md sigue diciendo “phase not started” cuando en realidad está casi terminada. ROADMAP.md muestra checkboxes vacíos cuando los REQ-IDs están terminados en código. PLAN.md no se actualiza. VERIFICATION.md nunca se genera.
Esto importa más de lo que parece. El seguimiento del desarrollo de cada funcionalidad se basa en el estado de GSD; si miente, el PM termianrá por no saber por donde va. La trazabilidad de auditoría se rompe — quién hizo qué y cuándo deja de ser reconstruible. Y cuando empieza la siguiente fase, los artefactos divergen tanto que ya nadie los actualiza, y el proyecto se queda con dos fuentes de verdad incompatibles: el código y los planes que describían el código que se iba a hacer.
Nuestra solución es un CLI standalone llamado gsd-bridge. ~250 líneas de Python, sin dependencias externas:
gsd-bridge sync # auto-sync desde git: detecta REQ-IDs en commits y actualiza .planning/
gsd-bridge mark-done X-01 # marcar manualmente si los commits no referencian REQ-ID
gsd-bridge amend "razón" # registrar drift de diseño en SPEC-AMENDMENTS.mdEl convenio mínimo: incluir el REQ-ID en el commit message. El bridge detecta el patrón [A-Z]{2,8}-\d{1,4} (ej: AUTH-01, DETECT-12), busca en qué PLAN.md aparece, lo marca como [x], y si todos los REQs de una fase están done, cierra la fase en ROADMAP.md, genera VERIFICATION.md y añade una entrada de sync al inicio de STATE.md.
Para automatizarlo del todo, hay un hook de Claude Code que ejecuta gsd-bridge sync --quiet al final de cada conversación. Si hay .planning/ en el directorio, sincroniza; si no, no hace nada. El usuario no se entera.
Un ejemplo concreto de “spec drift”. El SPEC.md de la feature de facetas decía que el threshold de ambigüedad sería un valor numérico simple (min_categories: 3). Durante la implementación, el ingeniero descubrió que necesitaba dos parámetros para que la heurística funcionase bien (min_categories + min_weight). Cambió el código y los tests, pero el SPEC.md siguió diciendo “valor numérico simple”. Tres semanas después, otro PM lee el SPEC.md para entender el feature, ve “valor numérico simple” y pierde 40 minutos antes de mirar el código. Esto es spec drift y pasa siempre.
Una decisión clave: no tocar SPEC.md. Cuando la implementación cambia decisiones de diseño respecto al spec original (cosa que pasa siempre que el problema no es trivial), el bridge no reescribe SPEC.md. En su lugar, crea/anexa SPEC-AMENDMENTS.md con cada cambio. Esto preserva el trail histórico — el “qué decidimos” original sigue intacto, los “qué cambió y por qué” quedan registrados al lado. Si reescribiésemos SPEC.md, perderíamos la capacidad de auditar decisiones a posteriori.
Por qué Superpowers y no gsd-execute
GSD tiene su propio comando de ejecución, gsd-execute-phase. Funciona, y para muchos proyectos comunitarios encaja bien, de hecho es la forma de mantener todo el status del proyecto correctamente actualizado sin toda la parafernalia que he descrito en las secciones anteriores. Sin embargo a nosotros no nos sirve.
La razón es cultura de ingeniería. En Mercadona Tech, las prácticas de desarrollo no son negociables: TDD obligatorio en el código de producción, code review exigente, verificación de aceptación antes de mergear, separación clara entre tests unitarios e integración. Esto no es ideología — es lo que mantiene un sistema con decenas de servicios y 12 equipos sin que se caiga.
Cuando probamos gsd-execute-phase para implementar funcionalidades reales, el código que producía pasaba los tests que se le pedían pero no aguantaba bien una code review estricta. Faltaba disciplina TDD: el orden tendía a ser “implementar → escribir test → ajustar test hasta que pase”. Eso es prácticamente lo opuesto del TDD que queremos. El resultado era código frágil, con tests que validaban lo que el código hace en lugar de lo que debe hacer. Y eso degrada con el tiempo.
Superpowers, sin embargo, se alinea con nuestra cultura. Su skill test-driven-development exige el ciclo rojo-verde-refactor. Su verification-before-completion se niega a declarar “hecho” sin evidencia fresca de que los tests pasan. Su requesting-code-review activa un revisor automático antes de que el ingeniero diga “está terminado”. Cada una de estas disciplinas es opcional en otras herramientas; aquí están reforzada por la skill.
Esto no es decir que gsd-execute-phase sea malo. Es decir que no es la herramienta adecuada para nuestra cultura de ingeniería. Si tu equipo no es TDD-strict, GSD-execute puede serviros bien. Si lo eres, Superpowers encaja mejor.
El coste real: tokens
Si vas a probar este pipeline, tienes que conocer el coste. Esto no es barato.
Mis estimaciones aproximadas para una feature mid-size (3 stories, ~1.5 semanas de trabajo):
GSD planning (project + phase + plan + research): ~50-100k tokens. Hay multi-agent (planner + plan-checker), por eso sube.
Mercadona User Story Toolkit pipeline (prd-quality-guard → research → analyze → stories → validate → split → prioritize): ~60-120k tokens. Las skills tienen muchos checkpoints y leen referencias bajo demanda.
Superpowers TDD subagent-driven: ~150-300k tokens. Aquí está el grueso. Cada subagente que lanzas es una conversación nueva con su propio contexto. Para una feature pequeña con 5-7 steps de TDD, llegas fácil a 200k.
Total por feature medium: 250-500k tokens. Con Claude Sonnet a precios actuales, son unos pocos dólares. Con Opus, más. Para un equipo que ejecuta varias features a la semana, el gasto no es despreciable.
¿Vale la pena? Honestamente, todavía no lo sé con números. Lo que tengo es la sensación de que el código sale más limpio y el rework baja, y eso compensa con creces el coste de tokens, por no hablar de que la velocidad del desarrollo se dispara entre un 5x y un 10x. Pero esa sensación necesita validación empírica que aún no hemos hecho.
Si tu equipo tiene presupuesto ajustado, dos consejos: (1) usa subagent-driven solo cuando las tareas sean realmente independientes — si fuerzas paralelización innecesaria, gastas el doble sin ganar tiempo; (2) deja Opus para los pasos críticos (writing-plans, refactor) y usa Sonnet para el grueso de TDD repetitivo.
Qué falla todavía
Llevamos unas pocas semanas usando esto. No todo funciona perfecto. Lo que aún nos duele:
1. La automatización del bridge tiene huecos. Si el ingeniero olvida poner el REQ-ID en el commit, el bridge no detecta nada y hay que hacer mark-done manual. Hemos pensado en un pre-commit hook que rechace commits sin REQ-ID, pero genera fricción y no siempre tiene sentido (commits de typo, bumps de dependencias). Decisión pendiente.
2. El handoff entre fases no es 100% automático. Cuando el PM termina con Mercadona User Story Toolkit y produce el batch priorizado, el ingeniero tiene que copiar las stories al input de /superpowers:writing-plans. Es un copy-paste de markdown — funciona, pero es manual, lo mismo que si te llevas las user stories a Jira y montas algo para que Superpowers las lea de ahí. Idealmente Superpowers debería leer directamente del output del toolkit, lo que implica cambios estructurales en la forma tradicional de trabajar apalancada en Jira.
3. El gasto en tokens sigue preocupándonos. Optimizaciones (cache, mezcla de modelos) en exploración — ver sección anterior, no es tontería a ver si va a salir el collar más caro que el perro.
4. Spec drift es real. Aunque el bridge registra amendments, en la práctica los ingenieros no siempre los registran al momento; lo hacen al final, retrospectivamente, y a veces se pierden detalles. Hace falta más disciplina o más automatización.
5. La curva de aprendizaje es alta. Las tres herramientas tienen su propia metodología (GSD = roadmap-driven, Mercadona User Story Toolkit = JTBD + Mom Test, Superpowers = TDD subagent-driven). Introducir a alguien al pipeline completo lleva tiempo. Los equipos que ya están cómodos con Jira + sprint planning tradicional pueden ver esto como overhead innecesario, y no voy a decir que no lo sea.
6. Mediremos pronto. Esto es lo más importante: medir bien el valor de todo este flujo sigue siendo trabajo pendiente. Necesitamos definir baselines (rate de bugs en producción antes y después del pipeline, time-to-PR-mergeada, % de stories que vuelven a abrirse por rework) y compararlas. Hasta que tengamos esos números, esto es una hipótesis razonable, no una verdad demostrada, no te fies por muy bien que suene todo lo que has leido aqui.
Liberación open-source
Hoy publicamos el toolkit en un repo público para que cualquier equipo lo pruebe, esta es una cuenta pendiente que tenía con vosotros desde que os hablé del Mercadona User Story Toolkit:
Repo: github.com/josemerca/mercadona-user-story-toolkit — Licencia MIT.
Incluye:
8 skills del Mercadona User Story Toolkit (prd-quality-guard, gsd-to-prd, research-from-prd, jtbd-to-stories, user-story-builder, user-story-quality-coach, story-splitting, story-prioritization)
11 comandos de slash para Claude Code
bridge/gsd-bridge.py — el CLI de sincronización GSD↔ejecutor, con README e hook de ejemplo
examples/searchmo-facets/ — el walkthrough completo del feature contado en este artículo, con todos los artefactos al desnudo
README + CONTRIBUTING + LICENSE MIT
Las dos herramientas que lo orquestan también son públicas:
GSD: github.com/gsd-build/get-shit-done — meta-prompting + spec-driven development.
Superpowers: github.com/obra/superpowers — agentic skills framework.
A ambos equipos, gracias. Sin sus herramientas no existiría este pipeline.
Millones de gracias al equipo de Producto e Ingeniería de Mercadona Tech que están probando todo este flujo y sin cuyas ideas todo este trabajo sería imposible, aunque lo que leéis aquí lo escriba yo (bueno en realidad lo escribe Claude 😂) muchas de las ideas surgen de mi equipo y no sería justo apropiarme de ellas, todo lo que leéis aquí ha surgido del equipo de Mercadona Tech, no de Jose Ramón Pérez Agüera.
Lo que pido: prueba el flujo en un proyecto real. Si te encaja, escríbeme. Si no te encaja, escríbeme también — quiero saber qué falla en otros contextos. Si encuentras bugs, abre issue. Si tienes una idea para mejorarlo, manda PR.
Esto está en versión 0.1. Vamos a iterarlo entre todos.
Cierre
El argumento de fondo de toda la serie Desarrollo de productos con agentes es que estamos en un momento bisagra. Las herramientas individuales (Claude Code, Cursor, Copilot, Superpowers) están bien. Las metodologías (vibe coding, spec-driven development) también. Lo que falta es estandarizar cómo se conectan entre sí para producir un flujo coherente desde la idea de producto hasta la PR mergeada.
Este pipeline es una propuesta. Probablemente no la mejor. Probablemente no la final. Pero es una concreta, ejecutable, y abierta para que tú la mejores.
¿Cómo lo estáis haciendo vosotros? ¿Qué herramientas os están funcionando para conectar producto e ingeniería en la era de los agentes? ¿Dónde se os rompe el flujo?
Lee, prueba, rompe, comparte.
Este es el cuarto artículo de la serie Desarrollo de productos con agentes. Anteriores: