Más Allá del Vibe Coding: Construyendo Software Profesional con IA y Metodología de Ingeniería
· 10 min de lectura
La revolución de la IA en el desarrollo de software tiene un problema de credibilidad. El "vibe coding" — la práctica de generar código a través de prompts con supervisión mínima — se ha convertido en la percepción por defecto de lo que es el desarrollo asistido por IA. Los resultados son predecibles: prototipos frágiles, cero tests, y decisiones de arquitectura tomadas por autocomplete.
Pero existe un enfoque fundamentalmente diferente. Uno que usa IA dentro de una metodología de ingeniería estructurada — planificando antes de construir, testeando junto con la implementación, revisando antes de desplegar.
Este artículo documenta cómo dos proyectos brownfield reales fueron reconstruidos desde cero usando el BMad Method y Claude Code CLI — no como experimentos de vibe coding, sino como proyectos de ingeniería con estándares profesionales. El resultado combinado: 62 historias, 11 épicas, 1,779 tests, y cero incidentes en producción.
El Problema del Vibe Coding
El vibe coding es seductor. Describes lo que quieres, la IA genera código, y algo aparece en pantalla en minutos. Para prototipos desechables, esto funciona. Para software de producción, es una receta para el desastre:
Sin arquitectura: El código crece orgánicamente sin estructura, haciendo que los cambios sean cada vez más costosos
Sin tests: El primer refactor rompe todo, y nadie sabe qué se rompió ni por qué
Sin quality gates: Vulnerabilidades de seguridad, fallos de accesibilidad y problemas de rendimiento se despliegan en silencio
Sin ciclo de aprendizaje: Los mismos errores se repiten porque no hay un proceso para capturarlos y prevenirlos
El problema fundamental no es la IA — es la ausencia de disciplina de ingeniería alrededor de ella. La IA amplifica cualquier proceso que le alimentes: si le das caos, obtienes caos más rápido.
Un Enfoque Diferente: BMad Method + Claude Code
El BMad Method es un framework de desarrollo asistido por IA que trata a la IA como un equipo de agentes de ingeniería especializados, no como un generador de código genérico. Piensa en ello como un equipo virtual de ingeniería:
Un Product Manager escribe el PRD con requerimientos medibles
Un Arquitecto diseña la solución técnica con trade-offs documentados
Un Diseñador UX define especificaciones de interfaz y criterios de accesibilidad
Un Scrum Master divide el trabajo en épicas e historias trazables
Un Developer implementa cada historia siguiendo criterios de aceptación estrictos
Un QA Engineer diseña la estrategia de testing
Un Code Reviewer realiza revisiones adversariales multi-capa
Cada agente tiene experiencia profunda en su dominio. Cada artefacto alimenta al siguiente. Los quality gates previenen avanzar con trabajo incompleto. Las retrospectivas al cierre de cada épica cierran el ciclo de aprendizaje.
Combinado con Claude Code CLI (impulsado por Claude Opus), esto crea un pipeline de ingeniería donde la IA opera bajo la misma disciplina que esperarías de un equipo profesional. Cada línea de código se traza a un requerimiento. Cada requerimiento se traza a una necesidad de negocio. Nada se despliega sin tests, revisión y validación.
El insight clave: la metodología es agnóstica del stack. El mismo workflow aplica tanto si estás construyendo una aplicación web como una app móvil. Para demostrarlo, la apliqué a dos proyectos completamente diferentes.
Caso de Estudio: Portfolio — Flutter Web → Stack Moderno
Mi portfolio anterior fue construido con Flutter Web hace casi 2 años. Flutter Web renderiza en un canvas HTML — los motores de búsqueda no ven nada, los lectores de pantalla no pueden navegar el contenido, y la tecnología se había estancado. Para un portfolio de desarrollador, estos eran problemas descalificantes.
Los agentes BMad produjeron una especificación de ingeniería completa antes de escribir una sola línea de código: un Product Brief definiendo visión y personas, un PRD con 49 requerimientos funcionales y 29 no funcionales, un Documento de Arquitectura seleccionando Astro 6 SSG + Svelte 5 + Firebase + TypeScript strictest + Tailwind CSS 4, y una Especificación UX con 46 requerimientos de diseño y criterios de compliance WCAG 2.1 AA.
La implementación se ejecutó en 5 épicas a lo largo de 20+ horas:
Épica 1 — Fundación (10 historias): Infraestructura de testing, pipeline CI/CD, Zod schemas, design system, i18n, theming. 146 tests, 54 patches de code review.
Épica 2 — Sitio Público (8 historias): Todas las páginas públicas, migración de datos del schema Flutter, View Transitions API, diseño responsive. 388 tests totales.
Épica 3 — Panel Admin (8 historias): Firebase Auth, CRUD completo, ImageService con retry logic y orphan cleanup. 879 tests.
Épica 4 — Sistema Blog (5 historias): Editor rico TipTap, contenido bilingüe, OpenGraph cards, drag-drop ordering. ~1,279 tests. Primera historia en pasar code review con cero patches.
Épica 5 — SEO y Accesibilidad (6 historias): Datos estructurados, sitemap, auditoría WCAG 2.1 AA con axe-core, optimización de performance. 1,406 tests totales, cero incidentes en producción.
La arquitectura entregó resultados medibles: las páginas públicas no envían JavaScript por defecto, con la página de inicio en solo 25.8 KB de JS total — la mitad del presupuesto de 50 KB. TypeScript en modo strictest atrapa errores de tipo antes del runtime. Los schemas Zod validan cada documento de Firestore en los boundaries. Lighthouse CI exige scores de 95+ en cada despliegue.
Caso de Estudio: TimeMoney — Legacy Dart → Flutter Moderno
TimeMoney es una app Flutter multiplataforma para que trabajadores por hora registren sus horas y calculen pagos, corriendo en iOS, Android, Web y Windows. Fue construida hace tres años con Dart 2.x, usando patrones obsoletos y sin arquitectura formal.
El mismo workflow del BMad Method produjo: un PRD con 24 requerimientos funcionales y 11 no funcionales, un documento de arquitectura especificando Clean Architecture feature-first con una estrategia de dual datasource (ObjectBox para plataformas nativas, Drift con WASM + OPFS para web), y una descomposición completa mapeando los 53 requerimientos detallados a 25 historias en 6 épicas.
La implementación se ejecutó en 6 épicas:
Épica 1 — SDK Foundation (4 historias): Dart 2.19 → 3.11+, Flutter 3.7.5 → 3.41+, resolución de dependencias.
Épica 2 — Arquitectura (5 historias): Reestructuración feature-first con capas domain/data/presentation, componentes compartidos.
Épica 3 — State Management (6 historias): Sealed classes de Dart 3 para estados BLoC, patrón ActionState genérico, infraestructura de tests.
Épica 4 — Multi-Plataforma (5 historias): Base de datos Drift para web, inyección de dependencias platform-aware via conditional imports, i18n bilingüe.
Épica 5 — Testing (3 historias): 200 nuevos tests (121% de crecimiento), widget tests, golden tests de regresión visual. 92.3% de cobertura alcanzada.
Épica 6 — Polish (2 historias): Pipeline CI/CD de 8 jobs, Maestro E2E con screenshots y video demo auto-generados.
El resultado: 373 tests con 92.3% de cobertura, cero deuda técnica diferida, 100% de use cases y BLoCs con cobertura completa, corriendo en cuatro plataformas desde un solo codebase. El monad Either (fpdart) asegura manejo de errores railway-oriented en todo el proyecto. Las sealed classes reemplazan patrones legacy con exhaustive matching en tiempo de compilación.
El Efecto de Calidad Acumulativa
El patrón más poderoso en ambos proyectos fue el efecto de calidad acumulativa — cada épica mejoró respecto a la anterior porque las retrospectivas cerraron el ciclo de aprendizaje.
En el portfolio, los patches de code review bajaron de 54 (Épica 1) a 26 (Épica 5) — una reducción del 52%. Los items diferidos cayeron de 12 a 1. En TimeMoney, los patches dentro de la Épica 5 sola bajaron de 14 a 2 en tres historias.
Esto no fue porque el modelo de IA mejoró. Fue porque el proceso mejoró. Cada retrospectiva capturó qué falló y qué cambiar:
Specs basadas en versiones obsoletas del framework → la validación de investigación se volvió obligatoria antes de crear historias
Cero tests E2E admin a pesar de tener diseños de tests → el Scrum Master ahora verifica que existan tareas de tests en cada historia
Tests tautológicos (verificando mocks en vez de comportamiento) detectados en review → el testing substantivo se volvió un criterio explícito de revisión
La lección: la IA no se auto-mejora dentro de un proyecto. El proceso sí. La metodología crea un ciclo de retroalimentación que hace cada épica subsecuente más eficiente y más correcta que la anterior.
Combinado entre ambos proyectos: 62 historias completadas, 1,779 tests escritos, cero incidentes en producción, 10 retrospectivas de épica, y una tendencia de mejora medible en métricas de calidad desde la primera épica hasta la última.
Por Qué Esto No Es Vibe Coding
Seamos directos con el contraste:
El vibe coding genera código desde prompts y despliega lo que compile. No hay PRD, ni documento de arquitectura, ni estrategia de testing. Cuando aparecen bugs, la respuesta es "pedirle a la IA que lo arregle" — creando un ciclo de parches sobre parches sin trazabilidad ni aprendizaje.
El desarrollo aumentado con ingeniería usa IA dentro de una metodología. Cada línea de código se traza a un requerimiento. Cada requerimiento se traza a una necesidad de negocio. Los tests se escriben junto con la implementación, no después. El code review atrapa lo que los tests no detectan. Las retrospectivas previenen que los mismos errores se repitan.
La diferencia no es el modelo de IA. Es el proceso alrededor de ella.
Este portfolio tiene 1,406 tests no porque la IA los generó automáticamente, sino porque la metodología los requirió en cada paso. Cumple WCAG 2.1 AA no porque la IA sepa de accesibilidad, sino porque la especificación UX lo definió como requerimiento no negociable, la arquitectura lo planificó, y el code review lo validó.
La Dirección en la Que Se Mueve la Industria
Las empresas no necesitan desarrolladores que escriban mejores prompts. Necesitan desarrolladores que puedan dirigir a la IA para producir software de calidad profesional — con arquitectura, tests, accesibilidad y mantenibilidad. La demanda no es por más código; es por código más confiable.
Los desarrolladores que prosperarán en esta era son los que traigan disciplina de ingeniería a la IA. Los que entiendan que un PRD previene scope creep, que el code review atrapa lo que los tests no detectan, que las retrospectivas previenen errores repetidos, y que los quality gates no son overhead — son lo que hace que el código generado por IA sea digno de producción.
Estos son proyectos pequeños — un portfolio personal y una app de utilidad. Pero la metodología escala. El mismo workflow del BMad Method que produjo 62 historias y 1,779 tests en estos proyectos puede producir cientos de historias para aplicaciones enterprise. Los quality gates, las retrospectivas, las revisiones adversariales — son fundamentos de ingeniería que se vuelven más valiosos, no menos, cuando la IA acelera el ritmo.
Explóralo Tú Mismo
Ambos proyectos son completamente open source. Cada artefacto de planificación, archivo de historia y retrospectiva está disponible en los repositorios:
Portfolio (Web): github.com/ChrisBP-Dev/portfolio
TimeMoney (Flutter): github.com/ChrisBP-Dev/TimeMoney
Metodología: BMad Method
Herramienta IA: Claude Code CLI de Anthropic (Claude Opus)
Los historiales de commits cuentan las historias completas — desde los product briefs hasta los deployments a producción. Estudiálos, haz fork, y aplica la metodología a tus propios proyectos brownfield.
El futuro del desarrollo de software no es la IA reemplazando ingenieros. Son ingenieros usando IA con la disciplina que el oficio demanda.