Claude Code coautor en commits: el giro de un desarrollador

El cambio de postura

Indradhanush Gupta, desarrollador con años de trayectoria, publicó este mes un post en su blog explicando que dejará de añadir a Claude Code como coautor en sus commits de Git, tras más de un año haciéndolo de forma explícita. Su razonamiento es directo: cuando un commit lleva tu nombre, la responsabilidad del trabajo — incluidos los bugs que aparezcan después — es tuya por completo, no de la herramienta que usaste para escribirlo.

El debate no es menor. Para 2026, el uso de asistentes de IA para programar dejó de ser opcional en la mayoría de empresas tech, según múltiples encuestas sectoriales. Claude Code, lanzado por Anthropic en mayo de 2025, fue nombrado favorito por casi la mitad de los desarrolladores encuestados en un relevamiento citado por Forbes en junio de 2026. La propia Microsoft había permitido a miles de sus ingenieros usar Claude Code con licencia corporativa hasta diciembre de 2025, antes de moverlos a su propio Copilot CLI en junio de 2026 por motivos de costo. La herramienta que Gupta decide dejar de acreditar es, según estos datos, una de las más usadas del mercado.

La analogía del carpintero y el serrucho

El argumento central de Gupta es una analogía que se ha viralizado en redes técnicas como Hacker News y Bluesky: «un carpintero firma su trabajo, pero no firma el nombre de la sierra con la que cortó la madera». Aplicado al código, añadir al LLM como coautor se siente igual: estás atribuyendo la herramienta, no el trabajo.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Su punto más punzante es el de la responsabilidad. En sus palabras: añadir la IA como coautora abre la puerta a escurrir el bulto ante errores — «oops, fue la IA la que no tuvo cuidado». Si el commit está bajo tu nombre, lo firmas tú. Completo. Y eso vale tanto para un script de side project como para código que va a producción.

Gupta también trae un antecedente útil: hace unos años, nadie habría añadido a Google o Stack Overflow como coautor de su código, aunque los snippets vinieran directamente de ahí. Sí era habitual enlazar la respuesta que resolvió el problema. La misma lógica debería aplicarse ahora con los modelos generativos, sostiene.

Cuando Microsoft ya intentó imponer la coautoría de la IA

No es solo una opinión aislada. La industria viene forcejeando con el mismo problema. Según TechSpot, un pull request en Visual Studio Code efectivamente convirtió a GitHub Copilot en coautor de todos los commits de cada proyecto, incluso de usuarios que no habían activado ninguna función de IA — incluyendo quienes la tenían deshabilitada explícitamente. La PR fue revisada y aprobada por Dmitriy Vasyura, ingeniero principal de Microsoft en el proyecto VS Code. Tras el rechazo de la comunidad, Microsoft atribuyó el cambio a un bug en su entorno de pruebas y lo revirtió. Una versión futura añadirá la atribución de Copilot solo cuando haya cambios generados por IA y con consentimiento explícito del usuario.

El episodio es relevante por dos razones. Primero, demuestra que la pregunta «quién firma este commit cuando una IA intervino» ya está sobre la mesa en los proyectos open source más usados del mundo. Segundo, muestra que la transparencia forzada genera rechazo, incluso entre desarrolladores que usan IA a diario.

Cuándo la coautoría sí tiene sentido

Gupta no es absolutista. Reconoce al menos dos escenarios donde añadir al LLM como coautor es razonable, o incluso útil:

Cuando estás evaluando distintos modelos para una tarea similar y necesitas distinguir rápidamente qué salida vino de cada uno.
Cuando el LLM crea el pull request y tú eres el revisor humano: la atribución deja claro quién escribió el código y quién lo aprobó.

Para quienes quieran mantener la transparencia sin firmar con la IA, Gupta sugiere dos alternativas prácticas: crear una cuenta específica de IA que commitee con tu nombre visible, o añadir un disclaimer claro en el README del proyecto (algo así como «AI slop, there be dragons»), del mismo modo que se advertiría sobre un hack no probado. Para cualquier cosa seria, dice, asume la autoría completa.

Qué significa esto para tu startup

Para equipos de ingeniería que ya usan asistentes de IA — que en 2026 son prácticamente todos — esta no es una discusión filosófica abstracta. Tres acciones concretas:

Define por escrito tu política de atribución de IA. Si tu equipo usa Claude Code, GitHub Copilot, Codex u otra herramienta, documenta en el engineering handbook si los commits llevarán coautoría del LLM, en qué casos y con qué formato. La decisión de Gupta solo funciona si es explícita y consistente; de lo contrario, cada dev resuelve por su cuenta y el historial de Git se vuelve inconsistente.
Separa la IA de la cadena de responsabilidad. En código de producción o entregado a clientes, asume autoría completa y verifica antes de desplegar. En prototipos, spikes o experimentos internos, la atribución puede ayudar a distinguir qué partes son tuyas y cuáles asistidas — pero no te exime de validar lo que pase a producción.
No impongas atribución de IA sin consentimiento en tu propio producto. El incidente de Microsoft con VS Code dejó una lección: si tu SaaS integra agentes de código o contenido generado, haz que la atribución de IA sea opt-in y configurable. Forzarla no mejora la transparencia; solo genera rechazo y migración a la competencia.

Para founders que están construyendo productos con IA en el centro, este debate también redefine qué significa «propiedad intelectual» en el repositorio: si el código lo firmas tú, lo entiendes tú, y lo puedes defender ante un cliente, regulador o inversor. Si la IA lo firma, nadie puede responder por él.