Mi flujo completo de AI en desarrollo web: del issue al deploy
El error de mis primeros meses con agentes fue pedir código. "Hazme esta feature" y esperar magia. El resultado era predecible: código que funcionaba a medias, revisiones eternas y la sensación de estar parchando algo que no entendía.
El cambio no fue un modelo mejor. Fue dejar de pedir código y empezar a pedir contexto, plan y verificación. Esta pieza es el flujo que uso hoy, con la fuente de cada idea: la columna vertebral viene del marco de 7 fases de desarrollo con AI que publica AI Hero, y lo adapté a mi trabajo. - Source: My 7 Phases Of AI Development - AI Hero
El flujo, de un vistazo
| Fase | Qué hago | Entregable |
|---|---|---|
| 1. Idea | Definir el problema, no la solución | Enunciado del problema |
| 2. Research | Cachear lo difícil de explorar | RESEARCH.md (temporal) |
| 3. Prototipo | Imponer mi gusto en lo que importa | Prototipo desechable |
| 4. Spec | Describir el destino | Spec con user stories |
| 5. Tickets | Partir en rebanadas verticales | Tablero con bloqueos |
| 6. Ejecución | Agentes trabajando | Código + tests |
| 7. QA | Verificar con plan explícito | Plan de QA y feedback |
Fases 1-2: idea y research
La idea se afina conversando, no escribiendo. Un skill tipo "interrógame hasta que entendamos lo mismo" obliga a recorrer el árbol de decisiones antes de tocar código; en sesiones reales eso produce entre 16 y 50 preguntas. - Source: 5 Agent Skills I Use Every Day - AI Hero
El research solo cuando la exploración es difícil (una API rara, una integración externa): se cachea en un archivo RESEARCH.md dentro del repo y se borra al terminar el sprint, porque la investigación añeja desinforma al agente. - Source: My 7 Phases Of AI Development - AI Hero
Fases 3-4: prototipo y spec
Si el resultado depende de tu gusto (UI, arquitectura, integración), prototipa antes de especificar: dos o tres variantes desechables para elegir con los ojos, no con la imaginación. Después, la spec describe el destino, no el camino, y lo importante son las user stories: el comportamiento deseado en lenguaje. - Source: My 7 Phases Of AI Development - AI Hero
Fases 5-6: tickets y ejecución
El tablero no es burocracia: es paralelización y desbloqueo. Cada ticket es una rebanada vertical (atraviesa todas las capas, no una capa entera) y las relaciones de bloqueo permiten lanzar varios agentes sobre los que no dependen de nadie. Con research, prototipo y spec listos, la ejecución puede correr desatendida sin que el resultado sea basura. - Source: 5 Agent Skills I Use Every Day - AI Hero
Fase 7: QA (la que separa producto de demo)
Un plan de QA explícito, revisión humana del código generado y tickets nuevos para lo que aparezca. Las fases 5-7 se repiten varias veces por feature: eso es lo normal, no una señal de fracaso. - Source: My 7 Phases Of AI Development - AI Hero
Lo que hace que todo funcione por debajo
Dos cosas, y ninguna es el prompt:
- Feedback loops rápidos. Si el agente no puede correr los tests en segundos, no sabe si lo que hizo funciona.
- Un codebase navegable. El agente lee tu repo, no tu mente: si el mapa del código no existe, improvisa. → Diseña tu repo para que los agentes trabajen mejor
Y una tercera que es contexto puro: un AGENTS.md corto y bien dirigido, no una biblia.
Mis 5 reglas
- Nunca pido código en el primer mensaje. Primero el problema, después el plan.
- Si no puedo verificar, no es una tarea: convierto el pedido en algo comprobable (test, validación, resultado esperado).
- Research caduca: lo que cacheé para esta feature se borra cuando termina.
- Tickets verticales: cada uno entrega algo observable.
- QA con plan escrito. El agente propone los escenarios; el humano decide qué importa.
Todo el marco está también en la guía AI Engineering.
¿Cuál de las 7 fases te salta la gente de tu equipo? En mi experiencia, la 7. Cuéntame en los comentarios cómo hacéis QA del código generado.