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

Una historia circula sin parar: Rakuten le dio a un agente de programación con IA una sola tarea dentro de un gran proyecto de código abierto, se fue, y volvió horas después a código que funcionaba. Es una buena historia. Es mayormente cierta. Y la parte que todos repiten, las horas y la cifra de precisión, es la menos interesante. Lo interesante es por qué funcionó siquiera, y qué dice eso sobre el trabajo de la ingeniería hoy.

Esta es una perspectiva de ingeniería, no un discurso de venta. Dirigimos agentes de programación en trabajo real con clientes cada semana, así que esto es menos una opinión caliente que una descripción de cómo cambió el trabajo de verdad.

¿Qué pasó realmente en Rakuten?

Aquí están los hechos, formulados con cuidado, porque la versión viral infla uno de ellos. En el lanzamiento de Claude Opus 4 en mayo de 2025, Anthropic dijo que Rakuten había validado el modelo con una refactorización de código abierto exigente que corrió de forma independiente durante unas siete horas. El detalle llegó después, en la propia historia de cliente de Rakuten: un ingeniero apuntó Claude Code a vLLM, el motor de inferencia de código abierto, y le pidió implementar un método específico de extracción de vectores de activación. El resultado, según se informa, alcanzó un 99,9% de precisión numérica frente a la implementación de referencia.

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

• No fue desatendido. El ingeniero describió haber dado orientación ocasional durante esas horas. "Corrió siete horas de forma independiente" es real e impresionante. "Totalmente autónomo, cero humanos" no es lo que pasó.
• 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.

Y la cifra que más le gusta a internet, que vLLM tiene "12,5 millones de líneas de código", es de la que hay que desconfiar más. Aparece en el propio texto de Rakuten, así que la gente la cita de buena fe, pero está desviada por un factor de unas veinte veces. El núcleo de vLLM ronda las 84.000 líneas de Python, y menos de 600.000 líneas en todos los lenguajes. Solo llegas a 12,5 millones contando cosas en las que nadie razona: todo el historial de git, cada repositorio relacionado, kernels incorporados y generados. El punto real sobrevive a la corrección sin problema: Claude navegó una base de código grande, multilenguaje y que nunca había visto, en Python, CUDA y C++, y colocó un cambio en el lugar correcto. Eso es lo impresionante. Nunca fue el número de líneas.

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

Si reduces la demo a su esencia, la lección es casi aburrida. Un ingeniero senior que ya conocía vLLM también podría haber escrito ese método. Un recién contratado también, con el tiempo, tras semanas de caminos equivocados. La diferencia entre el senior y el novato nunca fue inteligencia bruta. Fue cuánto de la base de código podía sostener cada uno en la cabeza y razonar a la vez.

Ese es el cuello de botella en la mayor parte del trabajo de software. No "¿puede una persona lista resolver esto?", sino "¿puede alguien sostener suficiente de este sistema en la memoria de trabajo para hacer el cambio correcto en el lugar correcto sin romper otros tres?". En una base de código grande eso es genuinamente difícil, y lo es de una forma que no tiene nada que ver con lo listo que seas.

¿Qué significa realmente "la IA no sufre fatiga de contexto"?

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 de programación no se cansa de esa forma. Puede mantener delante la porción relevante de una base de código grande y razonar sobre ella con la misma consistencia en la hora siete que en el minuto diez. Ese es el verdadero desbloqueo de la historia de Rakuten. No que el modelo sea más listo que un ingeniero senior, sino que no se degrada a lo largo de una tarea larga y cargada de contexto como lo hace una persona. Contexto sostenido, no inteligencia superior.

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.

¿Esto hace desaparecer a los ingenieros?

No, y quien predice eso suele estar vendiendo algo. Lo que hace es mover el trabajo. Los ingenieros que están escalando ahora mismo en su mayoría no son los que escriben cada línea a mano. Son los que se volvieron buenos dirigiendo agentes, revisando la salida con ojo crítico y reconociendo el momento en que un agente está a punto de hacer algo estúpido.

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?

La delegación se convirtió en el nuevo trabajo profundo. Las horas profundas y valiosas solían ser las que pasabas con la cabeza metida escribiendo la función difícil. Cada vez más son las que pasas acotando una tarea con precisión, ensamblando el contexto correcto y revisando lo que vuelve con ojo afilado. Es un músculo genuinamente distinto, y muchos ingenieros fuertes aún no lo han desarrollado, porque durante toda su carrera el cuello de botella fue teclear la solución, no especificarla.

La buena ingeniería en este modo se ve así: una tarea acotada y bien definida; el contexto correcto entregado al agente por adelantado; pruebas y guardarraíles que atrapan la respuesta equivocada automáticamente; y un humano que revisa como un senior, no como un sello de goma. El agente es rápido e incansable. El ingeniero es quien decide qué significa "correcto" y verifica que realmente se llegó allí.

"El agente no se cansa de sostener toda la base de código en la cabeza. Tú sí. Ese es todo el cambio. Tu trabajo pasó de escribir cada línea a decidir qué significa correcto y atraparlo cuando el agente se equivoca."

¿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 con precisión. "Implementa este método específico, ajustándote a esta referencia" supera a "mejora la capa de inferencia". Una tarea precisa fue lo que hizo posibles siete horas desatendidas. Una vaga produce siete horas de caminos equivocados con confianza.
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. La razón por la que Rakuten pudo confiar en la salida fue una referencia contra la que comprobar. Reprodúcelo: una suite de pruebas, una referencia, un guardarraíl que falle ruidosamente cuando la respuesta es incorrecta.
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.