Esta semana, Sourcegraph publicó los resultados de analizar 1,281 corridas de agentes de código en más de 40 repositorios empresariales de código abierto, y encontró algo que contradice el discurso dominante sobre coding agents: cuando un agente falla en una base de código grande, casi nunca es porque el modelo "no es lo bastante inteligente". Es porque pierde el acceso eficiente al contexto. Importa hoy porque mientras la narrativa de 2026 ha sido "mete más agentes, ve más rápido", la mayoría de los equipos de desarrollo —y de las agencias que les venden esa promesa— siguen operando sobre bases de código que ya tienen años, miles de archivos y nadie que las entienda por completo.
El hallazgo central: hay un umbral donde los agentes dejan de funcionar
El estudio de Sourcegraph identificó cinco patrones de falla recurrentes, pero el más contundente es el primero: arriba de 400,000 líneas de código, las herramientas de búsqueda convencionales —grep, lectura de archivos— empiezan a fallar de forma sistemática. No es una degradación gradual; es un punto donde el espacio de búsqueda se vuelve, en palabras del propio reporte, "estructuralmente intratable" para un agente sin motores de contexto más sofisticados.
Los otros cuatro patrones que documentaron:
- Calidad de búsqueda, no cantidad. Cuando un repositorio tiene múltiples archivos llamados
handler.goo__init__.py, la búsqueda por palabra clave regresa cientos de resultados irrelevantes y el agente no puede distinguir el código crítico del código legado o de pruebas. - Refactors incompletos. Cambios a medias en archivos interdependientes generan inconsistencias ocultas; las tareas que tocaban varios repositorios a la vez mostraron brechas de desempeño mucho mayores que las de un solo repositorio.
- El costo del "tool thrashing". En una de las tareas del benchmark, dar al agente herramientas de búsqueda más eficientes redujo el proceso de 96 llamadas en 84 minutos a solo 5 llamadas en menos de 5 minutos — una reducción de costo de 30% y una mejora de velocidad de 38% en todo el set de datos.
- Más herramientas no es igual a mejor desempeño. De forma contraintuitiva, dar a los agentes más opciones de búsqueda los hizo rendir peor: diluyeron su ventana de contexto con resultados irrelevantes en vez de mejorar la precisión.
Por qué esto no es un problema de "mejor modelo"
La conclusión del estudio es incómoda para cualquiera que esté vendiendo la idea de que el próximo modelo va a resolver esto solo: la diferencia entre una corrida que termina perfecta y una que fracasa por completo no fue la inteligencia del modelo subyacente, sino qué tan eficiente era el acceso al contexto. Un agente con un modelo más grande pero mala búsqueda sigue perdido en un repositorio de medio millón de líneas.
Lo que ya está pasando en empresas reales, no solo en el benchmark
Dan Adler, CEO de Sourcegraph, lo puso en términos más crudos esta semana: describió lo que está viendo como "un tsunami de código" que las empresas no pueden absorber al ritmo en que se genera. Algunos ejemplos que citó:
- Un líder técnico senior de una automotriz top-10 admitió sobre parte de su propio sistema: "No sé qué hace este código. La IA lo escribió por mí."
- Un banco entre los diez más grandes de Estados Unidos tuvo que revisar y corregir código en 90,000 repositorios después de descubrir una vulnerabilidad de cadena de suministro.
- En un caso de Mercari, un agente que arrancó investigando apenas dos ubicaciones de vulnerabilidades conocidas terminó encontrando 80 vulnerabilidades adicionales en el resto del código base.
El contexto de fondo: según cifras citadas en el mismo reporte, 72% de quienes trabajan en software lo hacen en empresas de 500 empleados o más —es decir, la mayoría de los desarrolladores no está escribiendo proyectos nuevos desde cero, está metiendo agentes a sistemas enormes que ya existían antes de que los agentes existieran.
Lo que esto significa para agencias y developers
Si tu agencia ya está vendiendo (o usando internamente) coding agents como una forma de acelerar entregas, este estudio es el que deberías revisar antes de prometer un cronograma basado solo en "ahora tenemos IA":
- Mide el tamaño real de la base de código antes de prometer velocidad. Un proyecto greenfield de 20,000 líneas y un sistema legado de 600,000 líneas no se comportan igual con el mismo agente, aunque uses el mismo modelo. El umbral de 400,000 líneas que encontró Sourcegraph es una señal concreta de cuándo necesitas infraestructura de contexto (indexado, búsqueda semántica, grafos de código) antes de soltar al agente.
- No confundas "el agente terminó la tarea" con "el agente entendió el sistema". El caso del líder técnico que no sabe qué hace su propio código es el riesgo real: entregas rápidas que nadie en el equipo —ni humano ni agente— puede mantener seis meses después.
- Revisa refactors multi-archivo con más cuidado que cambios aislados. El estudio es explícito: las tareas que tocan varios repositorios o archivos interdependientes son las que más fallan en silencio. Ahí es donde vale la pena un revisor humano antes de hacer merge, no en el cambio de una línea.
- No le des al agente todas las herramientas disponibles por default. El hallazgo de que "más herramientas = peor desempeño" debería cambiar cómo configuras el acceso de un agente: menos opciones, mejor curadas, casi siempre ganan.
La lección de fondo para agencias y equipos de producto en 2026 no es "los coding agents no sirven en bases de código grandes". Es que la velocidad de generación de código ya superó por mucho la velocidad con la que las empresas pueden indexar, entender y mantener ese código — y eso es exactamente el trabajo de infraestructura que una agencia seria debería estar vendiendo junto con la automatización, no después de que el cliente descubra 80 vulnerabilidades que nadie sabía que existían.
En Geek Vibes ayudamos a equipos a diagnosticar qué tan lista está su base de código para escalar el uso de agentes —y a construir la capa de contexto que les falta antes de que un refactor a medias se convierta en un incidente de seguridad. Si tu equipo está metiendo coding agents a un sistema que lleva años creciendo sin ese mapa, escríbenos a comercial@geekvibes.agency.
