OpenAI publicó un informe interno sobre cómo los agentes de código están cambiando la forma en que trabajan sus propios investigadores: Research acceleration: The view inside OpenAI. El material que hicieron público habla de uso de agentes, velocidad de experimentación, complejidad de las tareas y aceleración de la investigación. Simon Willison lo levantó el mismo día en su blog, que es la señal habitual de que algo vale la pena leer.
Aclaro algo antes de seguir: del anuncio circula el resumen y los ejes que OpenAI dice medir. Las cifras concretas no están en el material que tengo a mano, así que no las voy a citar ni a inventar. Lo que sí puedo analizar es qué eligieron medir, que muchas veces dice más que el número.
Por qué importa
La señal está en las métricas elegidas, no en el resultado. OpenAI no está contando líneas de código generadas ni pull requests mergeados: está contando velocidad de experimentación y complejidad de tarea. Eso es un cambio de unidad de medida.
Cuando una empresa mide líneas o commits, está tratando al agente como un tipeador más rápido. Cuando mide experimentos por unidad de tiempo, está tratando al agente como una forma de bajar el costo de probar una hipótesis. Son dos tesis de producto completamente distintas, y la segunda es mucho más incómoda para nuestra profesión, porque implica que el cuello de botella nunca fue escribir el código.
Que la empresa que vende los modelos publique sus propios datos internos es, obviamente, marketing. Pero el marketing también revela hacia dónde empujan el producto. Y acá empujan hacia agentes que sostienen tareas largas, no hacia autocompletado más rápido.
Qué cambia en la práctica
Si tomás en serio la idea de que la métrica es "experimentos por semana" y no "código por hora", cambian varias decisiones concretas en un equipo normal, sin GPUs ni laboratorio de investigación.
| Dimensión | Agente como tipeador | Agente como acelerador de experimentos |
|---|---|---|
| Qué medís | Código producido | Hipótesis probadas y descartadas |
| Cuello de botella | Escribir | Verificar y decidir |
| Inversión clave | Mejor prompt | Tests, entornos reproducibles, observabilidad |
| Riesgo dominante | Código con bugs | Conclusiones mal fundadas |
| Rol del senior | Revisar diffs | Diseñar el criterio de éxito |
La consecuencia práctica más directa: el valor se mueve de la generación a la verificación. Si un agente te permite probar cinco enfoques en el tiempo en que antes probabas uno, tu limitante pasa a ser cuán rápido y cuán confiablemente podés decidir cuál sirvió. Un equipo sin suite de tests decente, sin entorno reproducible y sin métricas de producto no acelera nada: multiplica ramas sin criterio para podarlas.
El flujo que a mí me terminó funcionando se parece más a esto que a un chat:
┌────────────────────┐
│ Hipótesis + criterio│
│ de éxito │
└─────────┬──────────┘
│
▼
┌────────────────────┐ ┌──────────────────┐
│ Agente implementa │──►│ Rama descartable │
└─────────┬──────────┘ └──────────────────┘
│
▼
┌────────────────────┐
│ Verificación auto │ tests, tipos, lint,
│ (sin humano) │ benchmark, build
└─────────┬──────────┘
│ pasa
▼
┌────────────────────┐
│ Revisión humana │ ¿resolvió el problema
│ del criterio │ correcto?
└────────────────────┘
Lo importante del diagrama es dónde está el humano: al principio definiendo qué cuenta como éxito, y al final juzgando si el criterio se cumplió. En el medio no aporta demasiado leer cada línea. Si tu proceso te obliga a leer todo el diff con lupa para dormir tranquilo, el problema no es el agente: es que no tenés verificación automática suficiente.
Otra cosa que cambia: las ramas se vuelven baratas y desechables. Antes descartar dos días de trabajo dolía. Ahora descartar un intento de veinte minutos es parte del método. Eso reordena el trabajo hacia "probá tres, quedate con uno" en vez de "discutamos cuál conviene".
Cuándo NO usarlo
Acá está la parte que los anuncios corporativos no escriben.
- Cuando no tenés cómo verificar. Un agente que produce diez veces más código en una base sin tests te da diez veces más deuda con la misma confianza que antes. La aceleración es real solo del lado donde hay un oráculo automático. En OpenAI ese oráculo existe: un experimento de investigación da un número. En un CRUD de negocio con reglas ambiguas, no.
- Cuando el problema es de decisión, no de implementación. Si el equipo no sabe qué construir, generar cinco versiones de lo indefinido no ayuda. Multiplica el trabajo de descarte.
- Cuando el dato es de OpenAI sobre OpenAI. Sus investigadores tienen contexto, tooling interno, modelos sin límites de cuota y problemas con criterio de éxito medible. Extrapolar esos resultados a un equipo de cinco personas con un legacy de 2018 es un salto que el informe no autoriza. Todavía no vi evidencia pública independiente que replique esos números fuera de la casa.
- Cuando hay dominio regulado o sensible. Si tocás datos personales, pagos o salud, la velocidad de experimentación no es la métrica; la trazabilidad sí. Ahí conviene un flujo más lento y más auditado.
- Cuando el costo legal del contexto todavía es incierto. El mismo día del informe, The Verge reportó que Seattle Times y Newsday demandaron a OpenAI y Microsoft por infracción de copyright, sumándose a demandas previas del New York Times, Ziff Davis, Merriam-Webster y Britannica. No cambia si el agente te sirve técnicamente, pero sí es un factor de riesgo si estás decidiendo apoyar tu producto entero sobre un único proveedor.
Ese último punto conecta con algo más grande. Corea del Sur arrancó la iniciativa "AI for All" justamente para no depender de proveedores extranjeros: exige que al menos el 50% del servicio use modelos nacionales soberanos y otro 30% modelos coreanos de empresas distintas a las que prestan el servicio. Un Estado está tratando la dependencia de un proveedor como riesgo estructural. A escala de tu arquitectura, la lectura es la misma: abstraé el proveedor detrás de una interfaz propia antes de que la decisión te la tome un juicio o un cambio de precios.
Qué haría hoy
Tres cosas, en orden. Primero, invertiría en verificación automática antes que en prompts: tests, tipos estrictos, entorno reproducible. Es lo que convierte la velocidad del agente en algo aprovechable y no en ruido.
Segundo, cambiaría la métrica del equipo. Si hoy medís tickets cerrados, empezá a medir cuántas hipótesis probaste y descartaste por sprint. Es la lectura práctica del informe de OpenAI para un equipo que no hace investigación.
Tercero, mantendría el acceso al modelo detrás de una capa propia, con al menos un proveedor alternativo probado. No por ideología: por el mismo motivo por el que no hardcodeás una base de datos.