Skip to main content

​
Capítulo 2: AI-First no es vibe coding

El developer AI-First no escribe código — diseña sistemas, dirige ejecución, cura contexto, y valida resultados. Los cuatro roles a la vez.

​
El espectro

Hay un espectro en cómo los equipos usan AI para construir software. Los extremos son claros. El medio es donde está la oportunidad — y la confusión.

​
Desarrollo tradicional

El humano escribe todo el código. La AI, si aparece, es autocompletado inteligente — sugiere la siguiente línea, completa una función, genera un snippet. El humano toma el 95% de las decisiones y escribe el 95% del código. La AI es un asistente de escritura, no un constructor. Funciona. Es predecible. Pero no aprovecha lo que la AI puede hacer hoy.

​
Vibe coding

El humano describe una idea en lenguaje natural y la AI genera todo: frontend, backend, base de datos, estilos. El humano no planifica, no documenta, no estructura — simplemente pide y evalúa el resultado. Si se ve bien, avanza. Si no, pide correcciones o empieza de nuevo. El vibe coding tiene un atractivo innegable: la velocidad inicial es intoxicante. En 10 minutos tienes algo que se ve como un producto. El problema aparece en el minuto 11 — cuando quieres agregar la segunda feature y la AI no recuerda la primera, o cuando el diseño cambia con cada prompt, o cuando descubres que la mitad de la interfaz es decorativa. El vibe coding funciona para prototipos desechables, demos, y pruebas de concepto que nadie va a mantener. No funciona para productos que van a producción, que necesitan evolucionar, o que más de una persona va a tocar.

​
AI-First (donde vive Blueprint)

El humano diseña el sistema, documenta el contexto, y define las reglas. La AI genera el 80-90% del código siguiendo ese contexto. El humano valida, corrige, y mantiene la documentación actualizada para la siguiente sesión. La diferencia con el vibe coding no es de grado — es de naturaleza. El vibe coder pide y espera. El developer AI-First prepara, dirige, y verifica. El vibe coder trabaja con prompts. El developer AI-First trabaja con sistemas de contexto. La diferencia con el desarrollo tradicional tampoco es de grado. El developer tradicional invierte su tiempo en escribir código. El developer AI-First invierte su tiempo en diseñar la arquitectura, curar el contexto, y validar los resultados. El código lo genera otro — y ese otro es extraordinariamente rápido pero necesita dirección clara.

​
Los 4 roles del developer AI-First

En desarrollo tradicional, un developer es fundamentalmente un escritor de código. En desarrollo AI-First, el código lo escribe la AI. Entonces, ¿qué hace el humano? Hace cuatro cosas, todo el tiempo, simultáneamente:

​
Arquitecto

Diseña la estructura del sistema antes de que exista una línea de código. Define las capas, los patrones, las tecnologías, y las restricciones. La AI puede proponer una arquitectura, pero la decisión de adoptarla — con sus tradeoffs de escalabilidad, mantenibilidad, y complejidad — es humana. El arquitecto responde: ¿cómo se estructura esto? En la práctica: escribe (o valida) el PRD, la arquitectura técnica, el schema de BD. Define la cadena de artefactos del capítulo anterior. Estas decisiones no son delegables porque dependen de contexto que la AI no tiene — el tamaño del equipo, el presupuesto, la experiencia disponible, las restricciones del negocio.

​
Director

Define qué se construye en cada sesión, en qué orden, y con qué restricciones. Le dice a la AI qué hacer, qué no tocar, y qué resultado esperar. No microgestiona cada línea — da la dirección y deja que la AI ejecute. El director responde: ¿qué hacemos ahora y cómo? En la práctica: prepara el prompt de implementación con contexto completo. Define la secuencia (schema → backend → frontend → tests). Divide features grandes en pasos pequeños. Detiene la sesión cuando la AI va por mal camino. Es el Protocolo de Desarrollo de Features en acción.

​
Curador

Mantiene el contexto del proyecto vivo y actualizado. Cada sesión de implementación produce conocimiento nuevo — gotchas descubiertos, patrones que funcionan, anti-patrones que se deben evitar. El curador captura ese conocimiento y lo integra en los documentos que la AI lee. El curador responde: ¿qué sabe la AI sobre este proyecto? En la práctica: mantiene el AGENTS.md con reglas críticas. Actualiza la guía de diseño con cada componente nuevo y cada gotcha. Agrega anti-patrones a “What NOT to Do” conforme se descubren. Ejecuta el Protocolo de Cierre de Sesión. Sin el curador, cada sesión empieza un poco más perdida que la anterior.

​
Validador

Revisa lo que la AI produce con criterio técnico y de producto. No lee cada línea de código — verifica que el resultado cumple la spec, que los tests pasan, que el diseño es consistente, y que no se rompió nada existente. El validador responde: ¿esto está bien? En la práctica: ejecuta los checklists post-implementación. Verifica que la documentación que la AI actualizó es precisa. Cruza el resultado con el PRD y la guía de diseño. Aprueba o rechaza antes de avanzar al siguiente paso.

​
Los 4 roles no son secuenciales

No se ejerce un rol y luego otro. En una sesión típica, el developer AI-First alterna entre los cuatro constantemente: 
"Vamos a implementar el módulo de tags"          → Director
"Seguir la clean architecture de 3 capas"        → Arquitecto
"No modificar el módulo de decisiones"            → Director
[AI implementa]
"Los tests pasan, el endpoint responde bien"      → Validador
"Descubrí que ScrollArea necesita altura fija"    → Curador (agrega gotcha)
"Ahora el frontend, usar shadcn/ui"               → Director
[AI implementa]
"El diseño no es consistente con la tabla anterior" → Validador
"Agregar regla: siempre ícono de ojo para detalle" → Curador
Esta alternancia constante es lo que hace que el rol sea nuevo — no existe en el desarrollo tradicional porque el humano escribe el código en vez de dirigir a otro que lo escribe.

​
Qué NO es AI-First

​
No es “la AI hace todo sola”

El developer AI-First no pone un prompt y se va a tomar café. Está presente durante toda la sesión, validando paso a paso, corrigiendo el rumbo, y tomando decisiones que la AI no puede tomar. La AI es el ejecutor más rápido que ha existido, pero sin dirección humana produce los mockups decorativos del capítulo anterior.

​
No es reemplazar developers

Un equipo AI-First no necesita menos developers — necesita developers con habilidades diferentes. Menos tiempo escribiendo for loops, más tiempo diseñando sistemas, definiendo arquitecturas, y manteniendo contexto. Las habilidades de programación siguen siendo necesarias para validar lo que la AI produce, entender los tradeoffs, y corregir errores que la AI no detecta.

​
No es solo para developers

Un product designer que entiende arquitectura y sabe validar código puede ser un developer AI-First efectivo. Un product owner que puede escribir specs claras y evaluar resultados puede dirigir sesiones de implementación. AI-First reduce la barrera de quién puede construir software, pero no la elimina — todavía hay que entender qué se está construyendo.

​
No es una bala de plata

Hay proyectos donde AI-First no funciona bien: sistemas legacy sin documentación (la AI no tiene contexto de dónde partir), investigación pura (no hay spec posible porque no se sabe qué se busca), código que requiere optimización de bajo nivel (la AI genera código funcional pero no necesariamente eficiente), y sistemas con requisitos de seguridad extremos (la AI puede introducir vulnerabilidades sutiles que un humano no detecta en la validación).

​
DEV AI First: el enfoque dentro del enfoque

Blueprint AI-First es la metodología. DEV AI First es el enfoque de desarrollo que la metodología enseña. La distinción importa: DEV AI First como enfoque significa: diseñar todo el flujo de desarrollo asumiendo que la AI es el builder principal. No es “desarrollo tradicional con AI auxiliar” — es un flujo rediseñado desde cero donde:
  • La documentación se escribe para que la AI la entienda, no solo los humanos
  • La arquitectura se define antes del código, no emerge del código
  • Las convenciones se codifican explícitamente, no se asumen implícitamente
  • La verificación es sistemática, no ocasional
  • El contexto es un producto, no un subproducto
Cuando un equipo adopta DEV AI First, no está “agregando AI a su proceso” — está cambiando su proceso para que la AI sea central. La cadena de artefactos, los protocolos, los templates — todo existe porque la AI es el builder principal y necesita una infraestructura de contexto para funcionar bien.

​
El cambio de mentalidad

La transición más difícil no es técnica. Es mental. En desarrollo tradicional, el valor del developer se mide en código producido. Más líneas, más commits, más features implementadas. Documentar se siente como “no trabajar” porque no produce código. En desarrollo AI-First, el valor del developer se mide en calidad de dirección. Un AGENTS.md bien escrito produce mejores resultados que 8 horas de vibe coding. Una guía de diseño con gotchas documentados evita horas de correcciones. Un protocolo de cambios previene regresiones. El cambio de mentalidad es: tu trabajo más productivo ya no se ve como trabajo. Las horas que inviertes preparando artefactos, curando contexto, y documentando anti-patrones son las horas que más impacto tienen en la calidad y velocidad del proyecto. Pero no se ven como “programar” — se ven como “documentar”. Equipos que no internalizan este cambio terminan con un developer que “vibecodeá rápido” y tres developers arreglando los problemas que el vibe coding creó. Equipos que sí lo internalizan terminan con un developer AI-First que produce el equivalente a un equipo completo — pero invierte la mitad de su tiempo en contexto, no en código.

​
Dónde empieza el viaje

Si vienes del vibe coding y quieres estructura: empieza por la cadena de artefactos (capítulo 3) y el template de AGENTS.md (capítulo 4). Solo eso ya transforma tu flujo. Si vienes del desarrollo tradicional y quieres velocidad: empieza por los protocolos (capítulos 7-10). Son procesos concretos que puedes adoptar mañana. Si eres un líder y quieres que tu equipo adopte esto: empieza por el caso de negocio (capítulo 1, que acabas de leer) y la guía de onboarding (capítulo 11). El resto del libro detalla cada pieza del sistema. Pero el fundamento es este capítulo y el anterior: documentar antes de codear tiene un ROI medible, y el developer AI-First es un rol nuevo que combina arquitectura, dirección, curaduría, y validación. El código lo escribe la AI. Tu trabajo es todo lo demás.