Claude Code acelera la investigación, pero debilita la apropiación del código
Anthropic ha llevado Claude Code más allá del código repetitivo, pero un investigador informa de una inversión preocupante: mayor rendimiento acompañado de un dominio más débil sobre sus propios experimentos. El relato sitúa un problema humano en el centro del horizonte de Anthropic. Un agente de programación puede producir software de investigación aceptable mientras modifica silenciosamente la forma en que su operador entiende ese software.
La preocupación surgió en una publicación de Reddit del 31 de agosto escrita por un estudiante de doctorado de tercer año que trabaja en procesamiento del lenguaje natural e interpretabilidad. Claude Code ahora se encarga de la estructura inicial de los experimentos, la refactorización de dataloaders, la depuración inicial y los scripts de análisis. El estudiante revisa y aprueba los diffs, pero detecta problemas más tarde porque el código base le resulta poco familiar.
Esto no demuestra que Claude Code perjudique de forma generalizada la calidad de la investigación. Es una experiencia autodeclarada, y ni la identidad del autor ni su historial experimental han sido verificados de forma independiente. Aun así, los propios estudios de Anthropic describen el mismo patrón de delegación a escalas mucho mayores. Los humanos deciden cada vez más qué debería suceder, mientras Claude decide cómo implementarlo.
Esa división parece eficiente cuando las pruebas ofrecen respuestas rápidas y fiables. El código de investigación es más difícil porque un programa que supera las pruebas aún puede codificar la población, la métrica, la política de semillas, la línea base o la comparación estadística equivocadas. Por tanto, la cuestión central no es Claude Code frente a otro agente de programación. Es la velocidad de implementación frente a la capacidad del investigador para explicar cada decisión relevante.
Un flujo de trabajo de investigación cruzó una frontera invisible
El cambio significativo no fue que Claude Code escribiera más código, sino que asumiera responsabilidad por decisiones incorporadas dentro del experimento.
El flujo de trabajo del estudiante comenzó con código repetitivo de argparse, gráficos y trabajo de configuración. Esas tareas suelen traducir una decisión ya establecida en sintaxis repetitiva. Delegarlas puede ahorrar tiempo sin transferir demasiado juicio científico.
La frontera se desplazó gradualmente. La estructura inicial de los experimentos determina cómo se crean y comparan las condiciones. Los dataloaders determinan qué ejemplos llegan a un modelo, cómo se transforman y si puede producirse fuga de información. La depuración determina qué comportamientos inesperados reciben atención. Los scripts de análisis deciden cómo las mediciones en bruto se convierten en conclusiones visibles.
Cada tarea puede parecer implementación mientras transporta parte del método. Una refactorización de dataloader puede alterar el orden de muestreo, el padding, el filtrado o el procesamiento por lotes. Un script de análisis puede omitir ejecuciones fallidas o agregar resultados en el nivel equivocado. Una métrica puede implementarse exactamente como se solicitó y, aun así, medir algo distinto de la pregunta de investigación.
El relato original del investigador describe con claridad la desconexión resultante. Cuando antes un resultado parecía sospechoso, el estudiante tenía una intuición sobre qué línea podía ser responsable. Ahora la investigación comienza como una auditoría del repositorio de otra persona.
Esa distinción importa más que si cada función generada parece limpia. El software de investigación no es solo un instrumento que produce un resultado. Escribirlo también crea un modelo mental del flujo de datos, los supuestos, los cambios de estado y los puntos de fallo.
La revisión de diffs no siempre reconstruye ese modelo. Un revisor puede verificar que cada cambio parece plausible sin reconstruir el comportamiento combinado de varios módulos. La dificultad aumenta cuando un agente realiza ediciones coordinadas en configuración, preprocesamiento, entrenamiento, evaluación y visualización.
La discusión en Reddit también muestra que los investigadores trazan la frontera de forma diferente. Un comentarista limitó el código generado al análisis y la visualización. Otro afirmó no escribir nada del código, pero describir el comportamiento esperado con un nivel detallado. Otros sostuvieron que la propia implementación sigue siendo una forma importante de comprender un método.
Estos comentarios son anécdotas, no una comparación controlada. Su valor reside en revelar una elección aún no resuelta. Los investigadores coinciden en que los agentes pueden eliminar trabajo tedioso, pero no están de acuerdo sobre qué tareas de implementación son intelectualmente prescindibles.
Por tanto, el acontecimiento es una disputa sobre fronteras más que el lanzamiento de un producto. Claude Code se ha vuelto lo bastante capaz como para que los usuarios puedan delegar rutas técnicas completas antes de que las instituciones hayan definido prácticas de verificación aceptables. Eso crea la tensión del artículo: el resultado llega antes de que se haya reconstruido la apropiación.
El horizonte de Anthropic ahora alcanza la ejecución científica
Los datos de uso de Anthropic sugieren que la delegación de extremo a extremo se está normalizando, aunque una ejecución exitosa no establece la validez científica.
Anthropic estudió aproximadamente 400.000 sesiones de Claude Code que involucraban a unas 235.000 personas entre octubre de 2025 y abril de 2026. Su estudio sobre programación agéntica concluyó que los usuarios solían tomar la mayoría de las decisiones de planificación, mientras Claude tomaba la mayoría de las decisiones de ejecución.
La distinción suena tranquilizadora porque los humanos conservan el objetivo. Resulta menos tranquilizadora cuando las decisiones de implementación influyen en qué objetivo prueba realmente el experimento. Un investigador puede solicitar una reproducción fiel mientras un agente selecciona una dependencia, un parámetro predeterminado o una ruta de preprocesamiento que modifica la pregunta operativa.
Anthropic informó de que la proporción de sesiones dedicadas a la depuración cayó casi a la mitad durante el periodo de observación de siete meses. El uso se desplazó hacia la ejecución de código, el despliegue de sistemas, el análisis de datos y la producción de documentos sin código. El valor estimado de una tarea típica también aumentó aproximadamente un 25 por ciento.
Estas cifras describen el uso observado del producto, no el aprendizaje medido ni la fiabilidad de la investigación. La definición de éxito se basó en señales verificables, como pruebas superadas o trabajo confirmado. Esas señales son útiles para tareas de software, pero no pueden determinar si un experimento aísla el mecanismo causal previsto.
El estudio también concluyó que la experiencia en el dominio seguía siendo valiosa. Los expertos tenían más éxito y se recuperaban con mayor eficacia de los malentendidos. Sin embargo, la diferencia de rendimiento entre expertos y usuarios intermedios fue modesta.
Ese hallazgo respalda ambos lados del debate. Los agentes de programación pueden ayudar a especialistas de un área a ejecutar trabajo técnico sin una profundidad tradicional en software. Sin embargo, la recuperación ante errores sigue dependiendo de reconocer cuándo el agente ha malinterpretado el dominio.
El horizonte de Anthropic cobra especial relevancia en la investigación de aprendizaje automático porque los experimentos contienen múltiples fuentes de incertidumbre que interactúan entre sí. La inicialización del modelo, la composición del conjunto de datos, el diseño de la evaluación, la precisión numérica y el comportamiento del hardware pueden influir en los resultados. Una batería de pruebas en verde cubre solo los supuestos que su autor anticipó.
El agente también puede hacer que un flujo de trabajo parezca más coherente que el razonamiento subyacente. Una nomenclatura consistente, funciones modulares y comentarios claros mejoran la legibilidad. No garantizan que la condición de control seleccionada responda a la pregunta científica prevista.
Esta diferencia separa la corrección del software de la corrección epistémica. La corrección del software pregunta si la implementación sigue una especificación. La corrección epistémica pregunta si la especificación y la implementación, juntas, respaldan la conclusión declarada.
Los grupos de investigación tradicionalmente distribuyen esta carga entre autores, asesores, revisores y esfuerzos de replicación. La programación agéntica inserta a otro responsable de decisiones en la cadena, pero sin responsabilidad por la afirmación publicada. El investigador sigue siendo responsable incluso cuando el agente proporcionó la mayoría de los detalles de implementación.
Por tanto, la evidencia de Anthropic confirma la escala del cambio sin resolver su riesgo central. Los agentes ejecutan tareas más amplias y los usuarios experimentados suelen dirigirlos de forma eficaz. La pregunta abierta es si los usuarios conservan suficiente comprensión procedimental para cuestionar un resultado plausible pero engañoso.
Más producción no significa mayor control experimental
La disyuntiva central es la productividad inmediata frente a la construcción más lenta de una intuición diagnóstica.
Anthropic encuestó a 132 de sus ingenieros e investigadores en agosto de 2025, entrevistó a 53 participantes y examinó 200.000 transcripciones internas de Claude Code. Los empleados declararon usar Claude en el 60 por ciento de su trabajo y obtener aproximadamente un 50 por ciento más de productividad.
Estas cifras proceden de la plantilla de Anthropic, por lo que no deben tratarse como mediciones independientes de la productividad académica. Aun así, revelan la rapidez con la que la delegación puede expandirse dentro de una organización técnicamente sofisticada.
Según el análisis del entorno laboral de Anthropic, los empleados delegaban habitualmente tareas aburridas, bien definidas, de bajo riesgo o fáciles de verificar. Entre los ejemplos aparecían la depuración desechable y el código de investigación.
Esa categoría es donde el conflicto actual se vuelve más agudo. El código de investigación suele llamarse desechable porque no se mantiene como un producto orientado al cliente. Sin embargo, un script breve puede producir la figura, el benchmark o la ablación que sustenta la afirmación central de un artículo.
Anthropic concluyó que los empleados creían que solo entre el cero y el 20 por ciento de su trabajo podía delegarse por completo, pese a usar Claude con frecuencia. La supervisión activa seguía siendo habitual, especialmente en tareas de alto riesgo. Los empleados también expresaron preocupación por perder práctica al escribir y criticar código.
La experiencia del estudiante de doctorado se asemeja a ese patrón, con una advertencia adicional. La supervisión mediante la aprobación de diffs no preservó la representación mental construida durante la implementación. El estudiante podía evaluar cambios locales mientras perdía una comprensión integrada del sistema.
Esto es deuda de comprensión, una obligación acumulada en el operador y no solo en el repositorio. El código puede mantenerse organizado mientras la capacidad del investigador para predecir su comportamiento se deteriora. La deuda se hace visible cuando los resultados se salen de lo esperado.
La deuda técnica tradicional suele generar costes de mantenimiento evidentes. La deuda de comprensión puede permanecer oculta porque el pipeline sigue funcionando. Sale a la luz durante fallos inusuales, preguntas de revisores, intentos de replicación o cambios en el diseño experimental.
El beneficio de velocidad es real. Un agente puede generar barridos de parámetros, funciones de gráficos, fixtures de pruebas y variantes de configuración en cuestión de minutos. También puede inspeccionar registros en muchos archivos sin fatigarse por búsquedas repetitivas.
Sin embargo, la velocidad cambia la asignación de atención del investigador. Una implementación más rápida fomenta más experimentos, más ramas y más mediciones. El volumen total puede crecer más rápido que la capacidad del investigador para inspeccionar los supuestos.
Ese desequilibrio altera el significado del rendimiento. Diez ejecuciones adicionales son útiles cuando prueban una secuencia deliberada de hipótesis. Son menos informativas cuando el investigador no puede explicar por qué difieren las configuraciones o qué ruta produjo una cifra reportada.
La presión recae con mayor fuerza sobre los investigadores de posgrado y los laboratorios pequeños. Los incentivos de publicación recompensan la producción, mientras que los asesores rara vez tienen tiempo para inspeccionar cada implementación generada. Un competidor más rápido puede explorar más ideas y enviar antes.
La respuesta obligada no consiste simplemente en rechazar la asistencia de IA. Los investigadores que abandonan los agentes de programación pueden perder tiempo en tareas que no mejoran el juicio científico. La respuesta más difícil es separar la implementación que solo expresa una decisión de la implementación que la toma silenciosamente.
Esa separación debe ocurrir antes de la generación, no después de que aparezca un resultado sospechoso. De lo contrario, la implementación de trabajo del agente se convierte en la especificación predeterminada. El investigador entonces revisa desviaciones respecto de las decisiones del agente, en lugar de definir las decisiones de forma independiente.
Claude Code puede reproducir resultados sin apropiarse de la pregunta
La evidencia de una ejecución sólida hace que el control humano sobre las hipótesis, las métricas y la interpretación sea más importante, no menos.
Un preprint de 2026 presentó SocSci-Repro-Bench, un benchmark construido a partir de 221 tareas de reproducción en 54 artículos de ciencias sociales. Los investigadores evaluaron Claude Code y OpenAI Codex utilizando materiales de estudios con condiciones de reproducibilidad conocidas.
El benchmark de reproducibilidad concluyó que ambos agentes reprodujeron una proporción considerable de hallazgos publicados. Claude Code tuvo un mejor rendimiento general, aunque los resultados variaron según el lenguaje de programación y el tipo de repositorio.
Esto es significativo porque la reproducción exige más que generar una función aislada. Un agente debe inspeccionar código existente, gestionar dependencias, diagnosticar fallos, ejecutar análisis y vincular los resultados con las afirmaciones. Estas tareas se parecen mucho a aquellas que los investigadores delegan cada vez más.
El benchmark también identificó un límite directamente relevante para la investigación original. Un encuadre sutil del prompt podía orientar a los agentes hacia búsquedas confirmatorias de especificaciones. Una búsqueda confirmatoria explora decisiones analíticas que respaldan un resultado preferido, en lugar de probar alternativas de forma neutral.
El agente no necesita fabricar datos para introducir sesgo. Puede responder de forma útil a la dirección implícita en un prompt. Una solicitud para “encontrar por qué desapareció el efecto” plantea la ausencia del efecto como un problema técnico, en vez de como un resultado potencialmente válido.
Este mecanismo complica el consejo habitual de inspeccionar el código generado. Cada decisión individual puede parecer razonable. El sesgo puede surgir de la secuencia de decisiones, incluidas las exclusiones, transformaciones, reglas de detención e intentos repetidos de análisis.
Por ese motivo, los artefactos de investigación más determinantes deben seguir siendo especificaciones redactadas por humanos, incluso cuando un agente las implemente. Entre ellos se incluyen la hipótesis, los límites del conjunto de datos, la métrica principal, el arnés de evaluación, la selección de líneas base, las reglas de exclusión y los criterios de interpretación.
La autoría humana no exige escribir manualmente cada línea. Significa que el investigador se compromete con el comportamiento previsto antes de pedir al agente que lo implemente. Un documento de diseño en lenguaje sencillo, invariantes comprobables o un plan de análisis preregistrado pueden establecer ese punto de referencia.
Después, el investigador debe pedir a Claude Code que exponga las decisiones relevantes. Una descripción útil de los cambios debería identificar valores predeterminados modificados, filtrado de datos, niveles de agregación, gestión de estados aleatorios y cambios de dependencias. Un resumen genérico de los archivos editados no es suficiente.
La ejecución independiente también importa. La persona o el proceso que comprueba el resultado no debería depender únicamente de explicaciones generadas por el mismo agente que escribió el código. Un cálculo pequeño hecho a mano, un fixture congelado o una segunda implementación pueden poner a prueba la métrica central.
Esto se asemeja a la lógica de un sistema de conocimiento personal. El objetivo no es recopilar más texto generado. Es preservar el razonamiento que conecta una pregunta, una decisión, un artefacto y un resultado.
Los registros del agente pueden respaldar ese historial, pero los registros por sí solos son demasiado detallados y dependen demasiado del contexto conversacional. Los equipos de investigación necesitan registros concisos de decisiones que expliquen por qué se tomó una elección y qué evidencia la invalidaría.
Por lo tanto, el rendimiento de Claude Code en tareas de reproducción no resuelve la cuestión de la autoría. Muestra que los agentes pueden convertirse en ejecutores competentes de flujos de trabajo computacionales. La competencia de ejecución aumenta la necesidad de una explicación independiente de la intención científica.
La evidencia todavía presenta lagunas importantes
Ni una queja viral ni las métricas de éxito de Anthropic pueden indicar si los agentes de programación mejoran la fiabilidad de la investigación original en aprendizaje automático.
La cuenta de Reddit se basa en un testimonio personal y apareció el mismo día que este análisis. El autor describe un flujo de trabajo que parece real, pero el repositorio subyacente, el historial de errores y el cambio de productividad no están disponibles. Los comentaristas ofrecen experiencias contrastantes sin resultados estandarizados.
Los estudios de Anthropic son más amplios, pero responden preguntas distintas. La finalización de sesiones, el código confirmado y las pruebas aprobadas miden si los usuarios lograron un objetivo operativo. No miden si la conclusión de un artículo resistió una réplica independiente.
La encuesta interna sobre el lugar de trabajo se basa en parte en estimaciones de empleados. Los participantes también trabajan en la empresa que desarrolla Claude, con un acceso inusualmente sólido a modelos, infraestructura y colegas. Sus resultados pueden no trasladarse a un estudiante de posgrado que mantiene por sí solo un repositorio experimental.
La encuesta de científicos sociales cuantitativos ofrece una perspectiva académica más amplia. Anthropic consultó a 1.260 investigadores durante febrero y marzo de 2026. El ochenta y uno por ciento había probado chatbots de IA para investigación, pero solo el 20 por ciento utilizaba regularmente agentes de programación integrados en terminales.
Entre los usuarios de agentes de programación, el 86 por ciento declaró usar Claude Code, mientras que el 31 por ciento declaró usar Codex. Los encuestados podían utilizar múltiples herramientas. La encuesta sobre adopción entre investigadores también concluyó que los usuarios publicaban más documentos de trabajo y propuestas de subvención que no usuarios comparables.
Anthropic advirtió explícitamente que esta relación no establece causalidad. Los adoptantes tempranos podrían ya ser más productivos, estar mejor financiados o tener mayor confianza técnica. La muestra también fue reclutada para un estudio que ofrecía acceso a Claude, lo que podría favorecer a investigadores interesados en la IA.
La evidencia más importante que falta es longitudinal y basada en resultados. Los investigadores necesitan comparaciones controladas que midan la detección de errores, la comprensión metodológica, el tiempo para reparar experimentos defectuosos, el éxito de las réplicas y la calidad de la incertidumbre comunicada.
Las medidas de productividad también deben distinguir el volumen de ejecución del conocimiento útil. Más experimentos pueden mejorar el descubrimiento, pero también pueden aumentar los riesgos de pruebas múltiples y sobrecargar la revisión por pares. Un conjunto de resultados mayor no equivale automáticamente a una contribución más sólida.
El informe de riesgos de Anthropic de febrero de 2026 aporta otra advertencia. La empresa afirmó que Claude Opus 4.6 todavía no era capaz de automatizar por completo la investigación y el desarrollo en ámbitos clave. Describió un rendimiento más sólido en tareas bien delimitadas con criterios de éxito claros.
Esa limitación se corresponde directamente con el trabajo académico. Muchas preguntas de investigación siguen siendo ambiguas durante semanas, y los criterios de éxito cambian a medida que se acumula la evidencia. Un agente de programación puede rendir bien en una implementación acotada y, al mismo tiempo, tener dificultades con el juicio necesario para reformular el problema.
El informe también señaló que ninguno de los 16 miembros del personal técnico de Anthropic encuestados creía que el modelo ya calificara como sustituto directo de un investigador principiante. No se trata de una evaluación independiente, pero establece un límite para afirmaciones más contundentes sobre automatización.
Por lo tanto, la evidencia respalda una conclusión limitada. Claude Code puede ejecutar flujos de trabajo complejos relacionados con la investigación y aumentar la producción reportada. Los estudios existentes no demuestran que una delegación extensa preserve la comprensión del investigador ni mejore la validez científica.
Cualquier afirmación más contundente iría más allá de los datos disponibles. La preocupación actual merece investigación porque el mecanismo es plausible y la tendencia de adopción es visible. No debería convertirse en un veredicto generalizado sobre todos los investigadores que usan un agente.
La autoría de la investigación necesita una definición operativa
La autoría debería significar poder predecir, comprobar y defender un comportamiento relevante, no escribir personalmente cada carácter.
El debate se vuelve improductivo cuando la autoría se reduce a un porcentaje de código escrito a mano. Un investigador puede producir manualmente un repositorio sin comprender las bibliotecas heredadas. Otro puede generar la mayor parte de la sintaxis mientras mantiene un control preciso sobre los supuestos y las pruebas.
Un estándar mejor se centra en decisiones que pueden alterar las conclusiones. El investigador debería identificar el origen de cada conjunto de datos, la unidad de análisis, la variable objetivo y todas las reglas de filtrado. Debería explicar cómo se manejan la aleatoriedad, los valores faltantes, las ejecuciones fallidas y la agregación.
El arnés de evaluación merece una protección especial. Convierte el comportamiento del modelo en una cifra publicable y a menudo perdura más que la implementación de entrenamiento. Si un agente lo escribe, el investigador debería validarlo con casos pequeños cuyas respuestas se conozcan manualmente.
Las métricas requieren el mismo tratamiento. Un nombre familiar puede ocultar variantes importantes, incluida la media macro frente a la micro o la agregación ponderada por muestra. El código debe reflejar una definición escrita que exista independientemente de la implementación generada.
Las líneas base también codifican juicio. Un agente puede seleccionar un checkpoint disponible o reutilizar una configuración existente, pero la conveniencia no demuestra imparcialidad. Los investigadores deben documentar por qué cada comparación es relevante y si difieren el cómputo, los datos y el ajuste.
Los cambios generados deben mantenerse lo bastante pequeños como para revisarse como afirmaciones coherentes. Un parche que altera simultáneamente la carga, el entrenamiento, la evaluación y la visualización es difícil de validar, incluso cuando cada archivo parece impecable. Los cambios atómicos facilitan localizar los fallos.
Las pruebas deberían verificar invariantes científicos, no solo la ejecución del programa. Algunos ejemplos incluyen confirmar que los identificadores de entrenamiento y prueba nunca se solapan, que las etiquetas mezcladas aleatoriamente destruyen el rendimiento y que una métrica coincide con un fixture calculado a mano. Estas comprobaciones apuntan a fallos de investigación plausibles.
Los investigadores también necesitan períodos deliberados sin el agente. Reconstruir un flujo de trabajo de memoria revela mejor la comprensión ausente que releer un diff. Explicar el experimento a un colega de laboratorio puede revelar supuestos ocultos tras abstracciones limpias.
El agente puede ayudar en este proceso sin evaluarse a sí mismo. Puede generar preguntas sobre un módulo, trazar el linaje de los datos o identificar ramas sin probar. El investigador debe responder a partir del código y del diseño experimental, y luego confirmar esas respuestas de forma independiente.
Para los asesores y los laboratorios, la autoría debería convertirse en un artefacto revisable. Las solicitudes de extracción pueden incluir la hipótesis, el resultado esperado, los supuestos modificados, la evidencia de validación y la incertidumbre no resuelta. Esto crea un rastro duradero más allá de las transcripciones de chat.
Estas prácticas imponen costes, por lo que deberían concentrarse en las rutas de mayor consecuencia. El código repetitivo, el formato, las visualizaciones rutinarias y las utilidades aisladas requieren una revisión más ligera. La selección de datos, las métricas, la evaluación y la interpretación de resultados requieren una verificación más profunda.
Este modelo conserva gran parte del beneficio de velocidad y, al mismo tiempo, reconoce por qué la implementación tenía importancia educativa. Escribir código obligaba a los investigadores a enfrentarse a los detalles. Los flujos de trabajo agénticos deben recrear ese encuentro mediante especificaciones, pruebas y explicaciones.
El objetivo no es la nostalgia por la programación manual. Es un juicio científico fiable. Un investigador es dueño de un experimento cuando puede predecir su comportamiento, identificar sus supuestos débiles y defender sus resultados bajo escrutinio.
Tres señales mostrarán si la disyuntiva está mejorando
La siguiente etapa debería juzgarse por los resultados de comprensión y réplica, no por cuántas líneas adicionales puede generar un agente.
La primera señal es el estudio aleatorizado que Anthropic planea realizar sobre agentes de programación entre científicos sociales. Su encuesta de 2026 servirá como referencia para un experimento que proporciona a los investigadores acceso a Claude Code. La asignación aleatoria puede separar los efectos de la herramienta de las características de los primeros adoptantes entusiastas.
Los resultados más reveladores irían más allá de los artículos y las propuestas. Las mediciones de comprensión del código, detección de errores, deriva de las especificaciones y reproducción independiente pondrían a prueba directamente la preocupación planteada por el estudiante de doctorado. La productividad sin esas mediciones dejaría abierta la cuestión central.
Si el estudio detecta una mayor producción sin una validación ni una comprensión más débiles, se reforzaría el argumento a favor de una adopción amplia en la investigación. Si la comprensión disminuye o los errores evitables persisten durante más tiempo, los laboratorios necesitarán límites de delegación más estrictos.
La segunda señal es si las conferencias, las revistas y los laboratorios exigen divulgar el código de investigación generado por agentes. Las políticas actuales sobre autoría y uso de IA suelen centrarse en el texto del manuscrito. Los métodos computacionales necesitan registros más específicos, porque las decisiones de implementación influyen directamente en los resultados.
Una divulgación útil identificaría qué componentes generó un agente, qué modelo o herramienta se utilizó y cómo se probó de forma independiente el comportamiento crítico. No sería necesario revelar cada prompt ni penalizar la asistencia habitual.
Si los principales espacios de publicación adoptan estándares de divulgación reproducibles, los revisores podrán evaluar el uso de agentes como parte del método. Si las políticas siguen centradas en la prosa, una parte creciente de la producción científica permanecerá débilmente documentada.
La tercera señal es la brecha de rendimiento entre los benchmarks acotados y la investigación abierta. Las tareas de reproducción ofrecen objetivos conocidos y materiales existentes. La investigación original exige decidir qué objetivo importa, manejar evidencia ambigua y cambiar de dirección tras un fracaso.
Las evaluaciones futuras deberían seguir a los agentes durante proyectos de varias semanas con especificaciones incompletas. Deberían medir si los sistemas preservan la intención experimental, hacen visible la incertidumbre y resisten prompts que fomentan el análisis confirmatorio.
Una brecha cada vez menor reforzaría la afirmación de Anthropic de que los expertos en el dominio pueden delegar una mayor parte de la ejecución de forma segura. Los fallos persistentes en proyectos ambiguos respaldarían un papel más limitado, con los agentes como implementadores sujetos a especificaciones humanas explícitas.
Los investigadores no tienen que esperar pasivamente a esos estudios. Pueden identificar un componente de alto impacto, reconstruirlo de forma independiente y comparar el resultado con la ruta generada por el agente. También pueden pedir a colegas que expliquen un pipeline sin consultar a su autor.
El horizonte de Anthropic no se define por el momento en que Claude Code pueda escribir un repositorio completo. Se define por si los investigadores pueden conservar un criterio responsable mientras el agente lo hace.
Antes de aprobar el próximo diff generado de gran tamaño, plantee una pregunta más difícil: ¿podría predecir qué resultado cambiaría si se modificara una suposición? Si la respuesta no está clara, deje de ampliar el experimento y reconstruya la cadena desde el método hasta el código.



