00:00:00Todo el mundo sabe que se necesita un marco de trabajo para usar agentes de programación, pero no muchos
00:00:04tienen uno que sea simple, realmente propio y que puedan evolucionar con el tiempo. Ahora bien,
00:00:09hay muchos marcos de trabajo sobreingeniados en GitHub. Todos esos sistemas multi-agente que
00:00:15la gente está creando... respeto su trabajo, pero muchas veces solo necesitas algo
00:00:19realmente simple que cumpla con el objetivo. Porque sé que tienes buenas ideas que
00:00:24quieres construir, y no quieres pasar más tiempo creando flujos de trabajo de agentes que
00:00:29programando de verdad, y eso es lo que tengo para ti ahora. Este es mi marco de trabajo simplificado
00:00:35que utilizo cada vez que empiezo un proyecto nuevo con mi agente de programación. Ahora bien,
00:00:40el desarrollo "Brownfield", trabajar en una base de código existente, es algo distinto. Eso es para otro video. Aquí,
00:00:45nos enfocamos en el desarrollo "Greenfield". Queremos un marco simple para ponernos en marcha
00:00:50lo más rápido posible, construyendo algo nuevo, y todo lo que cubro aquí es universal.
00:00:56Estos principios se aplican sin importar el agente de programación que estés usando. Así que hay dos
00:01:00partes en este video, y voy a realizar una construcción en vivo contigo mientras explico todo
00:01:05para que sea súper concreto. Lo que tengo ahora mismo en mi base de código no es prácticamente nada
00:01:11más allá de mi capa de IA. Hay algunos comandos y habilidades que traje conmigo. Esto es lo que uso como
00:01:16punto de partida para cada uno de mis proyectos. Vamos a crear algo desde cero,
00:01:21así que debemos empezar con la planificación inicial, creando lo que se llama un PRD. Este es el
00:01:27alcance inicial de trabajo que tenemos para crear el producto mínimo viable de nuestra aplicación. Y hay
00:01:32mucho que hacer aquí, configurando nuestra capa inicial de IA antes de entrar en la programación real.
00:01:37Luego tomamos nuestro PRD y lo dividimos en fases de trabajo, y lo resolvemos
00:01:43con bucles PIV. Hablaré de lo que eso significa, veremos un ejemplo, y luego,
00:01:47mientras realizo toda esta implementación, cubriré las cuatro reglas de oro que queremos
00:01:52seguir en todo momento. Estas reglas de oro encajarán de forma natural mientras
00:01:57creo el PRD, nuestra capa de IA y realizo un bucle PIV. Por ejemplo, la gestión del contexto.
00:02:03El contexto es tu recurso más valioso al trabajar con asistentes de programación por IA. Ese será un
00:02:08tema recurrente. También la creación de comandos y habilidades para todo y la mentalidad de evolución del sistema,
00:02:14porque lo que buscamos con nuestro sistema es crear algo que sea fiable y
00:02:18repetible. Así que hablaré de eso mientras avanzo. Solo intento resaltar algunos
00:02:23de los temas centrales que verán en todo esto. Va a ser un video con mucho valor. Y así,
00:02:28comenzaremos aquí con nuestra planificación inicial, creando lo que me gusta llamar la capa de IA. Explicaré
00:02:34qué es eso y la construiremos juntos ahora mismo. Tu capa de IA son todos los activos en tu base de código
00:02:39que creaste para que sirvan de contexto a tu agente. Como tu PRD: ¿qué vamos a construir?
00:02:45Tus reglas globales: ¿cómo lo vamos a construir? Los comandos: así tenemos flujos de trabajo reutilizables para
00:02:50nuestro agente. Nos enfocaremos en el principal primero. Y también sub-agentes, para poder delegar
00:02:55la investigación. Y generalmente, cómo trabajo con mi capa de IA (y tengo esto como recurso para ti),
00:03:01es que tengo un conjunto genérico de comandos que traigo a cualquier proyecto nuevo. El punto
00:03:07es que a medida que mi base de código crece y empiezo a desarrollarla, también evolucionaré mis comandos para
00:03:13hacerlos más potentes para el caso de uso específico, haciéndolos más acordes a mi código.
00:03:18Esa es mi recomendación general para ti. Usa esto como punto de partida si quieres. Dejaré
00:03:23un enlace al repositorio de GitHub en la descripción. El punto de mantener esto tan simple es que
00:03:27puedas tomarlo tú mismo y evolucionarlo fácilmente para tu caso de uso y tu forma de trabajar. Por eso
00:03:33recomiendo algo así sobre marcos más complejos como Beemad o el spec kit de GitHub.
00:03:38Son muy potentes, pero es difícil hacerlos realmente tuyos. Quiero que seas capaz de
00:03:42apropiarte de esto. Ahora te mostraré cómo es crear un PRD completo. Definir las
00:03:48reglas iniciales para nuestra base de código. Incluso personalizaremos un poco nuestro primer comando. Y luego
00:03:52hablaré de los sub-agentes. Sé que estamos planeando mucho antes de escribir
00:03:57el código real con los bucles PIV, pero es importante hacerlo. Planear
00:04:03de antemano puede parecer que vamos demasiado lento, pero si creamos un plan realmente bueno, con buenas
00:04:07reglas y un buen PRD, significa que todo nuestro desarrollo posterior será mucho más rápido
00:04:13y fiable. Empecemos con nuestro PRD. Mucha gente lo llama una especificación. De nuevo, es
00:04:18todo el alcance de trabajo para construir la versión inicial de nuestra aplicación. Y después de
00:04:24ese punto, cuando tengamos una buena base, pasaremos al desarrollo brownfield. Ese es el
00:04:28próximo video que tengo preparado. Mantente al tanto. Lo que haré aquí con Claude Code,
00:04:34en este proyecto básicamente vacío aparte de mi capa de IA, es tener una conversación casual
00:04:40al principio. Solo le contaré mi idea, quizás algunas ideas sobre el stack tecnológico y la
00:04:45arquitectura. Empiezas de forma desestructurada, lo que también facilita el comienzo.
00:04:50Y eventualmente llegas al punto en el que usas tu conversación como contexto para crear
00:04:55un PRD estructurado. Tengo un comando que nos ayudará, lo veremos cuando
00:05:01lleguemos allí, pero primero empecemos con nuestra idea. Lo que quiero construir, solo como
00:05:06un ejemplo divertido para este video, es algo parecido a Linktree, más bien una versión auto-hospedada
00:05:12donde puedas configurar tu propia página de aterrizaje con varios enlaces organizados.
00:05:16Con analíticas como el ratio de clics en los diferentes enlaces. Quiero construir algo
00:05:20como esto. Es un buen ejemplo ahora porque no es algo trivial que podrías
00:05:24programar al vuelo fácilmente con las funciones geniales que podemos añadir, pero tampoco
00:05:29va a ser excesivamente complicado como para no tener nada al final de este video.
00:05:33Voy a usar una herramienta de voz a texto para esto. Recomiendo mucho usar
00:05:39algo como Aqua Voice. Es la que yo uso. Hay muchas buenas opciones gratuitas y de código abierto
00:05:43también. Whisper Flow, Epicenter Whispering... grandes herramientas, pero me encanta usar voz
00:05:48a texto porque te prometo que nunca podré escribir 226 palabras por minuto. Así que
00:05:54usaré una herramienta así para soltar todas las ideas al principio sobre lo que quiero construir. Y esto
00:05:59va a ser algo muy crudo, pero voy a hacer una lluvia de ideas en vivo para ustedes ahora mismo, y
00:06:03presten atención a lo que le pido a Claude Code, porque esto es tan importante como las ideas que
00:06:09estoy compartiendo. Explicaré un poco sobre eso después también. Por cierto, puedes hacer todo
00:06:13esto con cualquier asistente de programación por IA. Aquí vamos: quiero construir un creador de páginas de enlaces en bio.
00:06:20Algo parecido a Linktree; los usuarios pueden crear una cuenta. Pueden crear su propia
00:06:24página de aterrizaje donde especifican los enlaces. Pueden cambiar el orden. Quiero que puedan tener
00:06:29analíticas para ver el ratio de clics en sus enlaces también. Y que puedan personalizar el
00:06:33tema. Para el stack tecnológico, estoy pensando probablemente en Next.js, me gustaría usar Neon para
00:06:37mi base de datos y Neon Authentication. Así que definitivamente activa un sub-agente para investigar
00:06:43eso. Y para la arquitectura, no soy muy exigente. Definitivamente quiero tus recomendaciones
00:06:48al respecto. Y sobre cómo vamos a manejar los temas y la construcción de enlaces, todo eso. Así que
00:06:55quiero que también actives un agente para que investigue en la web las mejores prácticas para
00:07:00crear este tipo de aplicaciones estilo Linktree. Y luego quiero que vuelvas a mí
00:07:04con una serie de preguntas para que estemos en sintonía incluso con los pequeños detalles de lo que
00:07:10estamos construyendo aquí. Muy bien, voy a enviar eso y se transcribirá
00:07:14en un par de segundos. Ahí está. Y listo, ya estamos en marcha. Lo más importante
00:07:20que hice ahí fue justo al final, cuando le dije que me hiciera un montón de preguntas
00:07:25después de investigar. Esto es realmente importante recalcarlo. Tu meta número uno
00:07:32en cualquier planificación con agentes de programación es reducir el número de suposiciones que el agente
00:07:37está haciendo. Porque al final, cuando un agente de programación comete un error en tu código,
00:07:42la mitad de las veces no es que el código sea malo, sino que simplemente no estaban alineados sobre qué
00:07:48debía construir exactamente. El dicho común es que una línea de código malo es solo una línea de código malo.
00:07:54Una línea de un mal plan son quizás cien líneas de código malo. Pero una mala línea
00:08:02en un PRD podría resultar en mil líneas de código malo por falta de alineación. He estado
00:08:08experimentando mucho con formas de reducir las suposiciones a lo largo del tiempo. Y hacer que el
00:08:13agente de programación me lance una ráfaga de preguntas me ha funcionado increíblemente bien.
00:08:17Especialmente Claude Code con su herramienta de preguntas al usuario, donde puede dar opciones múltiples o
00:08:23permitir escribir tu propia respuesta. Veremos eso en un segundo. Es muy potente. Hacen un gran trabajo pensando
00:08:28en todos los casos borde y detalles pequeños en los que quizás ni siquiera estamos pensando. Es difícil para nosotros
00:08:33razonar por nuestra cuenta qué suposiciones podría hacer el agente. Así que es muy, muy potente. Y
00:08:38lo otro que hice, como pueden ver aquí, es que tenemos diferentes sub-agentes que están
00:08:42ejecutando investigación. Me encanta usar sub-agentes para cualquier planificación, crear el PRD,
00:08:48o incluso para el proceso de planificación de los bucles PIV de los que hablaremos en un rato. Con
00:08:53Claude Code, no tengo que crear mis propios sub-agentes porque tenemos los de exploración e
00:08:59investigación integrados en la herramienta. Para otros agentes de programación, puede que tengas que
00:09:04construir los tuyos, por eso quería mencionarlo aquí. Pero casi cualquier buen agente de
00:09:08programación hoy en día admite la idea de sub-agentes. Me encanta usarlos para investigar. La razón
00:09:14es el aislamiento del contexto. De nuevo, uno de los temas clave aquí es que queremos proteger el
00:09:20contexto de nuestro agente principal. Y la razón por la que investigar es un caso de uso tan bueno para sub-agentes
00:09:26específicamente es porque cuando exploran, miran todo. Hacen mucha
00:09:32exploración de la base de código o investigación web. Cargan decenas o incluso cientos de miles de
00:09:36tokens para su trabajo. Pero en realidad, solo nos importan sus hallazgos, el resumen al final
00:09:41que devuelven a nuestro contexto principal. Así mantenemos limpio nuestro contexto principal. No recomiendo
00:09:46usar sub-agentes para la implementación porque en la implementación, usualmente nos importa todo
00:09:51el contexto de los archivos que hemos estado editando y creando. De lo contrario, produce muchas alucinaciones
00:09:57según mi experiencia. Por eso Claude Code no tiene agentes integrados para implementación.
00:10:01Es solo para investigación. Y eso es exactamente lo que estamos viendo aquí mismo. Voy a dejar
00:10:06que todo termine y volveré cuando tenga las preguntas para nosotros. Muy bien, toda la investigación
00:10:12de los sub-agentes terminó y ya tenemos el conjunto inicial de preguntas para responder. Mientras las
00:10:17reviso, creo que lo apreciarán tanto como yo porque estamos aclarando muchísimas
00:10:22cosas. Cada pregunta que respondemos aquí elimina una suposición del agente de
00:10:26programación. Y como es de opción múltiple y normalmente una de las opciones que presenta es buena, podemos
00:10:31avanzar muy rápido. Así podemos estar bastante seguros al ir a la implementación de que
00:10:36tenemos todos los detalles atados. Por ejemplo: ¿cómo debería funcionar la estructura de la URL pública?
00:10:41Me gusta la opción número uno y ¡pum!, a la siguiente. ¿Cuántas páginas debería
00:10:46poder crear cada usuario? Digamos solo una página por usuario. Algunas de estas simplemente las
00:10:50seguiré con los valores por defecto, pero hay muchos casos donde realmente
00:10:54malinterpreta algo fundamental y ahí es donde puedo escribir mi propia respuesta para aclarar. No
00:10:59sé si encontraré un ejemplo justo aquí, pero lo que haré es ir
00:11:03respondiendo todas sus preguntas y volveré cuando haya terminado. No necesitan verme contestar
00:11:07cada pregunta porque puede hacer hasta 20 o 25 preguntas. Realmente lo lleva lejos.
00:11:14De nuevo, hay que tener paciencia con esto, pero cada pregunta que respondes podría
00:11:19ahorrarte tener cientos de líneas de código malo. Aquí hay un buen ejemplo donde quiero
00:11:24aclarar algo totalmente diferente a lo que sugirió. Dice que este es el segundo
00:11:30lote de preguntas que Claude me ha hecho, por cierto. ¿Debería el editor de enlaces tener un marco de teléfono
00:11:35con vista previa en vivo? Algo como Lovable o Bolt.new, donde ves lo que creas y
00:11:39tienes el constructor a la izquierda, ¿o debería ser integrado? Y yo quiero tener
00:11:44ambas opciones. Así que puedo chatear sobre esto. Me hará las otras preguntas
00:11:49después, pero ahora podemos tener una pequeña conversación sobre esto específicamente. Diré
00:11:53aquí: quiero tener un editor integrado, pero quiero la opción de poder ver
00:11:58la vista previa también. Básicamente quiero tres botones: uno donde solo vea el editor, uno
00:12:03donde vea ambos, y uno donde solo vea la vista previa. Envío eso, volverá con
00:12:08más preguntas y continuaré el proceso. Aquí estamos. Claude terminó de hacerme
00:12:13un montón de preguntas, probablemente más de las necesarias, pero puedes ajustar esto como quieras.
00:12:18Ahora es momento de crear nuestro PRD porque, como pueden ver en el resumen final de la especificación,
00:12:23realmente tiene una comprensión clara de exactamente qué vamos a construir,
00:12:28incluso de dónde lo voy a desplegar. Lo desplegaré en Vercel después de construirlo.
00:12:31Esto es fantástico. Siento que ya no está asumiendo casi nada. Así que ahora lo que voy a hacer
00:12:36es simplemente ejecutar mi comando "create PRD". Lo pondré en .claude/prd.md. Puedes ponerlo
00:12:43donde quieras. Incluso llamarlo como quieras. Estoy usando el comando que
00:12:47mencioné antes porque, volviendo a nuestras cuatro reglas de oro, una de las principales
00:12:53es "comandificar" todo. Si haces algo más de dos veces, y yo definitivamente he comenzado
00:12:59más de un par de proyectos, deberías convertirlo en un comando. También conocidos como habilidades,
00:13:03porque Claude Code fusionó recientemente comandos con habilidades, pero todavía me gusta hacer la distinción:
00:13:10los comandos son cosas que tú invocas, como /commit. Y las habilidades son cuando un agente
00:13:15decide leer contexto, como entender cómo hacer algo nuevo. Así que estoy creando un comando
00:13:20aquí porque estoy decidiendo que, en este punto de la conversación, quiero ejecutar este comando para
00:13:27generar un PRD estructurado. Como parte de este comando, le doy la estructura exacta,
00:13:32todas las diferentes secciones que quiero en el PRD. De esa forma hago que todo mi proceso sea repetible,
00:13:38¿verdad? Una gran parte de este sistema que les muestro es que pueden crear algo que les funcione
00:13:42y luego repetirlo una y otra vez para nuevas funciones y nuevas bases de código.
00:13:48Voy a hacer un /createPRD. Lo dejaré trabajar y volveré cuando tengamos
00:13:53nuestro PRD final. Muy bien, nuestro PRD ya está creado y es muy completo, pero eso es bueno
00:14:00porque no es que vayamos a enviar todo esto a nuestro agente para que lo implemente. En su lugar,
00:14:04vamos a construir cosas por fases descritas en nuestro PRD. No voy a hacer
00:14:09mucha validación en cámara ahora. No vale la pena quitarles tiempo, pero sí quiero decir que
00:14:14es importante leerlo y asegurarse de estar alineados en todo. De lo contrario,
00:14:18esto llevará a mucho código malo en el futuro. Lo primero que quiero resaltar
00:14:22rápidamente es que tenemos nuestro alcance MVP y en él podemos ver todas nuestras preguntas cobrando vida
00:14:29en nuestro PRD. Eso es importante porque la conversación que tuvimos fue realmente solo contexto
00:14:34desestructurado para alimentar el PRD. El PRD es lo único que sobrevivirá. Así que debemos
00:14:40asegurarnos de que toda la conversación con nuestro agente esté plasmada aquí. Tenemos lo que está
00:14:44fuera de alcance, que es igual de importante: lo que no queremos construir ahora. Tenemos toda la
00:14:49estructura de directorios. Ya entiende generalmente qué irá en nuestra base de código,
00:14:53lo cual es bueno porque ya establecimos nuestro stack tecnológico y arquitectura. Y lo
00:14:58importante con esto es que tenemos nuestras fases de trabajo. A partir de esto, cuando usemos nuestro comando principal
00:15:04del que hablaremos luego, podremos establecer: muy bien, ¿qué hemos construido ya
00:15:09en nuestra base de código? ¿Qué tenemos que construir después según el PRD? Esta será una de
00:15:13las piezas de contexto importantes al inicio de cada conversación mientras construimos nuestro MVP. Y por
00:15:19cierto, aquí está la sección donde detallo las fases. Cada una de estas será una
00:15:24implementación granular, uno de nuestros bucles PIV. Construimos la base, construimos la gestión de enlaces,
00:15:29luego el tema, y planearemos cada uno individualmente. Así no intentamos que
00:15:33el agente de programación haga demasiado a la vez. Muy bien, acabamos de crear nuestro PRD y eso
00:15:38es realmente lo principal. Casi estamos listos para nuestra primera implementación. Lo siguiente que
00:15:43tenemos que configurar son nuestras reglas. Esto será bastante básico al principio porque nuestras reglas
00:15:48evolucionarán mucho a medida que evolucione nuestro código real. Estoy usando
00:15:53Claude Code. Me refiero a .cursorrules y rules.md porque es más el estándar universal
00:15:58de nombres para reglas globales. Lo importante aquí es que las restricciones
00:16:04y convenciones que siempre queremos que el agente siga van en nuestro archivo de reglas globales.
00:16:10Son cosas como los comandos para ejecutar nuestra aplicación, la estrategia de pruebas, la de
00:16:16logs. No importa qué estemos construyendo, siempre queremos que el agente vea esto. Así que
00:16:20queremos crear esto ahora, al menos una versión inicial para empezar. El otro
00:16:25componente que tengo aquí es la carpeta de referencia. También puedes usar habilidades de Claude Code para esto,
00:16:30pero esto es más universal porque muchas veces hay otro contexto que queremos que el agente
00:16:35tenga en mente, pero solo cuando trabajamos en partes específicas de la aplicación, como una guía
00:16:40para construir componentes de front-end si estamos en el front-end. La razón por la que no queremos
00:16:44volcar todo esto en nuestro rules.md es que este se carga en el contexto del agente
00:16:49en cada conversación. Y recuerden, el contexto es valioso. Queremos mantenerlo conciso
00:16:55y solo apuntar a cada uno de estos archivos. Podemos decirle al agente: si estás trabajando
00:17:00en el front-end, puedes leer este archivo. O si estás creando nuevos endpoints de API, entonces
00:17:04Básicamente, esto es divulgación progresiva. Tenemos diferentes capas de contexto
00:17:09que el agente puede ir descubriendo para asegurar que solo cargue lo que realmente necesita
00:17:14según la tarea actual. Y para esto, tengo otro comando. De nuevo, hay que "comandificar"
00:17:20todo; igual que tengo una plantilla para mis PRD, tengo una que me gusta para crear
00:17:25mis reglas globales. Primero vamos a explorar lo que ya tenemos en la base de código,
00:17:30porque diseñé esto para que funcione tanto en bases existentes como en nuevas. Realmente,
00:17:35lo único que explorará es el PRD. Determinará nuestro stack tecnológico, la arquitectura,
00:17:38hará investigación web sobre estrategias de prueba y registro, y luego unirá todo eso
00:17:43con mi guía para crear las reglas globales. Aquí tengo la estructura exacta.
00:17:50Se basará en esta plantilla que tengo. Se las mostraré rápidamente también,
00:17:55porque es la plantilla que me encanta usar para todas mis reglas globales. Pueden ver que
00:17:59todo aquí es lo que realmente nos importa del agente pase lo que pase. Como: este es el stack,
00:18:04los comandos para ejecutar y probar cosas, la estructura del proyecto... Básicamente un índice
00:18:08de nuestra base de código, arquitectura, patrones como convenciones de nombres o estrategias
00:18:13de validación. Es bastante básico en general, pero lo crearemos primero,
00:18:17y luego les daré ejemplos de documentos de referencia como contexto secundario bajo demanda.
00:18:22Así que iré a Claude y, en la misma conversación donde creé mi PRD,
00:18:27simplemente ejecutaré "create rules" porque puedo usar toda esta charla como contexto
00:18:33de ayuda. Inmediatamente sabe: "Vale, aquí está el PRD, este es el stack" y cosas así.
00:18:38Bien, el comando terminó y ya tenemos las reglas globales. Aquí las tengo abiertas.
00:18:43Bastante estándar: el stack, los comandos... por ejemplo, que usamos Drizzle ORM
00:18:47para la base de datos, la estructura, arquitectura y patrones de código. Para abreviar,
00:18:52no estoy personalizando mucho ni aplicando mis propias ideas aquí, pero
00:18:57dependiendo de tu nivel técnico, este es el momento de asegurar que las restricciones,
00:19:03convenciones y patrones estén alineados con cómo quieres crear tus bases de código.
00:19:07Puedes dedicarle mucho tiempo si quieres; yo no lo hago ahora para enfocarme en lo conceptual.
00:19:12También le pedí investigar en la web las mejores prácticas para crear
00:19:16componentes de frontend y endpoints de API. Y basándose en eso,
00:19:21creó algo de contexto bajo demanda. De nuevo, estos podrían ser "Claude code skills" si quisieras.
00:19:24Si volvemos a las reglas globales y bajamos a la sección de contexto bajo demanda,
00:19:29aquí está: "Al trabajar en componentes frontend, lee este archivo. Al trabajar en rutas de API,
00:19:34lee este otro". El archivo claud.md es lo único que se carga al inicio, pero
00:19:40el agente decidirá traer lo demás cuando lo necesite. En mi experiencia, es muy bueno
00:19:45referenciando esto, sobre todo si las reglas globales son concisas. Fíjense,
00:19:50no llegan ni a 240 líneas; son 233 para las reglas globales. Luego están api.md y
00:19:58components.md. Estos son mucho más grandes porque cuando estamos en una tarea específica,
00:20:03está bien aportar mucha más información para que el agente tenga una buena guía.
00:20:08Volviendo al diagrama: las reglas definen cómo queremos construir las cosas,
00:20:14y el PRD define qué vamos a construir exactamente. Con eso claro,
00:20:19lo último de lo que quiero hablar es de los comandos, específicamente el comando "prime".
00:20:23Luego planificaremos la primera fase y crearemos el código. En este punto,
00:20:29ya tenemos la capa inicial de IA: el PRD, las reglas y esos comandos genéricos
00:20:34que traje y que pueden usar. Pasamos a la implementación, pero hay un detalle.
00:20:39Al inicio de cada nueva conversación con un asistente de programación por IA,
00:20:44necesitamos que se ponga al día con la base de código. ¿Qué estamos haciendo? ¿Qué sigue?
00:20:50Ahí es donde entra el comando "prime". Ejecutaremos /prime al inicio de cada
00:20:56nueva sesión. Es un proceso guiado para que explore el código y llegue al punto
00:21:02en que tenga el modelo mental listo para la siguiente funcionalidad. Haremos
00:21:06que lea documentación y explore la estructura; puede usar sub-agentes para esto.
00:21:11También revisará el log de git, algo de lo que hablaré más adelante,
00:21:15usar el historial de git como memoria a largo plazo. Así verá cómo ha evolucionado
00:21:21el código, lo que le ayudará a decidir qué construir a continuación. Tras este comando,
00:21:26nos mostrará su comprensión de la base de código. Así validamos que sabe
00:21:31qué está pasando y podemos avanzar. Sin entrar en demasiado detalle con "prime",
00:21:36hacemos operaciones con git para aprovechar el historial. Luego leemos los archivos
00:21:40principales e identificamos puntos clave, como los de entrada de la aplicación.
00:21:45El reporte de salida sirve para validar su comprensión, y podemos evolucionarlo
00:21:49según el proyecto. Un ejemplo pequeño: para leer la documentación principal,
00:21:55podría decirle: "lee las migraciones de drizzle para que entiendas el esquema
00:22:01de la base de datos". El autocompletado ya sabía lo que buscaba. A medida que
00:22:08definas qué es lo fundamental que el agente debe vigilar en este código,
00:22:12como otra documentación en la carpeta de referencia, puedes añadirlo aquí.
00:22:16Ahora iré a Claude, pero abriré una conversación nueva porque vamos a empezar
00:22:20nuestro primer ciclo PIV. Explicaré todo el ciclo PIV en un momento, pero miren:
00:22:25Simplemente ejecutaré "Prime". Ese será el inicio antes de cualquier exploración.
00:22:30En este caso, se dará cuenta de que es un proyecto nuevo. Revisará el PRD y
00:22:34recomendará: "hagamos la fase uno primero, creemos los cimientos del proyecto".
00:22:39Terminó el Prime. Aquí está el resumen: página de enlaces para biografías. El estado actual:
00:22:44repositorio vacío solo con documentación. Hice una prueba antes, por eso dice eso,
00:22:49pero ya lo limpié todo. Luego extrajo la primera fase, los cimientos, de nuestro PRD.
00:22:54Eso es lo que recomienda construir, y es exactamente lo que busco: que elija
00:22:59las fases del PRD una a una para tener implementaciones granulares en los ciclos PIV,
00:23:04de los cuales vamos a hablar justo ahora. PIV es el acrónimo de Planear,
00:23:10Implementar y Validar. Tomamos un trabajo enfocado, normalmente una fase del PRD,
00:23:14y lo pasamos por todo este proceso. Creamos un plan estructurado sobre
00:23:20qué vamos a abordar. Este proceso es, de hecho, muy parecido a crear un PRD.
00:23:29Luego pasamos a la implementación. El objetivo es delegar toda la programación
00:23:34al agente de código, y después hacemos la validación. Explicaré rápido
00:23:38cómo es este proceso y luego lo veremos en acción. Primero, al planificar,
00:23:44tenemos dos capas: la planificación del proyecto a alto nivel, que es lo que ya hicimos
00:23:50con el PRD y las reglas, y ahora la planificación específica de la tarea.
00:23:55Como dije, son similares: crear un plan estructurado se parece a crear un PRD.
00:24:00La diferencia es que el plan estructurado se centra exclusivamente en una
00:24:07funcionalidad individual y sus tareas. Ahora bajamos al nivel del código.
00:24:13No somos tan abstractos, pero empezaremos con una conversación muy informal.
00:24:19Lo llamo "planificación por sensaciones", donde exploramos ideas generales,
00:24:24la arquitectura específica, usamos sub-agentes para analizar el código o
00:24:30documentación, y definimos qué tareas concretas hay que completar.
00:24:35Tras esa charla, que ya les mostraré, la convertimos en un documento estructurado,
00:24:40como el PRD. La meta es crear una hoja de ruta detallada para el asistente de IA
00:24:44basada en nuestra conversación. La charla es parte del contexto, pero aquí
00:24:50quiero secciones muy específicas en el plan: objetivo y criterios de éxito,
00:24:56documentación de referencia que algún sub-agente haya encontrado, la lista de tareas
00:25:02(incluso archivos individuales a crear o actualizar) y, probablemente lo más
00:25:09importante de todo el plan, la estrategia de validación. Esto es similar al
00:25:13desarrollo guiado por pruebas (TDD): queremos ser muy específicos sobre cómo
00:25:18validar la función antes de escribir ni una línea de código. Esto nos obliga
00:25:23tanto a nosotros como al agente a tener claros los criterios de éxito.
00:25:27Creamos el plan estructurado participando activamente, pero luego delegamos
00:25:33toda la programación al agente. Pero ojo, esto no es programar a ciegas.
00:25:38Confío en el agente pero verifico porque estoy rodeando la implementación
00:25:45con una planificación y validación en las que estoy totalmente involucrado.
00:25:51Haremos que el agente revise su trabajo con pruebas unitarias, de integración
00:25:56y de extremo a extremo (E2E). Lo veremos luego. Pero después yo haré
00:26:01mi propia revisión de código y probaré la aplicación manualmente. La revisaré
00:26:06como un usuario para asegurar que todo vaya bien antes de hacer el commit
00:26:11y mandarlo a producción o staging. Lo crucial aquí es que entre la planificación
00:26:16y la implementación, voy a reiniciar el contexto. Es una regla de oro:
00:26:20el contexto es sagrado. Tengo una conversación larga para definir la función,
00:26:26y luego el plan estructurado que genero debe ser todo el contexto que el agente
00:26:32necesita. Así inicio una charla limpia donde solo envío el plan, ya que
00:26:38contiene toda la documentación y tareas. Así sabemos qué hacer y cómo
00:26:44validar. Cortamos por lo sano y pasamos a la ejecución para mantener el foco,
00:26:50evitando que un exceso de contexto entorpezca la escritura del código real.
00:26:55Dicho esto, entremos en nuestro primer ciclo PIV. Será mucho más sencillo
00:27:00de lo que creen porque vamos a recoger los frutos de la planificación previa.
00:27:06Estamos sintonizados con el agente y confiamos en que entiende qué construir.
00:27:12Al principio no hará falta planificar tanto para cada fase. Volviendo aquí,
00:27:16terminamos el "prime", estamos alineados y le di una instrucción simple:
00:27:22"La fase uno me parece bien, confírmame exactamente todo lo que vamos a construir".
00:27:27Normalmente, tras el primer ciclo PIV, el proceso es más detallado, como: "miremos
00:27:31el código para ver cómo construir esto". Pero aquí es simple y se ve bien.
00:27:36Recuerden: "comandificar" todo. Quiero convertir esta charla y la idea de la fase uno
00:27:40en un plan estructurado con tareas y validación. Tengo un comando para eso:
00:27:44se llama "plan feature". Lo enviaré y ahora el comando, al igual que
00:27:49el de crear el PRD, ya tiene integrada la idea de plan estructurado. Se los muestre.
00:27:53Aquí está "plan feature". Acepta un argumento opcional para especificar
00:27:59qué construir; en este caso usa el historial del chat. Pasa por un proceso
00:28:04por fases: comprensión de la función, inmersión en el código (más útil para
00:28:10futuros ciclos PIV), mucha investigación y recopilación de documentación
00:28:17para tener un contexto rico antes de ejecutar. Y lo que ven aquí es la plantilla:
00:28:23descripción del problema, referencias, plan de implementación con tareas y,
00:28:28por supuesto, la estrategia de pruebas. Definimos la validación de antemano.
00:28:33Tras crear el plan, lo validamos. Seremos específicos, paso a paso:
00:28:38"así exactamente queremos que valides la aplicación". Estoy usando
00:28:44la herramienta CLI de navegador de Vercel (tengo un video sobre eso). Vamos a
00:28:49automatizar todo el navegador. El agente levantará el backend, el frontend,
00:28:55ejecutará migraciones, creará su propio árbol de enlaces y comprobará que
00:29:00todo funcione como lo haría un usuario. Es emocionante; la validación será
00:29:05tan detallada que cuando nos devuelva el control, estaremos seguros de la
00:29:11implementación. Seguiremos validando nosotros, pero será mucho menos trabajo.
00:29:17Ya tenemos el plan. Echémosle un vistazo. Hice algo de validación fuera de cámara.
00:29:21Normalmente iterarás bastante para asegurar que su visión de la fase uno
00:29:26esté alineada con el PRD y lo que quieres. Les recomiendo revisar todas las secciones.
00:29:31Aquí está el plan de implementación con las tareas. Es muy detallado, lo cual es bueno
00:29:36al enfocarse en una sola función. Tenemos la validación con la pirámide completa:
00:29:42tipado, linting y pruebas unitarias. Y para el E2E somos muy específicos
00:29:47con las rutas de usuario que debe probar. Así confiamos en el resultado.
00:29:52Al principio no lo hacía tan bien, así que añadí una instrucción extra para
00:29:56mostrarles cómo refinar el plan antes de implementarlo. Una última pepita de oro
00:30:01(prometo que ya casi programamos): esto es vital. Los agentes de código no suelen
00:30:05ser buenos con las variables de entorno; se lían. Si no las configuras antes,
00:30:10harán pruebas simuladas y dirán que todo está validado cuando no es cierto;
00:30:15es frustrante. Por eso, mientras planifico, suelo crear un archivo .env.example
00:30:20y hago que lo mire. Así conoce las variables necesarias y yo las configuro.
00:30:24No mostraré ese archivo porque tiene mis secretos de la base de datos y demás,
00:30:29pero como ya está listo, podemos lanzarnos a la implementación: escribirá el código,
00:30:34migrará la base de datos, arrancará todo y usará el CLI de Vercel para probarlo.
00:30:38Y no tendrá que interrumpirme para pedirme las variables de entorno. Todo listo,
00:30:43estoy contento con el plan. Ahora, recuerden: reinicio de contexto, porque
00:30:48el contexto es sagrado. Entro en una ventana nueva, uso el comando "execute" y
00:30:53le paso el plan como único parámetro. Eso es todo lo que necesita. Voy a
00:30:57pausar y vuelvo cuando termine. Estamos delegando todo al agente,
00:31:03cosechando el fruto del esfuerzo en planificación. A partir de aquí, cada ciclo PIV
00:31:09será rapidísimo gracias a este trabajo previo. Bien, implementación completada.
00:31:13Las capturas muestran que hizo pruebas E2E completas. Da mucha confianza
00:31:19ver que el agente se encargó de todo, pero la validación humana sigue siendo clave.
00:31:23Hay que confiar pero verificar. La revisión de código es muy técnica,
00:31:29así que me la saltaré ahora, pero si saben de código, es fundamental hacerla.
00:31:34Lo que sí haré es probar la aplicación en vivo con ustedes. Fuera de cámara
00:31:40solo creé una cuenta para ver si la autenticación básica funcionaba. Miren,
00:31:45esto es genial. Ya se ve muy bien. Puedo poner mi nombre, una biografía como
00:31:51"un constructor de IA guay". Vale, subo mi avatar a Imgur y... queda de lujo.
00:31:56Añadiré enlaces: YouTube... pongo mi URL... perfecto. Añado otro, LinkedIn,
00:32:01aunque no tengo la URL a mano ahora, pondré linkedin.com mismo. No importa.
00:32:06Añado uno más para X... x.com. Genial. Puedo arrastrarlos para reordenarlos
00:32:11y se refleja al instante. Puedo ver el editor y ajustar la vista previa.
00:32:16El tema no es el mejor ahora, es solo blanco, pero creo que eso viene
00:32:21en una fase posterior porque ahora estamos en los cimientos. Aún no es
00:32:26perfecto, pero como punto de partida se ve increíble. Le doy a guardar,
00:32:30cargamos los endpoints... esto corre en localhost... ¡y listo! Cambios guardados.
00:32:35Si refresco, todo sigue ahí. Es asombroso. Se ve realmente bien. Ahora,
00:32:39con los cimientos ya puestos, hablemos rápido del mensaje de commit.
00:32:43Tengo el comando /commit, que es muy básico. Pueden hacerlo más detallado,
00:32:49pero la idea es dar instrucciones al agente para crear el mensaje de git,
00:32:55porque será nuestra memoria a largo plazo. Volviendo al diagrama, esta es
00:32:59una de las reglas de oro: el historial de commits es tu memoria a largo plazo.
00:33:08Si estandarizamos los mensajes mediante un comando reutilizable, el agente,
00:33:11al ejecutar el "prime", podrá ver el log de git para entender qué se construyó,
00:33:18lo que guiará los siguientes pasos y patrones a seguir. Ese es el poder de esto.
00:33:24Ejecutaré /commit; podría hacerlo yo mismo, es fácil, pero así aseguramos
00:33:28que el estilo del mensaje sea siempre consistente. Aquí no hay nada que subir
00:33:32porque ya lo hice fuera de cámara, pero es vital hacerlo tras cada implementación.
00:33:37Otra cosa super importante tras asentar las bases del proyecto es
00:33:42establecer un marco de trabajo para pruebas de regresión. Queremos asegurar
00:33:46que al añadir nuevas funciones no rompamos lo que ya funciona perfectamente.
00:33:51Para eso usamos un conjunto de herramientas que el agente pueda ejecutar siempre.
00:33:57Esto cierra el círculo de confianza. Si el código pasa las pruebas unitarias,
00:34:01de integración y las de regresión, podemos estar muy tranquilos.
00:34:06Ahora pasaremos a la siguiente fase, donde añadiremos la personalización de temas.
00:34:11el diagrama; esta es una de las reglas de oro. Tu historial de commits es tu memoria a
00:34:17largo plazo. Por eso, si estandarizamos nuestros mensajes y usamos el comando /commit para
00:34:22hacerlo reutilizable, nuestro agente, al procesar el prompt, podrá consultar el git log para ver
00:34:28el historial de lo que construimos recientemente. Eso guiará los siguientes pasos y los patrones que
00:34:32queremos que siga. Ese es el poder de este mensaje de commit. Así que haré /commit,
00:34:38aunque podría ejecutar el commit yo mismo fácilmente, esto garantiza que
00:34:43el mensaje siempre mantenga el mismo estilo por consistencia. En este caso, no hay nada que confirmar
00:34:48porque ya lo hice fuera de cámara, pero es importante hacerlo después de cada
00:34:53implementación. Ahora, otro punto fundamental tras asentar las bases del
00:34:58proyecto es configurar un marco para pruebas de regresión. Debemos asegurar
00:35:04que, al avanzar en futuros bucles PIV y repetir este proceso para
00:35:09todas las funciones, lo que ya estaba hecho no se rompa. Trataré esto
00:35:14más a fondo en otro video, detallando las estrategias para implementar este tipo
00:35:19de arnés de pruebas por tu cuenta. Básicamente, le dices al agente: "Vale, lo que
00:35:25tenemos es genial, pero también quiero que entres en Aqua Voice y
00:35:31listes todas las pruebas de extremo a extremo que hiciste; ponlas en un comando para mí". Así podré
00:35:36ejecutarlo más adelante, tras añadir otras funciones, y confirmar que todo lo
00:35:41construido anteriormente sigue funcionando, ¿verdad? Algo así. Como dije, no me
00:35:46extenderé mucho ahora. Lleva tiempo configurar y mantener un arnés de pruebas,
00:35:50pero es la forma de asegurar que tu aplicación sea estable mientras sigues construyendo sobre ella.
00:35:55Requiere bastante esfuerzo crearlo y mantenerlo porque hay que actualizarlo constantemente.
00:36:00Sin embargo, existen soluciones que se encargan de esto por ti y son muy potentes.
00:36:05Una de ellas es QA Tech. Tienen agentes de IA para pruebas que evolucionan y se adaptan a tu código.
00:36:11A medida que añades más funciones, ellos añaden más casos de prueba para asegurar que
00:36:16toda tu aplicación funcione bien mientras sigues desarrollándola. Te mostraré
00:36:22un ejemplo rápido. Es muy fácil empezar: vas a QA Tech, tienen
00:36:26un plan gratuito para que lo pruebes. Crearé un proyecto aquí y solo hay que
00:36:30pegar la URL que quieres probar. He tomado esta aplicación ya que hice un commit
00:36:35y lo subí a GitHub, y la desplegué en un minuto en Vercel; es el sitio más fácil para
00:36:40alojar tus webs gratis, especialmente con Next.js. Así que iré a mi proyecto
00:36:45y pegaré la URL. Tardará un poco en crear el proyecto y analizar
00:36:50tu código. Lo que podemos hacer es decir: "Quiero una buena configuración de pruebas. Ayúdame a
00:36:55crear los primeros tres a cinco casos". Esto es como Bolt.new o Lovable,
00:36:59puedes darle instrucciones sobre qué quieres para configurar la suite de pruebas de tu
00:37:04proyecto. Pero esto es lo que ellos recomiendan para empezar. Lo enviaré.
00:37:08Es genial porque rastreará tu sitio, navegará por él, pero tú
00:37:12no tienes que gestionar la infraestructura. Analiza tu web y genera los casos
00:37:16de prueba. Volveré cuando termine. Durante la ejecución, quería mostrarles rápido
00:37:21que rastreó mi web en solo un par de minutos. Algo muy importante
00:37:25es que necesitamos una forma de loguearnos en el sitio para que la automatización pueda hacerlo.
00:37:29Tienen una opción para introducir usuario y contraseña, y los guardan de
00:37:34forma segura. He creado una cuenta de prueba; la guardaré ahora. La
00:37:38usará para entrar en la web, explorarla a fondo y entender los flujos de usuario
00:37:43que queremos probar. Y listo: ha generado varios casos de prueba para nosotros,
00:37:48e incluso podemos entrar en cada uno y ver el flujo exacto que siguió.
00:37:53Ahora ya tenemos estas pruebas configuradas. Los agentes de QA Tech irán
00:37:59evolucionando estos casos con el tiempo para cubrir todo nuestro código. Conforme añadimos
00:38:04más funciones, se vuelve algo increíble. Insisto, podríamos crear nuestro propio
00:38:09sistema de comandos para esto, pero prefiero tener una plataforma que se encargue de
00:38:14todo por mí. Hay agentes internos con los que puedo chatear para ajustar las
00:38:19pruebas y asegurar que realmente estoy cubriendo todo con pruebas de regresión. Así,
00:38:24si algo se rompe, puedo venir aquí y decir: "Hay un error en la aplicación,
00:38:28crea una prueba que falle". Corrijo el problema y entonces la prueba
00:38:33debería pasar. Esto nos lleva a la última regla de oro: la mentalidad de evolución del sistema.
00:38:40Cuando encontramos un error en el código, es fundamental no solo corregirlo,
00:38:46sino pensar qué podemos arreglar en nuestra capa de IA para que no se repita. Quizás
00:38:51debamos ser más específicos en nuestra guía de estilo o crear un nuevo contexto bajo demanda.
00:38:57O tal vez necesitemos más pruebas de extremo a extremo definidas en comandos o flujos,
00:39:02lo que sea necesario para evitar que el problema reaparezca. También podemos
00:39:06hacer lo que mostré en QA Tech o con comandos propios: añadir un test que asegure
00:39:12que ese fallo no vuelva a ocurrir. El poder de esto, aunque lleve
00:39:16tiempo, es que logramos un agente de programación más fiable y predecible, que
00:39:21evoluciona junto a nuestro código. Estamos trabajando en tres frentes paralelos.
00:39:26Mientras desarrollamos el código, evolucionamos la base de pruebas, el código y la capa de IA.
00:39:32Y eso se potencia muchísimo con el tiempo. Volviendo a Cloud Code, les daré un ejemplo simple.
00:39:37Una de las cosas en las que trabajé fuera de cámara fue en el estilo del sitio.
00:39:43Si revisan el inicio del video, verán que olvidé especificar el estilo,
00:39:47exactamente cómo quería que se viera. Cloud Code simplemente hizo sus propias
00:39:51suposiciones y no se veía muy bien, así que tuve que iterar sobre ello. Lo que
00:39:56puedo hacer aquí es decir: "Al principio no me gustó el estilo que implementaste. Claramente
00:40:01no tenemos suficiente información en la capa de IA, ni reglas ni contexto para una
00:40:06guía de estilo. Quiero que hagas un meta-razonamiento: no cambies nada aún, pero
00:40:10ayúdame a pensar qué podríamos cambiar en nuestras reglas o contexto bajo demanda,
00:40:15algo que añadir o actualizar para tener estilos más consistentes mientras
00:40:20seguimos construyendo las analíticas y otras páginas de esta aplicación".
00:40:25Lo importante aquí es decirle que no cambie nada todavía,
00:40:29porque prefiero tener mucho más control sobre los cambios en la capa de IA que en
00:40:34el código, donde sí quiero delegar todo lo posible al agente. Dejo que razone conmigo,
00:40:39pero suelo hacer estos ajustes pequeños y enfocados yo mismo. Aquí pueden ver que
00:40:44recomienda crear un archivo style.md en la carpeta de referencias: un tercer contexto bajo demanda.
00:40:50Esto iría junto a components.md. Ese archivo dice cómo organizar las cosas,
00:40:54mientras que styles.md diría cómo debe verse todo, cómo trabajar con Tailwind CSS
00:40:58o Shadcn, por ejemplo. No voy a realizar toda la implementación ni
00:41:03corregirlo todo ahora, solo quería darles un buen ejemplo de cómo,
00:41:06al encontrar fallos o falta de alineación, como en este caso,
00:41:11siempre hay una oportunidad para evolucionar la capa de IA. Así estamos
00:41:16cada vez más sintonizados con nuestro agente para este proyecto específico.
00:41:20Y esa, amigos míos, es la parte con más impacto de todo el proceso; lo mejor para
00:41:26el final. Eso es todo. Es un proceso realmente sencillo para obtener resultados
00:41:32fiables y repetibles con agentes de IA al iniciar proyectos nuevos, porque tras
00:41:35la evolución del sistema, volvemos arriba y pasamos por más bucles PIV
00:41:40siguiendo el mismo proceso para completar las fases del PRD, añadir funciones y
00:41:45lo necesario para llegar al producto mínimo viable. Después pasaremos al desarrollo
00:41:49Brownfield en uno de los próximos videos que subiré al canal. Si todo esto
00:41:54te suena bien y quieres profundizar con mi biblioteca completa de comandos y reglas,
00:41:59o ver cómo es realmente la evolución del sistema, no dejes de
00:42:04revisar el curso de programación con agentes en la comunidad Dynamics. Dejaré el
00:42:08enlace en la descripción y en el comentario fijado. Eso es todo por ahora. Si
00:42:13te ha gustado el video y esperas con ganas el de desarrollo en entornos
00:42:17Brownfield, agradecería mucho un Like y que te suscribas. Con esto, nos
00:42:22vemos en el próximo video.