¿Se aprende a programar si la IA escribe el código?

Cuando el código llega ya escrito, usted no hace el trabajo de escribirlo. La pregunta que se puede medir es si conserva la capacidad de escribirlo cuando ya no tiene la IA.

Algunos experimentos responden a esa pregunta porque hicieron exactamente eso: dieron acceso a la IA durante la práctica, lo retiraron y examinaron después. El primero se hizo con casi mil estudiantes de secundaria. Quienes practicaron con una interfaz de tipo ChatGPT sacaron un 17 % menos en el examen sin IA que quienes nunca la tuvieron¹. El mismo experimento incluía una segunda versión, configurada para dar pistas en lugar de la solución. Con ella, la pérdida desapareció casi por completo, y tampoco hubo ninguna ganancia¹.

En programación, un experimento con 69 principiantes no encontró pérdida. La mitad usó un generador de código durante el entrenamiento, y después, sin él, no rindió peor².

Recibir el código escrito no enseña por sí solo, y tampoco impide aprender por sí solo. El resultado depende de lo que usted haga después de recibirlo, y esa parte se puede configurar.

Solo uno de los estudios de aprendizaje citados midió a ingenieros de software, y ninguno en un repositorio en producción. Cada cifra describe solo a la población en la que se midió. A otros casos se puede trasladar el mecanismo que produjo el resultado, pero no el tamaño del efecto.

Las mediciones se hicieron el 27 de septiembre de 2026 con Claude Code 2.1.283 y git 2.49.0. La documentación de Cursor se consultó ese mismo día. Todo el código está reconstruido para el artículo.

1. Qué pasó cuando se retiró la IA antes del examen

El experimento se hizo en un instituto de Turquía durante el primer semestre del curso 2023-2024, sobre matemáticas de 9.º, 10.º y 11.º curso¹. Fueron cuatro sesiones de noventa minutos en unas cincuenta clases, con casi mil estudiantes en total. Las sesiones cubrieron alrededor del 15 % del temario del semestre³.

Cada sesión tenía dos partes. En la primera, los estudiantes resolvían problemas de práctica con sus apuntes, el libro de texto y el recurso que les había tocado al azar. En la segunda hacían un examen solos, sin ningún recurso.

Los recursos asignados al azar eran tres:

GPT Base, una interfaz de chat sobre GPT-4 que imitaba ChatGPT.
GPT Tutor, una segunda interfaz sobre el mismo modelo. Sus instrucciones del sistema incluían la solución de cada problema, la instrucción de no entregarla y las pistas que escribieron dos profesores de matemáticas.
Ninguno, en el grupo de control.

Durante la práctica, las dos interfaces ayudaron. El grupo de GPT Tutor resolvió un 127 % mejor que el de control, y el de GPT Base, un 48 % mejor¹. En el examen sin IA, el orden se invirtió. El grupo de GPT Base rindió un 17 % peor que el de control, con una diferencia estadísticamente significativa. El grupo de GPT Tutor quedó al nivel del de control, sin pérdida y sin ganancia¹.

El análisis de los mensajes explica de dónde salió esa pérdida. En el grupo de GPT Base, el 31 % de los primeros mensajes preguntaba cuál era la respuesta³. Los autores preguntaron diez veces cada uno de los 57 problemas de práctica a GPT Base para medir cuántas veces acertaba. Dio la respuesta correcta el 51 % de las veces. Tuvo errores de razonamiento en el 42 % y errores de cálculo en el 8 %³.

Esa cifra no es una tasa de error actual y no se traslada al código. Sirve para saber si los estudiantes comprobaban lo que copiaban. Cabría esperar que un estudiante de secundaria detectara los errores de cálculo con más facilidad que los de razonamiento. Aun así, perjudicaron su rendimiento tanto como los de razonamiento, y los autores leen esa coincidencia como prueba de que copiaban sin revisar³.

2. Qué midió el experimento equivalente en programación

El segundo estudio tiene el mismo diseño y otro resultado. Participaron 69 principiantes de entre 10 y 17 años, con una media de 12,5, reclutados en campamentos de programación de dos ciudades de Norteamérica. Ninguno tenía experiencia previa con lenguajes de programación escritos en texto². El estudio duró tres semanas. Hubo una sesión de introducción con Scratch y una prueba previa, siete sesiones de entrenamiento en Python y dos de evaluación.

El entrenamiento consistió en 45 tareas de escribir código, y cada una iba seguida de una tarea de modificar código². La mitad de los participantes tuvo acceso a Codex en la parte de escribir. En la evaluación, nadie tuvo acceso ni al generador ni a la documentación.

Durante el entrenamiento, el grupo con Codex rindió mejor en las tareas de escribir. Tuvo 1,15 veces más progreso, 1,8 veces más corrección, 0,59 veces los errores y 0,57 veces el tiempo². En las tareas de modificar que venían justo después, que eran manuales, los dos grupos rindieron igual. En la evaluación inmediata sin IA también rindieron igual.

La prueba de retención se hizo una semana más tarde. En las tareas de escribir, el grupo que había usado Codex sacó un 59,1 % frente a un 49,8 %. En las de modificar, sacó un 47,5 % frente a un 34,8 %. Ninguna de las dos diferencias fue estadísticamente significativa². Los autores señalan dos datos más de la misma tabla. El grupo de Codex cometió significativamente más errores en las tareas de escribir de esa prueba. El grupo de control abandonó significativamente más tareas sin intentarlas, un 33 % frente a un 14 %².

Un último resultado muestra dónde se concentra el efecto. Los autores dividieron a los participantes según su puntuación en la prueba previa de Scratch. En la mitad alta, quienes usaron Codex rindieron significativamente mejor en varias medidas de la prueba de retención. En la mitad baja, los dos grupos quedaron casi iguales².

Los propios autores señalan el límite de su diseño. El entrenamiento limitaba el generador a las tareas de escribir, y los participantes pudieron aprender los conceptos de Python mientras hacían las tareas de modificar².

3. Qué explica la diferencia entre los dos resultados

Los dos experimentos se diferencian en la materia, la edad de los participantes, la duración y la calidad de la IA.

La calidad es la primera candidata a explicar la diferencia. Codex resolvió bien 41 de las 45 tareas sin ningún cambio en el enunciado². GPT Base, en cambio, daba la respuesta correcta el 51 % de las veces³. Copiar de una IA que acierta casi siempre no equivale a copiar de una que falla la mitad de las veces.

Los autores del estudio de matemáticas comprobaron esa explicación, y sus datos no la confirmaron. Si los errores de la IA hubieran confundido a los estudiantes, habrían empeorado su nota en los problemas equivalentes del examen. La tasa de errores de razonamiento perjudicó el rendimiento durante la práctica, pero no tuvo un efecto estadísticamente significativo en el examen³. Según ese análisis, copiar la respuesta perjudicó el examen, fuera correcta o no.

Queda la diferencia de diseño del punto 2: en programación, cada tarea con Codex iba seguida de una tarea de modificar código a mano². Esa tarea es un intento sobre el material, hecho después de que el código llegara escrito.

De los dos diseños sale la misma conclusión: el cambio generado no es el final de la tarea.

4. Qué se midió sobre la sensación de haber aprendido

Al final de cada examen, el estudio de matemáticas preguntó a los participantes cuánto creían haber aprendido y cómo creían haber rendido. Los del grupo de GPT Base, que rindieron significativamente peor, no percibieron que hubieran aprendido menos ni que hubieran rendido peor. Los del grupo de GPT Tutor, que no mejoraron, percibieron que habían rendido significativamente mejor³.

Los dos grupos preferían además tener la IA. Estaban dispuestos a ceder minutos de examen a cambio de usarla. El grupo de GPT Base cedía unos 2,5 minutos, y el de GPT Tutor, unos 3,7³.

Este desajuste entre lo que se cree y lo que se aprende no es propio de la IA. Aparece en el experimento clásico sobre el testing effect, o efecto de la evaluación. Es la mejora en la retención que produce examinarse en lugar de volver a leer. En ese experimento, con estudiantes universitarios, el grupo que más releyó era el que más confiaba en recordar el texto una semana después. También fue el que menos recordó⁴.

Por eso, la sensación de haber entendido algo no distingue entre haberlo entendido y haberlo leído. La comprobación tiene que ser externa (punto 10).

5. Qué deja más recuerdo: leer una solución o producirla

El experimento que separa las dos cosas se publicó en 2006. Participaron 180 estudiantes de grado de entre 18 y 24 años, 30 en cada una de sus seis condiciones⁴. Todos trabajaron sobre un texto en prosa durante cuatro periodos seguidos, y las condiciones se distinguen por lo que hicieron en cada periodo.

En el grupo SSSS, los participantes estudiaron el texto en los cuatro periodos de cinco minutos. En el grupo SSST estudiaron en tres, y en el cuarto hicieron una prueba de recuerdo libre. En esa prueba se escribe todo lo que se recuerda del texto. En el grupo STTT estudiaron en uno e hicieron tres pruebas seguidas. Ninguna prueba llevaba corrección ni respuesta después. La única diferencia entre los grupos era la recuperación, el acto de recordar el texto sin volver a leerlo.

Cinco minutos después, el orden siguió a la exposición. SSSS recordó el 83 % de las unidades de idea del texto, SSST el 78 % y STTT el 71 %. Una semana después, el orden se invirtió: 61 % para STTT, 56 % para SSST y 40 % para SSSS⁴.

El número de lecturas confirma el resultado. El grupo SSSS leyó el texto entero unas 14,2 veces de media, el SSST unas 10,3 y el STTT unas 3,4⁴. Cuatro veces más exposición dio 21 puntos menos de recuerdo a la semana.

El estudio midió el recuerdo de un texto en prosa en estudiantes de grado, no el de código. Al código se puede trasladar la causa de la retención: el intento de recuperar el texto, no el número de veces que se leyó. Leer el código que generó un agente es exposición. Volver a escribirlo sin mirarlo es recuperación, y son dos actos distintos aunque el material sea el mismo.

6. Qué es el efecto del ejemplo resuelto y cuándo se invierte

Hay un resultado igual de firme en la dirección contraria, el worked example effect o efecto del ejemplo resuelto. Para quien no sabe nada de un dominio, estudiar un problema con toda su solución explicada enseña más que intentar resolverlo⁵. La revisión que reúne esa literatura lo atribuye a la carga de la memoria de trabajo. Esa memoria retiene la información mientras se razona, y es limitada. El ejemplo resuelto evita la búsqueda de la solución y dirige la atención al estado del problema y a las operaciones que se le aplican⁵.

La misma revisión describe el punto en que ese efecto desaparece y se invierte, y lo llama expertise reversal effect, o inversión por pericia. Un esquema es la forma en que alguien tiene organizados los conceptos de un dominio. Cuando quien aprende ya tiene construido el esquema, relacionar un ejemplo resuelto con lo que ya sabe cuesta más que resolver el problema. El ejemplo pasa a ser redundante, y la práctica de resolver enseña más⁵.

La revisión cita experimentos con aprendices de oficios mecánicos. En ellos, la ventaja del ejemplo resuelto primero desapareció con la experiencia y después se invirtió⁵.

El ejemplo resuelto enseña, por tanto, dentro de un intervalo con dos límites. El límite inferior es que quien lo lee tiene que poder seguirlo. El estudio de programación midió algo compatible con ese límite, porque la ganancia en retención se concentró en quienes ya puntuaban alto antes de empezar². El límite superior es un dominio que ya se conoce bien. Ahí, leer la solución añade poco, y el intento añade más.

El código que genera un agente es un ejemplo resuelto. En un lenguaje o una biblioteca que usted no conoce, leerlo es la forma barata de construir el primer esquema. En un dominio que ya conoce, leerlo es solo exposición.

7. Qué no sustituye el ejemplo resuelto

La literatura sobre carga cognitiva no dice que la dificultad enseñe por sí misma. Dice que buscar una solución sin guía consume memoria de trabajo en operaciones que no construyen esquema, y que el ejemplo resuelto evita esa búsqueda⁵.

El intento de recuperar lo aprendido, que es un acto posterior y distinto, sí enseña. En el experimento del punto 5 no hubo corrección. El efecto vino de haber tenido que producir el texto, no de recibir información nueva⁴.

Las dos piezas van en este orden. El ejemplo resuelto sirve para recibir el esquema por primera vez (punto 6), y la recuperación decide si ese esquema sigue ahí una semana después. Un flujo de trabajo con IA da lo primero en abundancia y no incluye lo segundo, salvo que usted lo añada.

8. Cómo configurar un agente para que dé pistas y no soluciones

El grupo que no perdió nada en el estudio de matemáticas usaba el mismo modelo con otras instrucciones del sistema. Esas instrucciones contenían la solución y la instrucción de no entregarla¹. En un agente de programación, esa configuración se reproduce con una regla del proyecto. Claude Code carga los archivos de .claude/rules/ que llevan la cabecera paths solo cuando trabaja con un archivo que coincide con esas rutas⁶. Así, la regla se aplica a la parte del código que usted quiere aprender y no al resto del repositorio.

Cree .claude/rules/aprender.md y escriba en paths los archivos que quiere aprender:

---
paths:
  - "src/carrito.js"
---

# Regla de aprendizaje

No escribas el código de la tarea en este archivo. Responde con la pista siguiente:
qué función tocar, qué concepto aplica y una pregunta que dirija al
siguiente paso. Si pido explícitamente el código, entonces sí lo escribes.

En la medición, src/carrito.js tenía una sola función y Claude Code tenía permiso para editar archivos. La petición «añade a src/carrito.js una función que aplique un descuento porcentual al total» devolvió esto:

Modo aprendizaje activo (`.claude/rules/aprender.md`), así que no escribo el
código. Te dejo una pista:

**Dónde:** `src/carrito.js`. Crea una función nueva junto a `total(items)`
(`src/carrito.js:1`) y exporta con `export`, igual que ella. No hace falta
modificar `total`. Mejor reutilizarla.

**Concepto:** composición de funciones. Un descuento porcentual consiste en
multiplicar el total por la fracción que queda después de restar el
porcentaje. Por ejemplo, un 20 % de descuento equivale a pagar el 80 %.
Conviene también validar la entrada, porque un porcentaje negativo o mayor que
100 no tiene sentido.

**Pregunta:** si `total(items)` devuelve `50` y el descuento es `20`, ¿qué
operación con `50` y `20` te da `40`? Y cuando la tengas, ¿qué parámetros
debería recibir tu nueva función: los `items` o el total ya calculado?

Si prefieres que te escriba el código directamente, pídemelo.

El archivo quedó sin tocar. Una petición parecida sobre src/fechas.js, que no está en paths, escribió la función en ese archivo. La última línea de la regla permite pedir el código cuando haga falta: al pedirlo de forma explícita, Claude Code lo escribió en src/carrito.js.

En Cursor, la misma configuración es un archivo .mdc en .cursor/rules con globs: src/carrito.js y alwaysApply: false en la cabecera. Cursor añade la regla cuando un archivo que coincide está en el contexto⁷.

Claude Code incluye además dos estilos de salida con el mismo fin. Según su documentación, Explanatory intercala explicaciones de las decisiones de implementación mientras trabaja. Learning le pide a usted que escriba pequeñas partes del código y las marca con TODO(human) en el archivo⁸.

En una sola petición no interactiva, el estilo Learning devolvió las explicaciones y escribió la función entera, sin dejar ninguna parte para usted. Elija el estilo con /output-style learning, que requiere la versión 2.1.269 o posterior. También puede elegirlo con /config, en la entrada de estilo de salida, o con el campo outputStyle de un archivo de configuración⁸.

Cómo comprobarlo. Escriba la regla, pida un cambio pequeño en un archivo de paths y ejecute git status --short. En la medición no devolvió ninguna línea, ni antes ni después de la petición. Si aparece ese archivo modificado, la regla no se está aplicando.

9. Qué formas de pedir conservan el aprendizaje

El punto 7 de primeros pasos para programar con IA explica tres formas de pedir, con sus ejemplos. Son pedir la explicación antes que el cambio, pedir orientación en lugar de una solución y escribir su propia versión antes de pedir la revisión. Las cuatro que siguen salen de los experimentos de los puntos 1 a 7:

Modificar a mano lo que escribió el agente. Es el protocolo del estudio de programación convertido en costumbre. Después de aceptar un cambio generado, haga una variación a mano, sin el agente. Sirve cambiar el criterio de un filtro, añadir un caso límite o mover una responsabilidad de sitio.
Predecir la salida antes de ejecutar. Antes de ejecutar el código generado, escriba en un comentario qué debería devolver con una entrada concreta. El punto 10 explica cómo contrastarlo.
Reescribir de memoria a los pocos días. Es la aplicación directa del experimento del punto 5, que no necesitó corrección inmediata para funcionar. El punto 10 explica el procedimiento.
Elegir según el dominio. En un lenguaje o una biblioteca nuevos, lo eficiente es dejar que el agente escriba y leer el código con atención. En un dominio que quiere aprender a fondo, la regla de pistas del punto 8 conserva el intento.

Situación	Forma de pedir	Comprobación
Lenguaje o biblioteca desconocidos	Que escriba el código y explique cada decisión	Modificar el resultado a mano sin el agente
Dominio propio que se quiere conservar	Regla de pistas, sin código	Escribir usted el cambio y hacer pasar las pruebas sin el agente
Concepto que se acaba de estudiar	Escribir primero la propia versión, después pedir revisión	Contrastar las dos versiones línea a línea
Código generado hace días	Reescribir la función de memoria	`git diff` contra la versión guardada
Explicación recibida del agente	Explicarla sin abrir el archivo	Pedirle que compare la explicación con el archivo

10. Cómo comprobar lo aprendido

Una comprobación sirve si produce un resultado que se puede mirar, no una impresión. Las cuatro que siguen se pueden hacer el mismo día.

La primera es la reescritura de memoria. Guarde la versión actual con un commit y borre la función. Escríbala de nuevo sin abrir la anterior y ejecute git diff sobre el archivo, que muestra los cambios línea a línea⁹. Las diferencias son la lista de lo que no había aprendido.

La segunda es la predicción escrita. Escriba la salida esperada en un comentario antes de ejecutar, y compárela con el resultado. Una predicción que falla señala el punto exacto donde su idea del código no coincide con lo que hace.

La tercera es la explicación contrastada, y la corrige el propio agente. Escriba de memoria qué hace una función, sin abrir el archivo, y pida al agente que compare su explicación con el código. Sobre una función de cuatro líneas y una explicación con dos errores introducidos a propósito, la respuesta fue esta:

Dos diferencias:

1. **Dice** "suma el precio de cada artículo". **Código** suma
   `item.precio * item.cantidad` — ignora `cantidad` en la explicación.
2. **Dice** "si el arreglo está vacío devuelve undefined". **Código** usa
   `reduce` con valor inicial `0` → devuelve `0`, nunca `undefined`.

Resto coincide: usa `reduce`, empieza en 0, devuelve número.
Archivo no tocado.

La respuesta es una lista de diferencias. Pida en la misma petición que no corrija el archivo, porque la comprobación deja de valer si el agente arregla lo que acaba de encontrar.

La cuarta es cerrar la sesión y reconstruir lo explicado sin ella, que es la comprobación del punto 7 de primeros pasos. Las cuatro siguen el mismo orden: primero producir algo y después contrastarlo.

11. Qué cambia si usted ya sabe programar

Casi todos los estudios citados midieron a estudiantes y aprendices: de secundaria, de campamentos de programación, de grado y de oficios mecánicos.

El más cercano a un puesto de trabajo lo publicó Anthropic en enero de 2026. Participaron 52 ingenieros de software, en su mayoría junior, que aprendieron Trio, una biblioteca de Python, con o sin un asistente de IA. Después hicieron un examen sin él. El grupo con IA sacó una media del 50 %, frente al 67 % del grupo que escribió el código a mano, y no terminó significativamente antes¹⁰.

El resultado dependió de cómo usaron el asistente. Quienes le delegaron el código, o le pasaron los errores uno tras otro, sacaron menos de un 40 % de media. Quienes le hicieron preguntas conceptuales, o pidieron el código y después lo explicaron, sacaron un 65 % o más¹⁰. Es el mismo patrón de los puntos 1 y 3. Los autores advierten de que la muestra es pequeña y de que el examen se hizo justo después de la tarea¹⁰.

Ninguno de estos estudios midió a un profesional en un repositorio de trabajo.

De los mecanismos anteriores salen dos consecuencias, que son un razonamiento y no un resultado medido:

La inversión por pericia funciona por dominio, no por persona. Alguien con diez años de experiencia en un lenguaje es principiante en el siguiente. El mismo día puede estar por encima del límite superior en un archivo y por debajo del límite inferior en otro.
Delegar en el agente un dominio que ya conoce cuesta poco en aprendizaje, porque ahí el ejemplo resuelto ya era redundante.

Queda un caso que ninguno de los estudios cubre y que aparece cuando el proyecto crece. Un repositorio que usted conocía deja de resultarle conocido cuando la mayor parte de sus cambios recientes los escribió un agente. En ese caso, usted no pierde la capacidad de programar, sino el conocimiento de cómo está organizado su propio código. Compruébelo como en el punto 10, en el archivo que va a tocar: explique qué hace antes de abrirlo.

12. Qué sigue sin medirse

La búsqueda de estudios para el artículo no encontró ningún ensayo aleatorizado que retire la IA a programadores profesionales tras meses de uso. El estudio de Anthropic del punto 11 midió una sola sesión. Tampoco encontró una medición de lo que saben hacer sin ella en esa población. Todo lo que se afirme sobre eso es una extrapolación.

Lo más cercano en población profesional mide velocidad, no aprendizaje, y aun así repite el desajuste del punto 4. METR repartió al azar 246 tareas entre permitir y prohibir la IA a 16 desarrolladores de proyectos maduros de código abierto. Antes de empezar, los desarrolladores esperaban tardar un 24 % menos. Al terminar, creían haber tardado un 20 % menos, y la medición dio un 19 % más de tiempo¹¹.

METR repitió el experimento a partir de agosto de 2025, con 57 desarrolladores y más de 800 tareas. Entre quienes ya habían participado, la estimación pasó a un 18 % menos de tiempo con IA, con un intervalo de confianza de −38 % a +9 %. METR advierte de que esos datos son una prueba muy débil. Muchos desarrolladores ya no aceptaban trabajar sin IA, y evitaban enviar tareas que no querían hacer sin ella¹².

El primer resultado describe a expertos que trabajaban con código que ya conocían, con la IA del primer semestre de 2025. Coincide con los estudios de aprendizaje en la distancia entre lo que los participantes creían y lo que se midió. En las dos poblaciones, la autoevaluación apuntó en la dirección equivocada.

El diseño que resolvería la pregunta consiste en retirar la IA y medir. Las comprobaciones del punto 10 son la versión individual de ese diseño.

Por dónde seguir

Revise el código generado aunque haya aprendido de él. Ocho cosas que revisar en el código que genera la IA recoge ocho fallos de seguridad frecuentes. Cada punto trae el código que falla, la corrección y la orden que la comprueba.

Para que la revisión se ejecute en cada cambio sin depender de nadie, siga con cómo pedirle a la IA código seguro.

Si le falta el principio, primeros pasos para programar con IA explica qué es un agente y cómo escribirle una tarea. También explica cómo detenerlo y cómo documentar el proyecto.

Referencias

Bastani, H., Bastani, O., Sungu, A., Ge, H., Kabakcı, Ö. y Mariman, R.. Generative AI without guardrails can harm learning: Evidence from high school mathematicsPNAS 122(26), e2422633122, 2025; ensayo aleatorizado con casi mil estudiantes.doi.org↩
Kazemitabaar, M., Chow, J., Ma, C. K. T., Ericson, B. J., Weintrop, D. y Grossman, T.. Studying the effect of AI Code Generators on Supporting Novice Learners in Introductory ProgrammingCHI 2023; 69 principiantes de 10 a 17 años, 45 tareas y prueba de retención a la semana.doi.org↩
Bastani, H. y otros. Generative AI Without Guardrails Can Harm Learning (versión de trabajo, PDF)tasas de error de GPT Base, reparto de los primeros mensajes y encuesta de percepción, en los apéndices.hamsabastani.github.io↩
Roediger, H. L. y Karpicke, J. D.. Test-Enhanced Learning: Taking Memory Tests Improves Long-Term RetentionPsychological Science 17(3), 249-255, 2006; experimento 2, 180 estudiantes de grado.doi.org↩
Kalyuga, S., Ayres, P., Chandler, P. y Sweller, J.. The Expertise Reversal EffectEducational Psychologist 38(1), 23-31, 2003; revisión del efecto del ejemplo resuelto y su inversión.doi.org↩
Claude Code. How Claude remembers your projectreglas de .claude/rules con la cabecera paths.code.claude.com↩
Cursor. Rulesconsultado el 27 de septiembre de 2026; .cursor/rules, extensión .mdc, globs y alwaysApply.cursor.com↩
Claude Code. Output stylesestilos Explanatory y Learning, marcadores TODO(human) y /output-style desde la 2.1.269.code.claude.com↩
Git. git-diffgit-scm.com↩
Shen, J. H. y Tamkin, A.. How AI assistance impacts the formation of coding skillsAnthropic, 29 de enero de 2026; 52 ingenieros, en su mayoría junior, y la biblioteca Trio.anthropic.com↩
Becker, J., Rush, N., Barnes, E. y Rein, D.. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer ProductivityMETR, julio de 2025; ensayo aleatorizado, 16 desarrolladores y 246 tareas.arxiv.org↩
METR. We are Changing our Developer Productivity Experiment Design24 de febrero de 2026; 57 desarrolladores y más de 800 tareas.metr.org↩