Usas la IA como tu Abuela: 5 Cosas que lo Cambian Todo

Aprende a usar la IA de forma avanzada con programación y flujos automáticos, dejando atrás el uso básico tipo chatbot.

Key Takeaways

No basta con usar IA como un chatbot; hay que programar flujos para autonomía real.
Los megaprompt son útiles pero insuficientes para sistemas complejos y fiables.
Automatizar con cronjobs y workflows mejora la eficiencia y evita errores de concurrencia.
La programación permite dividir tareas en piezas pequeñas para iterar y mejorar.
La IA puede trabajar de forma autónoma y generar resultados sin intervención constante.

What the video covers

El uso básico de IA como chatbot limita su potencial y genera autonomía parcial.
Los megaprompt funcionan, pero no garantizan resultados deterministas ni perfectos.
La solución es orquestar la IA mediante flujos programáticos y código para mayor control.
El uso de cronjobs permite automatizar tareas y ejecutar agentes IA de forma autónoma.
Se recomienda usar workflows para evitar conflictos al trabajar con múltiples agentes.
La autonomía total requiere que la IA pueda trabajar sin intervención constante del usuario.
La ingeniería y el conocimiento de programación son clave para aprovechar al máximo la IA.
El autor comparte su experiencia implementando sistemas automáticos que generan pull requests.
El enfoque reduce costos y dependencia de suscripciones caras de agentes IA.
El cambio de mentalidad es fundamental para pasar de un uso pasivo a uno activo y programático.

Chapters

¿Por qué no es suficiente usar la IA solo con megaprompt?

Los megaprompt pueden funcionar, pero no garantizan resultados deterministas ni que la IA cumpla todas las tareas. Son una caja negra y dependen de la interpretación del modelo, lo que puede generar fallos o tareas incompletas.

¿Qué ventajas ofrece programar flujos para usar IA?

Programar flujos permite controlar el orden y la lógica de las tareas, hacer comprobaciones y dividir el trabajo en piezas pequeñas que se pueden iterar y mejorar, logrando mayor autonomía y fiabilidad en los agentes IA.

¿Cómo ayuda un cronjob en la automatización con IA?

Un cronjob es una tarea programada que se ejecuta automáticamente en el ordenador a una hora establecida, permitiendo lanzar agentes IA y flujos sin intervención manual, lo que facilita la autonomía total y la ejecución continua.

Full Transcript — Download SRT & Markdown

Speaker A

¿Usas la IA como tu abuela? Si te abres Cloue, le pides un endp y esperas a que termine para volver a hablarle, lo que tienes es un chatbot. Créeme, me he tirado más de un año así pensando que sabía usar la IA, pero ahora sé que no porque he pasado de esto a esto.

Speaker A

Ahora enciendo el ordenador por la mañana y me encuentro full request que yo no he abierto. En una semana he sacado tres funcionalidades nuevas yo solo. Y todo por sacar ventaja de ser programador, por dejar de usarla ella como tu abuela.

Speaker A

El cambio son solo cinco cosas y las puedes montar esta misma tarde. La primera me enseñó que sí. Mis agentes me estaban mintiendo y los tuyos también.

Speaker A

Imagina que te sientas una tarde a trabajar tranquilo con tu café y le basas unas 50 cosas que hacer a tu cloue mientras te pones a ver un vídeo de Alpacatech Super chill. Al rato Clauda te dice que ha terminado. Revisas y

Speaker A

resulta que de las 50 cosas que le habías pedido, solo ha hecho 35. Y no es algo que tengas que imaginar mucho, porque esto está en la documentación de Antropic. Ahí te listan los tres modos en los que sus agentes fallan y uno de

Speaker A

ellos es este. Lo llamaron pereza. ¿Y sabes por qué? Porque todo depende de un prompt. En mi empresa nos hemos dado cuenta de que los megaprompt no funcionan bien, o sea, sí que funcionan, funcionan bastante bien. Ya sabrás que

Speaker A

yo he sacado mucha funcionalidad utilizando mi megaprompt, pero la realidad es que rozar la perfección con ellos es imposible porque un prompt es una caja negra. Son cosas que tú le dices a la gente y que la gente decide

Speaker A

cumplir o no. Cuando haces algo con un prompt y te falla, lo único que puedes hacer es añadir cosas o modificar ese prom y con ello volver a tirar la ruleta de Cloude. ¿Te hará caso en esta sesión?

Speaker A

No lo hará. Si solo dependemos de ellos, no tenemos ninguna seguridad de que no nos la vuelva a liar. Aunque si quieres seguridad, espera al tercer punto, porque ahí te diré una cosa que le tienes que decir a tus agentes y que lo

Speaker A

cambia todo. La cosa es que a base de prompts no hay seguridad de que la IA no te la líe. En su mayoría van bien, pero ya te digo, cuando empiezas a tener algo muy muy grande, arreglar los

Speaker A

detalles más finos se vuelve imposible. Básicamente porque no sabes qué estás haciendo ni qué es lo que está haciendo él. Por eso tenemos que sacar nuestra ventaja como programadores. Tenemos que hacer código. Te propongo que en lugar de tenerlo todo en un megaprompt, pruebes

Speaker A

a orquestar todo mediante un flujo programático. Las distintas piezas que necesites las puedes encapsular en forma de skill o en forma de agentes, pero el flujo, las comprobaciones, el cuándo, todo eso queda coordinado a nivel de código con un flujo programático como

Speaker A

este. Con él puedes asegurarte de que los pasos al menos son deterministas. Después de A va B. Y si pasa esto, ocurre esta otra cosa. ¿Por qué es código? Lo que nosotros conocemos y podemos determinar. Gracias a la

Speaker A

invocación de cloud men p y a los cubs que tenemos, podemos insertar cloud en nuestros flujos programáticos para hacer uso de toda su potencia de cómputo.

Speaker A

Ahora, el editor de código que yo me monté se ve así y todo es un flujo programático con muchas piezas pequeñas que voy iterando y voy mejorando. Cuando algo falla, sé qué pieza es la que ha fallado y la puedo iterar. Al final no

Speaker A

es más que acercar los agentes de inteligencia artificial todo lo que podamos a un sistema determinista y para ello hay que aplicar ingeniería. Por esto tu abuela no lo puede hacer ni la persona de marketing. De hecho, la

Speaker A

propia guía de Antropic para OPUS 5 ya te habla de esto. Yo ya tengo mi flujo de trabajo montado de esta manera y no solo mi flujo, porque en mi empresa hemos conseguido montar sistemas que nos arreglen los bugs y hagan de centinelas

Speaker A

de nuestra plataforma por nosotros de forma automática. Aunque para hacerlos tuve que recordar una palabra que se me había olvidado, una palabra que no he visto comentar a nadie que te hable de IA.

Speaker A

Con todo esto de la IA han aparecido muchas palabras que están en bocas de todos, guardarreiles, agentes y un montón de cosas más. Pero esas palabras no me solventaron nada porque hubo un tiempo en el que me pasé días enteros

Speaker A

buscando cómo podía automatizar cosas con Cloue y no quería descargarme la app de Cloue Cowork, sino que quería algo que yo pudiese pautar y se ejecutase en mi ordenador siempre a la misma hora. Y entonces recordé una palabra que me

Speaker A

habían enseñado en la universidad cuando estudiaba sistemas operativos. Una palabra que todo programador sabe, pero que con esto de la se nos ha olvidado porque solo sabemos la palabra guardarrail, los cronobs. Si eres un programador new age, posiblemente no los

Speaker A

hayas usado nunca. Un Chrome es una tarea que programamos para que se ejecute sola. Se queda de fondo en tu máquina mirando en Redoc y cuando llega la hora que le has puesto, lanza lo que le hayas dicho que lance.

Speaker A

Es algo muy común en el mundo de los servidores. Con esto se han montado toda la vida scripts de limpieza, recordatorios, copias de seguridad y un montón de cosas más, pero yo ni siquiera me acordaba de que existía, igual que

Speaker A

con el tipa anterior. Mucho quería lanzar agentes y gastar tokens, pero no me acordaba de que soy programador. Y si a la ejecución automatizada de tareas en el PC le sumamos que podemos lanzar cloud en modo Headless con la flag men

Speaker A

P, que no te preocupes porque esto no va a ser un problema para tu suscripción.

Speaker A

Yo lo vengo utilizando ya durante unas semanas y no he pagado por uso en ningún momento. Simplemente agota los límites de tu suscripción como si lo utilizases en la terminal o en el chat web. Si unimos a más cosas ya podemos montar

Speaker A

flujos automáticos en nuestro PC. Flujos que, como ya hemos visto, lo hacemos de forma programática para obtener lo mejor de los dos mundos. Eso sí. Y te dejo otro regalo por si no lo conocías.

Speaker A

Trabaja con Wordess porque si lanzas tres agentes sobre la misma carpeta se van a acabar pisando. Uno toca un fichero mientras que el otro lo está leyendo y al final la acabas con basura que no compila ni sirve para nada. Pero

Speaker A

con los work te quitas esos problemas, incluso lo recomiendan en la propia documentación de Cloude. Desde que hicimos eso, en mi empresa tenemos una resolución automática de books y junto a una compañera he montado un centinela que se despierta todos los días a las 9

Speaker A

de la mañana, revisa el estado y los logs de las aplicaciones y arregla si se ha roto algo por los despliegues del día anterior. Así es como exprimimos a la IA de verdad y esta es la nueva forma de

Speaker A

trabajar que estamos experimentando en la empresa. Yo enciendo el PC y lo que tengo son nuevas pull request que nadie ha hecho. Todo con al final un Chrome, un flujo y unos cuantos ficheros de texto. Aquí no hay suscripciones de

Speaker A

agentes gastando miles de dólares. Hay algo que tú puedes hacer porque eres programador y tu abuela no puede. Pero para poder hacer esto hay que tener algo en cuenta. Eso que ya te adelanté en el primer punto. Permíteme que te cuente.

Speaker A

Mi día ha cambiado mucho. Ahora llego a trabajar con la misión de probar y revisar lo que mi Claudia ha estado haciendo cuando yo no estaba, pero para esto hay que cambiar el chip porque yo creía que tenía montado algo autónomo

Speaker A

con mi Megaprom, pero era mentira porque eso que tenía necesitaba mi aprobado para el plan, mi aprobado para la implementación, mi aprobado para publicar la MR. El flujo entero en determinados puntos se quedaba quieto esperándome. Si yo entraba a una reunión

Speaker A

de una hora y a los 10 minutos resulta que Claude quería algo de mí, iba a perder 50 minutos que no estaba trabajando mi agente porque esa solo trabajaba cuando yo estaba delante.

Speaker A

Ahora eso lo llamo autonomía parcial, que es una autonomía de mentira. Pero yo no quiero eso. Tú no quieres eso.

Speaker A

Queremos la autonomía total, que Claude pueda estar trabajando 4 horas sin detenerse. Y para eso hay una frase que nos toca grabarnos a fuego. Un error se arregla una sola vez. Si quieres q

Speaker A

cabeza la mentalidad de arreglar las cosas, porque si no te vas a dedicar a poner parches, a llegar por la mañana, ver qué te han traído los flujos, corregir a mano lo que estaba mal y seguir. Y de nuevo, tú no quieres eso.

Speaker A

Tú lo que quieres es conseguir que cada flujo sea mejor hoy que ayer. Así que cuando algo falle, no entres a corregir ese ticket sin más. Vete a la pieza que tomó la decisión y arréglala, sea código, sea una skill o sea lo que sea.

Speaker A

Con los flujos programáticos es sencillo porque lo tienes todo en piezas pequeñas y sabes exactamente qué pieza es la que ha fallado. No es que hagas magia de ningún tipo, sino que empiezas a iterar y mejorar un sistema. Y ese trabajo, el

Speaker A

de abrir la pieza que falló, itterarla y mejorarla, es el de un programador. Mi abuela solo le puede pedir cosas a un chat, pero no puede dividir un sistema en piezas pequeñas e ir itándolas con criterio. Al final hay que tratarlo como

Speaker A

tratamos a un producto. Medimos, vemos dónde se rompe y añadimos una versión mejor la semana siguiente. De esta manera vamos iterando hasta llegar a rozar la perfección. Eso sí, si quieres que esto perdure, deberás tener en cuenta el último punto, porque si no, en

Speaker A

un mes hay que tirarlo todo a la basura. Una primera pieza que te diría que debes añadir siempre tus flujos es la observabilidad, porque el sistema que tú has montado lo tienes que mejorar e iterar. Tú tú eres la persona que sabe

Speaker A

cómo quieres que funcione y qué esperas de él. Así que vas a tener que poner tu criterio. Pero si le dices a la gente que busque cosas que mejorar, siempre las va a encontrar. Y tú no quieres eso,

Speaker A

tú quieres mejorarlas con tu criterio y para ello vas a necesitar datos y saber cómo ha ido funcionando todo. Porque cuando te pongas a montar este tipo de cosas, posiblemente la cagues. Te equivocarás mucho como me equivoqué yo y

Speaker A

vas a perder mucho tiempo y límites de la suscripción. Así que déjame ahorrarte todo eso.

Speaker A

Cuando empecé a montar cosas pensaba que cuanto más mejor, más super agentes, más esfuerzo de razonamiento, todo más. Y me monté un flujo entero de superentes convencido de que iba a ser la Pero, ¿sabes cuál fue la realidad? No

Speaker A

mejoró absolutamente nada. O sea, me monté un deep reviewer brutal con subagentes según aspectos específicos del código, otros subagentes adversariales, escépticos, un montón de cosas que se lo sirvieron para gastarme un 5% de la suscripción semanal cada vez

Speaker A

que lo ejecutaba, porque la calidad al final no difería mucho de cuando le decía a Claude, "Simplemente, revisa este código según los patrones del proyecto, aunque mi lógica no sonaba mal. O sea, si puedo tener más manos, más inteligentes haciendo algo, ¿por qué

Speaker A

no tenerlo?" pues porque no hace falta. Resulta que con la IA más no significa mejor. puedes acabar teniendo algo más lento, más caro y que falle más que antes. Y no lo digo yo. De nuevo, la propia Antropic su documentación dice

Speaker A

que en la mayoría de cargas de trabajo, el esfuerzo max del modelo te va a costar bastante más y te va a mejorar bastante poco. Para teras sencillas está demostrado que el modelo sobrepiensa y responde peor que si le pusieses un

Speaker A

esfuerzo más bajo. Y tiene sentido. Es como si pones a un Premio Nobel de física a un problema de regla de tres.

Speaker A

te lo resolverá y ya se pondrá a pensar que por algo le has llamado a él.

Speaker A

Buscará dónde está la trampa y te devolverá tres folios sobre porque tu pregunta está mal planteada. Con los suagentes pasa igual. Un agente bien montado puede ganarle a 20 agentes sueltos. La ley de Brook de toda la vida. Vamos.

Speaker A

Esta es una ley clásica del mundo de la programación. Más gente en un proyecto no significa ir más rápido, porque acá la incorporación hay que ponérgel al día, hablar entre ellas, etcétera, etcétera. Te aconsejo que de nuevo midas

Speaker A

todo en el proyecto y vayas haciendo AB testing. De este modo descubrirás qué merece la pena, dónde hay que añadir, dónde hay que quitar, etcétera, etcétera. Aunque yo te digo esto ahora, pero igual en una semana no te vale

Speaker A

porque yo lo tenía todo superbonito y al final me acabé pasando una semana entera cambiando la escritura de mis promps y skills por culpa de Antropic.

Speaker A

El otro día salió Opus 5 y ese día también publicaron su guía, una guía en la que te dicen que borres lo que ya tenías. En varios sitios de ese documento te dicen que borres, que borres las instrucciones de

Speaker A

verificación, que borres los vuelve a comprobar tu respuesta y que borres un montón de cosas, porque dice que esto ya no aporta nada, sino que se suma a lo que el modelo hace, así que vas a quemar tokens para no mejorar el resultado. La

Speaker A

conclusión es que con cada actualización que le hacen a los modelos se cambia cómo hay que hablarles y cómo se debe trabajar con ellos. Por eso yo tengo la costumbre de sentarme al menos una vez al mes a revisar las actualizaciones y

Speaker A

ver qué es lo que tengo montado para ver qué añadir o qué deja de hacer falta.

Speaker A

Ittero, lo que tengo, elimino, retoco, etcétera, etcétera. Todo gracias a que monté la pieza de la que te hablé antes, la observabilidad. Acostúmbrate a que cada vez que tu flujo corra deje escrito todo lo que ha hecho. En mi caso, genero

Speaker A

un punto Jason por cada corrida que me recoge el modelo utilizado, las herramientas que tocó, cuánto ha tardado, cuánto ha costado y un montón de cosas más. Una vez al mes me siento y reviso los Jason. Muchas veces si no vas

Speaker A

actualizando cómo haces las cosas, te vas a dar cuenta de que con un modelo mejor todo va peor. Además deberías hacer que tu sistema tenga memoria, un fichero de memoria donde el propio flujo pueda aprender lo que va descubriendo e

Speaker A

iterando. Yo esto lo he encontrado superútil con los agentes de implementación, por ejemplo. He acabado depurando un sistema de lecciones que voy fijando en cada ejecución y que hago que se lo lea la corrida antes de empezar a implementar. Pero no escribas

Speaker A

todo porque esto también acaba siendo ingeniería. Si le dejas escribir todo, en dos semanas, vas a tener un fichero de 1000 líneas lleno de basura que solo te comerá contexto cada vez que el modelo empiece. De nuevo, esto es algo

Speaker A

que acaba haciendo un programador, no una abuela. Todo esto lo puedes hacer tú, porque no es que sean flipadas mías, igual que las cosas que nosotros hicimos en mi empresa, tú te puedes hacer las tuyas. Y por ahí fuera hay gente que

Speaker A

está haciendo auténticas barbaridades. Vamos, que no sabes si lo que cuentan es real o esa. Esta frase que acabo de decir es bastante graciosa porque claro, tú piensas que es por los vídeos generados por IA, pero es que estamos

Speaker A

hablando de la IA en un vídeo donde hablamos de aplicar IA. Entonces, tu mente cortoocircuita y vamos al siguiente punto.

Speaker A

Sí, hay empresas que ya están trabajando de forma mucho más bestia que la mía.

Speaker A

Todo lo que yo te he contado lo hacemos con suscripciones Max de Cloud, pero hay gente que utiliza agentes en VPS y cosas así. Pero antes quiero hacerte una puntualización porque todo esto va llegando poco a poco y no quiero que sea

Speaker A

un agobio para ti. Y cuando te digo poco a poco, me refiero a muy poco a poco. Se estima que menos de dos de cada 10 personas a nivel mundial en edad de trabajar utilizan actualmente la IA. Y

Speaker A

todas estas barbaridades de las que te hablo o te enseño se suelen ver sobre todo en empresas de Silicon Valley.

Speaker A

Posiblemente te parezca chulo y quieras montarlo para tus cosas, porque a nosotros al final nos gusta mucho la tecnología. Pero la realidad es que de todos los amigos que yo conozco y que tengo trabajando, la única empresa en la

Speaker A

que se hacen cosas similares es en la mía. Pero si buscas en internet encuentras ejemplos. En blog metieron agentes a sus 12,000 empleados en 8 semanas y dicen que seis de cada 10 los usan siempre. No solamente en

Speaker A

ingeniería, también en ventas. diseño, producto. Desde que lo hicieron parece que sacan un 40% más de código producción o en Interworks que metieron seis agentes corriendo a través de Cronjogs. Y el resultado es que resuelven un 50% más de tickets de

Speaker A

soporte. En mi empresa no estamos tan lejos. De forma 100% autónoma tan solo tenemos lo de los lockss y lo de los books. La implementación de features es cierto que todavía pasa por un diseño técnico humano antes y un cua humano

Speaker A

después, pero somos seis en el equipo y la semana pasada en tr días de sprint ya habíamos sacado cinco funcionalidades nuevas a producción. Ahora, cuando le pases este vídeo a tu colega, porque se lo vas a pasar y le vas a dar muchísimo

Speaker A

amor al vídeo, te va a decir que todo esto es muy bonito, pero que en un mes ha caducado. Y es verdad, pero lo que caduca es la forma específica de montar las cosas, no el conocimiento que necesitas para montarlo, ni la

Speaker A

ingeniería que tienes que aplicar para ello. Y eso es algo que solo puedes hacer tú porque eres programador, pero no tu abuela. Así que saca ventaja de ello y empieza a usarla ella como Dios manda. Aunque esto puede sonarte a

Speaker A

locura y quizá pienses que con este nuevo potencial en mi empresa seamos demasiado. Y yo te digo que tienes razón, literalmente el otro día, eso lo dijo mi CTO en una reunión, nos dijo que sobramos. Si quieres saber lo que pasó y

Speaker A

si me van a despedir o no, ya te lo conté en el vídeo anterior que te estará apareciendo por pantalla. Échale un objito 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.

Topics:inteligencia artificialautomatizaciónprogramaciónmegapromptcronjobsflujos programáticosagentes IAautonomía IACloudeingeniería de software

Get More with the SozAI App

Transcribe recordings, audio files, and YouTube videos — with AI summaries, speaker detection, and unlimited transcriptions.

App Store Google Play

Or transcribe another YouTube video here →

Free tools: TXT to SRT · SRT Validator · Merge SRT · Subtitle to Text · All tools