Por Agentes, Para Agentes: Construyendo Herramientas de IA Que Se Mantienen Solas

Hola a todos. Mi nombre es Rudhankariyam y hoy voy a hablar sobre cómo utilicé la codificación impulsada por IA para construir herramientas de IA que solían construirse y mantenerse a sí mismas. Así que, construí una herramienta de desarrollo para agentes donde observé al agente fallar, mejorarse a sí mismo, añadí analíticas para que pudiera dejar de adivinar por qué está fallando y tener estos bucles en funcionamiento donde los agentes reportarán los problemas, los corregirán, los auditarán, los clasificarán, crearán los lanzamientos después, y también verificarán los lanzamientos de manera autónoma. Porque siento que en 2026, los desarrolladores no son solo los únicos que usan los CLIs o herramientas de IA en el terminal, sino que los agentes también los están usando y mejorándolos al mantenerlos también.

Así que, una breve introducción sobre mí. He estado desarrollando plataformas de Apple durante los últimos siete años y también trabajé con Apple Cupertino con el equipo de Team Voice Control, y anteriormente trabajé con Alex Sidebar, que era cursor para Xcode y luego fue adquirido por OpenAI. Y actualmente trabajo en Rourke, donde gestiono la publicación en App Store así como la publicación en Google Play Store. Así que, este enero, ha pasado mucho tiempo, cuando hablo de meses de IA, creé un proyecto de código abierto llamado App Store Connect CLI. La idea era que este proyecto es algo que usaré como ejemplo a lo largo de la charla y como un caso de estudio sobre cómo abordé la codificación impulsada por IA.

Así que, quería una forma de automatizar la publicación en App Store porque si has trabajado con el sitio web de App Store Connect, entenderás lo difícil que es, y quería tener un código en la nube o codex o cualquier agente con el que estés trabajando para revisar todas las compilaciones, los metadatos, las capturas de pantalla, todo lo que App Store admite debería estar en un CLI para que los agentes puedan hacer el trabajo pesado por mí. Y me di cuenta de que era posible porque App Store Connect tiene su propia API, aunque hay muchas de ellas, y esta es la idea de darte este contexto es cómo abordo la construcción de las herramientas en tres etapas donde es para los agentes, se construye con los agentes usando los agentes de codificación y luego es utilizado por los agentes en la forma de CLI y ahora mantenido por los agentes ahora que tenemos automatizaciones con bucles y programación.

Así que, escribí este CLI en Go porque quería una inspiración de código abierto que es el GitHub CLI. GitHub CLI es algo que todos hemos estado usando y parece que los modelos están entrenados para usar este CLI muy bien y porque el código era de código abierto, si para cualquier arquitectura, podría simplemente apuntar mi agente a ese repositorio y estaba escrito antes de la IA, así que sé que está muy bien hecho también y así es como quería que el CLI fuera que dejas el CLI en cualquier terminal de codificación y el agente podrá descifrar cómo funciona. Y para eso, necesito entender cómo el agente también pensaría al trabajar con el CLI y esto resultó ser muy bueno para probar el enfoque impulsado por IA porque tiene 1300 endpoints y no hay manera de que vaya a escribir manualmente los comandos yo mismo o crearlos yo mismo. Así que, desde el primer día, fue un proyecto nativo de IA que fue construido por los agentes diseñado para ser usado por ellos y luego mantenido por ellos también porque siento que los agentes o los modelos de lenguaje grande tienen una comprensión mucho mejor de trabajar entre ellos. También cambió cómo pensaría sobre las herramientas de desarrollo porque antes cuando diseñaba un comando, sería para humanos que lo escribirían, pero ahora es como si primero hiciera una lluvia de ideas con el agente de codificación y luego le preguntara, ¿tendría sentido para ti? ¿Sabrías qué comando llamar? Y si la descripción de ayuda que hemos dado es suficiente o no, ¿puedes interpretar la salida muy bien y el error que da tiene sentido para que entiendas qué corregir a continuación? Y me di cuenta de que el agente puede decirme dónde el propio agente se está confundiendo y yo descifrándolo para ellos. Y ahí es donde entran las cuatro partes de los agentes.

Así que, la única manera en que podría cubrir esta gran área de superficie fue confiando en agentes en la nube y dividiendo el trabajo. No estoy afiliado a ningún otro producto, pero para este caso particular, uso Cursus Cloud Agent porque me ofreció configurar un entorno donde puedo tener mi clave API de App Store Connect, dársela para el caso de uso particular y también crear una aplicación desechable para el propósito exacto de darle un bucle verificable donde en lugar de solo el agente escupiendo código que se ve bien, tengo que probarlo manualmente. Así que en el agente o el propio entorno, intentará usar mi clave API de App Store Connect, obtener los datos en vivo basados en los comandos que tiene que trabajar, crear un verificable, como verificar la salida y luego también mencionar todo eso en el PR que crea más tarde. Así que, un agente obtendría cada una de las áreas, uno en compilación, uno en test flight, uno en suscripciones, capturas de pantalla de metadatos, y cada uno de ellos tendrá una idea actual de cómo se construyen las formas para los comandos y no lo memoriza. Comienza desde cero. Así que, tiene una idea de toda la base de código y todo el CLI en sí mismo y luego usa el esquema de API abierta para implementar los endpoints, probarlos, construir el binario y también usarlo y luego un agente de terceros u otro agente lo usaría. Y si los mocks no eran suficientes, entonces probaría en vivo usando mi API en la aplicación desechable. Y luego antes de ir a dormir, ejecutaría seis, siete agentes y luego en la mañana revisaría los PRs. Y porque otra cosa que quiero mencionar es que todos los comandos para los agentes en la nube no fueron escritos por mí. Tendría a cursor mismo, escribir los problemas, dividir el trabajo y luego escribir todo el problema para mí porque era mucho mejor de lo que podría haber escrito yo mismo, toda la descripción del problema. Y este CLI se hizo popular en la comunidad de iOS y decenas de miles de desarrolladores lo usan y hay cientos de, más de cientos de colaboradores también que están abriendo problemas diariamente. Y comencé a recibir oportunidades de trabajo y ofertas de adquisición. Y más tarde lo adquirieron, donde trabajo ahora. Y tenía sentido para ellos porque estaban usando el CLI en su pipeline de publicación de App Store. Pero eso cambió el problema porque fui, ahora estoy en un lugar, estaba en un lugar donde estaba, cuando de crear algo a mantenerlo y ahora tengo los usuarios, los colaboradores, todos los casos extremos que no podría haber imaginado ahí fuera. Y no quiero tenerlo como mi misión principal más porque tengo un trabajo a tiempo completo. Así que mantener este CLI es una misión secundaria ahora. Y ahí es donde entra la parte de mantenimiento. Y así, y solo para hacer un poco de alarde humilde, en los últimos 60 días desde la adquisición, he lanzado 26 versiones. Se siente como un impostor diciendo que lancé, Codex ha lanzado y he fusionado, Codex ha fusionado 183 pull requests. Y este es un resultado que esperaría aproximadamente de un pequeño equipo. Pero mi tiempo directo que he invertido en mantener el CLI, especialmente todos los casos y todo ha sido menos de una hora a la semana. Y me di cuenta de que mi rol seguía cambiando trabajando en esto. Pasé de escribir los prompts, luego convertirme en el revisor del código del agente, luego me convertí en un gerente de los agentes y las reglas que creé para los agentes.

Y los cambios de reglas donde hablo más sobre la parte de mantenimiento ahora. Así que por un tiempo, me di cuenta de que los agentes están haciendo la mayor parte del trabajo. Yo era una especie de programador. Así que diría, mira este PR, mira este problema, pruébalo, ¿crees que tiene sentido, reproducirlo, por favor arreglar, y decidir si necesitamos un lanzamiento o no. Y luego ejecutar el lanzamiento. Y me di cuenta de que esto no es un sistema autónomo en absoluto. Es solo que estoy haciendo manualmente mucho del trabajo pesado. Y me sentí como un trabajo cron. Y lo que quería era un bucle que pueda los agentes sean lo suficientemente inteligentes como para ejecutarse por sí mismos cuando sea necesario. Y luego actualizar los problemas de PRs. Si es un P0, arreglarlo en el lugar y luego crear un nuevo lanzamiento. De lo contrario, esperar todo un día y hacer diariamente o cada pocos días un nuevo lanzamiento si tiene sentido. Así que quería tener un sistema más inteligente que el que tenía antes comparado con lo que tenía antes. Así que ahora estamos en un punto donde las automatizaciones son mucho mejores en las respectivas aplicaciones proporcionadas por Frontier Labs. Y me di cuenta de que no quiero crear todo mi sistema alrededor de una solución personalizada. Solo usar lo que sea que esté ahí y solo tener una programación mínima alrededor de ello. Así que lo que tendría es que en lugar de, porque el CLI es mucho más manejable ahora, tal vez menos de 10 PRs o problemas al día. Así que preferiría gestionarlos en bloque. Así que en mi Mac mini al lado, ejecutaría codex automations así como cursor cloud automations que tendrían prompts específicos y se basarían en habilidades específicas que he creado a lo largo de los meses trabajando en esto y entendiendo cuál sería el mejor enfoque para manejar la automatización. Así que cada ejecución obtendría un árbol de trabajo aislado fresco, tendría un archivo de memoria compartida donde se habla sobre la ejecución anterior, qué salió mal, y luego tengo un registro de cambios al final para poder entender qué pasó al final del día. Y una de las cosas para las que tengo automatizaciones es llamada wall of apps donde las personas que han usado el CLI mostrarían con orgullo las aplicaciones en las que han trabajado.

Y hay un comando para ello, pero lo que quería verificar era que la aplicación existe, el icono que enviaron es el más reciente o no, y no hay código malicioso en ningún sentido. Así que hay una pequeña entrada JSON en el CLI y una automatización que se ejecuta cada medio día verificará y luego lo fusionará, lo aprobará, pondrá un emoji que sea relevante para la aplicación en sí, y luego simplemente lo fusionará y aprobará también. Así que me sentí cómodo dando plena autonomía aquí porque el radio de explosión es pequeño, la política o las reglas que tengo son muy claras, y la verificación es determinista. O la aplicación existe o no. Otro fue sobre la higiene de problemas. La idea es que recoge algunos problemas incompletos que están ahí, intenta reproducirlos contra el CLI actual porque mi Mac Mini ya tiene mis credenciales, así que ya estoy conectado, y luego los clasificará por prioridad y dificultad, los etiquetará. Si es un P0, comienza a trabajar por sí mismo. Cuando digo que comienza a trabajar por sí mismo, también crearía un lanzamiento para que eso se envíe lo antes posible al usuario para que puedan desbloquearse. Y me di cuenta de que estoy muy agradecido con mis colaboradores porque siento que casi todos ellos usan agentes para crear los problemas o los PRs.

Así que separé tener una guía de contribución específica para los agentes, de modo que cuando mis agentes hablen con los problemas que su agente creó, sea mucho más agradable para ellos que ambos agentes se comuniquen bien, y entiendo que tendrá el mismo contenido que querrá y luego trabajará en ello. Así que creé esta cosa muy divertida llamada AAC snitch donde los agentes tienen un espacio libre para desahogarse sobre el trabajo que no funcionó. Así que si el agente está usando el CLI y se confunde o el comando siente que no debería ser de esa manera, el agente delatará y creará un problema perfecto, hermoso donde dice lo que sucedió, lo que se esperaba y lo que podría haberse hecho mejor. Y estos problemas luego serán recogidos por el programador para trabajar en ellos.

Así que la idea de este delator era obtener una retroalimentación mucho mejor de los usuarios directamente que lo están usando sin depender de ninguna analítica en ese momento. Y realmente funcionó muy bien para mí porque solo hablar con la gente de que no está funcionando no ayudó, pero ahora tengo toda la transcripción de cómo el agente trabajó y creó un problema a partir de ello que es mucho más accionable para trabajar. Y otra cosa que me di cuenta es crear otro bucle de retroalimentación que es con analíticas. La razón por la que agregué analíticas no fue porque quería ser invasivo. No recojo nada, argumentos en bruto o el ID de cuenta, ID de aplicación. La idea era solo obtener la señal a nivel de comando porque muchos de los desarrolladores con los que hablé en la vida real y en las redes sociales mencionaron que el cloud code se confundía al trabajar con el CLI, pero Codex funciona muy bien.

Y no tenía idea de cómo eso es posible. Sé que he usado modelos en la nube para trabajar en esto, pero para mí, realmente necesitaba esos datos en bruto para entender qué sucedió. Y al final, resulta ser que el cloud code al trabajar con el modelo estaba inventando los comandos. Estaba tomando algunas suposiciones y luego no estaba usando la ayuda tanto como Codex estaba usando. Codex estaba usando tres veces la opción de ayuda en cada uno de los comandos que usaría más tokens, pero al final, Codex era mucho mejor para trabajar debido a una tasa de error mucho menor. Así que lo que me di cuenta es que en este caso, si en lugar de tener los modelos o los comandos que no existen, nos encontramos a mitad de camino.

Así que añadiría alias para los comandos que cloud code alucinó y obtuve analíticas para ello y luego creé esas formas de comando hechas. Y en los otros casos, intenté mejorar la descripción del comando y el ejemplo para que la próxima vez que el agente lo use, sea mucho mejor. Y basado en esto, también creé una automatización diaria. Así que esta es una muy buena porque crearía un PR basado en las analíticas del CLI cada día, ver qué salió mal en comparación con cómo estaba antes, y luego reproducir cualquier problema que crea el agente.

En este caso, utilicé específicamente modelos en la nube porque sé que ese es un punto de datos, un punto de datos muy fuerte donde no está funcionando bien. Así que sé que si el otro está funcionando bien, preferiría centrarme en el que no lo está. Así que para estos casos exactos, usaría modelos en la nube y con esto, cuando se crea este PR, el otro programador que se ejecuta en el PR lo revisaría e intentaría reproducirlo de nuevo. Y cuando esté satisfecho, lo fusionará y luego creará una nueva versión.

Así que cada día el CLI está mejorando porque el agente sigue dejando estos rastros donde la herramienta llamada o cualquier cosa era confusa. No querría llamarlo agentes auto-mejorables, pero a nivel superficial, la idea es que está mejorando cada día basado en la retroalimentación que obtengo de los agentes y es mantenido por agentes. Estoy cansado de ver la palabra agentes una y otra vez. Y también tengo habilidades específicas para ello. Así que cada vez que hay una nueva versión, la etiquetaría y luego ejecutaría un agente programado que revisaría la nueva base de código, la versión que ocurrió, todos los commits que ocurrieron desde la versión anterior.

Y luego verificar cruzadamente si los archivos de habilidades, creo que hay una docena de archivos de habilidades y revisarlos y actualizarlos automáticamente y luego crear un PR y luego otro agente lo verificaría de nuevo, solo para estar seguro. Y luego hace otro lanzamiento también. Entonces, al final, ¿cómo confío en alguno de estos para fusionarlo con algo que está siendo usado por decenas de miles de personas? Así que la regla a la que llegué es que el agente que construye la corrección no puede crear su propio trabajo porque hemos descubierto que el agente trabajador que terminó la tarea tiene mucha más confianza en su trabajo que otro agente independiente que tiene el contexto fresco. Así que hay un agente auditor separado cuya idea es que básicamente ataca el trabajo que hizo el agente trabajador. Obtiene el problema, la política del repositorio, el commit exacto, el diff, y luego usa code simplify, ser implacable al respecto, los cambios que hizo y luego actualiza el comando doc, ver si todo está actualizado o no. Y luego verifica todos los códigos de salida, verifica en mi aplicación desechable, no filtró ningún secreto, nada. Y luego cuando está satisfecho, entonces iría y fusionaría directamente ese PR.

Y porque en este punto, la base de código es de medio millón de líneas de código. Y todo está escrito por agentes en los últimos meses. Me basé en el desarrollo guiado por pruebas desde el primer día, porque me di cuenta de que querría tener casos de prueba mucho mejores que no tener ninguno. Y el código de prueba en realidad es mucho más que el código real en sí. Y me di cuenta de que no quiero refactorizarlo muy a menudo y simplemente dejar que estos agentes se descontrolen cuando se trata de refactorizar y quemar todos mis tokens. Así que lo que tendría es en los comandos o los archivos que tengo, simplemente mencionaría que se centren en pequeñas correcciones de errores aquí y allá. Si hay un ayudante duplicado que agregó, simplemente refactorizar eso o auditar algunos comandos que lo estaban manejando de manera diferente, tienes mucho más un lugar para hacerlo. Porque para un CLI, no es muy difícil tener mucho código en comparación con, digamos, algo que es una aplicación iOS o una aplicación Android o una aplicación web.

Y una cosa que he notado, si miras las capturas de pantalla, me di cuenta de que un día me desperté por la mañana y vi las notas de la versión al mismo tiempo que otros las estaban viendo, porque había pasado por todos mis PRs en los que trabajó y luego hizo un montón, como en masa, fusionó todos los PRs y luego crearía un nuevo lanzamiento para mí después de hacer toda la auditoría que quería que hiciera. Y luego me di cuenta de que estamos en un punto donde estoy muy feliz de que mantenga todo el proceso. Y con eso me he dado cuenta de que estos lanzamientos autónomos, por mucho que sea genial hacerlo y mantenerlo por sí mismo, me di cuenta de que me siento mucho más alienado del producto ahora en el sentido de que, como mencioné, no quiero ver las notas de la versión al mismo tiempo que otros, necesito estar más en el proceso. Pero por ahora, estoy disfrutando lo que llamo la fábrica de agentes.

Así que si tengo que aconsejarte, no comiences automatizando toda la parte de lanzamiento, comienza con algo que sea solo preguntar al agente que estás usando y pregúntale qué puedo automatizar en primer lugar, donde puede haber algunas reglas que se pueden crear en una habilidad, algo que le estás pidiendo una y otra vez, créalo en una habilidad, y luego ejecuta un programador alrededor de ello o una automatización, y luego tener diferentes... Otro agente que tengo es en seguridad, así que uno es para el triaje, uno es auditor, uno es mejorador de análisis, que es el auto-mejorador, uno es para el ejecutor de lanzamientos y la verificación pública es donde tengo una auditoría de seguridad, que verifica el SHA, las etiquetas CI para asegurarse de que no haya forma de que haya una inyección de comandos que haya ocurrido y que pueda ser lanzada en un lanzamiento público que otros también descargarán. Así que al final, me di cuenta de que tener cero problemas y cero PRs es algo con lo que estoy muy contento y no desencadena mi TOC en absoluto. Y mi conclusión es que los humanos deben decidir la dirección del producto y escribir las reglas y políticas iniciales, pero no tienes que ser el programador o trabajar en trabajos monótonos que pueden ser tomados por todos estos agentes. Y muchos de ellos ahora pueden ser tomados por los agentes hasta el punto en que puedes confiar en ellos para mantener tu trabajo también. Y con eso, gracias por escuchar mi charla y puedes encontrarme en X en Rudrank. Creo que en la mayoría de las redes sociales, puedes encontrarme por mi primer nombre, gracias a mi SEO único, el nombre que mis padres me han dado. Y comparto muchos de mis experimentos allí. Gracias. Gracias Rudrank por tu sesión perspicaz. Tengamos una conversación. Veo que tenemos un par de preguntas hasta ahora de nuestros queridos asistentes y seguro que tendremos más, porque el tema definitivamente resuena con muchos desarrolladores. Personalmente construyo bastantes herramientas para desarrolladores, por supuesto impulsadas por IA. Y personalmente hago mi mejor esfuerzo para automatizar todo lo que sea posible automatizar. Así que llamo a esto una especie de meta IA, cuando la IA ayuda a construir y mantener IA. Pero tomemos la primera. Alejandro está preguntando, ¿cómo decides el modelo y el esfuerzo para cada tarea? Así que en una nota no seria, depende de cuánto uso me queda. Así que si no tengo mucho, simplemente usaría un modelo medio. De lo contrario, simplemente iría a extra alto. Pero en una nota seria, me he dado cuenta en los últimos meses de construir este CLI, o cualquier otra herramienta que para los modelos de codecs, es mucho mejor usar en bajo o alto o medio para la mayoría de las tareas e ir a alto y extra alto, solo cuando no puede resolver en los niveles de razonamiento más bajos. Porque la razón es que siento que en los niveles alto y extra alto, tienden a sobrepensar. Pero por otro lado, para los modelos de nube, prefiero usar el razonamiento alto y no medio y bajo porque en bajo y medio, siento que toman atajos. Y no tengo evaluación para probar esto, es solo por la experiencia de construir todas mis herramientas de código abierto en los últimos cinco meses. Y sí, esta es mi idea. Para la mayoría de las tareas, para los modelos de nube, usaría alto y para los modelos de codecs, usaría medio y o alto basado en cuántos tokens me quedan. Sí, muchas gracias. Esas son recomendaciones bastante concretas. Y personalmente espero que tarde o temprano, los desarrolladores nosotros mismos seremos liberados de pensar en eso porque siento que nosotros, como proveedores de los modelos y arneses, deberíamos idear enrutadores muy inteligentes, ¿verdad? No necesitamos pensar en, oye, como, qué modelo de la semana o qué tipo de caso de razonamiento usar, todo debería suceder automáticamente porque tenemos, quiero decir, podemos tener un nivel de inteligencia bastante poderoso solo localmente, ¿verdad? Así que solo basado en tu solicitud, el enrutador inteligente debería definir eso. Espero que este sea el futuro. Y tomemos el siguiente, también de Alejandro.

Por cierto, gracias, amigos, por enviar sus preguntas. Sí, realmente quiero que este evento sea como una conversación bidireccional. ¿Tenemos evaluaciones para garantizar la calidad de las salidas? Sí, tal vez vamos a generalizar. ¿Cuál es tu enfoque para establecer el estándar y seguir el estándar de calidad en las respuestas del modelo? Así que lo primero es que el modelo debería haberme dado la respuesta que quiero, esa es la calidad que esperaría sin ningún error. Y anteriormente, no tenía evaluaciones. Pero lentamente, lo que estoy tratando de construir se basa en las analíticas, estoy tratando de entender cómo estos modelos funcionan y entender más sobre, no sobre qué tan bien funcionan, sino más sobre cuántos errores estoy obteniendo. Así que, por ejemplo, en el propio CLI, el problema que estaba enfrentando era que el modelo no llamaría al comando exacto que querría y trataría de asumir cosas. Así que ese era el error que estaba tratando de perseguir, y así es como llegué a la conclusión de que los modelos de codecs versus modelos de cloud, cloud tenía un 2x, el error, dando 2x errores que lo que codecs tenía basado en milésimas o diezmilésimas de salida. Así que para mí, me di cuenta, está bien, los modelos de codecs son mucho mejores, pero porque la mitad de mis usuarios o desarrolladores usan cloud, todavía usan cloud, así que tendría que mejorar el CLI en esto. Y luego, sobre esa base, tenía una automatización que se enfoca específicamente o pide a los modelos de cloud que automaticen o creen una automatización cada día para revisar las analíticas y luego mejorar. Así que ese es mi conjunto de evaluaciones que construí.

Genial. Así que, también una especie de bucle de meta IA, ¿verdad? Sí. Así que la IA sigue y mejora la IA. Y, quiero decir, mi opinión personal sobre la misma pregunta es, si hay una oportunidad de proporcionar cualquier verificación determinística, evolución, como quieras llamarlo, ve por eso. Quiero decir, la evaluación basada en IA es el último recurso, ¿verdad? Por supuesto, en muchos casos, solo puede ser impulsada por IA, pero si puedes simplemente conectar un viejo algoritmo determinístico dorado, si lo deseas, evaluación, es la opción más simple. Y lo mismo para el enfoque, cómo uso herramientas de codificación de IA. Intento instrumentar tanto como sea posible puertas determinísticas, porque eso ayuda a ahorrar tokens, cuesta dinero, tiempo, esfuerzos y todo. Sí, y tomemos el siguiente. Eso es muy interesante, por cierto, y también plantea una gran pregunta abierta. Permíteme también generalizar esto un poco. ¿Hay alguna tarea que tal vez intentaste automatizar con IA, pero fallaste o tal vez incluso no intentaste automatizar con IA? Entonces, donde nuestro juicio sigue siendo la única forma de avanzar. ¿Alguna tarea, alguna experiencia como esa? Creo que no. No puedo pensar en algo en el lado del CLI, pero al menos en el trabajo, lo que me di cuenta, porque no puedo escribir mucho código sobre cómo trabajé en el CLI, porque hay mucho dinero involucrado. Así que, trabajo en la publicación de la app store, así que cualquier pequeño error que cometa afectará a miles de desarrolladores en una hora, así que tengo que ser muy cuidadoso con eso, y ahí es donde el juicio humano es muy insustituible. Así que, tengo una automatización donde vería los errores de la app store, y luego ejecutaría nuestro bot RORC. Así que, trabajo en RORC, así que tendría un bot que se ejecutaría en los problemas, pero a veces, incluso después de darle tanto contexto como sea posible, la base de código, e incluso mis gráficos locales de codex, he encontrado que no sería capaz de señalar el problema exacto donde querría que estuviera. Tal vez, ahora mismo, los últimos modelos GVT no están en ese punto donde creo que tal vez es un problema de habilidad de mi parte, donde no he podido escribir suficientes habilidades, juego de palabras intencionado. Pero la idea principal es que siento que en este punto, hay muchos lugares donde intenté la automatización, y especialmente esta tubería donde tomaría los errores que obtengo de los usuarios, y trataría de automatizarlo hasta un punto donde pueda decir con confianza que este PR que se ha generado es algo que puedo fusionar autónomamente en la base de código de producción. Así que, todavía soy un humano en el bucle en este momento.

Por supuesto, el juicio es uno de los últimos puntos que realmente nos diferencia a nosotros los humanos de todo tipo de máquinas. Así que, tal vez el juicio, basado en la experiencia, basado en habilidades, basado en años de trabajo dentro de un dominio particular o con un producto particular, es la parte más valiosa de nuestro trabajo como humanos hoy en día. Así que, ese es mi enfoque. Escucho esta palabra juicio cada vez más y más a menudo hoy en contexto, cómo mantenerse relevante en el desarrollo de software, cómo mantenerse relevante con tal presión de la UI, de la IA, por supuesto. Creo que en realidad respondiste la última pregunta que teníamos sobre la experiencia negativa. Elaboraste un poco lo que no es posible realmente automatizar hoy.

Pero tal vez, como un último comentario, ¿algún caso interesante de fallos, de desastre completo, algo que puedas compartir con nosotros? Entonces, en el lado de la experiencia negativa, he sido muy cauteloso al incluir la automatización. Así que, solo comencé las automatizaciones hace como dos meses, aunque he trabajado en este CLI durante cinco meses. Porque en los primeros tres meses, fui muy cauteloso, como, las cosas pueden salir mal. Pero afortunadamente, no fue así. Y porque estamos en esta era en la que recibes muchos PRs o problemas mal gestionados, o incluso problemas o PRs inyectados por prompt, ahí es donde tuve muchas puertas.

Todavía invierto mucho en las habilidades o la automatización que, para un paso, los protegería, para que pueda dormir bien por la noche. Esta es la idea. Así que, para esta cosa, no he tenido ninguna experiencia negativa donde tuve que revertir o deshacer cambios, pero en el trabajo, tengo que revertir muchas cosas, porque hay muchos casos extremos que surgen cuando trabajas a una escala mayor. Que los modelos, incluso si intentan con sub-agentes y tratas de tener muchos sub-agentes trabajando en diferentes aspectos, algo aún puede ser pasado por alto desde un ángulo que no habías pensado. Así que, esas son las cosas en las que soy muy considerado.