¿Quién responde por el código que escribió el agente de IA?

Respuesta corta: respondes tú, y el git ya lo dice. En el repositorio detrás de este sitio, los 251 commits sin merge hechos entre el 18 de julio y el 10 de agosto de 2026 llevan un único nombre humano en el campo de autor del git, mientras que el 69,8% de las líneas vivas en ese código hoy se escribieron dentro de una sesión de agente de IA. El git registra quién ejecutó el commit, nunca quién produjo el texto, así que la responsabilidad no se reparte con la herramienta. Lo que todavía puedes decidir es si existe algún registro de lo que hizo el agente, porque ese registro no se reconstruye después.

¿Qué registra el git realmente sobre quién escribió el código?

El git guarda dos identidades en cada commit, el autor y quien hizo el commit, y las dos son personas. La documentación de git commit-tree las lista como campos separados, de un lado nombre, correo y fecha del autor, del otro nombre, correo y hora de quien hizo el commit. No dice por qué existe esa separación, así que la explicación habitual es nuestra y no del manual: los dos campos divergen cuando alguien aplica un parche escrito por otra persona, que es lo más cercano que tiene el git a la situación en la que estás con un agente de IA. Ninguno de los dos campos tiene sitio para una herramienta.

Lo que el git sí ofrece es el trailer, una línea Clave: valor al final del mensaje del commit, leída por git interpret-trailers. La convención que más gente ha visto es Co-authored-by, que GitHub usa para mostrar una segunda cara en el commit, documentada como forma de acreditar a más de una persona. Parte de las herramientas de agente añade su propio trailer: en este repositorio, los commits hechos dentro de una sesión de agente llevan una línea Claude-Session que apunta a la sesión que los produjo.

Lo importante es que nada de esto ocurre solo. Un trailer existe únicamente si algo lo escribió al hacer el commit, y un commit hecho sin él es indistinguible, para siempre, de uno tecleado a mano. Comprueba qué registra tu repositorio antes de suponer que registra algo: git log -1 --format='%(trailers)' imprime los trailers de tu último commit, y una respuesta vacía también es una respuesta.

¿Cuánto del código que está corriendo ahora salió de una sesión de agente de IA?

Lo medimos en el repositorio de este sitio el 12 de agosto de 2026. Es una muestra extrema, y eso es lo que la hace útil: el sitio lo escriben agentes de IA trabajando en worktrees paralelas del git, con un operador humano que revisa y hace los commits. El método es correr blame en cada línea viva en HEAD, resolver cada línea hasta el commit que la tocó por última vez y preguntar si ese commit lleva el trailer de sesión.

De 90.456 líneas vivas en 641 archivos rastreados, sin contar binarios, 63.166 líneas, o sea el 69,8%, vienen de commits hechos dentro de una sesión de agente. Restringido a archivos PHP y Blade, que es donde vive la aplicación, la porción es del 87,2% de 58.849 líneas. La diferencia entre las dos cifras tiene dos fuentes de peso parecido, y ninguna es código de aplicación: el composer.lock guarda 12.631 líneas escritas por un instalador de paquetes, solo el 10% de ellas de sesión, y la documentación en Markdown del proyecto guarda otras 13.547 líneas, el 55% de ellas de sesión.

El comando tiene tres pasos y solo lee. Excluir binarios no es un capricho: el git blame trata un favicon como 1.790 líneas de autoría sin inmutarse, y eso infla el resultado.

git log --format=%H --grep='^Claude-Session:' | sort > agent.txt

git ls-files -z ':!:*.png' ':!:*.ico' ':!:*.jpg' ':!:*.webp' ':!:*.woff2' ':!:*.pdf' \
  | xargs -0 -n1 git blame --line-porcelain -w HEAD -- 2>/dev/null \
  | grep -aE '^[0-9a-f]{40} [0-9]+ [0-9]+' | cut -c1-40 | sort | uniq -c \
  | awk '{print $2, $1}' | sort > lines.txt

join agent.txt lines.txt | awk '{s+=$2} END{print s}'

El segundo archivo también te da el total, con awk '{s+=$2} END{print s}' lines.txt. Cambia el nombre del trailer por el que escriba tu herramienta y amplía la lista de exclusión a los formatos binarios que tu proyecto tenga de verdad. Si tu repositorio no tiene ningún trailer, el primer archivo sale vacío, y la lectura honesta es que la porción es imposible de medir, no que sea cero.

¿Por qué "lo escribió el agente" no sobrevive a un análisis de incidente?

Porque las preguntas de un incidente no son sobre teclear. Son quién aprobó esto, quién explica la decisión detrás de esto y quién lo está arreglando en la próxima hora. Un agente de IA no responde a ninguna de las tres, y esa es nuestra lectura de por qué la frase se cae tan rápido en la práctica, no una afirmación jurídica.

Los números le dan forma al problema. En este repositorio, 214 de los 251 commits llevan el trailer de sesión, y esos 214 commits salieron de apenas 24 sesiones distintas, con una mediana de 7 commits por sesión y una sola sesión firmando 37 commits ella sola. O sea, el trailer dice a qué conversación pertenece un cambio, no qué decisión lo produjo. Saber que 37 commits comparten una sesión es casi no saber nada de ninguno de ellos.

Por eso también "fue el agente" y "fui yo" son la misma respuesta en una revisión, y solo cambia el tono. Quien abrió la sesión eligió la tarea, leyó el resultado y pulsó commit. Todo lo que aportó la herramienta pasó por esa puerta, y la puerta tiene nombre en el campo de autor.

¿Qué se puede recuperar meses después y qué se pierde para siempre?

Lo que sobrevive es la cadena que va de la línea al commit: git blame te da el commit, el mensaje del commit te da el trailer, el trailer te da un identificador de sesión. Esa cadena basta para responder "esta línea nació en una sesión de agente" mucho después de que todos hayan olvidado la semana en que ocurrió.

Lo que no sobrevive es todo lo que hizo que el cambio sea lo que es. La petición que lo inició, las alternativas que el agente propuso y rechazaste, la prueba que corriste antes de aceptar, el trozo que leíste por encima porque parecía obvio: nada de eso está en el git salvo que lo hayas escrito ahí. Un identificador de sesión es un puntero, y un puntero vale lo que valga el sitio al que apunta, que puede no estar legible para quien investigue dentro de seis meses.

La consecuencia práctica es incómoda y conviene decirla sin rodeos: la trazabilidad que vas a querer durante un incidente hay que crearla antes del incidente, por hábito, y ninguna herramienta instalada después recupera una semana que nadie registró.

¿Qué dice cada registro?

¿Cómo dejar rastreable el trabajo del agente antes de necesitarlo?

Empieza por averiguar qué tienes ya, porque mucha gente registra más de lo que cree. Corre git log -20 --format='%h %s%n%(trailers)' y busca cualquier línea escrita por una herramienta. Si algo ya sella tus commits, el trabajo es no perderlo, lo que en la práctica significa no aplastar los mensajes con squash y no reescribir el historial por prolijidad.

Si nada los sella, el hábito más barato y útil es que tú mismo escribas una línea en el mensaje del commit: qué herramienta produjo el cambio y qué verificaste antes de aceptarlo. Esa sola frase vale más en un incidente que cualquier marcador automático, porque registra la decisión humana y no el evento de la máquina.

Después, mantén la unidad de cambio lo bastante pequeña para que el registro signifique algo. Una sesión que firma 37 commits, como firmó la nuestra, es una sesión que nadie va a auditar; el mismo trabajo repartido en commits pequeños con mensajes honestos sí lo puede auditar un desconocido. Nuestra medición no prueba que más pequeño sea más seguro, y no afirmamos que lo pruebe, pero un registro cuya menor unidad es una sesión enorme es un registro que responde "cuándo" y se niega a responder "qué".

¿Avisar de que lo escribió un agente cambia quién responde?

No. Avisar cambia lo que el revisor mira primero, y es el error más barato cuando el proyecto no tiene política declarada, pero no mueve la responsabilidad a ningún sitio. Quien manda el cambio sigue siendo su dueño. Esa es una pregunta distinta de si un proyecto va a aceptar código de agente, que tratamos aparte en por qué hay proyectos que están desactivando los pull requests para código generado por IA, donde la puerta se cierra desde fuera. Este artículo trata del código que ya entró, en un repositorio que es tuyo.

Las dos situaciones tiran hacia el mismo lado, además. Lo que hace que un cambio sea revisable por un mantenedor que no confía en ti es lo mismo que lo hace auditable por un colega que lo hereda, y todo baja a tamaño, calidad del mensaje y una prueba que falle cuando el cambio está mal.

Lo que esta medición no prueba

Un repositorio es un repositorio. Este sitio es un caso extremo a propósito, así que el 69,8% dice cómo es un proyecto pesado en agentes, no cómo es el tuyo. Corre el comando en tu propio historial antes de suponer que algo de esto se transfiere.

El trailer de sesión marca la sesión, no la línea. Un humano abrió esa sesión, leyó la salida e hizo el commit, así que una línea contada como "de sesión de agente" no es una línea que nadie haya visto. En sentido contrario, los 37 commits sin trailer no prueban código tecleado a mano: un commit hecho fuera de sesión, o con el marcador ausente por cualquier motivo, queda idéntico a uno escrito desde cero. Ese 37 es aritmética, 251 menos 214, y no tiene relación con los 37 commits de la sesión más grande citados arriba; los dos números coinciden y significan cosas distintas.

Dos límites más que conviene decir. Corrimos git blame -w, que ignora los cambios solo de espacios, y el blame siempre atribuye la línea viva al commit que la tocó por última vez, así que una refactorización posterior mueve la autoría aunque no haya movido nada relevante. Y si comparas este 69,8% con la porción que publicamos antes en el artículo sobre pull requests desactivados, fíjate en que responden preguntas distintas: aquella mide el cambio tal como ocurrió a lo largo del historial, incluido código ya borrado, y esta mide solo lo que sigue en pie hoy.