El peor consejo que veo dar a equipos pequeños de dev es "empiecen a automatizarlo todo". Los equipos de cinco no tienen ancho de banda para construir cinco agentes. Apenas tienen ancho de banda para construir uno. Elige mal el primer agente y te pasas tres semanas en algo que el equipo usa dos veces y abandona.
La pregunta que vale la pena responder: en un equipo de 2 a 10 desarrolladores, ¿cuál es el primer agente que construyes? La respuesta depende de qué duele más. Pero hay un orden real, y hay una automatización seductora que absolutamente no construiría primero. Déjame desgranarla.
Los seis candidatos
Estas son las seis que se proponen. Las clasifico en dos ejes: esfuerzo para construirlas, y valor una vez que existen. Las que quedan arriba a la derecha se construyen. Las que quedan abajo a la izquierda se comentan y nunca se entregan. Ninguna necesita una orden de compra para empezar: SonarQube Community Build, un Sentry autohospedado y GitHub Actions en un plan gratuito cubren toda la lista, con una salvedad de licencia en la primera que explico más abajo.
El seductor que me saltaría: asistente de onboarding
El agente de onboarding suena genial. Entra una nueva persona, el agente explica la codebase, responde preguntas de arquitectura, sugiere primeras tareas. Es la automatización que emociona a todo el mundo. Es el peor lugar para empezar.
Por qué. El agente de onboarding necesita saberlo todo. Cada servicio, cada convención, cada patrón deprecado, cada razón por la que se tomó una decisión rara hace tres años. Si la base de conocimiento está mal o incompleta, la nueva persona aprende cosas equivocadas y hay que hacerla desaprenderlas. Si la base de conocimiento está completa, ya hiciste el 80 por ciento del trabajo de onboarding, y un README habría hecho la mayor parte del trabajo.
En un equipo pequeño contratas quizás 2 o 3 personas al año. El agente se dispara 2 o 3 veces. Todas las demás automatizaciones de esta lista se disparan en cada PR o en cada merge. Estás gastando semanas de esfuerzo de ingeniería en un agente que corre un puñado de veces al año y que se equivoca si la base de conocimiento no es perfecta. Sáltalo. Constrúyelo cuando seas 30 personas, no 8.
Empieza aquí: puente de SonarQube a Copilot
Este merece un post propio. Versión corta: Sonar marca problemas en código asistido por IA, los desarrolladores ignoran el dashboard porque actuar sobre él les cuesta cambios de contexto. El agente lee el reporte de Sonar, genera un prompt de Copilot listo para pegar, lo deja en el PR. El desarrollador pega, revisa, commitea.
Por qué este primero. Se dispara en cada PR. La entrada es una API estructurada. La salida es texto, sin riesgo de ejecución. Un solo desarrollador puede construirlo en un fin de semana. Cada miembro del equipo ve el valor en la primera semana. Esta es la victoria más fácil que conozco, y los equipos siguen sin construirla.
La salvedad que nadie pone en el pitch: el análisis de pull request necesita SonarQube Developer Edition o superior. Community Build rechaza sonar.pullrequest.key, así que el disparador por PR no es gratis. La versión gratuita de este agente corre sobre análisis de rama: escanea main, lee los issues que aparecieron desde el último análisis, comenta en el commit de merge. Pierdes el feedback antes del merge y conservas todo lo demás. El plugin comunitario de ramas (mc1arke/sonarqube-community-branch-plugin) devuelve el disparador por PR en Community Build, de forma no oficial y sin soporte de SonarSource. Decide eso antes de presupuestar el fin de semana.
Segundo: detector de drift de docs
Este corre al merge a main. El agente mira qué archivos cambiaron en el PR y chequea si la documentación relacionada se actualizó. Si no, postea un comentario o abre un PR de actualización de docs con un borrador.
Por qué segundo. El drift de documentación es universal. Nadie actualiza los docs por gusto, todos actualizan los docs bajo presión justo antes de un release o un onboarding. Un agente que marca el drift en el momento en que ocurre significa que lo arreglas en 10 minutos en vez de auditar 200 páginas seis meses después.
Tejido cicatrizal de equipos con los que he trabajado: los docs quedan desactualizados porque la actualización es un PR separado y se desprioriza. La corrección es atar la actualización de docs al cambio de código en lugar de dejarla para después. El agente hace eso: abre el PR de docs vinculado al PR de código, mismo sprint, mismo reviewer.
Tercero: bot de briefing de standup
A las 9:00 AM, el agente recoge: commits del día anterior por desarrollador, PRs abiertos o mergeados, cambios de estado en Jira, menciones de bloqueadores en Slack. Postea un briefing por persona en el canal del equipo. El humano sigue haciendo el standup. El bot solo reemplaza el ejercicio de memoria del tipo "déjame ver mi git log rapidito".
Por qué tercero. Es de bajo riesgo, bajo esfuerzo y alta señal. A los tech leads les encanta porque los impedimentos salen a la superficie sin que la gente tenga que ofrecerlos. A la gente del equipo le encanta porque el demo de lo de ayer ya viene escrito.
Cuarto: triage de bugs
Se dispara con nuevos eventos de Sentry o issues recién abiertas en GitHub. El agente clasifica la severidad, busca incidentes pasados similares en el vector store, asigna un owner basado en ownership de archivo vía git blame, y postea un ping de Slack a la persona correcta.
Por qué cuarto, no primero. El triage de bugs requiere dos cosas que los agentes anteriores no: una memoria ya poblada (vector store de bugs pasados), y una lógica de clasificación afinada que encaje con tu equipo. Entrégalo después de que los dos primeros estén corriendo, no en la primera semana. Para entonces tendrás suficientes corridas del puente de Sonar y del de docs para entender cómo construir un agente más stateful.
Quinto: asistente de revisión de PR
Primera pasada de revisión de PR antes de que el humano llegue. Revisa convenciones, riesgo, cobertura, probabilidad de regresión basada en bugs pasados en archivos relacionados.
Por qué quinto. La revisión de PR es una tarea de juicio. El primer 80 por ciento es mecánico y el agente lo clava. El último 20 por ciento es contexto sobre el equipo, el roadmap, las cosas que se rompieron el trimestre pasado. Si el agente no está calibrado con las revisiones pasadas de tu equipo, va a generar ruido. Necesitas suficiente historial propio de revisiones para calibrarlo, o sea meses de corridas, no semanas, y no vas a saber el número hasta que mires el ruido que produce.
La regla de decisión
Cuando evalúo un agente candidato para un equipo pequeño, hago tres preguntas en orden. Si alguna respuesta es mala, me lo salto, sin importar qué tan emocionante sea el pitch.
- ¿Con qué frecuencia se dispara? Si la respuesta es menos de una vez al día, no es tu primer agente.
- ¿Requiere memoria o calidad de clasificación desde el día uno? Si sí, no es tu primer agente. Los agentes anteriores pueblan la memoria de la que dependen los agentes posteriores.
- Si produce una salida equivocada, ¿cuál es el radio de explosión? Texto en un comentario de PR, bien. Código ejecutado en producción, no. Empieza donde el radio de explosión es el más pequeño.
Aplica esas reglas a los seis candidatos y obtienes el orden que acabo de plantear. Aplícalas a cualquier otra cosa que alguien te pitchee y vas a saber si vale las próximas tres semanas de tu equipo.
Qué pasa después del primer agente
El primer agente es el más difícil. No porque el código sea difícil, sino porque tienes que elegir la estructura, la historia de despliegue, el enfoque de observabilidad, el layout de memoria. El segundo agente es 5x más rápido porque reutilizas todo eso. Para el tercero, ya tienes una pequeña plataforma interna y el equipo empieza a proponer sus propios agentes.
Ese es el objetivo real de empezar con el puente de SonarQube. No el puente en sí. La base compartida que hace triviales los siguientes cinco agentes.
Un agente que el equipo usa todos los días le gana a cinco agentes que usan una vez y olvidan. Elige el que se dispara a menudo, que falla de forma segura, que devuelve valor obvio en la primera semana.
Referencias
- SonarQube Web API: https://docs.sonarsource.com/sonarqube/latest/extension-guide/web-api/
- GitHub Actions: https://docs.github.com/en/actions
- Sentry API: https://docs.sentry.io/api/