El cuello de botella del software nunca fue la inteligencia. Fue el contexto.

Un caso de un proveedor circula con frecuencia: Rakuten dio a un agente de programación con IA una tarea concreta en un gran proyecto de código abierto y reportó un resultado funcional tras una sesión larga. El hecho es real, pero no es un estudio controlado de productividad ni demuestra una teoría general sobre agentes. La lección útil es más estrecha: tareas acotadas, contexto relevante del repositorio, comprobaciones ejecutables y revisión humana pueden sostener trabajo útil en un sistema desconocido.

Esta es una perspectiva de ingeniería, no un discurso de venta. Los hechos y fuentes se comprobaron el 2 de septiembre de 2026. La capacidad y productividad varían según modelo, herramienta, repositorio, tarea, revisor y método de evaluación.

¿Qué pasó realmente en Rakuten?

En el lanzamiento de Claude Opus 4 en mayo de 2025, Anthropic dijo que Rakuten había probado el modelo en una refactorización de código abierto de unas siete horas. En el caso de cliente de Anthropic, un ingeniero pidió a Claude Code implementar en vLLM un método específico de extracción de vectores de activación. El relato informa de un 99,9% de precisión numérica frente a una referencia. Es evidencia de cliente publicada por el proveedor, no un benchmark independiente.

Dos correcciones honestas, porque preferimos tener razón antes que ser dramáticos:

• No se demostró como totalmente desatendido. El relato dice que el ingeniero dio orientación ocasional. Trate "autónomo" como descripción del editor, no como prueba de cero intervención humana.
• El 99,9% es una métrica estrecha. Es la precisión numérica de la salida de un método frente a una referencia, no una afirmación general de que el agente acierta el 99,9% en todo. Útil, específica, y fácil de malinterpretar como titular.

El mismo relato llama a vLLM una base de código de 12,5 millones de líneas, pero no publica método de recuento, revisión, repositorios incluidos ni tratamiento del código generado o vendorizado. No use esa cifra como tamaño medido. La afirmación respaldada es que la tarea afectó a un sistema abierto grande y multilenguaje y a una implementación de referencia concreta.

¿Por qué el contexto fue el verdadero cuello de botella, y no la inteligencia?

El caso respalda una hipótesis práctica, no una ley universal: el contexto del repositorio y la retroalimentación pueden ser cuellos de botella incluso cuando un modelo genera código plausible. Los ingenieros también aportan conocimiento tácito, historia de arquitectura, criterio de producto y responsabilidad que no se capturan cargando más archivos.

La pregunta útil no es si contexto o inteligencia son el único cuello de botella. Es si el agente recibió código, restricciones, herramientas, pruebas y feedback relevantes, y si el revisor puede detectar fallos que las comprobaciones omiten.

¿Cuáles son los límites del contexto en ejecuciones largas de agentes?

Los humanos somos malos sosteniendo contexto grande durante tramos largos, y no porque seamos torpes. Nos cansamos. Olvidamos lo que leímos cuarenta archivos atrás. Hacemos una pausa y perdemos el hilo. Cometemos pequeños errores al final de una sesión larga que jamás cometeríamos en la primera hora. Sostener un modelo mental extenso de un sistema agota, y el agotamiento es de donde salen los bugs.

Un agente no experimenta fatiga humana, pero eso no implica razonamiento estable durante siete horas ni uso perfecto de una ventana grande. Los modelos pueden perder información, sobreponderar lo reciente, acumular errores o consumir su presupuesto de contexto. La investigación sobre contexto largo muestra que el rendimiento puede depender de dónde aparece la información relevante. Los agentes largos necesitan selección, resúmenes, checkpoints, pruebas y recuperación.

La trampa, y es real, es que el agente solo razona bien sobre el contexto que de hecho recibe. Apúntalo a los archivos equivocados, o niégale las restricciones que importan, y construirá con confianza lo incorrecto sin cansarse. Darle el contexto correcto es ahora la habilidad. Escribimos sobre el lado del coste de esa disciplina en cómo reducir los costes de tokens de LLM en 2026: gestionar el contexto, no solo gastar tokens, es la mayor parte del juego.

Para una arquitectura concreta que separa memoria duradera, estado compartido, razonamiento acotado e intención, consulta nuestro análisis verificado del context layer de Meterless.

Si faltan relaciones entre archivos, nuestra review de Graphify para compradores compara el grafo del código con búsqueda y RAG y propone una prueba medible de dos semanas.

Cuando el siguiente límite sea preparar repositorios e integrar cambios de agentes en paralelo, usa nuestra guía de decisión Git worktrees vs Jujutsu para elegir entre una base Git optimizada y un piloto medible de Jujutsu.

Para la capa de herramientas que deja ese contexto escrito entre sesiones, mira nuestro review de Graft sobre si el mapa del repo pertenece a Git o sigue siendo una caché local reconstruible.

¿Esto hace desaparecer a los ingenieros?

Este caso no puede responder una pregunta laboral. Muestra un flujo técnico, no un resultado del mercado ni una ganancia universal de productividad. Los agentes pueden desplazar trabajo hacia diseño de tareas, preparación de contexto, supervisión y revisión, con efectos distintos por equipo y tarea.

Esa última habilidad está infravalorada. Un agente produce código seguro de sí mismo, bien formateado y plausible que es sutilmente incorrecto, y un revisor junior lo deja pasar porque parece correcto. Atrapar eso requiere exactamente el criterio que construyen los años escribiendo código a mano. La experiencia no se vuelve inútil. Cambia de "yo escribo la solución" a "reconozco la solución equivocada antes de que llegue a producción". Si quieres una versión concreta de cómo es esa revisión, nuestra lista de preparación para producción de código vibe es la lista contra la que de verdad contrastamos la salida del agente.

¿Cómo se ve la buena ingeniería cuando los agentes escriben el código?

Delegar puede convertirse en trabajo de ingeniería concentrado: acotar la tarea, reunir evidencia, definir criterios de aceptación y revisar el resultado. No elimina el conocimiento de implementación, porque el revisor debe entender el sistema y las consecuencias.

La buena ingeniería usa una tarea acotada, contexto relevante, herramientas con privilegios mínimos, comprobaciones reproducibles, un diff revisable y una decisión humana cualificada. Las pruebas reducen riesgo, pero no demuestran más de lo que cubren.

"Un agente no experimenta fatiga humana, pero sigue teniendo contexto acotado y modos de fallo. La ventaja viene de seleccionar evidencia, definir controles y revisar el resultado, no de suponer que sostiene todo el repositorio a la perfección."

¿Cómo deberías reorganizar tu flujo de trabajo en torno a los agentes de programación?

Si quieres el resultado de Rakuten en tu propio trabajo, los movimientos que importan, en orden:

1. Acota la tarea. "Implementa este método según esta referencia" es más comprobable que "mejora la capa de inferencia". La precisión reduce ambigüedad, no garantiza éxito desatendido.
2. Dale el contexto correcto, no todo. Apunta el agente a los archivos, interfaces y restricciones que de verdad importan. Más contexto no es mejor; el contexto correcto lo es. Ahí vive ahora la mayor parte de la habilidad.
3. Pon límites con pruebas y guardarraíles. Use pruebas relevantes, referencias, análisis estático y controles de seguridad. Un resultado aprobado es evidencia dentro de la cobertura, no una prueba absoluta.
4. Revisa como un senior, no como un sello de goma. Lee el diff buscando los errores sutiles y de apariencia plausible, los que compilan y pasan un vistazo superficial. Es la hora de mayor impacto que invertirás.
5. Mantén la propiedad y el conocimiento en casa. Un agente que entrega código que nadie en tu equipo entiende es una dependencia, no una victoria. Asegúrate de que un humano sea dueño y pueda explicar lo que se entregó.

Nada de esto es exótico. Es la misma disciplina que la buena ingeniería siempre necesitó, reponderada: menos tiempo produciendo el código, mucho más tiempo especificándolo y verificándolo.

El trabajo visual necesita el mismo tratamiento. Nuestra guía del sistema de diseño para Claude Code explica cómo convertir ejemplos aprobados, evidencia de marca y reglas de implementación en contexto duradero del repositorio, sin repetirlos en cada prompt.

Semaprax es una respuesta de investigación a este problema de contexto, no prueba de que un lenguaje nuevo lo resuelva. El benchmark de Semaprax congela un contrato pequeño de contexto estructurado y publica sus límites. Todavía no mide tokens, calidad de tarea ni coste a escala de repositorio.