El creador de Claude Code dice que borres tus skills transcript

Esto es mi carpeta de skills de cloud code. Son 26 y tengo otras 15 adicionales de distintos plugins. La junté durante 6 meses y acabo de borrar casi todas. Y Cloud no se puso más tonto, de hecho, al contrario, se puso más inteligente. Y antes de que pienses que perdí la cabeza, por favor, mira esto. Ese es Boris Cherney, el creador de cloud code arriba de un escenario en White Combinator. Y esto no es una opinión suelta.

De hecho, cuando salió el nuevo modelo de Opus, Antropic borró el 80% del System prompt de cloud [música] code, es decir, de su propio producto. Y ahora la parte un poco incómoda, por así decirlo, es que en febrero yo grabé un video que se llama Pensé que Cloud Skills era puro hype, me equivoqué y 6 meses después estoy grabando este. Y no vengo a decirte esta vez que me equivoqué de nuevo. Las dos cosas son verdad al mismo tiempo y ya vas a entender por qué.

Vamos a recorrer la entrevista juntos y al final vas a tener mi regla de las 3r para saber qué skills se quedan y cuáles se van. Y vas a aprender cómo promtea el creador de Cloud Code palabra a palabra y cómo el mismo creador nos dice que podemos usar Cloud Code para ser el top 1% de los usuarios, es decir, lo que el 99% de las personas está haciendo mal. Y hay un skill también que yo no borré, de hecho ni siquiera lo dudé y es el que menos parece un skill de todos.

Ya, ese te lo voy a dejar para el final. Así que le metí mucho cariño a este video. Te agradecería un montón si me ayudas con un like, no solamente para que me ayudes a mí y al canal, sino porque también le dices a tu algoritmo que este estilo de video te gusta. Además es que he visto que el 80% de los que están viendo mis videos no están suscritos. Así que si eres parte de ese 80% te agradecería un montón si te suscribes aquí abajo.

Vamos con manos a la obra. Solo para asentar una base rápida, porque aquí está el malentendido y yo lo tuve también, un skill no es conocimiento necesariamente, no le enseña nada nuevo a Cloud. Un skill es solamente la estandarización de un proceso. Es como una receta, un manual de cocina, tipo este es el orden, esta es la temperatura y así se plata y después va siguiendo esa receta. ¿Y para qué nos sirve esto? Bueno, para que el plato salga igual la próxima vez.

Es un proceso de repetibilidad. Esa es como la función principal de los skills. Y quédate con esto porque es el video entero en una línea. Cuando quieres el mismo resultado, un skill es oro. O sea, todo lo que es tu facturación, tus propuestas, el formato de tu marca, eh canales automatizados de YouTube, todo lo que sea repetible, los skills son realmente maravillosos. Pero cuando quieres el mejor resultado, la receta estorba a veces.

Ya, porque le estás diciendo al final a este cocinero, "No pienses, sigue esto específicamente como yo te digo que tiene que ser." Y eso tiene un término que ya lo vamos a ver. Y en febrero, claro, esa receta quizás era necesaria. El modelo de febrero eh se podía perder sin ella, pero hoy día ya sabe cocinar y probablemente mejor que cualquier skill que nosotros le podamos dar. Le preguntaron al creador de Cloud Code, a Boris, ¿por qué borraron el 80% de su System prompt?

Y escucha la respuesta completa porque son 35 segundos y es lo más importante de esta entrevista. Every time that a new model comes out, we delete a bunch of the system prompt, change a bunch of the system prompt. We change the set of tools all the time. We change the prompts for the tools all the time. And the reason is every model is very different. So something that you did for one model maybe 3 months ago, it just might not translate at all to the next model.

And so one thing about Opus 5 is it's just really intelligent. And of the stuff in the system prompting for these behaviors that the model should have known, but it didn't. Now Opus 5%. Hay tres cosas muy importantes ahí. Primero, que cada modelo que va saliendo es muy distinto. Entonces, lo que armaste antes fue que ya no te sirva tanto para el siguiente. Y no es que se vaya como degradando necesariamente, sino que ya no aplica.

Ya. Y eso a mí me pegó. O sea, yo tenía skills desde febrero. Segundo, la frase que vale el video, dice que mucho de lo que había en el system prompt eran parches, o sea, cosas para arreglar cosas que el modelo debería haber sabido ya y que no sabía y después remata diciendo que el Opus nuevo simplemente ya lo hace más. Y si traducimos eso a un caso un poco más chico, es decir, a nuestro caso específico con nuestros skills, ese mismo paso uno, paso dos, paso tres, lo escribiste porque el modelo antes se perdía sin él. ya el de hoy día no se pierde realmente tanto y probablemente encontró una manera mejor que la tuya de resolver eso mismo.

Entonces quizás como tu mismo skill puede estar limitando el real potencial que tiene el nuevo modelo de Cloud Code o el nuevo modelo de Antropic, mejor dicho, porque estamos intentando de hacer este micromanaging cuando realmente hay mejores maneras de hacer las cosas. Y no es que hacer skills sea malo, no es que a veces hacemos skills cuando no realmente tenemos que hacerlo. Si tenemos que repetir muchas veces un mismo proceso, es genial hacer un skill, pero cuando no es mejor no tenerlo.

Y tercero, bueno, lo escuchaste en sus propias palabras, borraron el 80% eh de su system prompt y en la última línea de lo que vimos te invita a borrar el resto. Ahora, ¿cómo lo hacen? Aquí viene la palabra que te vas a querer robar y es la hablación. system prompt and then you bring it back line by line to figure out what is the impact of each individual line. It's sort of like a evalu and you can kind of like evaluate it and evaluation essentiates evalu but you delete things to figure out the impact and yeah like we do the same thing for tools like we unship tools all the time we you know delete code in the harness all the time if you look at the code that's in the cloud code harness today almost all of it is about analysis and there's a bunch of y esto recalca también un punto muy importante, nos preocupamos tanto de sobreconstruir, que a veces colapsamos las cosas cuando lo que tenemos que estar haciendo es eliminar, ya tenemos que simplificar y aquí es donde entra lo que vimos, que era la hablación, ya término de investigación que aplica el mismo equipo de cloud code en su propio producto, que borra todo y lo empieza a devolver línea por línea, o sea, midiendo qué aporta realmente cada uno, ¿no? ¿Qué crees que aporta? ¿Qué realmente aporta? es como un experimento que van haciendo.

Y no es que lo hagan solamente con el prompt, sino que lo hacen con las herramientas y con el código. O sea, que durante todo este tiempo, mientras nosotros pasábamos agregando durante 6 meses capas al modelo, ellos pasaban esos 6 meses sacándole capas a su propio arnés. Entonces, están como simplificando todo porque los modelos hoy día ya se pueden encargar un poco de eso y ese es el movimiento que nosotros tenemos que empezar a replicar.

Ahora, eso es lo que hacen ellos, ya que construyeron directamente este producto. Ahora, la siguiente pregunta es, ¿todos deberían hacer esto? Mira lo que dicen acá. 100%. Yeah. And and for people that aren't building products, but you're using quad code, every six months, delete your quotum d, delete your skills, delete your hooks, see what the model does and it might surprise you. And actually for Opus 5, this is something we really do recommend is just try deleting all of these things because the model might just not need all those instructions that you needed for models.

Entonces, mira, no dijo evalúa si te conviene, dijo cada 6 meses borra tucloud.md. borra tus skills, borra tus hooks y de hecho subió la apuesta para Opus, que ya que esto es algo que sí recomiendan directamente. Este, estamos hablando de el creador de la herramienta pidiéndote en público que borres la configuración que pusiste de su propia herramienta. Y el cierre de todo esto es lo que me ordenó todo esto un poco en la cabeza, ya porque puede que el modelo no necesite necesariamente esas instrucciones que le solíamos dar a modelos anteriores porque ya las puede descifrar o las puede sacar incluso mejor de lo que tú decidiste armarlo en ese momento.

Y no es que tus skills estén mal escritas, sino que están escritas para un modelo que ya no existe necesariamente o que no estamos usando, lo que nos lleva a uno de los términos más importantes que me llevé de toda entrevista, que es el hobeling. Esta parte me encantó porque introdujo un término que no conocía que es el hobeling. El hobeling es traballo en la pista de carreras para que el caballo no corra. Y es cuando básicamente le empezamos a decir a la IA como debería actuar y nos metemos en su proceso de razonamiento.

Mira cómo lo define el mismo creador. Not that we have not yet realized. Entonces, fíjate, te dice como yo lo voy a resolver de una manera y cuando la gente empieza a meterse en ese proceso de razonamiento, empieza a desviarlo cuando quizás habían mejores maneras de poder llegar a ese output en específico. Y fíjate en el cambio porque es enorme. Venimos de una época donde el trabajo era dirigir antes el modelo. Ya le decíamos exactamente qué hacer y cómo.

Y eso era como ser bueno usando la IA, por así decirlo. Antes abríamos CharGPT, abríamos cloud y le decíamos algo y después nosotros ejecutábamos y nos apoyábamos. Después pasamos a este proceso agéntico donde le empezábamos a pedir un poco como, "Oye, hazme esto." Y te lo empezaba a hacer, pero teníamos que seguir dándole las instrucciones de lo que tenía que hacer. Hoy día el que construyó la herramienta eh de cloud Code te dice que el modelo ya está haciendo algo y que tú estás metiéndote en el camino.

O sea, que basta con escribir o decirle un poco como cuál es el objetivo de lo que quieres lograr y va a hacerlo. Y cuando nos metemos a veces en ese proceso estamos haciendo hobeling, es decir, estamos trabando al caballo para que corra. ¿Es necesariamente algo malo? No, no. Siempre tenemos que hacer una especie de steering o de dirigir el prompt hacia donde queremos ir, pero muchas veces este hobeling ya está hecho y predefinido en nuestros skills y no nos damos cuenta.

O sea, en los skills determinamos como haz las cosas de una manera en específico, cuando quizás no es la mejor manera de hacer esto. Ya quizás hay mejores maneras, más eficientes, porque armamos ese skill cuando estábamos en Opus 4.5. Hoy día ya estamos en el cinco punto, entonces quizás existen mejores maneras o han salido nuevas cosas y seguimos cescados o digamos como atados a esta manera antigua de hacer las cosas.

Por ejemplo, en mi caso me di cuenta aquí que tengo las 26 skills y las 15 skills de plugins, que son estas 41 y existen acá podemos ver 2095 palabras que el modelo lee antes de que hagamos nada. O sea, son cinco páginas que el modelo va a leer en cada sesión antes de que tú puedas escribir la primera letra. En la mayoría son cosas que no uso o que no he usado hace meses. Y eso no es memoria, es ruido que se crea en las sesiones que no te está aportando realmente nada, a menos de que esa skill sea algo fundamental que tienes que repetir constantemente y necesitas estandarizar un proceso, pero para el 99% de los casos eso no es necesario.

Entonces, ¿debería borrar todo y me quedo pelado, no? Y aquí es donde me separo un poco de el titular, porque hoy día borrar todo es mentira. O sea, no es que tengamos que borrar todos los skills. Yo borré lo que no pasaba tres preguntas, o sea, son mis filtro y las uso hasta hoy. Si quieres puedes sacarle un pantallazo a esta parte. Le puse esto como las reglas de las 3 R o el filtro de las 3R. Es repetible, igual, es requisito y es repartible.

El repetible acá es haces esa tarea exactamente igual, más de tres veces al mes, ya no parecido, igual si la respuesta no, no necesitas una skill, ¿ya? Necesitas un buen promp para ese caso. La segunda R es el requisito. Esto que tenemos acá es el dato que no se puede adivinar. Tienes adentro un dato que el modelo no puede adivinar, o sea, tu tono de voz, quizás tu marca, una ruta de las carpetas, eh algo muy clave en ese caso.

Si es que es requisito, ¿okay? Te puede servir a un skill. Y la tercera R, que también es super interesante, es repartible. Se lo vas a pasar a alguien más este skill le vas a pasar este skill a tu equipo, a algún cliente. Entonces ahí deja de ser tu muleta, por así decirlo, y pasa a ser lo que de verdad es. Es un proceso empaquetado para que otro lo pueda correr igual que tú. Recordemos, un skill no es nada más que la estandarización de un proceso, es crear una especie de TRZ que pueda ser replicada en otros lados.

Es genial si quieres compartir SOC. Un SOP es un standard operating procedure. Es como la estandarización de un proceso, no es nada más que eso. Y a mis 26 skills que están acá, eh, hay 17 que instalé de afuera. Son nueve realmente las que construí yo. ¿Adivina cuáles sobrevivieron? Obviamente las nueve que eran mías. Entonces casi todas las de afuera terminaron muriendo y no murieron por estar mal hechas, de hecho estaban super bien hechas, sino que murieron porque estaban hechas para el proceso de otra persona.

Entonces yo fui el primero que anduvo cazando esos skills en internet cuando salió. Eh, literalmente bajaba todo. No vale la pena. O sea, los skills que realmente valen salen de tu propio trabajo y esos no los bajas, te los construyes tú después de hacer la tarea a mano varias veces. Ahora, si quieres tomar skills y readaptarlos para tu caso, está bien, puedes hacerlo, pero no realmente va a valer la pena para eh las personas en general.

Ahora, si quieres realmente tomar skills y adaptarlos a tu caso, está bien, pero para la mayoría de los casos no es necesario directamente. ¿Cómo hacer la tarea? Y eso hoy muchas veces lo hace mejor solo. Entonces, tenemos, ya hemos visto en videos previos que se carga siempre algo de contexto en la sesión. Ese contexto puede ser el cloud.md, md se carga siempre al inicio de cada sesión y eso vendría siendo como una especie de contexto, por así decirlo.

Y los skills son las instrucciones de cómo hacen la tarea y eso hoy día muchas veces lo hace mejor, solo no son necesarios, menos es más. Benja, y si le saco las instrucciones que tengo que poner en su lugar en la entrevista. Eso es exactamente lo que le preguntaron y la respuesta es lo más accionable de toda esta charla y también una de las cosas más importantes que me llevo. Por favor, préstale atención a esto. I thinkon mist they just give it like way over specific instructions.

They're like, I want you to do this, but I want you to do it in this way, this way, this way. You must do like one, then two, then three, then four. And for modern models, that's actually really not the way to do it. You want to go a little bit higher level. You want to describe the task, you want to describe the guard rails. You want to describe like the exit criteria and then just go the model cook and come back in a little bit.

And I think itl it will surprise you. And again, like this is just not something that would work today. Okay, escuchaste lo que definió como el error más común. instrucciones demasiado específicas. Ya, haz esto, después esto, después esto, paso uno, paso dos, paso tres, paso cuatro. Y eso es literalmente un skill, es un skill disfrazado de un prompt porque le estás dando todas las instrucciones de cómo tienes que hacer la tarea.

Entonces, eso también me impactó mucho. O sea, el mismo creador de Cloud Code acaba de describir el error más común de los propios usuarios y es exactamente lo que tú y yo estuvimos guardando en carpeta durante 6 meses, solamente que no sabíamos que se estaban haciendo los llamados. Y la corrección son tres palabras y puedes escribirlas o sacarle un pantallazo, lo que quieras. Y ojo con la distinción porque aquí también está la mitad del valor de este video.

Un guard drill no es un paso. Un paso es abre el archivo y edita la línea 12. No sé, es no toques la base de datos. Eso es como el límite, no toques la base de datos. Uno le dice por dónde ir, el otro le dice como por dónde no salirse, dónde están como tus límites y las áreas que no quieres que queden afectadas. Y el paso al final le le quita esta capacidad de tomar decisiones y de razonar. El guardril es que se las deja todas al final y va a buscar el mejor camino para resolver las cosas, pero le dice como, "Okay, estas son las únicas cosas que no puedes tocar porque es información sensible o porque simplemente no es por ahí." No sé, no sé. es como eh no toques esto, pero tienes todo este otro sin fin de opciones que va a decidir y razonar por su cuenta.

Y el criterio de término también es la pieza que casi nadie escribe y que he visto que se repite mucho durante este video, es decir, el definir cuándo esto está listo, cómo sabe Cloud que terminó. Entonces, le dejas la tarea, el guard rail y el criterio de término. Esas son las tres cosas que son s super importantes, como en este nuevo prompting, ya, pero no es como prompting engineer. De hecho, mira este fragmento que dice acá de hacia dónde cree que va el futuro de todo esto.

I think these will kind of like come and go. I I think the skill nowadays is less about prompt engineering and more about figuring out how do you give quad a hard task that seems a little bit too hard and then how do you make it possible for its work along the way and the verification. O sea, hace un año era el prompt engineering, después el context engineering y hoy dice que ninguna de las dos es realmente la habilidad.

Son dos cosas, darle una tarea que se vea demasiado difícil y darle una forma de verificarse solo. Y la verificación, dice, es lo único más importante que la gente no está haciendo bien hoy día. O sea, mientras medio internet está vendiendo cursos de prompt engineering o context engineering, como la habilidad del futuro y todo, que en parte está bien si es que los aprendes, no te va a dañar. El que construyó la herramienta dice que ese no es realmente el trabajo, sino es cómo diseñamos este trabajo que se revisa solo. ¿Cuál es el objetivo? ¿Cuál es la tarea? ¿Cuáles son los cardils? ¿Cuál es el criterio de término?

Y aquí te voy a mostrar algo que también me encantó porque vimos como el creador de Cloud Code hizo un prompt en vivo y lo voy a descomponer contigo y creo que es la mejor clase gratis de cómo se le habla a un modelo hoy. Contexto. Quería ver cómo se vería la aplicación de escritorio de cloud si es que fuera nativa de Mac y este fue el prompt completo que hizo. Swiftion. Fíjate, esto fueron cuatro líneas y tiene exactamente las tres partes que acabamos de ver.

Primero, la tarea. Reescribe la aplicación de Electron en Swift. Esta es como la tarea que se le dio. Es una línea sin adjetivos, sin relleno, sin eh por favor sé cuidadoso, es el objetivo pelado. Y fíjate en el tamaño, o sea, le está pidiendo reescribir una aplicación entera en otro lenguaje de programación, que es una tarea que se ve demasiado difícil y se lo pidió a propósito. Después fíjate cómo hace el steering o cómo va navegando un poco o le da como una orientación y le pone los guard w reels y le dice, "Ábrela en la máquina virtual, sácale un pantallazo y luego compárala píxel por píxel en la versión en Swift." Y eso está buenísimo y eso es lo más importante de este video.

O sea, eso no es decirle cómo programar, ya no hay una sola instrucción sobre arquitectura ni qué librería usar ni nada, pero lo que sí le da es una manera o una forma de mirarse, de saber solo si es que va bien o si va mal. Entonces, esa es la diferencia entre un paso y un carbakil. Tú le das esta especie de carril y el modelo va eligiendo como la ruta y donde no puede ir. Y tercero es el criterio de término, que esto también lo hemos visto bastante cuando dice no pares hasta que esté listo puede ser un poco redundante, es un prompt igual que hizo en vivo, pero fíjate cómo puso el criterio de término, o sea, son cinco palabras, ¿ya?

Y es la pieza que casi nadie escribe. Eh, sin eso, de hecho, el modelo hace un intento razonable y te entrega algo que parece terminado y se va, con eso sigue. Pero cuando le pone como este este objetivo verificable, por así decirlo, dimensiona cuánto tiempo tiene que seguir. O sea, en este caso le digo una tarea que era s superdfícil. Y dato curioso, cuando se subió a hacer esta charla, ese mismo prompt que le dio lleva 2 semanas corriendo, o sea, dos semanas corriendo con un montón de agentes y no ha parado porque no está listo.

Y fueron estas mismas cuatro líneas, o sea, dos semanas de trabajo en cuatro líneas y mira lo que no hay ahí. No hay un paso uno, paso dos, paso tres, no hay un skill, ya no hay una sola instrucción sobre el cómo hacerlo. Y lo que sí hay es una tarea difícil, un carril y un criterio de término. Eso en el fondo es lo que está reemplazando a los otros skills. Y bueno, yo en lo personal no borré todos los skills. De hecho, hay un skill que no borré ni lo pensé y ese es el que tiene mi tono de voz, o sea, el cómo escribo yo con cientos de ejemplos reales míos y es el que menos parece un skill de todos porque no tiene eh ningún paso, es solamente contexto sobre mí, cómo hablo, mi manera de comunicarme, que creo que es s super importante de tener en cuenta, sobre todo si es que estás haciendo publicaciones en redes sociales o si quieres como comunicar ciertas cosas, a mí me ayuda bastante.

Hay otra cosa también que no tenía planeado mostrarte en este video, pero que lo consideré muy muy interesante. Y es que Diana llega acá y le pregunta a Boris cómo las personas pueden usar Cloud Code como el top 1% de los usuarios. Y mira lo que responde acá. Y lo encontré genial. No escuches a los influencers, no nos escuches a nosotros. La mejor manera es simplemente anda y prueba. O sea, es más simple de lo que parece es la idea y lo que trata de ejemplificarnos.

No hay una receta mágica para usar Cloud Code al 100%. Siempre hay cosas que se pueden usar. Me duele un poco el orgullo también decir esto en el video como o escuchar al creador decir como no uses loops, no uses goals, como que al final mantén las cosas simples y claro, claro, o sea, al final creo que es lo importante, está diseñada esta herramienta para que funcione para la mayoría de las personas y probablemente su nivel de razonamiento de cómo resolver tareas específicas es mucho más alto que el que tenemos nosotros.

Y yo he hecho videos anteriores de este tipo de cosas sofisticadas, o sea, de los loops, de los goals, de la orquestación y las uso y sirven, obviamente. Ah, el mismo dice que ayudan. Pero ahí es donde me cayó un poco la teja de que estaba sobrecomplicando las cosas, estaba armando estructuras arriba de estructuras cuando eh muchas veces la idea principal era dale la tarea, dale un sistema de cómo verificarse y ándate, ándate, déjalo, déjalo correr.

Ya creo que es como lo importante con lo que me quedo de todo esto y un cambio en este paradigma, es la lección que más me ha servido después de ver esta entrevista, es mantener las cosas simples. O sea, hace unas semanas me junté con los cofundadores de School, fuimos a buscar el premio de los School Games y una de las grandes cosas de lo que conversamos, de lo que me llevo, es no sobrecompliques las cosas. El mismo fundador de School, o sea, Movens en este caso, decía como siento que School todavía es muy complicado, necesitamos ir eliminando más cosas, no agregando, eliminando.

Y nosotros tenemos que hacer lo mismo. Entonces, sí, nosotros nos guiamos mucho por la ley de Gal. Todo sistema complejo es la evolución de un sistema simple que funciona, pero a veces no tenemos que evolucionarlo a un sistema complejo. A veces es mejor cuando las cosas se quedan en un sistema simple y funcionan. Una cosa adicional que dice Boris es que cuando el modelo se trabe, dice que lo puedes arreglar de una de tres maneras, ¿ya? con un mejor prompting, con un skill como en específico de alguna situación en la que tienes o con un MSP si es que le falta contexto y necesita acceder a otro tipo de contexto que no está limitado.

Y no sé si escuchaste ahí, sí dije una skill. Entonces, no quiero que como que enemistes o que tengas una percepción mala de las skills, ya los skills no son malos, ya. Un skill es la estandarización de un proceso que tienes que repetir o que has vivido con un manual escrito, pero muchas veces no tenemos que seguir eso para resolver casos o situaciones en específico. Y si es que las tenemos ahí, Cloud Code se puede sesgar por ese skill porque dice como, "Ah, sí, no, el usuario cree o quiere que lo hagamos de esta manera y a veces hay mejores maneras porque depende mucho de cada caso." Están trabajando mucho en mantener las cosas simples.

Y aquí viene también una de las partes favoritas mías y que refuerza nuestra tesis de que no necesitas ser técnico para saber usar este tipo de herramientas. Así que por favor presta atención a lo que tiene Boris que decirnos ahora. you had to do it. So when I look at engineers that have been you know coding for a long for a long time you know like for for years or for decades this is a really common failure mode is trying to overfy and trying to be overly specific you know get the model to do the task exactly the way that you would have done it and just not works.

Brutal, brutal. O sea, que los mismos ingenieros tienden a sobrecomplicar las cosas y a veces esto le hace una especie de hobeling a Cloud Code y quizás no es la mejor solución que tienen. ¿Por qué dice que hacen esto? Bueno, lógicamente porque aprendieron en una época donde había que especificar todo. Si no le decías a la máquina exactamente qué hacer, no hacía nada. Y ese reflejo al final se les quedó grabado en su manera de pensar. irónicamente es lo que los está frenando.

Y no, no estoy diciendo que programar sea malo. Lo que quiero que escuches con atención, si tú no eres programador, que somos hartos en este canal y las personas que ven estos videos, significa que tú estás en una ventaja. Estás en una ventaja. No tienes 20 años de reflejo de estar haciendo este micro managing y moviendo todas las piezas. No, no es como estrictamente necesario, ya simplemente tienes que saber qué es lo que quieres, le pides lo que quieres en tu idioma y dejas a la máquina trabajar, o sea, dejas a Cloud Code corriendo, que es exactamente lo que el creador está funcionando y lo que está mencionando.

Y no digo que no aprendas, ¿no? O sea, te digo que la barrera técnica está en el punto más bajo que ha estado de la historia y solamente va a seguir bajando el reflejo que a otros les tomó 20 años construir. hoy día les toca empezar a desarmarlo y eso requiere un gran trabajo. Tú te puedes saltar ese proceso, o sea, tú estás en ventaja en esa situación porque nunca lo tuviste. Entonces, mi punto con todo esto es no sobreespecifiques, no hagas micromanaging y no sobreingenierices algo que se puede resolver con una sola frase.

Después, si quieres seguir viendo esta entrevista, hay muchas cosas interesantes. A medida que avanzábamos le preguntan como cómo hace para correr miles de agentes en paralelo y te dice que hay dos caminos que son los dynamic workflows, que se lo pides como para hacer una tarea larga gigante que se parte como en pedacitos y se reparte entre muchos agentes y es s simple activar, simplemente le dices como activa los dynamic workflows eso es todo.

Y el segundo camino que te menciona también es que usemos los loops y las routins. O sea, esta es la definición más limpia que he escuchado de los loops y los routins. Mira, aquí la pueden encontrar. Muy interesante la definición. Un loop corre en tu computador, un routín corre en la nube, es decir, en la infraestructura antrópica. Entonces, cierras tu computador y se pueden armar como automatizaciones sencillas, como que la principal diferencia es que el workflow o el dynamic workflow es una tarea grande que se reparte en muchos pedacitos y tienes muchos computadores y subagentes que están tratando de resolver esa tarea en paralelo, mientras que el loop y la routine son una tarea que se repite constantemente una y otra vez, cada hora, cada día, cada cierta cantidad de tiempo, sea en la infraestructura Antropic o en tu mismo computador.

Después puedes ver cómo lo usan ellos para mantener su propio código. De hecho, super bueno. Dice como que todos los días hay una parte que dice como borra código y trata de buscar como código que esté muerto y lo trata de eliminar de la base de datos. Muy buena. Es literalmente un routín no más que dice como una sola oración y dice como borra código muerto que está buenísimo. Y en fin, superreomendado que veas esta entrevista.

A mí me iluminó bastante. Estoy seguro que a ti también te va a servir más porque de seguro va a explicar las cosas mejor de lo que yo lo hice en este video. Tres cosas que te puedes llevar sí o sí accionables para hoy de 15 minutos de trabajo es primero abre tu carpeta de skills. Ya cuéntalas, pásale las eh tres RS a cada una o este filtro, ve que realmente usas y la que no pase ninguno de estos filtros, cámbiala de carpeta y no se las des como contexto, ya no es necesario.

Segundo es que el próximo prompt o la próxima vez que te estés comunicando con Cloud Code y estés prompteando algo, en vez de darle los pasos, dale las tres partes. ¿Cuál es la tarea? ¿Cuál es el carril? Que tiene que seguir más o menos ya con las limitantes y los card rails. Y el criterio de término. Y después déjalo cocinar. ¿Quién sabe? Puedes dejar corriendo un prom por dos semanas como lo hizo Boris. Y tercero es deja de sobrecomplicarte, deja de sobresespecificar, deja el micromanagement.

Las cosas son más simples. Boris nos hace ver que esto es más simple de lo que crees. Así que si te sale el reflejo de escribir como el paso uno, paso dos, haz esto, esto, esto, para, para. Quizás no es estrictamente necesario, quizás eh basta con escribir qué quieres y cómo se verifica y ándate, ándate. Ya son muchas las ocasiones en las que tendemos como a sobrecomplicarnos y realmente no es algo que tenemos que hacer a menos de que sí o sí necesitas que se haga algo.

Así que si estás recién partiendo con Cloud Code y esto te sonó todo a chino, bueno, te recomiendo que veas el curso completo de Cloud Code gratis aquí en YouTube. Son más de 6 horas, está s super bueno. Te explico y te acompaño literalmente todo, desde instalarlo hasta más de 10 proyectos prácticos que armamos en vivo. Está muy muy bueno. Lo puedes encontrar aquí en el link de la descripción. Y si estás construyendo algo y quieres estar donde estamos discutiendo todo lo que pasa en el día a día, te invito a Imperio Agéntico.

Somos más de 3000. [música] Está superinesante. Tenemos muchas sesiones donde vamos viendo al final cada cosa. Está realmente bueno. Somos 3,500 miembros en el momento de grabar este video. Tenemos sesiones de bienvenida eh que tenemos los días lunes y los días jueves. Tenemos sesiones de soporte, tenemos sesiones de vibe coding, talleres prácticos, tenemos muchos cursos adentro y bueno, muchos logros que se van publicando todos los días.

[música] Ya, gente que logra sus primeras automatizaciones como gente que vende IA y servicios como IA. Recomiendo que te des una vuelta también. También te voy a dejar el link a la entrevista de Boris Cherney, es decir, este que está acá, por si quieres ver esto y escucharlo desde sus propias palabras. Todo esto quizás te puede hacer un poco más de sentido. Y cuéntame abajo qué te pareció este video, o sea, si realmente crees que vale la pena eliminar skills, si también te tiendes a sobrecomplicar, eh si crees que simplificar es importante, cuántas skills tenías, cuántas te quedaron, de hace cuánto no hacías una limpieza.

En fin, eh coméntame aquí abajo, los voy a leer todos. Así que dicho eso, espero que este video te haya servido. Suscríbete si no estás suscrito y eres parte de ese 80%. Ya nos vemos.