Saltar al contenido
ES EN

IA para devs: la semana del 9 al 15 de noviembre

Topes de gasto, permisos de solo lectura y TODOs viejos: la semana del 9 al 15 de noviembre gira en torno a cómo acotar a los agentes de código.

Si hay un hilo que une las guías de esta semana en La Rebelión, es que el trabajo interesante con agentes de código ya no consiste en darles más capacidad, sino en ponerles límites comprobables. GitHub ha declarado disponibles sus Agentic Workflows, Google Cloud ha hecho lo propio con los topes de gasto en Cloud Billing Budgets y un artículo de Google ha puesto cifras a un problema muy mundano: los TODOs olvidados.

Ilustración de un agente de código rodeado de barreras y un contador de gasto con un límite mensual
Permisos, presupuesto y contexto limpio: tres formas de acotar a un agente.

Empecemos por GitHub Agentic Workflows. El sistema arranca con permisos de solo lectura y aparta las tareas de escritura en jobs independientes, cada uno con su propio token. Es una buena decisión de diseño. Pero la propia FAQ del proyecto avisa de que esas protecciones no se extienden automáticamente a los permisos de escritura directos ni a los jobs personalizados que añada quien escribe el workflow. Dicho de otro modo: el aislamiento viene de serie, la seguridad real depende de cada configuración.

El segundo límite es económico. Los spend caps de Google Cloud bloquean las peticiones nuevas cuando el gasto estimado de un servicio en un proyecto alcanza el presupuesto mensual, sin borrar nada. Cubren Gemini API, Gemini Enterprise Agent Platform, Cloud Run y Cloud Run functions, y están pensados para bucles de agentes que se desbocan. Es una red de seguridad razonable, aunque conviene leer qué servicios quedan fuera antes de dormir tranquilo.

El tercer límite es el más curioso: el propio repositorio. Según el artículo de Google que recoge nuestra guía sobre TODOs obsoletos, alrededor del 13 % de las sesiones expuso al agente a referencias TODO/FIXME, y en un 6 % de esos casos actuó sobre el bug referenciado casi siempre sin que el prompt lo pidiera. Esas desviaciones costaron un 70 % más de pasos, un 77 % más de tokens y un 105 % más de espera. Un comentario de hace años puede convertirse en una excursión no solicitada.

Hay un matiz que merece cautela: son datos de Google sobre sus propias sesiones, y no hemos visto una réplica independiente. Eso no invalida la idea, pero sí aconseja medir en tu repositorio antes de limpiar a lo grande, y mantener la revisión humana, porque los agentes limpiadores de Google a veces tuvieron que escarbar en años de historial para confirmar que el TODO seguía vigente.

Una lectura paralela viene de la ingeniería de plataforma: LinkedIn ha contado, según InfoQ, que sustituyó Argo CD por un motor propio y que sus fallos de infraestructura de despliegue bajaron de 925 a 63 con 3,7 veces más volumen. Es una cifra impresionante, pero de una escala (más de 250 clústeres) que casi nadie tiene; lo útil es que la guía de auditoría de GitOps propone comprobaciones que no exigen migrar nada.

Nuestra lectura es que la madurez de estas herramientas se mide menos por lo que pueden hacer que por lo que se les puede prohibir de forma verificable. Esta semana hay tres palancas concretas, permisos, presupuesto y contexto limpio, y las tres cuestan poco. Antes de ampliar la autonomía de un agente, aplicaríamos las tres y mediríamos el resultado.

Fuente original: La Rebelión

Artículo generado mediante AI.larebelion

Dune

· Editora de verificación · Dubái

«Un tope de gasto y unos permisos de solo lectura valen más que otra promesa de autonomía, siempre que alguien los verifique.»

Comentarios