¿Por qué VS Code firmó tus commits también por Copilot?

VS Code añadió a Copilot como coautor de commits sin avisar y abrió un debate serio sobre autoría, IA y confianza en código profesional real.

Visual Studio Code acabó en el centro de una tormenta muy propia de esta época: una herramienta de desarrollo modificó la firma de commits de Git para añadir a Copilot como coautor sin que muchos usuarios lo vieran antes de confirmar el cambio. La línea que apareció en el historial fue Co-authored-by: Copilot [email protected], una etiqueta pensada para reconocer la intervención de la inteligencia artificial cuando realmente participa en el código, pero que terminó saliendo donde no debía: en commits sin Copilot, incluso con funciones de IA desactivadas en algunos casos.

El origen está en la opción git.addAICoAuthor, introducida en VS Code 1.110 con el valor por defecto en off, es decir, desactivada. Luego, con el despliegue público de la versión 1.117 iniciado el 22 de abril de 2026, Microsoft cambió ese comportamiento por defecto a all, la opción más amplia, y el editor empezó a añadir la atribución de Copilot de forma automática en commits hechos desde VS Code. Tras las quejas, la compañía reconoció el fallo, rebajó el comportamiento en VS Code 1.118 y anunció la vuelta a off en la versión 1.119, cuyo despliegue público arrancaba el 6 de mayo de 2026.

El pequeño texto que incendió a los desarrolladores

En Git, un commit no es una nota cualquiera. Es la huella de una decisión, el sello que queda pegado al historial de un proyecto y que permite saber quién cambió qué, cuándo lo hizo y, muchas veces, por qué. Para quien mira desde fuera, puede parecer una línea administrativa, una etiqueta sin sangre. Para quien trabaja con repositorios, auditorías, revisiones de código, licencias, responsabilidad profesional o proyectos abiertos, esa línea pesa. No pesa como una losa, pero pesa. Tiene consecuencias.

Por eso la polémica no nació de una alergia infantil a la inteligencia artificial, aunque también haya mucho ruido tribal alrededor de Copilot, Microsoft y todo lo que huela a automatización. El enfado fue más preciso. VS Code alteraba el mensaje final del commit añadiendo una coautoría que el usuario no siempre había aceptado, no siempre había visto y no siempre correspondía con lo ocurrido. Es como firmar una crónica con dos nombres cuando solo uno estuvo delante del incendio. Luego vendrán los matices, las excusas técnicas, el botón oculto en ajustes. Pero el historial ya quedó tocado.

La función, sobre el papel, tenía una intención defendible. Si una IA ayuda a escribir código, resulta razonable dejar constancia. No por puritanismo, sino por trazabilidad. Cada vez más equipos quieren saber cuándo ha intervenido un asistente, qué parte del trabajo se ha generado con ayuda automatizada y cómo se audita después. El problema fue el camino elegido. En vez de funcionar como una decisión clara, visible y consentida, el mecanismo acabó pareciendo una firma metida por debajo de la puerta. La clase de automatismo que parece pequeño hasta que aparece en producción, en un repositorio público o en una revisión de seguridad.

La documentación de VS Code explicaba que la opción podía añadir automáticamente un trailer Co-authored-by: cuando el commit incluía contribuciones generadas por IA, y que solo afectaba a commits realizados desde el propio editor, no desde herramientas externas de Git ni desde la línea de comandos. Ese detalle importa: no hablamos de Git como sistema global, sino de la integración de Git dentro de Visual Studio Code. El bisturí estaba en el editor, no en todo el quirófano.

La opción git.addAICoAuthor y el giro que no se explicó bien

La opción conflictiva tenía tres valores principales. Con off, VS Code no añadía ninguna atribución a Copilot. Con chatAndAgent, la etiqueta se aplicaba cuando el código procedía de Copilot Chat o del modo agente. Con all, el editor podía añadir la firma por cualquier tipo de código generado con IA, incluidas sugerencias en línea. Ahí está el corazón del asunto: all era la opción más expansiva, la que convertía la atribución en una red muy ancha. Y una red demasiado ancha, en desarrollo, acaba pescando botas viejas.

En VS Code 1.110, esa función llegó desactivada por defecto. Era una novedad más dentro del ecosistema Copilot: útil para equipos que quisieran marcar la intervención de la IA, irrelevante para quienes no quisieran hacerlo, relativamente limpia porque exigía que alguien moviera la palanca. La historia cambió cuando el valor por defecto dejó de ser off. Microsoft explicó después que en VS Code 1.117 el ajuste pasó a all, y que un bug no detectado en pruebas atribuyó a Copilot contribuciones que no eran de Copilot. Es decir, no solo había un debate sobre consentimiento; también había un fallo de detección.

Ahí se rompió la porcelana. Varios desarrolladores empezaron a ver la firma de Copilot en commits en los que aseguraban no haber usado Copilot. Otros indicaron que tenían las funciones de IA deshabilitadas. En una incidencia abierta el 28 de abril de 2026, un usuario describió que la línea aparecía “por alguna razón” en sus mensajes de commit, pese a no usar Copilot para editar código ni escribir esos mensajes; añadió que lo descubrió al revisar la salida de CI y después el registro de Git. La etiqueta no era una sugerencia visible en una caja de texto. Era un añadido posterior, una pequeña sombra al final del commit.

Y claro, el detalle técnico se convirtió enseguida en un problema de confianza. Porque no es lo mismo que una herramienta proponga una frase a que la incruste después. No es lo mismo que avise a que actúe. No es lo mismo que diga “esto podría llevar atribución de IA” a que coloque el nombre de Copilot como coautor en una pieza de trabajo que quizá salió de una cabeza humana, una madrugada, con café malo y un bug imposible. La diferencia parece fina, pero en software las diferencias finas suelen ser las que separan una ayuda de una intromisión.

Por qué una coautoría no es una pegatina inocente

La palabra coautor tiene una carga que la industria tecnológica no puede tratar como si fuera una pegatina de equipaje. En GitHub, en repositorios corporativos, en proyectos de código abierto o en entornos con compliance, la autoría sirve para reconstruir decisiones. Puede afectar a revisiones internas, a métricas, a responsabilidad sobre cambios sensibles, a normas de contribución y a la percepción de un trabajo. Copilot no firma contratos, no responde a una auditoría, no comparece en una retrospectiva de equipo con cara de sueño. Un modelo puede asistir. Otra cosa es figurar como coautor.

Ese matiz apareció también en la propia discusión técnica. Una petición abierta en el repositorio de VS Code planteó que, para agentes de IA, quizá sería más adecuado usar Assisted-by en lugar de Co-authored-by, precisamente porque la coautoría humana implica beneficios, responsabilidades y significados que una herramienta no puede asumir. La propuesta encaja con una idea cada vez más extendida: la IA puede haber ayudado, pero el humano sigue siendo quien decide, integra, revisa y responde. El robot pone manos invisibles; la responsabilidad, de momento, sigue teniendo nómina.

El caso también toca una fibra incómoda para Microsoft. VS Code no es un editor marginal, sino una de las herramientas más utilizadas por desarrolladores de todo el mundo, con un pie en el código abierto y otro en el ecosistema comercial de GitHub, Copilot y servicios asociados. Cuando un cambio así llega de forma silenciosa, la sospecha aparece sola: si Copilot figura como coautor en millones de commits, aunque sea por accidente o por un ajuste torpe, también gana visibilidad simbólica. Es marca dentro del historial. Un pequeño cartel en cada pared recién pintada.

La lectura más generosa dice que Microsoft intentó resolver un problema real —la atribución del código asistido por IA— y lo hizo mal. La lectura menos generosa ve un patrón de la industria: productos que activan funciones por defecto, fuerzan opt-out y luego llaman “mejora” a lo que muchos usuarios entienden como invasión. La verdad probablemente vive en una zona gris, esa habitación con fluorescentes donde se mezclan producto, métricas, IA, prisas de lanzamiento y poca sensibilidad hacia el oficio de quienes usan la herramienta ocho horas al día.

El fallo que obligó a Microsoft a recular

La respuesta oficial llegó en GitHub, con una explicación bastante clara. Microsoft reconoció que el ajuste había nacido en 1.110 con off como valor por defecto, que en 1.117 se cambió a all y que hubo un bug que hizo aparecer la atribución en código no relacionado con Copilot, incluso cuando disableAIfeatures estaba activado. Después, en 1.118, el comportamiento se movió a chatAndAgent, más limitado, y para 1.119 se anunció la vuelta a off junto con una garantía adicional: si las funciones de IA están desactivadas, la atribución no debe aplicarse aunque otro ajuste diga lo contrario.

La compañía también admitió que revisaría sus procesos de prueba y lanzamiento para evitar casos parecidos. No es una frase menor, aunque suene a ese idioma corporativo de moqueta y café de cápsula. Aquí falló algo más que una línea de configuración. Falló la detección, falló la experiencia de usuario, falló el aviso previo y falló la comprensión de lo delicado que resulta tocar el historial de Git. Un editor puede sugerir, completar, colorear, advertir. Pero cuando modifica el registro permanente de un proyecto, entra en otra liga.

El compromiso posterior fue más allá de devolver el valor por defecto a off. Microsoft indicó que la atribución no se aplicará nunca a cambios que no estén relacionados con IA y que, antes de añadir un trailer al commit, el usuario deberá dar consentimiento, sin depender del valor por defecto. También dejó abierta la posibilidad de revisar el propio mensaje de atribución, incluida una alternativa tipo Assisted-by, más ajustada al papel real de una herramienta de inteligencia artificial.

Ese giro confirma algo obvio y, aun así, necesario: el consentimiento no puede esconderse en una configuración recóndita. En desarrollo, los defaults mandan. La mayoría de usuarios no vive buceando en cada opción nueva de cada actualización. Actualizan, trabajan, hacen commit, siguen. Si una herramienta cambia el sentido de una operación tan sensible, debe decirlo a plena luz. No con una nota enterrada. No con una casilla que aparece cuando ya se ha montado el incendio. Con claridad. La tecnología adulta empieza ahí, en no tratar al usuario como un figurante.

Qué pueden revisar los usuarios de VS Code

Quien haya usado VS Code para hacer commits durante el periodo afectado puede encontrarse la línea de Copilot en su historial. Lo importante es entender el alcance: el añadido se aplicaba a commits hechos desde el control de código fuente de VS Code, no necesariamente a commits realizados desde la terminal externa o con otros clientes de Git. Esa frontera, para muchos equipos, será la diferencia entre un susto localizado y una limpieza mucho más amplia.

La forma más directa de impedir la atribución automática es fijar explícitamente "git.addAICoAuthor": "off" en la configuración del editor. También puede hacerse desde los ajustes de VS Code buscando la opción relacionada con añadir coautor de IA en Git. En versiones corregidas, el valor por defecto vuelve a ser más prudente, pero fijarlo manualmente evita sorpresas en entornos donde la autoría es sensible. Para equipos profesionales, no es paranoia; es higiene. Como mirar el diff antes de fusionar una rama. Como no desplegar un viernes a las seis, aunque siempre haya alguien que jure que esta vez no pasa nada.

Después está la cuestión de los commits ya creados. Git permite reescribir historial, sí, pero hacerlo no siempre es trivial ni recomendable. En repositorios compartidos o públicos puede romper referencias, obligar a coordinar ramas, alterar hashes y generar una pequeña nevada de problemas secundarios. Si la línea ya llegó a un repositorio remoto, conviene valorar caso por caso. En un proyecto personal quizá se puede limpiar sin drama. En una organización, tocar historia publicada exige prudencia, comunicación y criterio técnico. El remedio, a veces, mancha más que la gota original.

El episodio deja además una advertencia para quienes usan cualquier asistente de código, no solo Copilot. La IA se está metiendo en el flujo de trabajo por capas: autocompletado, chat, agentes, generación de mensajes de commit, búsqueda semántica, revisión de cambios. Algunas capas son visibles; otras actúan como el polvo fino sobre una mesa negra, no lo ves hasta que pasa el dedo. Conviene revisar qué funciones están activas, qué datos salen, qué metadatos se añaden y qué políticas tiene cada equipo. No por miedo teatral a la máquina, sino por profesionalidad básica.

La batalla real: transparencia, no nostalgia

Hay una tentación cómoda: convertir este caso en otro capítulo de la guerra cultural entre desarrolladores “auténticos” y usuarios de IA. Sería demasiado simple. La cuestión no es si Copilot ayuda o estorba, si escribir código con IA es hacer trampas o si el programador romántico debe volver al Vim iluminado por una vela. La cuestión seria es otra: quién controla el rastro que queda en un proyecto de software. Y ese control no puede depender de decisiones silenciosas tomadas por una actualización.

La atribución de IA tiene sentido cuando es precisa, proporcional y visible. Puede servir para auditorías, para investigación, para seguridad, para entender cómo se construye el software moderno. Pero si se hace mal, contamina la señal. Si Copilot aparece como coautor donde no intervino, la etiqueta deja de informar y empieza a deformar. Peor todavía: perjudica la confianza en los mecanismos legítimos de transparencia. Una mala alarma no vuelve más seguro el edificio; solo consigue que la gente ignore la sirena.

También hay un punto de lenguaje. Coautor no es lo mismo que asistente. Un coautor participa de una obra en un plano reconocible de responsabilidad y agencia. Una herramienta puede sugerir una función, completar una línea, ordenar un bloque, incluso generar una parte sustancial del código. Pero el marco legal, ético y profesional todavía está digiriendo qué significa eso. Poner la palabra equivocada en el sitio equivocado no es un detalle semántico. Es dejar una brújula cerca de un imán y luego fingir sorpresa porque el norte baila.

Microsoft ha corregido el rumbo, al menos en lo declarado. La vuelta a off, el compromiso de pedir consentimiento y la revisión del formato de atribución apuntan a una salida razonable. Pero la herida reputacional queda como aviso. En herramientas de desarrollo, la confianza se gana en silencio durante años y se pierde con una línea invisible al final de un commit. Qué ironía, por cierto: tanto hablar de inteligencia artificial y al final el problema fue bastante humano. Una decisión por defecto, pruebas insuficientes, comunicación pobre. El clásico.

Cuando una firma automática dice demasiado

El caso de VS Code y Copilot no va solo de una etiqueta molesta. Va de poder por defecto. En el software moderno, quien decide los ajustes iniciales decide buena parte del comportamiento real de millones de personas. Un botón activado o desactivado puede cambiar prácticas de trabajo, generar metadatos, alterar historiales y mover normas culturales sin necesidad de grandes discursos. La revolución, a veces, llega con una casilla marcada.

Para los desarrolladores, la lección es sobria: revisar la configuración del editor ya no es una manía de perfeccionistas, sino parte del trabajo. Para Microsoft, la lección debería ser todavía más clara: no se toca la autoría sin permiso explícito. Y para la industria de la IA aplicada al código, el mensaje queda escrito con tinta bastante negra: la transparencia no consiste en poner a la máquina en todas partes, sino en decir exactamente cuándo ha estado allí. Copilot puede ayudar mucho. Pero colarse como coautor donde no ha trabajado es otra cosa. Eso no es asistencia. Es ruido en el acta.