El SECRETO para que la IA no haga CUALQUIERA: Spec-Driven Development de punta a punta

0:00 Abuela, salió video de gentleman. ¿Qué hace locura de mi corazón? Dios. Impresionante. ¿Cómo andás, espectador mío? Mira, te voy a explicar una cosa. Si vos le tirás una proma, bien a una gente de día que bueno, querés que le haga magia prácticamente, te va a escupir basura. Es así no más. Entonces, después de qué te vas a quejar, ¿no? Si el problema no es la IA a, si no es que vos no le diste un contexto. El problema también es el tema de darle tanto contexto. Acuérdense, cuanto más contexto damos, hay una cosa que se dice por ahí, es que mejor actúa una agente. Mentira. Hay que darle lo justo y necesario. Bien. ¿Por qué? Porque todo el otro es ruido. Es algo que va a ofuscar el objetivo que realmente queremos. Entonces, hoy les voy a mostrar cómo en Gentley hacemosd,

0:47 que es lo que se llama spec. Driven Development para que la gente no improvise nunca o por lo menos tratar un poquitito. Es una forma de hacer un arnés bien a la hora de trabajar. Esto está hace bastante tiempo, desde antes que se empiezan a llamar estas cosas arneses, pero bueno, esto no es prom engineering, esto directamente es ingeniería de proceso. Bien, entonces vamos a verlo. Acá está el problema real. Cuando vos le pedís a un agente, "Implementame esto, locurísima, el agente no sabe qué patrón querés, qué tradeoffs ya descartaste, qué constraints tenés. que testing strategy usas y tampoco la arquitectura que tenga sentido bien para tu proyecto. Por ahí te da una resolución que está bastante buena, pero que no es lo que vos necesitas justo para este contexto que es tu proyecto. Bien, puede ser o tu equipo o puede ser xazón. Un dev senior

1:34 no le tira una tarea ambigua a otro dev y espera que adivine. Bien, menos vos, locurísima, vos sabes quién sos. Bien, entonces por qué se lo hacemos así a la IA. Ese DDD se inspira. A ver, esto es viejísimo. Bien. lo mismo que el TDD, es viejísimo el test driven development, pero son metodologías que a la hora de ser viejas eran tediosas de hacer, pero ahora con la IA es un limitador más, es una forma de guiarla. Bien, entonces SD se inspira en lo que hace Openespec.Ded.D. Antes de implementar voy a definir el cambio, voy a escribir lo que son los requerimientos, el diseño, las tareas, pero Gentil ahí lo lleva más lejos que eso, porque el problema no es solamente tener un spec. Bien, el problema es que el agente respeta el proceso, no se manda solo, no

2:19 pierde contexto y puede verificar lo que hizo. Resumen la tía. Ah, purísima. Vamos a ver por partes. Sí, antes de meternos en el flujo de SDD, hay un paso cero que la mayoría no conoce que se llama SDD Init. Esto no es parte del cambio funcional, es la calibración del sistema antes de hacer SDD. ¿Qué es lo que hace? Detecta el proyecto, lees y tenés un packet jason, un go.mod, un pippo project.Tom, resumen, se fija las cosas del proyecto, qué estructura de carpetas tenés, qué frameworks, convenciones tooling test patrones existentes. Y antes de todo eso, el arnés hace lo que se llama un preflight. ¿Qué es eso? Que te preguntas si querés trabajar de manera interactiva, automática. En resumen, ¿querés que

3:05 después de cada pasito yo te muestre lo que hice? y vayamos ahí teando, te voy preguntando cosas y demás. ¿O queres que yo haga todo? ¿Por qué? Es más. Bien. Entonces, después también te voy a preguntar dónde vamos a guardar las cosas. Open spec, que directamente es una carpeta en el repositorio y ya queda ahí. O por ahí. Mirá, si tenés engram, aguante, vas a poder guardar las cosas en engram, pero siempre guardando lo último que hacemos, ¿bien? No un histórico, eso es para cosas rápidas y demás. Además, también te voy a preguntar, por ejemplo, cómo manejar cuando el código ya es mucho, cuando es un PR grande, cuál es el presupuesto de review. Todo esto lo tenés en mi otro video, que es el de 20 arneses que yo utilizo en gentelia. Bien, pero después de ese DD init aterriza eso en el

3:51 proyecto. Crea o lee openspecfig.jamle, guarda contexto del stack, reglas por fase y testing capabilities. Bien, y también otra cosa que hace que está bastante interesante es que verifica que exista el skill registry. ¿Qué es esto? Esto es, a ver, no es una biblioteca gigante, sino es un índice de skills disponibles que tenemos tanto en el proyecto como también en el usuario. Pero hay algo más y esto es importante. Detecta testing capabilities. Si encuentra test y un runner configurable como puede ser, no sé, yo utilizo Vtest, buenísimo, utilizo Vitest browser, espectacular, que uso Playwrght o por ahí. Todo eso lo detecta y lo deja identificado y también sabe qué scripts utilizar para ejecutarlo. Bien, entonces

4:37 ya en Tela ahí lo que va a hacer es activar lo que se llama el strictd mode. ¿Qué es eso? Es que en apply y verify el agente no trabaja en, bueno, impamente después vemos qué sucede, bien, sino que trabaja con una regla más fuerte. I test a runner, seguí test driven development. Acepte primero los test antes de cualquier tipo de código para satisfacer los requerimientos. Después hago que pasen y después le puse un tuning un poquitito bien de gentle ahí que es va a buscar casos edge. ¿Qué es eso? Casos que pueden llegar a romper esa lógica y los va a cubrir también. Entonces todo esto deja evidencia y hace que no se salte la verificación. Eseit es como calibrar la máquina antes de empezar a

5:22 cortar las piezas. Sí, no estás construyendo todavía, estás midiendo el proyecto, cargando contexto, detectando test, preparando el arnés para que después el agente no improvise. Bien, espectacular. Acá, por ejemplo, tenemos un proyecto, ¿ven? que es el de Gentlep y van a ver que tiene un open spec y cuando yo entro acá van a ver que tenemos un config y gam yamel, lo poner bien grande y este config y jamel es justamente el que denota que es el proyecto, bien, todo lo que es el contexto te va a decir cuáles son las diferentes reglas a seguir. Sí, por ejemplo, cuando hagas un apply tenés que utilizar este comando para hacer el testing, lo mismo para la parte de verificación. Eh, por ejemplo, también necesita eh que cuando haga la fase te pregunte. Perfecto, lo tenemos ahí. Sí,

6:10 tenemos todo puesto. Ahí están todos los comandos, utilizar, todo. Esto está buenísimo. Sí, no más se los digo, es espectacular. Pero te voy a mostrar otro conceptito más. Está también lo que es el skill registry, que esto es lo que yo les decía antes, esto lo hice yo porque estaba harto de utilizar diferentes agentes como puede ser Cloud Code, como Codex, como Gemini. lo que sea y que cada uno de ellos guarde las skills donde se les canta y sea muy arduo tomarlo. ¿Vieron eso que ustedes dicen, "No, porque le pedí cada tal cosa, pero no me usó la skill." Bueno, se terminó. Esto es una cosa que diferencia mucho a Gentle de cualquier otro setup que hayan visto es cómo maneja el contexto. Bien, Gentil no le tira todas las skills completas a su vagente como si fuera una bolsa de papa. Eso sería carísimo en

6:55 Tokens y aparte metería ruido. Entonces, vamos a ver cómo se hace. Lo que hace el orquestador es mucho más inteligente. Lee el skill registry del proyecto. Detecta qué skills aplica según el contexto, que React, que Tycrip, que Go testing, que Playby, arquitectura, PR, lo que corresponda. Pero ojo, el registry no es un resumen mágico ni un megaprompt, es un índice. El orquestador selecciona los path exactos de las skills relevantes y se lo pasa a subagente. Entonces, el subagente no recibe 20 documentos enormes, instrucciones que no aplican, directamente tiene un contrato claro para esta tarea. Vas a tener que cargar estas skills y respetar estas reglas. Bien, eso lo que hace es reducir el ruido, evita contexto innecesario,

7:40 mantiene una separación importante y es que el orquestador coordina, el subagente ejecuta y las skills siguen siendo la fuente de la verdad. Gender no es un prom largo, es una orquestación que tiene un contexto seleccionado. Bien. Y viene una partecita que a mí me encanta y ahora les voy a mostrar un ejemplito de todo esto, no se preocupen. Sí, hay una parte que es el presdd porque ya tenemos todo el sistema calibrado, ya tenemos todo, pero viene la fase previa, ¿no? Que es donde vos como humano todavía estás dirigiendo de cerca investigar el patrón e, por ejemplo, valor alternativas, armar un briefing técnico que después le entregas al flujo CDD como input. Entonces, yo esto lo hago en terminal. Tengo un workflow donde abro documentos, rep de proyecto, eh papers cuando aplica, bien,

8:28 y voy armando un documento en mar con los approachs considerados, los tradeoff, las decisiones preliminares, ese documento es lo que alimenta a la exploración y al proposal dentro del Gentle Ei. ¿Sí? ¿Por qué hago esto antes de iniciar el flujo? Porque cuanto más contexto entra en la arnés, mejor decide el agente en cada fase. Si vos ya hiciste la mitad de research, el agente no tiene que adivinar y aparte reducimos gasto de tokens, pero de vuelta un contexto específico para el problema que trato de solucionar. Sí, espectacular. Entonces, ahora lo que vamos a hacer es vamos a adentrarnos dentro de Gentle P, que es el repositorio open source para configurar pi de gentli. Voy a abrir ahí y van a ver que va a ser una cosa muy interesante. Primero, es hermoso. Y segundo, ¿ven lo que dice acá? Skill

9:14 registry refresh. 51 skills. ¿Qué es lo que yo hago? Yo lo que hago es lo siguiente. Dentro del proyecto voy a tener esta carpetita pun ATL. Cuando yo introduzco mi persona dentro de la misma, van a ver que hay un skill registry MD. Y acá van a poder ver todas las skills que está sacando, que son skills que yo tengo en configuraciones de Open Code, de Cla, de Gemini, Cursor, Codex, Codeum, OpenCla, lo que dé. Bien. Y establezco el contrato de cómo tiene que trabajar el orquestador y esto es solamente para la persona que delega. Bien, entonces acá tenemos todas las skills en formato tabla donde vas a decir cuál es la skill, cuál es el

10:00 trigger que ejecuta dicha skill y después dónde la puede encontrar. Es así de fácil, es un buscador. Esto cargarlo en contexto es baratísimo. Bien, baratísimo. Y eso es lo que tratamos de hacer. Ahora que ya tenemos eso, voy a hacer otra cosa más. Le voy a pedir algo. Quiero que con SDD eh hagamos mejoras para la performance a la hora de iniciar Pi. Bien, vamos a ver qué pasa esto. Si va todo bien, primero buscan engram si ya hay información sobre esto. Eso es otra cosa para otro día. Aguante Engram, gente. Aguante engram. Carga la skill de Gentlieli. Resumen, le da el contexto de cómo tiene que comportarse de todos los arneses y demás. empieza a leer un poquitito las configuraciones,

10:45 lee también el skill registry para saber qué skills hay y demás. Y con todo esto me empieza a hacer las preguntas que yo les decía, el preflight, ¿quiero hacer interactivo o lo quiero hacer automático? Vamos a hacerlo interactivo. ¿Cómo lo quiero guardar? Que open spec o directamente lo dejamos en el chat o también puede ser engram, eh, lo que vos quieras. Vamos a decir open spec. Y acá viene una parte importante. Si esto empieza a ver que crece lo que es la cantidad de líneas, bien que va a cambiar. Si son más de lo que ahora vamos a ver, te va a crear PRS encadenadas. Esto para otro día es una locura, bien, que se está haciendo ahora mismo y que yo ya lo tengo integrado dentro de todo el ecosistema. Vamos a poner uno que es auto forecast, ¿qué quiere decir? va a estimar el tamaño y si se pasa de el tamaño que le vamos a

11:32 decir luego vamos a recibir una pregunta diciendo cómo queremos no eh hacer un split de esas tareas y ahí está. Vamos a ponerle unas 400 submit. ¿Ven cómo está todo integrado? Esto es hermoso. Esto va actuando solito. Yo no tengo que hacer nada. Esto es divino. Y ahí es cuando empieza a explorar, hacer todas las cosas que necesita hacer. Y cada uno de estos steps va a hacerse en un subagente. ¿Para qué? Porque todo ese trabajo que va a hacer el agente no quiero que ensucie la conversación que yo estoy teniendo con el orquestador. Entonces, esto, si yo ahora entro adentro, vemos todo lo que se le pasa a ese subagente. En resumen, lo que le está pasando el orquestador al subagente para que este ejecute. Sí, le está

12:17 diciendo cómo es la ejecución. También le está diciendo información del proyecto, qué skills tiene que cargar, que es lo que yo les decía. Por lo cual ni siquiera tienen que ir a leer el archivo de skills. Bien, el skill registry ya lo sabe. Después cuál es la tarea que tiene ahí. Explorar solamente, no implementes porque esa es la parte más. Algunas cositas que yo también doy para tratar de enfocarlo. Bien, y eso es un poquitito la fase que eh hacemos bien dentro de lo que es SDD con Gendel y demás. Pero también no hay una fase de research y briefing que es laburo. Hay días que lo hago a mano, otros que tengo 20 tas abiertos y todavía no escribí una sola línea de briefing. Entonces acá está el punto, ¿no? Cada día aparecen herramientas nuevas que atacan esta fase

13:02 específica. Hay gente que le gusta hacerlo, por ejemplo, con una sigl directamente hablando. Como les digo, en esta parte interactiva de la exploración, podemos decirle, "Mira, para esta parte exploratoria, para cuando tengas que hacer la proposal, bien, una vez que ya exploró todo, eso termina y con todo el contexto necesario va a hacerte una propuesta. Esto es lo que podemos hacer. Entonces ahí tenés que hablar con él, investigar, hacer de todo. Bien, pero como les digo, a mí me gusta también hacer una fase exploratoria previa a eso. Bien, entonces se puede hacer por si se puede hacer con Wordpace visuales. Otras son extensiones del browser. Vos elegís la que te baje la fricción según como vos trabajas. ¿Okay? Entonces, cuando se necesita, por ejemplo, acelerar la parte del research estructurado y el briefing, una alternativa, por ejemplo, que está

13:47 muy buena es la que te voy a mostrar ahora. Antes de pasar a cóm Gentle convierte una proposal SD ejecutable, me voy a afeitar un poquitito. Bien, después vamos a volver a la barba, pero quiero frenar un segundito. Esta sección la va a traer Jens Park, bien, avisito arriba, ya tú sabes, Ad, pero esto conecta directamente con lo que venimos viendo. Hay una fase de research que define si la IA ejecuta bien o mal. La pregunta es justamente, ¿cómo bajas la fricción sin salteártela? Gin Park se vende como un AI workspace All-inone que les voy a mostrar que tiene tres piezas que encadenan para esta fase y las tres están pegadas justo con todo lo que ya venimos viendo. Vamos a empezar con lo primero. Lo primero que vamos a estar viendo es esta interfaz. Esto es James Park AI Workspace. Está 4.0. Acá tenemos todos los agentes. Puedes construir los

14:34 tuyos también te puede crear imágenes, te puede crear videos, puede hacerlo de todo. Bien, pero les voy a mostrar cómo podemos integrar herramientas a todo este flujo que ya venimos viendo para crear tus propios arneses y demás. Entonces, hay una partecita acá que dice all agents. Yo lo toco y me voy a dar todos los agentes que ya vienen configurados, pero también puedes crear los tuyos y vamos a hacer uno también. Pero el primero que vamos a estar viendo es justamente el de atentos con esto, deep research. Van a ver que hay de todo, de creación de imágenes, videos, esto, el otro, hasta vos tenés de todo, pero el que me importa a mí primero es el deep research. Bien, entonces acá vamos a hacer, por ejemplo, lo que sería una investigación solo un poquitito de engram. Sí, Engram es mi modelo mental para los agentes, para guardar contexto, que se puede compartir entre diferentes IDs y demás y está hecho en FT eh S5 con

15:22 un ranking justamente BM25 y además de eso es una base de datos SQLite local. ¿Para qué importa todo esto? Porque justamente le voy a preguntar que investigue cómo hacer eso. Justamente con todo el stack que es con Go y demás. Le estoy diciendo qué es lo que necesito para la parte de research. Bien, con todas las partes desde que se approches conocidos, bien para hacer esto tradeoff, o sea, ventajas y desventajas y demás, riesgos comunes en producción, alternativas, no SQLite para ver justamente cómo podemos hacerlo, decisiones comunes que toman proyectos similares y demás. Entonces, esto directamente ha ido, ha investigado en profundidad el tema y miren cómo fue leyendo ¿no? diferentes documentaciones para llegar justamente a este resultado con todas las cosas. Pero

16:08 esto no queda acá. Además de que me va a dar toda esta información, va a haber una parte interesantísima al final de todo. Miren, es mucha información, ¿eh? Es impresionante para hacer justamente estas búsquedas que nosotros estábamos diciendo al principio que necesitamos saber para poder tomar decisiones. Y acá lo tenemos. Hace lo que es una vista en la cual yo puedo entrar. Es más, esto se puede descargar directamente en PDF. Puedes conectar un notion tuyo para poder guardar todo directamente ahí. Y acá tenemos cómo queda generado todo, ¿sí? Todo este briefing que recién les mostré, todo completito, pero nos vamos a quedar ahí. Vamos a ver ahora una segunda herramienta, otro segundo agente que tiene, que está buenísimo para poder transformar esto a algo presentable para lo que es un equipo o como documentación propia, eh, no de repositorio. Entonces,

16:54 lo que voy a hacer ahora es tomar ese research que ya hicimos, ¿sí? y lo vamos a convertir en un briefing técnico con headings, decision arquitectura, alternativas descartadas, formato claro, listo para utilizar. Bien, esta es la idea. Entonces, acá lo tenemos. Le estoy diciendo toda esa parte. Le voy a decir que esto va a estar consumido para Spect Dream and Development. Ya les estoy dando ahí una adelantito de lo que vamos a hacer y le estamos diciendo exactamente cómo queremos dicho briefing. Ahora con esto directamente esto fue lo he hecho en HTML porque yo se lo pedí así. Ahí está todo y yo cuando lo toque van a ver la implementación. Sí, ya es un documento que tiene un formato que está bonito, está todo muy sexy. Ahora, esto también se puede presentar de diferentes maneras. Por ejemplo, por ejemplo, podemos elegir acá diferentes eh digamos templates para poder hacer dicha

17:41 documentación. Así que esto está genial porque son todos cosas que ya están preparadas para ser funcionales y productivas de una, sin tener que andar lidiando con las configuraciones custom y demás. Y ahora lo que vamos a hacer es poner new y podrían poner ustedes super agent. ¿Para qué? para poder crear su propio agente. Ya tengo uno listo. Miren qué bonito. Genderd. Ahora vamos a ver cómo se configuró y demás, pero literalmente ya acá puedo hacer lo que quiera, ¿sí? Ya puedo utilizarlo en el día a día, pero vamos a ver cómo lo he creado directamente. Vamos a un poquito más de zoom. Le he dicho, quiero que me crees un agente de especializado en estructurar documentaciones y demás de SDD. ¿Para qué? para desarrollo de eh proyectos de software. Esta gente tiene que tomar cualquier tipo de input

18:26 técnico y justamente sacar un draft de todo el proceso de CD. Entonces, esto así no más se lo di, automáticamente ya lo creó. Miren qué bonito. Le puso un diseño, le puso todo. Eh, esto está bastante interesante y todo se puede leer y se puede justamente actualizar. Otra de las cosas que yo hice ahora es actualizarlo con un poco más de limonada. Sí, tenemos acá directamente todas las especificaciones de metodologías, etcétera. Entonces, con esto, con reglas y demás, me dio la última versión, que es esta. Sí. Entonces, otra cosa más. A su vez hice una cosa bastante interesante. Bien, acá tenemos todos los pasos, todo muy bonito, todo explicadito, pero le pedí, quiero que aparte crees documentos que son para ti, porque esto tiene como un

19:13 AI Drive, bien, como Google Drive, pero de IA para lo que son los agentes. Y le dije, quiero que guardes en documentaciones diferentes conceptos. Cada uno de estos conceptos se puede utilizar luego para lo que es el entendimiento, el aprendizaje y demás. De vuelta. Lazy loading de contexto. No queremos cargar todo de una, sino que lo haga de a poquitito. Bien. Y ahí está. Automáticamente fue agregando cada uno de estos dentro, no sé si lo ven ahí, de una base de datos que tiene directamente la herramienta. Sí. Lo bueno también tiene esto es que acá puedes seleccionar qué tipo de pensamiento tiene y demás. Y tenemos el Ultra, por ejemplo, que es el Opus 47 con un millón de contexto. ¿Sí? Entonces está bastante muy potente. Ahí lo tenemos. ya hizo toda la lo que es la estructura para estos archivos y demás. Es superceto, no sé si lo ven. Eh, es

19:59 realmente muy muy completo. Y ahora lo que les voy a mostrar es cómo lo utilizo directamente. Yo lo hice acá porque ya lo tenía impuesto, pero podría haberlo hecho directamente en una nueva directo para este agente. Y lo que hice fue decirle, "Mirá, procesá el siguiente briefing técnico y genera la preexecution de SDD." Este es el briefing completo con toda la metodología. Pum. Esto, ¿saben qué? El briefing que hicimos antes. Bien, el briefing público ese que yo les dije que esto lo guarda acá y lo pueden exportar a Pf este mismo se lo he pasado y automáticamente fue, lo leyó e hizo todo. Miren, acá está la proposal, estos son los riesgos, cómo ir para atrás, bien cualquier cosa que suceda, el access criteria, resumen, todo lo que ya vimos de SD y que van a ver ahora

20:44 implementando, bien dentro de lo que es la terminal. Entonces, acá están todos los escenarios, están todas las partes del proceso de SDD, los diseños, todo bien. Esto está bárbaro para poder hacer este pensamiento y vemos de paso cómo se puede adaptar toda esta metodología que yo les estoy diciendo en diferentes herramientas. Y ahora con esto volvamos al SSD por terminal, un ejemplo de lo que es la proposal. ¿Sí? Directamente te dice, "Dale, mira, la proposal está bien orientada, pero la idea central es esta, no arrancar optimizando a ciegas. Primero hacemos observar el arranque de P con profiling opin. Resumen. Me está dando todo un resumen de todo lo que se quiere hacer. Se está hablando, por ejemplo, no hay una lentitud en tal lado. Fantástico. Sospechoso principal es este. Ahí vamos a ver qué onda, cómo se puede optimizar. A ver, esto no hay

21:30 que optimizarlo, anda muy rápido. Esto ya está hilando en lo fino, pero para que lo vean, sí, más o menos como está acá, por ejemplo, el punto discutible y dice la propósal dice considerar como mucho una optimización chica. Eh, yo sería incluso más estricto para la primera PR. Bien, de todo. Entonces, vamos a decir solo profiling, ¿les parece? Vamos con solo profiling. Eh, acá le podría decir, "Bueno, dime cómo vamos a hacer ese profiling. De todo." Sí, igualmente acá está un poquitito más ya explicado arriba, pero para que vean cómo es. Ahora, una vez que esto ya se elige, esto ahora lo está guardando como una observación dentro de Engram. Mi cerebro de agente de vuelta es gratis también, es open source, es parte de Genteli. Para cualquier cosa, yo el día de mañana vuelvo y digo, ¿qué estáamos haciendo con esto? Y lo sabe bien. No

22:16 perdemos contexto. Ahora crea un subagente nuevo donde se hacen las especificaciones que tienen que cubrir dicha propuesta. Ahora cuando termine se los muestro. Ahora estamos acá directamente con la parte de specs ya realizada. Ahí nos está diciendo, mira, este es el resumen de lo que se va a hacer. Si seguimos con el diseño, le voy a pedir al subagente de diseño que defina cómo se va a implementar dichas funcionales a nivel técnico. De vuelta, si yo voy entonces a la parte de open spec changes y veo la de improp startup performance, esta es la que estamos hablando ahora mismo. Y si yo entro acá, vamos a ver que ya tenemos la proposal, si la quieren ver en totalidad para poder hacer modificaciones o lo que ustedes necesitan y va a detallar cuál

23:01 es el problema, cuál es la intención, qué es lo que se va a meter dentro de esta propuesta, qué no se va a meter, qué áreas se ven afectadas, en este caso qué archivos, bien, cuáles son las métricas que se quieren mejorar, cuáles son los riesgos que hay que tener en cuenta. Rollback, ¿qué pasa si tenemos que volver para atrás? y también obviamente un success criteria. Esto es lo que tiene que suceder para que esto funcione. Bien, asimismo ya tenemos la parte de specs, en este caso la del scope chiquitito que acabamos de decir de profiling. ¿Ven? Como algo grande lo empezamos a particionar en cosas más chiquititas. Perfecto. Entonces acá de vuelta va a decir cuáles son los requisitos, cuáles son los escenarios, cuándo pase tal cosa. Entonces, bien, esa es la idea. ¿Sí? Dado este caso,

23:48 cuando pase tal cosa, entonces y tiene que suceder esto de vuelta. Esto para cada tipo de requerimiento. Esto es lo que nosotros necesitamos. ¿Para qué? Para la siguiente fase que vamos a ver qué es. Acá acaba de terminar lo que es el subente de diseño y vamos a ver lo que dice. Design listo y delineado, solo profiling. Desiones principales. Se va a hacer un nuevo helper interno acá. Activación exacta es esta. Esta es la salida del Jason. resumen, da toda la información de cómo quiere técnicamente desarrollar esa especificación. ¿Sí? Entonces, ¿cuál es el tema de esta parte? Una vez que ya tenemos todo esto, viene lo lindo, lo interesante. Vamos con las tareas. Y mientras tanto, otra vez se los digo, pueden entrar, pueden entrar en

24:35 cualquier momento a ver el diseño desde acá mismo. Y ahí lo tenemos. Design Stata performance profiling only slice. Y acá está de vuelta técnicamente todo como se quiere hacer. Miren, hasta da recomendaciones de la API utilizar y demás. En resumen, tiene todo lo necesario para que cuando realmente se tenga que hacer la implementación ya vaya con una guía específica de qué tocar, cómo tocarlo y mucho más. Esto es super powerful. Y acá tenemos implementadas las tareas y lo va a hacer en unidades de trabajo. ¿Para qué? Para que se vaya haciendo de forma controlada. De nuevo, nosotros podemos entrar en lo que es el proyecto y vemos la parte de tareas. Y acá van a ver que esto literalmente se va a ir metiendo

25:20 con checks. ¿Sí? ¿Y por qué se hacen con diferentes checks? Justamente para ir validando qué es lo que hace la IA. Y no solamente eso, sino dejando constancia para que cualquier persona que quiera continuar este trabajo es la gente ya va a saber qué se hizo, cómo se hizo, por qué se hizo y continuar sin ningún tipo de problema y más y me estés enrí no más. Ahora, antes de continuar, una parte que me interesa que ustedes vean es cómo le pasó el trabajo a este subagente de apply. Bien, primero me va a decir justamente el tema del autoforecast. ¿Para qué? para que me recomiende, e este trabajo se implementa de tal manera, vamos a ver qué onda, hasta 400 líneas como mucho y demás, pero además de eso también tiene la parte de e modo estricto TDD está activo. Eso quiere decir que tenés que

26:07 utilizar PNPM test. Tenés que primero hacer las reglas como les decía, ¿no? Los test en rojo, luego lo tenés que pasar a verde, luego tenés que triangular y refactorizar acorde y justamente guardar todo tipo de evidencia. Bien, esto está espectacular, gente. Esto es lo que yo les digo. Esto es un arnés. Esto realmente es un arnés. Esto es lo de open spec, pero mejorado. Sí. El siguiente nivel, la evolución, el ecosistema de gentilidad. ¡Carajo! Una vez que terminé de implementar, vino la etapa de revisión. Bien, para verificar. Fíjense que cuando hizo la revisión sí que encontró cositas. Bien, dijo, todo esto está correcto, no hay ningún problema, pero ojo con esto. Problema

26:52 mayor, problema mayor, problema menor, menor. Es cositas. En resumen, esto está fantástico. Por más que fuimos con toda la guía, que fuimos todos bien, falta una parte de verificar. ¿Qué es lo que verifica? que las especificaciones cumplan justamente al revés mejor, eh, que lo implementado cumpla con las especificaciones y con el diseño. Entonces, una vez que terminó todo, llega a esta parte espectacular donde nos dice, "Hermoso de mi vida, listo, ya ha hecho el apply, el review y el verify, ya está todo hecho." Bien, hubo un problema, justamente hubo un gap de cobertura, que es lo que les dije recién, y cómo lo corregí. Acá está todo hecho. ¿Qué faltaría? archivarlo. Bien, ahí le pongo, vamos con la siguiente fase a ver qué me dice. Y es cuando inicia la parte de archivar. ¿Qué es

27:40 esto? Archivar, va a documentar todo lo que me acaba de decir. Bien, lo va a documentar y también va a buscar otros specs dentro de Open Spec que estén relacionados a este para hacer esa conexión. Es decir, esto, por ejemplo, es una evolución de esto que ya hicimos antes y demás y se empieza a crear como este histórico. Sí, pero este es el flujo completo de SD. y por qué es tan importante. Entonces, vamos a ver que cuando entremos a proyecto va a pasar algo muy interesante. Entro Open Spec y voy a ver que en la parte de cambios no está más. ¿Por qué? Porque ahora está archivado, ya ha terminado. Ahí lo tenemos. Te pone la fecha cuando se terminó. Entro acá y tenemos la parte de especificaciones, la parte de profiling. Y ahora sí que sí tenemos ya lo que sería el apply progress. Bien, es el

28:26 reporte de todo, cómo se implementó y demás. Después tenemos el reporte final. de todo, todo, todo, ya, cómo ha quedado todo fantástico, se haga un warning, algo que haya quedado por ahí y también el state jamel, que va a ser un resumen super rápido de todo lo que se fue configurando y demás para esta sesión y el verify report. Bien, ahí tenemos todo explicadito y demás. Y esto sería si lo hiciéramos todo con Gentlei dentro de un CLI, pero para que veas más o menos todo esto cómo funciona. Bien. Y la pregunta que se están haciendo entonces, ¿qué le agrega a Openp.d? Más o menos ya lo vimos, ¿no? Pero tenemos diferentes etapas. Uno es engram, es memoria persistente. Cada fase guarda artefactos, el agente puede continuar

29:12 sesiones sin perder el contexto y mucha otras cosas más. Esto tengo un video de Eng, así que vayan a verlo porque es espectacular. Dos, el strict TDD mode. Cuando hacemos el SD init, detectamos test la gente recibe instrucciones más fuertes en apply y verify, ¿no? Es implemento y después los vemos. Acá hay test, hay runner, seguir el TDD, no te salte la verificación, etcétera. Tres, sub agents por fase. Bien, ¿qué es esto? Que el orquestador no hace todo, coordina. Una fase puede correr con un agente distinto que la siguiente, lo cual evita contaminar contexto y permite usar modelos distintos por fase. Importante para no crear ruido a la hora de hacer esa implementación de cualquiera de estas tareas, de cualquiera de estas fases. Bien, y la más importante de todas, la número

29:58 cuatro, harnesses y Garels. Bien, Gentley no confía en el agente, bien, no confía de que se porte todo bien y que sea un good boy. Bien, acá lo que le hace es le pone un arnesa alrededor antes de avanzar pregunta automático, interactivo, dónde guardamos, qué hacemos, quién so qué acá qué hacemos si supera el presupuesto, etcétera. Entonces, parece que es un detalle, pero no es un detalle porque el problema con la IA, bien, con cualquier coding agent, no es que no sepa escribir código, es que si no le podés meter un límite hacen cualquier cosa con muchísima confianza. Aparte y te lo van a decir, "No, es que esto es así, esto es espectacular." Y vos decís, "Pero no era así." Ah, tenés razón. Te voy a decir, "Pero ya te exploté toda la base de datos." Entonces, Genti, convierte esos límites

30:45 en proceso de vuelta. No es prom engineering, es ingeniería de procesos, de workflows. Bien, entonces la diferencia entre un dev junior con IA y un senior con no es la herramienta, es el contexto. El junior le pide magia, pero el senior lo dirige. Vos sos el arquitecto, la I es el ejecutor. Tony Stark no le dice a Jarvis, haceme algo flaco. No le dice contexto, constraints, objetivos y feedback. Eso es gentil aplicado a código o al cualquier cosa. Porque muchas me preguntan, esto lo puedo hacer con data science. Hacelo, papurre, gente hasta con medicina que aplica esto. Bien. Y además, no pasa nada si sos junior, no pasa nada si sosenior, si sos senior o lo que sea. Gentently te va a llevar ese objetivo que vos querés porque también tiene una

31:31 personalidad hecha para enseñar. Entonces, no tenga ningún tipo de problemática, lo instalo y veo que anda. Sí. Entonces, tres cosas para cerrar. Una, si quieren que baje este flujo a una fichure real completa desde proceso hasta verify, déjenme en los comentarios si lo grabamos. Bien, a ver, acabo de hacer una presentación, pero si quier algo más lo hacemos y si no tienen mi segundo canal Genteman Programming Bots BODS en el mismo YouTube y ahí hago siempre streams todos los viernes explicando todos estos flujos implementando cosas en tiempo real. Número dos, si estás armando un research técnico y querés probar una herramienta que ataques a fase específica, James Park, como les mostré por ejemplo, le regala créditos gratis a registrarse. Tienen un link abajo en la descripción. Y número tres, suscríbanse porque el

32:18 próximo video seguimos con cómo hace que los agentes trabajen en equipo, no como chatbots sueltos. Y no solamente eso, sino que también les doy novedades del ambiente, cosas de seguridad y también enseño obviamente programación soft skills, lo que quiera, papá. Acá estamos. Así que nada, nos vemos. Lo van a compartir hasta con su abuela. Abuela. Saludo video de Gentman. Nos vemos, gente hermosa. Chao. Nos vemos. Oh.