2. Autoría y responsabilidad: quién firma el código

Descripción

Al terminar esta lección vas a poder aplicar, sin ambigüedad, la regla que decide quién es la persona responsable de un cambio de código en tu equipo: quien abre el pull request, nunca la herramienta que generó el diff. Vas a poder explicar, con un ejemplo concreto, qué cambia esa regla en una revisión, en un incidente real y en una evaluación de desempeño. Y vas a poder decidir cómo tu equipo declara que un agente participó en un cambio, de una forma que informe sin volverse ni un estigma que castiga a quien lo declara ni una excusa que baja la guardia de quien lo usa.

Esto importa porque es exactamente la pregunta que la lección 1 dejó sin responder. El líder del equipo, en la reunión de postmortem, preguntó "¿quién revisó esta lógica de impuestos?" y la respuesta que recibió —dos personas distintas la tocaron, ninguna escribió toda la lógica a mano, nadie puede reconstruir con precisión quién debería haberla atrapado— no es un problema técnico. Es un problema de autoría sin resolver, y se resuelve con una sola regla, aplicada de forma consistente antes de que el primer PR generado por un agente llegue a producción, no después del primer incidente.

Conexión con el módulo: esta es la primera de las cinco lecciones de frente que anunció la lección 1, y corresponde exactamente a la fila "Autoría y responsabilidad" de su tabla. Todo lo que sigue en esta lección da por sentado que ya trabajaste con un agente lo suficiente como para saber que el código que produce puede ser indistinguible, línea por línea, del que escribirías tú —que es precisamente lo que hace que la pregunta "¿quién firma esto?" deje de tener una respuesta obvia por defecto y necesite una regla explícita—. La siguiente lección va a dar por sentada la regla que construyes aquí para resolver un problema relacionado pero distinto: de dónde salen las instrucciones que el agente sigue cuando tú, como autor, lo pones a trabajar.

Quién firma cuando el diff no lo escribiste tú

Piensa en el redactor de discursos de un director general. Ese redactor puede escribir cada palabra del discurso, elegir cada metáfora, pulir cada frase durante semanas. El día del evento, sin embargo, es el director general quien sube al podio, dice esas palabras en primera persona, y responde las preguntas de la prensa después. Si el discurso contiene una cifra falsa o una promesa que la empresa no puede cumplir, ningún periodista busca al redactor para pedirle explicaciones —busca al director general, aunque él no haya escrito una sola palabra—. Y esto no es ningún secreto vergonzoso: es rutina completamente normal que el redactor aparezca agradecido por su nombre en los créditos internos, sin que ese crédito le quite al director general ni un gramo de la responsabilidad por lo que dijo en público.

La razón no es que el redactor no haya hecho un trabajo real —lo hizo, y bueno—. La razón es que la responsabilidad no la determina quién movió los dedos sobre el teclado: la determina quién puso su nombre, en público, detrás del resultado final. El director general revisó el discurso (se supone), decidió pronunciarlo tal como estaba, y aceptó por adelantado que cualquier consecuencia de esas palabras cae sobre su cargo, no sobre quien las tecleó primero.

Con un agente de código pasa exactamente lo mismo, y la regla es así de simple: el autor responsable de un cambio de código es la persona que abre el pull request —o lo integra directo a la rama principal, en el caso, cada vez más raro, de que tu equipo todavía lo permita sin PR—, sin importar qué proporción de esas líneas tecleó un humano y cuánta generó un agente.

Vale la pena separar, con precisión, tres hechos técnicos distintos que Git y GitHub (o la plataforma equivalente que use tu equipo) registran, porque es fácil confundirlos:

• El autor del commit (git log, columna Author) es la identidad que firmó ese commit puntual —casi siempre la cuenta de la persona que corrió git commit, pero algunos harnesses de agente pueden agregar aquí un nombre de herramienta como coautor, como vas a ver en la última sección de esta lección.
• Quien integra el cambio (mergedBy en la API de GitHub) puede ser una persona distinta de quien lo abrió, si tu política exige una segunda persona para aprobar el merge.
• Quien abre el PR es, para efectos de esta lección y de cualquier postmortem serio, la autora o el autor de registro: la persona que decidió que ese conjunto de commits estaba listo para pedirle a otro humano que lo revisara.

Ninguno de los tres hechos anteriores le pertenece a un agente, ni debería. Un agente no tiene, en la mayoría de los repositorios bien gobernados, una cuenta con autoridad para abrir un PR de forma autónoma (y si la tiene, el tercer error común de esta lección explica por qué eso es un riesgo, no un logro de automatización). El PR necesita una persona con nombre y cuenta detrás, y esa persona es quien firma.

Ejemplo trabajado: la pregunta sin respuesta de la lección 1, con la regla aplicada

Vuelve al incidente completo de la lección 1: doscientos clientes con un cobro duplicado, causado por un error de redondeo en apply_tax, dentro de un PR de 1,800 líneas que nadie leyó línea por línea, más una segunda función de cálculo de impuesto duplicada que un tercer ingeniero agregó sin ver la primera. La pregunta del líder del equipo —"¿quién revisó esta lógica de impuestos?"— no tenía respuesta porque, en ese equipo, nadie había decidido de antemano qué determina la autoría de un cambio. Aplica ahora la regla de esta lección a los mismos dos PR.

gh pr view 482 --json number,title,author,mergedBy

Qué esperar:

{
  "number": 482,
  "title": "Add prorated billing support",
  "author": { "login": "jrivera" },
  "mergedBy": { "login": "jrivera" }
}

gh pr view 515 --json number,title,author,mergedBy

Qué esperar:

{
  "number": 515,
  "title": "Calculate tax on invoice adjustments",
  "author": { "login": "ncastillo" },
  "mergedBy": { "login": "dpatel" }
}

Dos hechos, ya sin ambigüedad: jrivera —a quien la lección 1 describía solo como "el ingeniero del día 4"— es la autora de registro del PR #482, y lo integró ella misma. ncastillo —"el tercer ingeniero"— es el autor de registro del PR #515, que integró una segunda persona, dpatel, como aprobadora requerida. Cuatro nombres, no una nube difusa de "dos personas distintas la tocaron".

Con esos dos hechos, la sección de postmortem que en la lección 1 quedó sin poder llenarse ahora tiene dónde apoyarse:

## Postmortem — cobro duplicado en facturación proporcional

### PR de origen del defecto
#482 — Add prorated billing support

### Autor de registro (quien abrió el PR)
jrivera

### Asistencia de IA declarada en el PR
Sí — agente dirigido por jrivera, ver trailer `Co-Authored-By` en los commits de origen.

### Decisión concreta que causó el fallo
jrivera aprobó un PR de 1,800 líneas sin dividirlo, confiando en que las pruebas
generadas por el agente cubrían el caso de cambio de tasa a mitad de mes. Esa
cobertura nunca se verificó contra la especificación original antes de aprobar.

### PR relacionado con la lógica duplicada
#515 — Calculate tax on invoice adjustments

### Autor de registro (quien abrió el PR)
ncastillo

### Decisión concreta que causó la duplicación
ncastillo le pidió al agente una función de impuesto sin buscar antes si ya
existía una en el repositorio; el agente, viendo solo el archivo abierto, no
tenía forma de saberlo por su cuenta.

Fíjate en lo que este documento hace y que la respuesta de la lección 1 no podía hacer: nombra, para cada uno de los dos fallos, una persona con cuenta y una decisión concreta que esa persona tomó. No dice "la IA generó un error de redondeo" —el redondeo es un detalle de implementación, no una decisión—; dice qué decisión tomó jrivera (aprobar sin dividir, confiando en una cobertura sin verificar) y qué decisión tomó ncastillo (no buscar antes de generar). Ninguna de las dos frases culpa al agente, y ninguna de las dos deja la pregunta sin respuesta. Eso es, en la práctica, lo que significa "el autor es quien abre el PR": no es una frase para repetir en una política, es la diferencia entre poder llenar este documento o no poder.

Qué cambia en la revisión, en un incidente y en una evaluación de desempeño

La regla de la sección anterior no es un tecnicismo de quién hace clic en "Merge". Cambia, de forma concreta, tres momentos distintos del trabajo diario.

En la revisión, la responsabilidad de poder explicar cada línea del PR es de quien lo abrió, no de quien lo revisa. El gradiente de confianza de la lección 2 del Módulo 4 te deja decidir cuánta atención dedicarle a una revisión según el riesgo real de la tarea —pero ese gradiente decide cuánto revisas, nunca quién firma. Aunque revises con la atención mínima que el gradiente permite para una tarea de bajo riesgo, sigues siendo, sin excepción, quien firma en cuanto abres el PR. Si a jrivera le hubieran preguntado, antes de aprobar el PR #482, "¿por qué esta prueba cubre el cambio de tasa a mitad de mes?" y no hubiera podido responder con algo más específico que "el agente la generó y pasó en verde", esa era la señal —disponible antes del incidente, no después— de que el litmus test de la lección 5 del Módulo 4 todavía no se había aplicado de verdad.

En un incidente, la pregunta correcta de un postmortem nunca es "¿de quién es la culpa?" —es, como documenta la cultura de postmortems sin culpa que Google formalizó en su libro de SRE, "¿qué decisión, tomada por quién, con qué información disponible en ese momento, produjo este resultado?". "Sin culpa" no quiere decir "sin autoría": significa que nadie pierde el trabajo por haber tomado una decisión razonable con la información que tenía, pero sí se espera que esa persona explique la decisión con precisión, exactamente como lo hizo el documento de la sección anterior. "Lo generó la IA" falla esta prueba en el peor lugar posible: no nombra ninguna decisión y no nombra a nadie que la haya tomado. Es la versión, dentro de un postmortem, de la respuesta difusa de la lección 1 —y por eso no es aceptable, no porque suene mal, sino porque no responde la pregunta que un postmortem existe para responder.

En una evaluación de desempeño, el error más común es empezar a contar PR abiertos o líneas integradas como si fueran una señal directa de productividad, justo cuando un agente puede inflar ambos números sin que la persona detrás haya aportado más criterio que antes. Ya viste en la lección 1, citando el reporte DORA 2024, que el agente amplifica lo que ya existe —y un conteo crudo de volumen es exactamente la clase de métrica que un agente amplifica sin que eso signifique nada bueno. La señal que sí vale la pena evaluar es la que se deriva directamente de esta lección: la tasa de incidentes en el código que una persona firmó como autora, la calidad de las respuestas que da cuando se le pregunta por una decisión puntual, y la profundidad real de las revisiones que hace sobre el trabajo de otros. Eso mide criterio. El conteo de PR mide, cada vez más, qué tan rápido escribe un agente.

Cómo se declara la asistencia de IA sin estigma ni excusa

Nada de lo anterior significa que declarar que un agente participó en un cambio sea innecesario —al contrario: es información real que tu equipo va a necesitar más adelante, para una auditoría de licencias (lección 6), para reconstruir un incidente como el de la sección anterior, o simplemente para saber, en una retrospectiva, qué proporción del código del último trimestre pasó por un agente antes de llegar a producción. El problema no es declararlo. El problema son las dos formas en que esa declaración se tuerce.

La primera torcedura es el estigma: tratar la etiqueta "asistido por IA" como una marca de menor calidad que exige más escrutinio que el resto, o peor, como algo que la persona prefiere esconder para que su PR se revise "normal". Si tu equipo castiga —aunque sea con una ceja levantada en el canal de Slack— a quien declara la asistencia, la próxima persona simplemente deja de declararla, y pierdes exactamente la información que ibas a necesitar el día del incidente.

La segunda torcedura es la excusa: usar la misma etiqueta para bajar la guardia, propia o ajena —"no lo revisen tan a fondo, es que lo hizo la IA" o, peor todavía, decirlo uno mismo por adelantado para amortiguar una futura crítica. Esto es, en los hechos, lo opuesto exacto de la regla de esta lección: la etiqueta describe cómo se produjo el diff, no reduce en absoluto quién responde por él.

El punto medio —declaración neutral, autoría completa— ya tiene un mecanismo tan mecánico y aburrido como uno quisiera de una convención de este tipo: el trailer de Git. Muchos harnesses de agente, incluido Claude Code por defecto, agregan al pie del mensaje de cada commit que generan una línea con el formato Co-Authored-By: <nombre de la herramienta> <correo> —el mismo mecanismo de trailer que Git usa hace años para programación en pareja entre dos personas, reutilizado aquí para declarar la participación de una herramienta.

git log --oneline -1 --format="%B" 482a1c3

Qué esperar:

Add prorated billing support

Co-Authored-By: Claude <noreply@anthropic.com>

Esa línea no cambia en nada quién es el autor del commit ni de qué PR (jrivera, según el ejemplo anterior); es un dato adicional, no un traspaso de responsabilidad. Y por estar en el mensaje del commit, no en un canal de chat que se pierde en un mes, ese dato queda disponible para siempre con herramientas tan simples como:

git log --all --grep="Co-Authored-By: Claude" --oneline | wc -l

Este comando cuenta, sin señalar a nadie por nombre, cuántos commits del repositorio declaran asistencia de un agente —el tipo de cifra que sirve para una retrospectiva de equipo ("un tercio de nuestro código de este trimestre pasó por un agente, ajustemos el tiempo de revisión en consecuencia"), no para una lista de sospechosos.

La Apache Software Foundation formalizó esta misma idea como política oficial: cualquier contribución asistida por una herramienta generativa debe declarar qué herramienta se usó, y quien contribuye acepta exactamente las mismas obligaciones de licencia y de originalidad que si hubiera escrito cada línea a mano —la declaración informa, la responsabilidad no se mueve ni un milímetro. Cómo se hace cumplir esa declaración de forma automática —un hook de commit-msg, una compuerta de CI que rechaza un PR sin el trailer— es una decisión de implementación que corresponde a las guías de CI/CD de este catálogo; lo que te corresponde decidir a ti, como parte del gobierno de tu equipo, es la regla de contenido: qué se declara, en qué campo, y la confirmación explícita de que nada de esa declaración exime a quien abrió el PR de ninguna de las responsabilidades de esta lección.

Errores comunes

"Yo solo dirigí al agente" como atenuante de responsabilidad (conceptual). Qué pasa: alguien que aprobó e integró un PR, cuando algo sale mal, explica que "yo solo le pedí al agente que lo hiciera" —como si haber usado un intermediario redujera su parte de la responsabilidad, de la misma manera que un gerente que delega una tarea a un asistente se siente menos responsable del resultado. Por qué pasa: es intuitivamente fácil confundir "quién ejecutó el trabajo mecánico" con "quién responde por el resultado" —la misma confusión, en espejo, que la analogía del redactor de discursos deshace: el director general tampoco escribió una palabra, y eso nunca lo exime de nada frente a la prensa. Cómo detectarlo: si la explicación de alguien frente a un error empieza con "yo solo..." seguido de una descripción de lo poco que hizo con sus propias manos, esa frase es la señal de que está tratando la autoría como proporcional al esfuerzo tecleado, no como la regla binaria que es. Cómo corregirlo: recuerda, y haz explícito en tu equipo, que la regla de esta lección no tiene grados —quien abre el PR es cien por ciento el autor de registro, sin importar si tecleó una línea o cero.

Tratar la declaración de asistencia de IA como estigma o como excusa (conceptual). Qué pasa: un equipo castiga en la práctica a quien declara que usó un agente (con más escrutinio, con comentarios de "esto necesita más revisión que lo normal") o, en el extremo opuesto, alguien usa esa misma declaración para pedir menos revisión de la que el cambio necesita ("no hace falta que lo mires tan a fondo, es que lo hizo la IA"). Por qué pasa: la etiqueta "IA" activa dos reflejos contradictorios y ambos equivocados —desconfianza automática de un lado, permiso automático del otro— cuando el propósito real de declarar la asistencia es puramente informativo, como viste en esta lección. Cómo detectarlo: si el nivel de revisión que recibe un PR cambia solo por saber que un agente participó, sin que cambie nada sobre el riesgo real del cambio (tamaño, criticidad, reversibilidad —los mismos factores del gradiente de confianza del Módulo 4), la declaración se está usando mal en cualquiera de las dos direcciones. Cómo corregirlo: la declaración informa, el gradiente de confianza y el tamaño del cambio deciden cuánta atención recibe —nunca la etiqueta por sí sola.

Dejar que un agente abra o integre PRs con su propia identidad de Git, sin una cuenta humana como autora de registro (práctico). Qué pasa: para automatizar más el flujo, algunos equipos configuran su agente con credenciales propias —un token de una cuenta de bot dedicada— que le permiten abrir PRs o incluso hacer merge directo a main sin que ninguna cuenta humana aparezca como autora. Por qué pasa: parece una optimización razonable, del mismo tipo que automatizar las compuertas de la lección 4 —menos pasos manuales, más velocidad—, pero confunde automatizar verificaciones mecánicas (que no necesitan criterio humano) con automatizar la autoría (que, por definición de esta lección, siempre lo necesita). Cómo detectarlo: corre git log --format="%an" -20 | sort -u sobre tu rama principal; si aparece un nombre de cuenta de bot o de agente entre los autores de commits recientes, sin una cuenta humana visible en el mismo PR como quien lo abrió y aprobó, tienes exactamente este problema. Cómo corregirlo: cualquier permiso que le des a un agente para escribir en el repositorio (tema del Módulo 3, lección 4) debe terminar, sin excepción, en un PR abierto bajo la cuenta de una persona —el agente puede empujar commits a una rama, pero la cuenta que abre el PR y responde por él tiene que ser humana.

Ejercicios

Ejercicio 1 — El autor de registro en un caso de tres personas. En tu equipo, una tarea sigue este camino: una persona (Persona A) escribe la especificación completa siguiendo el Módulo 2. Otra persona (Persona B) dirige al agente, revisa el diff, y hace push de los commits a una rama, pero se va de vacaciones antes de abrir el PR. Una tercera persona (Persona C) retoma la rama, la revisa de nuevo, y abre el PR. Una cuarta persona (Persona D) lo aprueba como reviewer requerida y hace clic en "Merge". Seis meses después, ese código causa un incidente. Según la regla de esta lección, ¿quién es la autora o el autor de registro? Justifica con la definición exacta de la sección "Quién firma cuando el diff no lo escribiste tú".

Ver solución

La autora o el autor de registro es la Persona C: es quien abrió el PR, sin importar que no haya escrito la especificación (Persona A) ni haya tecleado los primeros commits (Persona B). La regla de esta lección es explícita en que la autoría la determina quién abre el PR, no quién contribuyó en el camino hasta ahí. La Persona D, al aprobar como reviewer e integrar el cambio, comparte una responsabilidad distinta —la de reviewer, no la de autora— y la Persona A y la Persona B, aunque su trabajo fue real y necesario, no son las que "firmaron" el resultado final ante el equipo.

Por qué funciona: fuerza a aplicar la definición exacta de la lección —"quien abre el PR"— a un caso con más de dos personas involucradas, donde la tentación de repartir la autoría "en partes iguales" según el esfuerzo de cada quien es más fuerte que en el ejemplo de dos personas de la lección.

Ejercicio 2 — Reescribe la respuesta de postmortem. Un compañero, en un postmortem real, respondió así a la pregunta "¿por qué se aprobó este cambio?": "La verdad es que el agente generó casi todo, yo solo revisé por encima porque confiaba en que las pruebas que también generó cubrían los casos importantes. No sabría decirte exactamente qué pasó." Usando el formato del documento de postmortem de esta lección (autor de registro, decisión concreta), reescribe esa respuesta en dos frases que sí serían aceptables en un postmortem.

Ver solución

Una reescritura posible: "Yo abrí y aprobé este PR, y la decisión concreta que tomé fue confiar en la cobertura de las pruebas generadas por el agente sin verificar contra la especificación original si cubrían el caso límite que causó el incidente. Antes de aprobar un PR similar en el futuro, voy a aplicar el litmus test de la lección 5 del Módulo 4 antes de dar por buena cualquier prueba que no escribí yo mismo."

Ambas frases nombran a la persona que responde como autora de registro (primera persona, sin diluir con "el agente" como sujeto de la oración) y nombran una decisión concreta y verificable ("confiar en la cobertura sin verificarla contra la especificación"), no un estado de ánimo difuso ("revisé por encima"). Eso es exactamente lo que separa la respuesta original —que no nombra ninguna decisión ni la conecta a ninguna causa concreta— de una respuesta que un postmortem sin culpa puede usar de verdad.

Por qué funciona: aplica el mismo estándar que separó la respuesta difusa de la lección 1 del documento de postmortem corregido de esta lección —nombrar la decisión, no solo el sentimiento o el nivel de esfuerzo.

Ejercicio 3 — Clasifica la declaración. Tres mensajes de commit, cada uno de un compañero distinto:

Commit A: "Fix rate limit off-by-one.

Co-Authored-By: Claude <noreply@anthropic.com>"

Commit B: "Refactor auth module — heads up, this one's mostly AI-generated so
don't spend too much time reviewing it, it already passed all the tests."

Commit C: "Add CSV export endpoint" (sin ningún trailer ni mención de
asistencia, aunque la mitad del equipo sabe que esta persona usa un agente
para casi todo su código)

¿Cuál de los tres declara la asistencia de forma neutral, cuál la usa como excusa, y cuál la esconde? Para cada uno, nombra el riesgo concreto que crea para el equipo.

Ver solución

Commit A es la declaración neutral: informa qué herramienta participó, en un trailer que queda para siempre en el historial, sin pedir ni más ni menos escrutinio del que el cambio merecería de todas formas. No crea ningún riesgo adicional.

Commit B usa la declaración como excusa: pide explícitamente menos revisión por el solo hecho de que un agente participó, exactamente el segundo error común de esta lección. El riesgo es que "pasó todas las pruebas" —como viste en la lección 4 del Módulo 4— nunca fue suficiente para saber si esas pruebas prueban lo correcto, y esta persona está pidiéndole al equipo que se salte precisamente la verificación que lo confirmaría.

Commit C esconde la asistencia: no hay trailer, no hay declaración, solo conocimiento informal de "la mitad del equipo". El riesgo es exactamente el que describe la sección de esta lección sobre por qué la declaración importa: el día que ese código esté en un incidente o en una auditoría de licencias (lección 6), no va a existir ningún registro mecánico y buscable de que un agente participó —solo el recuerdo, poco confiable, de quién se acuerda de qué.

Por qué funciona: aplica la distinción de "ni estigma ni excusa" de esta lección a tres casos que, a primera vista, podrían parecer variaciones inocentes del mismo hábito, y muestra que solo uno de los tres es, en los hechos, neutral.

Resumen y siguiente paso

Ya puedes aplicar la regla que decide, sin ambigüedad, quién es la autora o el autor de registro de un cambio de código: quien abre el PR, nunca la herramienta que generó el diff, y nunca en proporción a cuántas líneas tecleó cada persona involucrada. Puedes nombrar, con el mismo incidente de la lección 1 ya resuelto, qué cambia esa regla en una revisión (la autora sigue firmando aunque el gradiente de confianza le permita revisar menos), en un incidente (un postmortem sin culpa pregunta por la decisión y quién la tomó, nunca "de quién es la culpa", y "lo generó la IA" no nombra ninguna de las dos cosas) y en una evaluación de desempeño (la tasa de incidentes y la profundidad de revisión de una persona importan más que el volumen de PR que un agente le permite integrar). Y sabes cómo declarar la participación de un agente con un mecanismo tan aburrido y confiable como un trailer de Git, sin que esa declaración se convierta ni en estigma ni en excusa.

Antes de avanzar a la lección 3 deberías poder: explicar en una frase por qué "yo solo lo dirigí" no reduce la responsabilidad de quien abre un PR; distinguir, frente a una respuesta de postmortem real, si nombra una decisión y a su autor o si es una versión disfrazada de "lo generó la IA"; y reconocer, frente a un mensaje de commit con o sin declaración de asistencia, cuál de las tres torceduras de esta lección —estigma, excusa, o ninguna— está ocurriendo.

La siguiente lección da un paso atrás en el tiempo: si tú eres el autor de cualquier cambio que tu agente produzca, la pregunta que sigue es de dónde salen las instrucciones que ese agente sigue cuando lo pones a trabajar —y qué pasa cuando esas instrucciones viven en la cabeza de cada quien, en vez de en un archivo que tu equipo pueda versionar, revisar y auditar igual que el código mismo.

Recursos

• Apache Software Foundation — Generative Tooling Guidance — la política oficial que exige declarar el uso de herramientas generativas en una contribución y reafirma que la persona que contribuye conserva las mismas obligaciones de licencia y originalidad, citada en la sección sobre cómo declarar la asistencia de IA.
• Google SRE Book — Postmortem Culture: Learning from Failure — el capítulo que formaliza la cultura de postmortems sin culpa y la distinción entre no castigar a una persona y no dejar de nombrar la decisión que tomó, base de la sección sobre qué cambia en un incidente.
• GitHub Docs — Creating a commit with multiple authors — el mecanismo del trailer Co-Authored-By que esta lección reutiliza para declarar la asistencia de un agente en un commit.
• Git — git-interpret-trailers — la documentación oficial del mecanismo de trailers de Git sobre el que se apoya cualquier convención de declaración de asistencia, incluido Co-Authored-By.
• GitHub Docs — About code owners — el mecanismo con el que un repositorio real exige que una cuenta humana específica apruebe un cambio antes de integrarse, la contraparte técnica de "quién firma" en un repositorio gobernado.