Como referente técnico Android en entornos Agile multi-squad, con clientes de banca, telecomunicaciones y retail, una parte importante de mi trabajo no es escribir features nuevas, sino sostener la calidad y la velocidad de varios equipos a la vez: revisar código, mantener estándares de arquitectura, documentar decisiones y automatizar tareas que se repiten cada sprint. Ahí es donde entraron los agentes de IA, no como una demo vistosa, sino como una herramienta más del ciclo de ingeniería.

El problema: tiempo senior gastado en tareas repetitivas

En proyectos con varios squads trabajando sobre la misma base de código, hay un conjunto de tareas que consumen tiempo desproporcionado respecto al valor que aportan: revisar que un PR cumple el estándar de arquitectura acordado, generar o actualizar documentación técnica, detectar código candidato a refactor antes de que se convierta en deuda técnica, y encadenar pasos manuales en la integración continua. Ese tiempo es tiempo que no se dedica a diseño de arquitectura ni a resolver problemas de negocio complejos.

La arquitectura de agentes que uso

La base es Claude Code como orquestador de tareas de ingeniería, conectado mediante MCP (Model Context Protocol) a las fuentes de contexto que ya existen en el equipo: repositorios Git, documentación interna y pipelines de CI/CD (Jenkins, Bamboo). MCP resuelve un problema muy concreto: en lugar de copiar y pegar contexto a mano en cada conversación con un LLM, el agente accede directamente a las herramientas y datos que necesita, con permisos acotados.

Sobre esa base construyo Skills a medida: procedimientos documentados y reutilizables para tareas que se repiten igual en distintos proyectos —por ejemplo, revisar que un módulo nuevo respeta las capas de Clean Architecture, o generar el changelog técnico de una release—. Una Skill bien definida convierte una tarea ad-hoc en un proceso repetible y auditable.

Casos concretos en producción

  • Apoyo a la revisión de código: antes de que un PR llegue a revisión humana, el agente comprueba convenciones de arquitectura, detecta violaciones de las reglas de dependencia entre capas y señala patrones ya identificados como problemáticos en el proyecto.
  • Documentación técnica: generación y actualización de documentación de módulos y decisiones de arquitectura, reduciendo el desfase habitual entre lo que dice el código y lo que dice la documentación.
  • Automatización en CI/CD: integración con Jenkins/Bamboo para tareas mecánicas del pipeline que antes requerían intervención manual repetida.

De prototipo a producción: cómo se valida

La parte menos visible, pero más importante, es cómo se garantiza que el trabajo de un agente es fiable en un entorno crítico. En la práctica esto significa tres cosas: el resultado del agente pasa siempre por los mismos filtros de calidad que el código escrito por una persona (testing unitario, SonarQube), el alcance de autonomía del agente está deliberadamente acotado a tareas verificables, y siempre hay una persona en el bucle antes de que algo llegue a producción. Un agente de IA en un proyecto bancario no es una excepción a las reglas de calidad del equipo; tiene que superarlas igual que cualquier otro cambio.

Automatizar sin verificar no ahorra tiempo, lo traslada al futuro en forma de incidencias.

Lecciones aprendidas

Lo que mejor ha funcionado es empezar por tareas de alcance pequeño y verificación objetiva —donde es fácil comprobar si el resultado es correcto—, y ampliar el alcance del agente solo cuando ese primer paso demuestra ser fiable de forma consistente. Lo que peor ha funcionado es intentar automatizar de golpe tareas ambiguas o poco documentadas: un agente no puede seguir un estándar que el propio equipo no ha explicitado todavía. El impacto real se mide en tiempo de revisión ahorrado, menor fricción entre squads que comparten estándar, y en la posibilidad de que el equipo dedique más tiempo a decisiones de arquitectura que a tareas mecánicas.