Claude lidera el 26% de la I+D de Anthropic. ¿Quién revisa?

Anthropic afirma que Claude lideraba el 26 % de su trabajo interno de investigación y desarrollo en IA en una medición de agosto de 2026, bajo supervisión humana. El informe del 17 de septiembre no identifica trabajo plenamente autónomo entre las actividades medidas. Mi conclusión es que dirigir una investigación y verificar sus resultados deben medirse por separado. [1]

¿Qué significa que Claude lidere el 26 % de la investigación?

Según la clasificación de Anthropic, Claude dirige el trabajo mientras una persona lo supervisa. Eso es distinto de investigar sin intervención humana. Un sistema puede decidir cómo ejecutar una tarea y seguir dependiendo de otra persona para determinar si el resultado sirve. [1]

La conversación del 17 de septiembre en r/singularity se hizo eco del 26 %. Creo que es una buena razón para leer el informe original, sobre todo porque la palabra «liderar» invita a una interpretación más amplia de lo que exige la medición. Al oírla, un desarrollador puede imaginar una IA que elige un programa de investigación, ejecuta los experimentos y decide qué publicar. Son responsabilidades distintas. [2]

Así las separaría al evaluar un agente en mi trabajo. Es un marco de revisión propio, no la tabla oficial de Anthropic.

Delegar la fila central no resuelve las otras dos. Esa distinción también está detrás de mi análisis de los problemas de programación y supervisión de Opus 5: producir un resultado importante y facilitar que se pueda confiar en él son propiedades diferentes.

¿Cómo se midió el porcentaje?

Anthropic describe una estimación interna basada en registros de trabajo y una clasificación asistida por modelos. La ponderación utiliza el tiempo de las personas como aproximación y reparte el peso semanal de cada persona entre sus tareas. Sirve para seguir los cambios en la forma de trabajar, no para medir directamente las horas ahorradas. [1]

Ese denominador cambia mi lectura del titular. «La IA lidera una parte del trabajo» no puede convertirse sin más en «necesitamos esa proporción menos de personas». Para sostener lo segundo, querría saber qué hacen esas personas después de delegar, cuánto tiempo dedican a revisar y si la calidad o el volumen del trabajo aceptado han cambiado.

Imaginemos a un ingeniero que delega un experimento y pasa la tarde comprobando si las condiciones de la prueba eran válidas. El agente puede haber dirigido la ejecución mientras el ingeniero sigue dedicando bastante tiempo al proyecto. También podría revisar varios experimentos útiles en el tiempo que antes necesitaba para uno. Una clasificación de tareas, por sí sola, no distingue ambas situaciones.

Usaría el informe para plantear preguntas de evaluación más concretas, igual que uso las comparaciones de benchmarks de IA para decidir qué merece una prueba. El siguiente paso útil es relacionar la delegación con los resultados aceptados y el esfuerzo de revisión. De lo contrario, un equipo puede medir más actividad de IA sin saber si su trabajo ha mejorado.

¿Significa esto que la IA se mejora de forma autónoma?

En otro ensayo, When AI builds itself, Anthropic afirma que todavía no se ha alcanzado la mejora recursiva y que tampoco es inevitable. Además, señala la elección de objetivos de investigación y la evaluación de resultados como áreas en las que la experiencia humana sigue siendo importante. Este informe describe cómo se organiza la investigación; no demuestra que todo el ciclo de desarrollo funcione solo. [3]

La mejora recursiva exige algo más que una IA que aporte código al siguiente modelo. Lo interesante sería demostrar que esas mejoras permiten al sistema realizar otras nuevas con menos dependencia de las personas. Una contribución útil no demuestra por sí sola que exista ese proceso continuo. Examino esa misma distinción en el relato de Z.ai sobre el uso de GLM para optimizar software de inferencia.

Mi interpretación es que la presión inmediata recae en la verificación. Si resulta más fácil proponer un experimento, alguien todavía tiene que decidir si responde a la pregunta planteada. Una explicación convincente de una prueba mal diseñada puede complicar la revisión al añadir más material plausible que comprobar.

Por eso separaría el mecanismo que produce una respuesta de las pruebas utilizadas para aceptarla. En desarrollo de software, podría significar comprobar el comportamiento frente a requisitos y tests que no se hayan reescrito para acomodar el parche. En investigación, supone preguntar qué resultado pondría en duda la explicación propuesta. Son decisiones de evaluación, no hallazgos adicionales del informe de Anthropic.

¿Qué cambiaría en un flujo de trabajo de programación?

Definiría la revisión necesaria antes de delegar una tarea grande. El agente necesita un resultado esperado claro, pero quien revisa también necesita una forma de comprobar que es correcto. Me parece una respuesta más útil al informe que aumentar sin más el número de agentes.

En una investigación, pediría las pruebas que respaldan la conclusión y las contradicciones pendientes. Para un cambio de código, preguntaría qué comportamiento ha cambiado y cómo se ha comprobado. Después evaluaría si revisar exige menos esfuerzo que hacer el trabajo directamente, incluido el tiempo de corregir un error que al principio parecía convincente.

La misma pregunta corresponde al diseño de aplicaciones basadas en la OpenAI Agents API. Una aplicación puede delegar la ejecución y dejar la aceptación en manos de la persona responsable del resultado. Decidir dónde ocurre esa aceptación forma parte del diseño del producto.

En el próximo lanzamiento de un modelo, prestaría atención a lo que un revisor puede verificar tras una ejecución larga. Un modelo que hace más trabajo resulta útil; saber en qué partes se puede confiar determina cuánto de ese trabajo puedo aceptar.