Desde que empecé a trabajar en la serie sobre IA hace poco más de un mes, he podido empezar a integrarlas en mi entorno profesional, y poco a poco han emergido dos patrones claramente diferenciados que a lo largo de este artículo he denominado exploración y ejecución, y que describiremos en profundidad con algunos ejemplos que he visto a lo largo de estas intensas semanas.

Mis herramientas, de momento, usando los modelos de Anthropic, siendo Cline y Q Developer para mi entorno profesional y Claude (Chat, Voz y Code) para aprendizaje personal. Estoy haciendo un esfuerzo consciente en limitar el número de herramientas ya que cada día hay novedades y es muy sencillo perder el norte.

Respecto al tipo de proyectos, de momento estoy usando IA para proyectos en ejecución (incluidos tests) y mantenimiento, dejando fuera áreas como arquitectura o seguridad.

Exploración: Buscando los huesos

Originalmente quería llamar a esta sección «Paleontología», que es el estudio de la vida prehistórica a través de los fósiles. A veces así se sienten los sistemas de software en los que trabajamos, en los que las plumas, el color, y los miembros originales del proyecto han desaparecido pero nos quedan los huesos y el código en producción, pero no todo el código es antiguo.

El código nuevo, recién desplegado, ya es código «legacy», las actualizaciones traen cambios que rompen casos de uso y muchas veces los errores no son viejos, sino nuevos.

En las últimas semanas he estado trabajando haciendo manteniminento y operaciones en un sistema para el que tengo poco contexto, y he usado la oportunidad para ver cómo las herramientas de IA me podían ayudar.

Mapa del territorio

Lo primero que hice antes de decidir por donde empezar fue mirar la lista de tickets o casos de soporte que estaban abiertos. En nuestro caso tenemos una herramienta que tiene soporte para MCP (Como puedes encontrar para Jira y otros), así que pude pedirle a Cline hacer una búsqueda de todos los tickets abiertos, darme detalles sobre la última acción, o el último mensaje, y lo más importante, agruparlos por categoría y producir un documento.

Esto me permitió tener una conversación mucho más productiva con otro compañero que tenía más contexto, ya que podíamos hablar de bloques de incidencias, priorizar, generar planes comunes, y actualizar el documento que posteriormente podría usar como entrada a la hora de expandir y actualizar.

Búsqueda de conceptos y campos

Una vez seleccionado un ticket, le pedí a Cline primero que lo leyera y creara un documento de análisis con la información del ticket y el contexto, acto seguido que buscara conceptos asociados con el fallo en el código del proyecto, encontrara los caminos de búsqueda y los agrupara en el documento, usando un prompt parecido a este:

- From the ticket X, create a document and add all the context.
- Find references to the user account management in this package.
- Give me the points where we create a user and becomes admin
- List the tests (if any) that check for admin customers.
- Save the information in the ticket document.

Esto me permitió fijar el tiro a la hora de saber donde mirar. Una vez que encontré el problema que estaba buscando, pude utilizar un segundo MCP para buscar referencias en otros repositorios (como tienes para Github), y agregar la información al documento de análisis, en un prompt parecido a este:

- Find in other repositories other references to account management.
- Search for the different account types and the explanation.
- Add this information to the doc, including the commands used.

Como el proceso no es perfecto, tuve que corregir varios puntos del documento, y agregar preguntas para áreas que no quedaban claras. El poder realimentar al agente con este contexto permitió, a lo largo de varias iteraciones, tener toda la información que necesitaba para pensar en una solución.

Correlación y AWS

Otra incidencia estaba causada por una alarma de CloudWatch, en ese caso mi proceso habitual sería ir a la alarma, buscar los logs asociados y comparar con el código a ver qué puede estar causando el problema. En este caso, el proceso lo seguí usando la línea de comando de Q:

- From the ticket X, create a document and add all the context.
- Using AWS CLI, get credentials for the account and find logs associated with the alarm dates and time (in UTC), filter by ERROR or WARN. Get local copies of the logs
- Using the codebase on /Users/rlbisbe/w/Project, find and reference the files that are causing the issue.
- Add the information to the document, including all the commands used.

En una ocasión, la explicación que dio el agente no fue correcta, y en otra, la fecha estuvo mal calculada porque no estaba teniendo en cuenta el cambio de hora, por eso insisto en el proceso de investigación en escribir el resultado en un documento que luego pueda revisar y además que escriba en el documento los comandos que está usando, eso nos permite explorar, validar lo que está haciendo el agente.

Ejecución

El otro área en el que me estoy apoyando más en Cline es en la ejecución, cuando tengo claro que quiero hacer o cómo quiero resolver el problema y quiero delegar en la IA para escribir el código y/o los tests. En mi caso ha sido fundamental tener el agente integado en el IDE y poder tener el contexto de un proyecto completo.

Un modo Kanban

Una de las ideas que me hizo tomarme a los agentes en serio vino por parte de Diego (Kartones) en su artículo Does Cursor support a Kanban flow?. Diego es un desarrollador fuera de serie así que suelo tomarme muy en serio lo que escribe.

En su artículo comentaba cómo había experimentado con extraer las tareas a un modelo Kanban de tal manera que el agente pudiera mantener cierto estado al ejecutar acciones, dividir el proceso en varias acciones, y ejecutarlo a posteriori. Esta estrategia la he usado en múltiples ocasiones desde que vi el artículo y tengo pensado usarla a lo largo de esta semana con un proceso más largo.

El patrón Plan/Act

Cuando empecé a usar Cline, Q, Copilot y Claude Code mi modo de ejecución fue un poco «elefante en una cacharrería», viviendo constantemente en modo Ejecución (también denominado Agente o Act en función de la herramienta) y activando la aprobación automática para los cambios. Eso hacía que si el prompt no era correcto (que no suele serlo al principio), el sistema se ponía a realizar cambios, y a veces tardaba en darme cuenta que lo que estaba haciendo no era exactamente lo que yo quería, y hacer correcciones en un proceso en funcionamiento rápidamente degrada el contexto.

El modelo kanban mencionado anteriormente ayuda a conservar el contexto, pero podemos utilizar el modo Plan para definir lo que vamos a hacer, iterar, ajustar, y luego cambiar a modo ejecución. A raíz de este artículo del blog de Cline Plan Smarter, Code Faster: Cline’s Plan & Act is the Paradigm for Agentic Coding empecé a tomarme más en serio la diferencia entere los modos de planificación y ejecución. Otra referencia que encontré fue este artículo de Carl Rannaberg My current AI coding workflow que aplica el mismo concepto a Cursor.

Un ejemplo de este modo de ejecución lo empleé la semana pasada: Necesitaba cambiar un filtro, tenía claro que tipo de cambio quería hacer, así que, en modo plan, escribí el prompt para realizar el cambio:

In the function XX, change the filter so it now discards discounted values for the item type X.

El cambio era verdaderamente trivial, pero el objetivo era una vez más, aprovechar las oportunidades para aprender a usar la herramienta. La primera versión del plan, como era de esperar, tenía algunos fallos:

• No cambiaba el filtro, sino que agregaba uno nuevo y no borraba el anterior.
• Duplicaba código, haciendo la misma comprobación varias veces en la misma función.

Si hubiera ejecutado directamente el plan, habría tenido que esperar a que terminara de hacer todos los cambios y corregir en ese momento, perdiendo tiempo y foco. En su lugar, como estaba en modo plan, pude actualizar las condiciones, especificar cambios, clarificar mi intención, e iterar un par de veces hasta que tenía un plan concreto.

Otra de las ventajas del modo Plan, es que podemos decidir guardarlo como un fichero y ejecutarlo más adelante. En mi caso estuve trabajando en un plan parecido el viernes por la tarde, y tengo previsto volver a él, volver a confirmar que hace lo que quiero que haga y ejecutarlo este lunes por la mañana.

Conclusiones

Las herramientas de IA son eso, herramientas, y somos nosotros los que tenemos que darles uso y adaptarlas a nuestras necesidades. Hoy estos dos modos de ejecución, el de exploración y el de ejecución, han cambiado no solo cómo interacciono con la IA sino también cómo planifico mi trabajo.

El uso de agentes integrados tanto en la terminal como en el editor de código me han permitido mantener el foco especialmente trabajando en tareas de mantenimiento en las que a mí, personalmente me cuesta concentrarme durante largos períodos de tiempo, y no podemos olvidar que los humanos seguimos teniendo problemas estructurales a la hora de hacer cambios de contexto.

El poder delegar la búsqueda de información y poder generar un documento con los comandos usados me ha ahorrado tiempo y energía, y el poder iterar sobre el plan me ha permitido mantener la concentración sobre el problema a resolver, y una vez el plan está claro la ejecución es más previsible. Por norma general, mientras más claros estén los pasos más probable que la solución se parezca a lo que tenúamos en mente la probabilidad de alucinaciones se reduzca.

Como parte de este viaje estoy intentando recopilar información sobre cómo la gente usa estas herramientas, así que si tienes algún modo diferente a los que he comentado, estaré encantado de leerlo.