Así Programo con IA Tras +500 Horas (SOLO CÓPIAME) transcript

Mira esto. ¿Sabes qué es esto? Es un flujo de IA programático y con él hemos multiplicado por cuatro las feature que sacamos en mi empresa. Yo le digo el ticket a resolver y él me da la feature terminada. Me lo habéis pedido muchísimo, así que por fin vengo a contarte cómo tengo montados estos flujos, qué lenguaje de programación usar, cuáles son las piezas que lo componen y también cuáles son los problemas asociados.

Mi idea es que cuando acabes este vídeo seas capaz de montar tu propio sistema. Porque si lo que tú haces es abrir Cloue y hablarle al chat, ya te digo yo que eso no es vida. Y lo sé muy bien porque hace unos meses yo era como tú. Antes nos metíamos en linear, revisábamos el ticket, abríamos Clou en una terminal y le decíamos de implementarlo. Estábamos atentos por si Cloue requería de nosotros, algo que conforme te ponías a multiplicar tareas se convertía en un infierno con 1000 terminales abiertas a la vez.

Cuando terminabas te ponías a revisar el código y le decías de cambiar unas cositas, cositas que podían ser dos o podían ser 30. Así una y otra vez, porque no contábamos con un sistema. Lo que teníamos era un chatbot que podía picar código y si tú ahora mismo trabajas así, te digo que lo que tienes es una y no porque no funcione. O sea, yo he estado sacando features así con mi equipo, la empresa donde trabajo durante meses, pero la realidad es que con los sistemas que tengo montando ahora, que te vengo a contar, se vive mucho mejor.

Piensa que tengo algo que me avisa cuando me necesita, por lo que no tengo que estar revisando todo el rato las terminales, que es capaz de trabajar 10 horas en mi presencia y que cada fallo que le corrijo sé lo que tengo que tocar para que no lo vuelva a hacer. Pues la vida es otra, como te podrás imaginar, y la productividad también. Para ello, lo único que necesitas hacer es montarte un flujo programático. Ah, que no sabes lo que es un flujo programático.

Normal, pero espera porque lo vas a saber. Te aviso desde ya. Voy a decir flujo programático unas 40 veces en este vídeo, así que vamos a dejar claro qué es. No es un prom muy largo, no es un chat con la IA, es un programa literalmente un ejecutable con sus pasos, sus condiciones y sus bucles. Un programa que va llamando a la IA por trozos. ¿Y por qué un programa? Porque la es buenísima haciendo cosas, pero es malísima decidiendo por su cuenta cuándo ha terminado, qué es lo que toca después y si lo que acaba de hacer está realmente bien o mal.

Sobre todo cuando tenemos agentes a los que les damos muchísimas cosas y se le llena el contexto. Así que toda esa parte la vamos a obviar y solamente nos vamos a quedar con su capacidad y su potencia de cómputo. Para el resto, lo que queremos es usar código. De ese modo vamos a intentar obtener algo más determinista. Es como si quisiésemos atar en corto a la IA usando la programación. Piensa, por ejemplo, en un bucle.

Si lo que tenemos es un chat con la el bucle acaba siendo tú. Tú le pides, tú lees, tú ves que no te hace caso, tú se lo vuelves a pedir y todo eso. Tú eres al final el que se cansa. Sin embargo, si montamos un programa, si montamos un flujo programático, ese bucle vive en código. Está escrito y siempre va a ser el mismo y no se va a cansar nunca. En una sola frase es el cómputo de la con la correa de la programación. ¿Cómo se consigue eso?

Con tres pilares sersencillitos que cuando los entiendas ya vas a poder empezar a montarte tu propio sistema. Así que espero que tengas la tarde despejada. Espera que te cuento. Si tienes que revisar lo que te ha dado Claude, darle permiso en cada paso, responderle preguntas a mitad del proceso. Vives en el pasado, porque el primer pilar de esto es la autonomía. Y autonomía de verdad es en la que tú defines el problema y el sistema te devuelve el trabajo terminado y probado sin que tú tengas que aparecer en cada paso.

En mi caso solo le tengo que dar el número del ticket, los repositorios implicados y él me avisa cuando están las full request abiertas y ha respondido todos los comentarios del bot que tenemos para revisar las pull request. Para esto vas a tener que sentirte cómodo otorgándole permisos o adaptando todo para comprometer lo mínimo posible la seguridad, pero darle la mayor cantidad de libertad y vas a tener que desapegarte del código porque tú ya no vas a estar.

Tú vas a iterar al final el sistema en base al output que te dé, pero no vas a corregir nada a medio camino porque si no estamos en las mismas. Además, tendrás que asegurarte de hacer bien los diseños iniciales, porque este sistema que yo te presento no es un end to en que va de una idea feliz de una persona a una feature, sino que nosotros le damos como entrada, que es lo que nos sirve a nosotros para crear los tickets y los substickets en linear, un buen diseño técnico, un diseño que hemos revisado y hemos aprobado el resto del equipo, ya que la cosa es ponerle las mínimas piedras en el camino a nuestras agentes. tendrás que insertarle la máxima de que sean lo más autónomos posibles.

Así que ellos deben ser capaces de tomar decisiones y averiguar cuando les falte algo de información. Quizás te pienses que esto del libre albedrío no puede salir bien, pero es que para eso tenemos el segundo pilar, la corrección única de errores. Enfócate en que cada cosa se arregle solo una vez. Un fallo se puede cometer solamente una vez. En el momento que ocurre, no te dedicas a arreglarlo y ya está, porque eso sería poner un parche, te dedicas a iterar la pieza del sistema que haya cometido ese fallo para que no vuelva a ocurrir.

En mi caso, yo tengo un sistema de destilado de lecciones para cada vez que acabo un ticket que saca información de las correcciones que le he ido dando. Además, cada semana me dedico a lanzar la skill de retro analizar y mejorar los flujos que he estado trayendo esa semana. ¿Cómo te puedes asegurar de que la pieza que falló no vuelve a fallar? Pues porque tenemos un programa al fin y al cabo. Si lo que tú tienes es un bloque gigante de código, arreglar un error te acaba rompiendo otras tres cosas.

Y eso no es una corrección, es otro parche. Si queremos que sea definitiva, no vale solo un programa al uso, sino que cada pieza tiene que hacer una sola cosa o lo que es lo mismo, hay que tener muchas piezas chiquititas. Y este es el tercer pilar, modularidad y granularidad. En la experiencia de mi empresa, los agentes funcionan mejor cuantas menos responsabilidades tienen. Vamos, que cuanto más pequeño, mejor. Por eso el sistema se debe de componer de piezas chiquititas que interactúan entre sí.

Yo lo que tengo es una pieza por cada paso, pero de eso te hablo ahora. La cosa es que cuando algo falle, tú lo que haces es iterar esa pieza, darle algún ejemplo más, descomponerla en piezas más pequeñas, cambiar el código que tiene asociado, etcétera, etcétera. Siguiendo estos tres principios, puedes montarte flujos y sistemas como el que tengo yo. Aunque si lo que queremos es implementar bien estos pilares, hay algo que no te he dicho realmente sobre la autonomía, porque el problema es que estos flujos son autónomos, pero con comillas, porque si te da por apagar el PC dejan de funcionar.

Al final es una herramienta que abres y cierras como cualquier aplicación que tengas instalada. Por eso yo desde hace algún tiempo estoy explorando la autonomía completa. Imagínate poder despertar por la mañana, encender el ordenador y encontrarte con cosas hechas. ¿Cómo? Gracias a tener un servidor, concretamente un VPS autogestionado de Dreamhost, una máquina completamente mía con acceso root donde yo decido todo lo que corre dentro, pero que nunca tengo que apagar.

Desde el panel despliegas automatizaciones con N8N en minutos o te montas cositas más adoc como las que tengo yo. Piensa que aquí los recursos son tuyo. Entras por SSH como en cualquier servidor y hala, a correr. Yo tengo un sistema al que le he dado mis gustos y me trae cada mañana un periódico curado con solo lo que me interesa. Y algo que claramente se beneficia mucho de todo esto son los sistemas de observabilidad de los que te he hablado alguna vez.

Nuestra plataforma está monitorizada y protegida sin que ninguno del equipo necesite tener el ordenador encendido. Y si quieres le instalas Hermes Agent y tienes tu propio mayordomo haciendo lo que te da pereza. Además, puedes tener todo a la vez porque el plan de entrada ya trae 4 GB de RAM, disco NVME y ancho de banda ilimitado. Dreamcost te pone la máquina, la red y la protección contraataques. Lo de dentro ya lo instalas y lo configuras tú si quieres, que es justo lo que queremos, no tener que abrir un ticket con soporte cada vez que quieras instalar algo en algo que se supone que es tuyo.

El precio menos de $7 al mes en el plan de 12 meses. menos de lo que te cuesta una de las suscripciones que tu VPS autogestionada te va a permitir quitarte encima. Te lo digo ya. Dejando de lado lo útil que puede resultarte esto, es muy divertido ser capaz de montar y crear tus propios servicios. Así que échale un ojito. Te dejo el enlace en la descripción. Con esto ya sabes dónde correr tu flujo, pero sé que aún te queda una duda.

Pero, Jesús, ¿en qué lenguaje de programación lo hago? Ah, claro que todavía no te ha hablado del código. Espera que te recomiendo uno para que no falles. Para montarte este tipo de flujos, mi recomendación es que uses cualquier lenguaje. Mejor dicho, me da igual el lenguaje que uses porque no lo vas a tocar tú. En mi caso, tengo el editor de código montado en RA porque quería hacer una aplicación para el Mac que fuese lo más rápida posible, pero yo no sé nada de Rust.

De hecho, en este vídeo apenas tienes ejemplos de código porque ni siquiera yo sé código que hay dentro que ha montado todo esto. O sea, no vayas a ponerte a hacer esto a mano. La idea es que reflexiones sobre los pilares arquitectónicos, sobre los principios, sobre los pasos que te voy a describir en el siguiente punto y decidas qué es lo que tienes que adaptar para montarte el sistema que tú quieras. O si no, que le pases la transcripción de este vídeo a Cloue y le digas que te monte algo similar, ya sea en RAS, Python, Tie Script.

Usa el lenguaje que mejor te venga mientras funcione. Adelante. Aquí lo que importa no es la sintaxis, sino la arquitectura a nivel de flujo. De hecho, todos los diagramas y esquemas que te he estado mostrando por pantalla están pensados para que tú puedas alimentar a tu IA y replicar todo esto en el lenguaje que sea. Con el lenguaje que tú quieras e invocando a Cloud con Cloud - P, ya vas a poder tener tu IA en formato Headless y crear flujos con ella.

Lo único que tienes que configurar es que te dé la salida en JSON. Y una vez que has montado eso, lo que necesitas es un proceso que lea el Jason y haga cosas. Ya está. En mi caso, cada paso del flujo es uno de estos procesos y cada uno arranca con algunas cosas que ya tengo configuradas como el modelo, el esfuerzo, las herramientas que puede usar y qué es lo que tiene que cumplir para dar su trabajo por bueno. No te preocupes porque el coste al menos utilizando Cloude, que es lo que tengo yo, acaba tirando de tu suscripción semanal.

No obstante, si aún así tú quieres código, aquí tienes algunos ejemplos muy lindos. ¿Te han gustado? Pues esto te va a gustar más porque estás a punto de descubrir los pasos que componen todo el flujo. Todo el flujo se puede acabar descomponiendo en tres grandes bloques. El primero, investigar. El objetivo es que los agentes lo tengan todo bien masticadito para que se inventen las cosas lo menos posible. El segundo, implementación.

Aquí el objetivo es que sea lo más rápida y lo más fiel posible a la calidad que nosotros esperamos para que después haya que corregir lo mínimo. Y el tercero, la verificación. En este comprobamos que la funcionalidad hace lo que tiene que hacer. Revisamos el código y lo dejamos todo listo para que probarlo sea sersimple. Estos pasos se coordinan mediante el flujo, mediante el programa principal, con la mentalidad y los principios que yo te he dicho antes.

De tal manera que si algún paso de la verificación encuentra algo que hay que corregir, no lo corrige el mismo, sino que lo enruta y se lo pasa a los agentes de implementación. Vamos, en algunas partes es como si fueran bucles montados y estos tres bloques se acaban dividiendo en ocho pasos. El primero de ellos, Enrich, recibe el ticket, se lee los criterios de aceptación e investiga por todos los repositorios buscando información útil para hacer la feature, site cases, archivos de ejemplo que tenga que modelar, funcionalidad que se vea afectada, etcétera, etcétera.

El segundo paso es el plan y este produce dos cosas. La primera es un plan en formato pund y la segunda es el mapa de los criterios de aceptación. Y estos criterios no son checkboxes, ¿vale? Estos son comandos ejecutables por el sistema. ¿Por qué? Porque la máquina va a tener que verificar que los agentes están haciendo lo que se supone que tienen que hacer para completar la tarea. Y de este modo es como podemos saber si se ha completado o no de una manera programática y no siguiendo el criterio de un agente cualquiera.

Además, dentro de este paso se genera una especie de libro de tareas, que es lo que va a llevar la contabilidad de las tareas y de lo que hace cada gente. De esta manera genera coherencia entre los agentes que son independientes. Aquí básicamente almacenamos qué construyó cada uno anotándolo con el Sha de su comit. Tercer paso, implement y aquí es donde se va el 80% de los tokens. Lanzamos agentes independientes de implementación, concretamente uno por subtarea, para que no se llenen los contextos.

Esta descomposición sale del diseño técnico, ¿vale? Yo la modelo en forma de subtickets de linear. Cuando todos los agentes de implementación han terminado, lanzo un último agente que se encarga de pasar los test y el linter y arreglar aquello que no esté bien. Cuarto paso, la revisión de código. Este es un sistema bastante tocho e ineficiente porque no creo que necesitemos una review tan grande si me preguntas, pero básicamente se encarga de revisar toda la implementación y le dice a los agentes de implementación si es que hay que arreglar algo.

De nuevo, un agente una responsabilidad, el que revisa no arregla. Quinto, Qacode. Este no revisa el código como el de antes, sino que este ejecuta la lista de los criterios de aceptación que te he dicho previamente, la que se escribió en el paso del plan y reporta que ha devuelto. Con esta me aseguro que el código a nivel funcional, a nivel de código, hace lo que se supone que tiene que hacer para cumplir con el ticket.

Sexto paso, release, que simplemente me crea las PRs en GitHub. Sexto, QAES, que me genera un plan de prueba si me lo deja en el ticket de linear para que yo pruebe la funcionalidad con todo bien mascadito. Y el octavo, Adress review. Una vez que se ha subido la PR, me dejo aquí este agente haciendo polling y revisa los comentarios que le han puesto en esta full request. Decide cuáles tienen razón, arregla los que sí la tienen, responde, cierra los hilos y básicamente se encarga de que la PR esté limpita para que yo se la pueda pasar a los compañeros.

Antes también le tenía metido unos pasos de qua backend y qua frontend que me levantaban el servidor y navegadores utilizando play rate para poder probar la funcionalidad de manera géntica. pero los acabé quitando porque la realidad es que si yo tengo que revisar la funcionalidad, o sea, en mi empresa todo el mundo hace cua. Entonces, una tarea que yo deje en CUA le va a tener que hacer Cuba mi compañero. Y si yo le pongo unas QA noes o yo le indico más o menos cómo hacer el QA con casos que no van a pasar, va a perder tiempo mi compañero y lo voy a perder yo.

Así que de igual manera yo tengo que asegurarme después de que mi feature funciona y de que todo lo que escribo para hacerle cua pasa, por lo que yo ejecutaba estos pasos, pasaban. tenía que verificarlo yo manualmente porque si no mis compañeros iban a perder el tiempo y así era una tontería porque estaba haciendo lo mismo dos veces, así que como yo lo voy a tener que hacer igual los quité y lo hago yo. De ese modo la responsabilidad queda donde ya te he dicho, al principio para los diseños y al final para hacer el qua.

Y de nuevo, cada paso de estos que te acabo de nombrar es un agente independiente que invoco en una fase distinta del flujo de forma headless. Con el paso de tiempo he ido adaptando el esfuerzo y el modelo que utilizo en cada uno y actualmente esta es la distribución que tengo. En mis primeras iteraciones me fundí a la suscripción entera con solo el implement, así que esto es a base de prueba y error. Gracias a esto, puedes darme hoy una funcionalidad de producto y que la tengamos en producción con calidad en una o dos días.

Claro, con esto la cantidad de fature que podemos sacar se ha multiplicado drásticamente. Tanto es así que ahora la velocidad es un problema porque claro, yo te he contado las luces, pero la realidad es que este sistema también tiene muchas sombras, así que prepárate porque igual te has comido todo el vídeo y no te interesa montarte algo de hecho. Eso de la velocidad está muy guay, pero como te digo, es problemático.

Dejando de lado el usuario que recibe más faturana de las que puede llegar a usar, es que realmente nuestro departamento de producto no puede dar tantas fatures. O sea, si produésemos todos a plena capacidad nos comeríamos el backlock que tenemos en una o dos semanas. Si queremos hacemos feature. Tanto es así que nos estamos abriendo proyectos en paralelo. El mío es el de observabilidad, que casualmente también usa estos flujos programáticos de lo que te estoy hablando.

Además de esto, posiblemente te encuentres problemas con los límites, porque todo esto no es barato. Como te podrás imaginar, tener a la IA 10 horas trabajando solo es posible con la suscripción de 200 € que es la que nosotros tenemos en la empresa. Durante mis primeras interacciones las fundía y seguramente si ahora lanzo dos features en paralelo me acabe comiendo los límites de 5 horas. Uniendo todo esto debes entender que no es un sistema perfecto.

O sea, el concepto de la granularidad y someter a la IA está brutal a nivel teórico, pero aún así no vamos a conseguir un sistema determinista 100%. Igual que te digo que hay errores que yo itero el sistema y no vuelven a ocurrir jamás, todavía no he conseguido que entienda bien cuándo tiene que poner comentarios y cuándo no. Y tampoco llegamos a conseguir esa perfección en el trabajo de front. Es verdad que a nivel funcional y de calidad, el output es buenísimo, pero a nivel de diseño y pixel perfect no conseguimos que clave lo que hace nuestro diseñador.

Muchas veces se inventa el CSS y hace lo que quiere o cambia de 14 píxeles a 16 píxeles o utiliza otros componentes, lo que le venga en gana ese día. Vamos. No sé si es porque utilizamos Tailwind o por qué, pero actualmente es lo que más problemas nos está dando. Por lo general, cuando acabo la feature, más que ya hacerle un qua estricto funcional, me dedico a revisar que los píxeles, los márgenes, que todo esté tal y como pide el diseño.

Es cierto que actualmente estamos trabajando en crear un bucle con una skill que te abra el navegador y se encargue de verificar todo esto por ti, pero aún no hemos llegado a la perfección. Y si tú vas a hacer algo así, que sepas que este es un problema al que nosotros nos estamos enfrentando. Y el último problema que te vas a encontrar y que te mereces que te revele por haber llegado hasta aquí es que posiblemente no te merezca la pena hacerte algo de esto.

Me refiero, todo esto que yo te he contado al final no es más que un SDD con esteroides. Es verdad que está muy guay como proyecto porque acabas entendiendo muy muy bien cuáles son los harness que se recomiendan, cómo se hacen las cosas y al final puedes modelarlo al milímetro como tú quieras. Pero vamos que si coges, por ejemplo, el Gentle AI de Gentleman Programming y te pones a darle, posiblemente los resultados que obtengas sean muy similares, si no mejor de lo que podemos llegar a hacer nosotros con nuestro sistema.

Yo sigo con Forge, que es mi ID porque lo empecé hace mucho tiempo, es como mi bebé y me gusta iterarlo y hacer un poco de min maxing cada semana para ver qué más le puedo seguir sacando. Además de que claro, el flujo que tiene Forge está hiperespecializado para la forma y las herramientas con las que nosotros desarrollamos en mi empresa, pero la realidad es que si yo estuviera solo y quisiese hacer esto para mis proyectos personales, el trabajo de Gentleman, yo creo que es más que de sobra para sacar una calidad brutalísima.

De todos modos, si te quieres montar algo así, adelante, yo lo hice. Pero para hacerlo vas a necesitar proyectos y cositas para probar. ¿Y de dónde sacas estos proyectos? Mi consejo es que de un roadmap. No, en serio, los roadmap están muertos. Para progresar ahora en programación y comerte algo, tienes que hacer otra cosa, aunque de eso ya te hablé en el vídeo que te estará apareciendo por pantalla. Échale un ojito porque te va a encantar.

Sin más, no te quito más tiempo. Gracias por estar en otro vídeo más aquí conmigo.