Agente por Defecto: Repensando los Flujos de Trabajo de Desarrolladores con Claude Code

Hola, bienvenidos al AI Coding Summit. Mi nombre es Ado Kukic y soy gerente de comunidad en Anthropic. Y hoy, vamos a hablar sobre la decodificación de agentes, qué es, y patrones concretos que puedes usar hoy para lograr mucho más con Cloud Code. Y prometo que intentaré mantener esto lo más práctico posible. Y todo lo que te muestre hoy, podrás ir y probarlo en tu terminal en unos cinco minutos. Así que vamos a ello.

Entonces, la primera pregunta obvia es, ¿qué hace que algo sea agéntico? Y para mí, realmente se reduce a este ciclo de planificar, actuar y verificar. Cómo la mayoría de las personas usan la IA para codificar hoy es que le preguntan algo a su LLM, obtienen una salida de texto, y pueden copiar y pegarlo en su IDE y ver si compila. Y si no lo hace, pegan el error de nuevo, obtienen más salida e intentan de nuevo. Básicamente estás jugando al teléfono con una IA muy inteligente. Una herramienta agéntica es fundamentalmente diferente. Cuando le das una tarea, no solo escupe código y espera lo mejor. Primero planifica, lee la base de código, trata de entender el contexto, y averigua qué archivos importan, y elabora un enfoque.

Luego actúa, escribe el código, ejecuta comandos, usa herramientas, y hace cambios reales en tu proyecto. Y finalmente, verifica lo que hizo. Va a ejecutar la prueba, va a intentar construir la aplicación, va a leer la salida de errores o los registros, y si algo está roto, va a intentar arreglarlo. Y si no lo hace, va a volver a empezar, va a replantear, reaccionar y reverificar una y otra vez hasta que el trabajo esté realmente hecho. Y si miramos cada una de las fases, la fase de planificación va a usar un cierto conjunto de herramientas como read, grep y think para realmente tratar de entender el problema. En la fase de actuación, va a escribir nuevos archivos, editar archivos existentes, ejecutar comandos bash, y acceder a herramientas adicionales a través de servidores MCP. Finalmente, la verificación va a usar esas mismas herramientas para verificar su propio trabajo. Y si miramos los puntos brillantes en esta diapositiva, rebotando entre los tres nodos, eso es realmente lo que está sucediendo con Cloud Code. Continúa este ciclo hasta que la tarea en cuestión esté completa.

Y aquí hay otra forma de pensar en Cloud Code, es solo un agente en tu terminal. Tu prompt entra por el lado izquierdo, algo como añadir notificaciones por correo electrónico cuando un usuario es mencionado. Y eso es todo, esa es la instrucción. No le estamos diciendo cómo hacerlo, no le estamos diciendo a dónde ir, solo le estamos dando lo que queremos, le estamos dando la tarea. Y en el medio, tenemos Cloud Code, un agente sentado en el terminal con cuatro capacidades principales, la capacidad de pensar y razonar, la capacidad de leer nuestra base de código, la capacidad de escribir y editar, y la capacidad de usar varias herramientas a través de bash. Va a razonar sobre nuestro código, va a leer archivos en nuestra base de código, escribir nuevo código y ejecutar los comandos hasta que lleguemos al lado derecho del código funcionando. Nuestra prueba pasa, el código está listo para PR y listo para fusionar. Y lo que sucede en la caja del medio es donde vive toda la magia. Cloud está aprendiendo sobre nuestro sistema de notificaciones existente que tenemos en su lugar para entender los patrones que estamos implementando. Está escribiendo nuevo código que coincide con esas convenciones y no nuevas. Y luego está ejecutando el conjunto de pruebas para asegurarse de que el nuevo código que escribió y añadió realmente no se rompa. Y si algo se rompe, vuelve y lo arregla hasta que lleguemos a nuestro código funcionando. Así que al final del día, le das el qué y va a averiguar el cómo.

Bien, eso es solo una visión general a muy alto nivel. Pero ahora entremos en los patrones de decodificación de agentes y técnicas prácticas para obtener lo máximo de nuestras herramientas de decodificación de agentes. Comenzaremos con el contexto. Y honestamente, este es probablemente el más importante, darle al agente el contexto correcto. Y la mejor manera de hacerlo es a través de un archivo cloud.md. Es un archivo markdown que vive en la raíz de tu proyecto y cloud lo lee al inicio de cada sesión. Piénsalo como documentación de incorporación. Y si tu proyecto aún no tiene un archivo cloud.md, puedes ejecutar el comando slash init para que cloud code lea automáticamente la base de código y escriba su propio archivo cloud.md basado en lo que encuentra. Algunas buenas cosas para agregar en tu archivo cloud.md son tus comandos de uso frecuente, tu estilo de codificación y preferencias, convenciones de nomenclatura, cosas así, tus patrones arquitectónicos que son específicos de tu proyecto, y tu stack tecnológico y directorios clave. Y podemos ver a la derecha aquí, tengo algunos comandos. Tengo el stack tecnológico que estoy usando y convenciones que quiero que cloud code siga cuando trabaje con cloud code. El siguiente patrón va de la mano con tener un contexto realmente bueno y ese es el modo de planificación. Ahora, un problema con el que la gente típicamente se encontrará cuando están intentando por primera vez la decodificación de agentes es que le darán a cloud una tarea muy compleja y esperarán que simplemente salga y haga el trabajo y lo haga bien en el primer intento. Y no me malinterpretes. Cloud intentará hacerlo. Va a ir a mirar la base de código, va a hacer su mejor esfuerzo para hacer tantos cambios como sea posible para cumplir con la tarea. Pero sin un plan, las probabilidades de que se descarrile son significativas.

Y el modo de planificación puede solucionar esto. Cuando lo activas, en lugar de que cloud vaya y haga cambios ansiosamente en tu base de código basado en el prompt que le diste, te dará un plan detallado y en lugar de reescribir inmediatamente la mitad de tu aplicación, cloud code va a leer tu código existente, entender los patrones, tal vez hacer una o dos preguntas aclaratorias, y luego proponer un plan de ataque. Esto es lo que voy a cambiar. Aquí están los archivos que tocaré y aquí está el enfoque que estoy pensando en hacer. Puedes revisar este plan, puedes rechazarlo. Cloud va a ajustar el plan y solo una vez que lo apruebes comenzará a hacer cambios. Recomiendo encarecidamente usar el modo de planificación para cualquier tarea no trivial ya que va a mejorar mucho la salida de tu código.

Para el patrón tres, veo que este es mucho más un cambio de mentalidad en lugar de un patrón real. Y la razón por la que digo eso es que muchas veces los desarrolladores darán instrucciones a cloud sobre lo que quieren que haga y pueden volverse muy verbosos y muy específicos. Y lo que quiero desafiarte a hacer es enfocarte en describir lo que quieres que se haga en lugar de cómo. Tenemos un par de ejemplos aquí en el lado izquierdo y el lado derecho sobre qué hacer y qué no hacer. Siempre animo a los desarrolladores a no darle instrucciones muy descriptivas sobre ir a esta línea específica y hacer este cambio específico. Más bien, trato de darle una tarea, darle un problema y dejar que Cloud Code descubra cómo implementarlo mejor. En lugar de decir ve a package.json y añade . como una dependencia, podría decir algo como añade validación de entrada a todos nuestros endpoints de API y asegúrate de que estamos obteniendo respuestas de error consistentes para cada endpoint de API en lugar de decirle exactamente cómo hacerlo y cómo quiero que se escriba todo el código. Y un consejo profesional aquí también es que Cloud Code tiene un concepto de comandos slash. Así que cualquier prompt que estés usando varias veces al día, puedes realmente almacenarlo como un comando slash, guardar ese prompt y luego solo ejecutas el comando y va a ejecutar el prompt, también puede aceptar argumentos, haciendo que todo el flujo de trabajo de pensamiento y tareas sea mucho, mucho más simple.

Comenzando con el patrón cuatro, nos estamos moviendo hacia el territorio de usuarios avanzados y la característica de la que quiero hablar aquí son los subagentes. Así que los subagentes son asistentes de IA especializados que se ejecutan en su propio contexto aislado. Cada uno obtiene su propia ventana de contexto de 200k tokens completamente separada de tu agente principal. ¿Y por qué importa esto? Bueno, por dos razones. La primera es la especialización. Si miras el ejemplo de la izquierda aquí, tenemos un subagente revisor de código. Su enfoque está en la calidad del código, la seguridad y la mantenibilidad. Solo tiene la capacidad de leer código, puede leer, puede buscar, pero no puede modificar o escribir código accidentalmente. Y también utiliza un modelo más rápido para la velocidad porque las revisiones no necesariamente necesitan un modelo pesado. En el lado derecho, tenemos un subagente depurador.

Y este obtiene las herramientas de edición y bash porque necesita poder realmente arreglar cosas. Va a heredar con cualquier modelo que estemos usando y tiene un trabajo totalmente diferente al del agente de revisión de código. Y la segunda gran razón es la gestión del contexto. La ventana de contexto de tu sesión principal es un bien preciado.

Si una revisión de código lee 50 archivos y genera un análisis masivo, todo eso va a estar ocupando y contaminando tu ventana de contexto, consumiendo espacio y consumiendo la memoria de Cloud. Con un subagente, todo ese trabajo ocurre en aislamiento y solo el resumen regresa al agente principal. Puedes crear agentes con el comando slash agents o simplemente dejar un archivo marcado en tu carpeta Cloud.agents.

Soy un gran defensor de poner tanto trabajo como sea posible en los subagentes y hacer que ese agente principal solo supervise el trabajo y asigne trabajo adicional. El siguiente patrón del que quiero hablar es hooks. Y los hooks son comandos de shell definidos por el usuario que se ejecutan automáticamente en varios puntos del ciclo de vida. Le dan a Cloud un control determinista sobre la IA probabilística.

Por ejemplo, antes del uso de herramientas, puedes bloquear o permitir el uso específico de herramientas. Solicitud de permiso, puedes aprobar o denegar permisos automáticamente. Para un ciclo de vida de inicio de sesión, puedes cargar contexto adicional desde un lugar diferente o establecer variables de entorno para esa sesión que no existen. Y muchos, muchos más.

Notificaciones es una que uso mucho solo para enviarme una notificación de audio o visual cuando Cloud necesita mi atención. En mi opinión, los hooks están muy, muy subestimados y algo en lo que todos los que se toman en serio el uso de Cloud Code deberían invertir mucho.

El patrón seis es MCP o protocolo de contexto de modelo. Esta es la capa de integración universal y honestamente una de las cosas más emocionantes que están sucediendo en el espacio de herramientas de IA. Sin MCP, Cloud Code vive en tu terminal y puede leer archivos y ejecutar comandos de shell. Pero no puede consultar directamente tu base de datos, no puede publicar en Slack, no puede navegar a tu tablero de Jira o al navegador. Pero con MCP, puedes configurar varios servidores en tus configuraciones y de repente Cloud tiene acceso a todo a lo que tú tendrías acceso. Tu GitHub, tu Postgres, Slack, Jira, Stripe, Linear y muchos más. Los servidores MCP exponen varias herramientas para permitirte ejecutar acciones a través de sistemas.

Y esto es lo que realmente significa en la práctica. Puedes decirle a Cloud que encuentre todos los tickets asignados a mí en Linear que están bloqueando la liberación. Verifica los PRs correspondientes en GitHub y publica un resumen en nuestro canal de Slack. En Cloud, si tienes configurados los servidores MCP, podremos hacer todo eso. Va a usar las diversas herramientas proporcionadas por los servidores MCP para completar las tareas. Y la mejor parte es que este es solo un único protocolo. Sin integraciones personalizadas. Si alguien construye un servidor MCP para un servicio específico, cada herramienta compatible con MCP puede usarlo de inmediato.

Para el patrón número siete, esta es una capacidad más nueva de Cloud y herramientas agenticas llamadas Skills. Y las Skills son cómo conviertes a Cloud de un asistente de propósito general en un especialista de dominio que realmente conoce tu material. Cada equipo tiene conocimiento institucional. Tus convenciones de nomenclatura, tu lista de verificación de despliegue, tus patrones de diseño de API, guías de marca, y mucho más. Normalmente, estas cosas son tribales. Puede que vivan en una página de notion o una página de esquema. Pero con las Skills, puedes empaquetar toda esta experiencia y Cloud puede cargarla bajo demanda.

El diseño aquí es realmente elegante y se compone de tres características clave que lo hacen tan poderoso. La primera es el descubrimiento progresivo. En lugar de cargar todas las Skills en el contexto cada vez que inicias una sesión, Cloud solo cargará los metadatos de la Skill. En nuestro ejemplo aquí, solo va a cargar el nombre, diseño de front-end, y la descripción. Las Skills también se activarán autónomamente cuando sea necesario. Si le das a Cloud un aviso que tiene algo que ver con el diseño de front-end, va a mirar en el directorio de Skills y verá que hay una Skill de diseño de front-end, en cuyo punto va a cargar el resto de las instrucciones para la Skill y adicionalmente, cualquier script o cualquier otro archivo que sea relevante para esta Skill.

Y las Skills son universalmente portátiles. Así que las mismas Skills que funcionan en Cloud Code, funcionan en la API, funcionan en Cloud.ai, o funcionan en varios agentes personalizados. Así que solo tienes que escribir la Skill una vez y puedes usarla en todas partes. Y las Skills son un estándar abierto que cualquier herramienta agentica puede aprovechar y usar. Así que hablamos mucho sobre hooks y Skills y servidores MCP. Y los plugins son realmente donde todas estas diferentes capacidades se unen. La primitiva de plugins resuelve el problema de compartir mi configuración. Un plugin agrupa todo en un paquete compartible e instalable, lo que significa que podemos agrupar comandos, agentes, hooks, Skills, y servidores MCP y compartirlos a través de todo nuestro equipo.

Por ejemplo aquí, si tenemos un plugin de diseño front-end, podría contener un comando de diseño, una Skill de diseño front-end, un hook de verificación de estilo, y un servidor MCP de Figma. Y con un solo comando de slash install plugin, diseño front-end, podemos obtener todas estas capacidades en nuestra máquina y compartirlas con todo nuestro equipo. Casi puedes pensar en ello como NPM para herramientas de IA porque eso es básicamente lo que es.

Patrón número nueve, trabajar en paralelo. Este es uno de los mayores desbloqueos de productividad en todo tu flujo de trabajo. Con Git WorkTrees, si no los has usado antes, crean directorios de trabajo aislados que comparten el mismo historial de Git. Y lo que esto significa para nosotros es que puedes ejecutar una sesión de cloud code completamente separada en cada uno. Y cada sesión obtiene su propia ventana de contexto fresca de 200k y cada una puede estar haciendo una tarea diferente simultáneamente.

Así que aquí estamos implementando OAuth 2.0 con Pixy, estamos construyendo un panel de análisis, migrando nuestra tabla de usuarios a UIDs de usuario, y solucionando casos límite de tasa simultáneamente. Así que tenemos cuatro sesiones de cloud code independientes todas ejecutándose al mismo tiempo, todas haciendo trabajo realmente significativo. Y esto es en realidad cómo se ve mi flujo de trabajo la mayoría de los días. Llego, miro mi tablero de sprint, y creo múltiples WorkTrees basados en tickets recientes que se han abierto o cosas recientes que necesito hacer. Luego voy a tomar café por la mañana, y cuando regreso, tengo múltiples PRs listos para revisión.

Y no estoy exagerando. En un buen día, podría cerrar 10, 20, 30 PRs a primera hora de la tarde. Y dado que estamos usando Git WorkTrees aquí, no tenemos que preocuparnos por las sesiones de cloud code interfiriendo entre sí. Cada WorkTree está completamente aislado. Cada nube tiene su propio contexto, por lo que no tenemos que preocuparnos por conflictos de fusión hasta que estemos realmente listos para fusionar. Si hay algo que debes llevarte de esta charla es que deberías estar usando Git WorkTrees y paralelizando tu trabajo de cloud code.

Y para nuestro último patrón, quiero hablar sobre cómo puedes hacer que tus agentes sean no interactivos. Tenemos dos capacidades realmente geniales que te permiten aprovechar todas las capacidades de cloud code de una manera no interactiva. La primera es ejecutar cloud code en modo sin cabeza. Así que en tu terminal, si haces cloud y pasas la bandera dash P, va a ejecutar cloud sin una interfaz de usuario de terminal. Con esto, puedes canalizar un prompt, obtener una salida estructurada de vuelta, lo que significa que puedes aprovechar esto en tu pipeline CICD o, por ejemplo, aquí tenemos un ejemplo de GitHub Action que va a hacer automáticamente una revisión de código en cada PR. Va a canalizar el diff, va a obtener retroalimentación JSON estructurada sobre errores, problemas de seguridad y violaciones estáticas automáticamente. Pero no solo tiene que ser revisión de código. Puedes hacer que intente automáticamente corregir los errores, puedes hacer que documente los cambios, cree registros de cambios, guías de migración, y mucho más.

Y finalmente, también tenemos el Cloud Agent SDK, y este es el mismo arnés agentic que impulsa cloud code pero como una biblioteca programable disponible tanto para TypeScript como para Python. Así que si quieres construir tus propios agentes de producción, con herramientas personalizadas, flujos de trabajo personalizados, todo personalizado, no tienes que reinventar esa infraestructura. Puedes construir sobre lo que ya ha sido probado en batalla por millones de desarrolladores. Y algo que debe quedar muy claro antes de que terminemos esta charla es que la codificación agentic no es todo o nada. No es confiar en la IA para todo o aprobar cada pulsación de tecla. Es un espectro, y deberías moverte fluidamente a lo largo de él según tu nivel de comodidad. A la izquierda, tenemos el control total donde todavía estás usando mucho el modo de planificación, aprobando cada paso, te estás sintiendo cada vez más cómodo con la codificación agentic, y esto es realmente bueno para cualquier cosa que sea sensible a la seguridad, trabajando en una nueva base de código, y cualquier cosa donde el costo de un error pueda ser bastante alto.

En el medio, donde creo que la mayoría de las personas están, es una especie de autonomía guiada. Aquí es donde debería vivir la mayor parte de tu trabajo diario. Estableces las directrices, tienes un cloud MD para tus convenciones, has configurado algunos hooks para la aplicación, configuraciones de permisos para los límites, y así sucesivamente, y dejas que el cloud code trabaje dentro de ellos. Así que le das suficiente libertad para ser genuinamente útil, pero suficiente estructura para que realmente puedas dormir por la noche.

Y finalmente, a la derecha, tenemos la autonomía total. Modo sin cabeza, añadiendo cloud a tu pipeline CICD, operaciones por lotes, dispara y olvida. Usa esto para tareas bien definidas y repetibles donde ya has validado el enfoque. Personalmente, creo que el punto óptimo para la mayoría de los equipos está justo en el medio con autonomía guiada donde le das un buen conjunto de directrices y dejas que la magia suceda.

Y si todo esto es nuevo para ti y realmente solo quieres probar, aquí hay cuatro pasos que puedes seguir para experimentar la decodificación de agentes hoy. Uno, instala cloud code y ejecuta slash init en tu terminal. Va a dar al agente contexto sobre tu proyecto. En unos cinco minutos, vas a obtener un archivo cloud MD que te dará la base de lo que cloud puede hacer. Dos, usa el modo de planificación. Puedes presionar shift tab para cambiar al modo de planificación en cloud y darle una tarea.

Revisa el plan que propone y si te sientes bien con él, deja que se ejecute. Tres, itera en tu archivo cloud MD. Cada vez que cloud haga algo mal o haga algo realmente bueno que quieras que repita, agrégalo al archivo cloud MD. Tu archivo cloud MD debe ser un documento vivo y en evolución que evoluciona a medida que evoluciona tu proyecto. Y finalmente, deja que el agente haga algo de trabajo. Dale una tarea. Deja que trabaje. Deja que se autocorrija cuando falle. Y resiste la tentación de interrumpirlo después del primer error.

El ciclo de planificar, actuar y verificar significa que cloud a menudo detectará y corregirá su propio error. Así que dale espacio para hacerlo. Cuatro pasos. Eso es todo. Inténtalo. Esa es tu rampa de acceso a la decodificación de agentes. Así que esto nos lleva a la conclusión de esta charla. He compartido un par de recursos aquí sobre qué hacer a continuación, instalar cloud code, ver la documentación, y si quieres más consejos y trucos sobre cómo aprovechar al máximo cloud code, creé un admin de cloud en diciembre del año pasado que tiene 31 consejos y trucos para optimizar realmente tu flujo de trabajo. Muchas gracias por acompañarme hoy. Espero que hayas aprendido algo, y espero verte en línea.