Guía práctica inspirada en el caso del ADK de Google: skills por repositorio, un objetivo medible y revisión humana para que un agente optimice tu código.
Google ha contado cómo dejó a un agente trabajando sin supervisión durante 11 horas sobre el código del Agent Development Kit, más de 200.000 líneas de Python. El resultado fueron dos optimizaciones aceptadas. Lo interesante no es el modelo, sino el método, y eso se puede adaptar a cualquier repositorio. Aquí resumimos cómo plantearlo, basándonos en la crónica de InfoQ y en el artículo original de Google.
Lo que necesitas
Antes de lanzar nada, conviene tener tres piezas. La primera, una batería de pruebas fiable: el ADK tiene cerca de 17.000 pruebas unitarias y el agente las ejecutó todas antes de terminar. La segunda, una forma de medir el rendimiento antes y después. La tercera, guías escritas del repositorio para el agente, como las que Google guarda en .agents/skills.
- Un agente de programación con modo de objetivo persistente (Google usó /goal en Antigravity).
- Pruebas unitarias que se ejecuten completas en un tiempo razonable.
- Pruebas de referencia (benchmarks) para comparar cifras antes y después.
- Un humano disponible para revisar la pull request al día siguiente.
Los pasos, en orden
- Haz una ejecución corta de prueba para descubrir qué convenciones de pruebas y de benchmarks ignora el agente.
- Escribe esas convenciones como archivos de skills, a modo de guía de incorporación para un ingeniero nuevo, y pide que el agente cargue solo la que necesite para no llenar su ventana de contexto.
- Redacta un objetivo único y medible: sin sobrecoste apreciable, API pública intacta, una prueba por cambio y una sola pull request con cifras antes y después.
- Prohíbe explícitamente fusionar: el agente abre la pull request, nunca la integra.
- Lanza la ejecución larga y revisa al terminar los registros: lectura de guías, líneas base, propuestas, autorrevisión y pruebas completas.
- Revisa cada cambio como si lo hubiera escrito una persona y descarta lo que no supere el listón.
Cómo formular el objetivo
Google resumió su petición en una sola instrucción con límites claros. Nosotros recomendamos adaptar esa estructura a tu proyecto, cambiando los ámbitos de rendimiento que te importen. Lo esencial es que el objetivo sea comprobable y que incluya la restricción de no tocar la API pública.
/goal Reduce el sobrecoste del framework en arranque y en sesiones largas.
Mantén sin cambios la API pública y lo que recibe el modelo.
Respalda cada cambio con una prueba que detecte regresiones.
Abre una sola pull request con cifras antes y después. No la fusiones.Qué esperar del resultado
En el ADK, las dos mejoras aceptadas filtraban eventos antes de copiar el historial de sesión y cargaban de forma diferida paquetes pesados. Redujeron el sobrecoste de preparar la sesión en memoria un 40 % y el tiempo de importación en frío un 21 %. En una ejecución de 158 turnos con herramientas, el total bajó de 65,6 a 56,1 segundos.
Ojo con las expectativas: Google también reporta cuatro modificaciones rechazadas tras la revisión por dudas de fiabilidad, mantenibilidad, compatibilidad o beneficio medible. Contad con que parte de lo que proponga el agente no se aprovechará, y con que revisar, depurar y probar sigue siendo el cuello de botella. Un solo caso tampoco demuestra que funcione igual en cualquier base de código.
Para saber más: Chinese edition · Events.
Artículos relacionados de LaRebelión
tsrs de Cloudflare: guía para evaluar el port de TypeScript a Rust
Guía: prepara tu UI Android para agentes de IA con Jetpack Compose
Guía: cómo preparar a tu equipo para delegar trabajo en agentes de IAFuente original: infoq.com
Artículo generado mediante AI.larebelion
Comentarios
Publicar un comentario