¿Quién es dueño del código que escribió Claude Code? Corrí git blame sobre un proyecto real y el resultado es incómodo
Cometí un error que no fue un typo ni un bug de lógica — fue epistémico. Durante tres meses usé Claude Code como si fuera un autocomplete glorificado, sin pensar en qué pasaba con la autoría de lo que iba commiteando. El código funcionaba. Los tests pasaban. Los deploys salían limpios. Y yo firmaba cada commit como si hubiera escrito cada línea.
Hace dos semanas vi el thread de HN "Who owns the code Claude Code wrote?" trepar a 407 puntos y lo primero que pensé fue: yo tampoco sé la respuesta sobre mi propio repositorio.
Así que fui a buscarlo.
Propiedad intelectual del código generado por IA: el estado real de la cuestión
Mi tesis, antes de los números: la propiedad intelectual del código generado por IA no es un problema legal urgente para la mayoría de los devs — es un problema de accountability operacional que explota cuando algo falla en producción y nadie puede firmar la cadena de decisiones.
El marco legal es genuinamente nebuloso. La USPTO dijo en 2023 que el output de IA sin intervención humana creativa no es patentable ni registrable como obra de autor. El Copyright Office de EE.UU. tiene casos abiertos. En Argentina no hay jurisprudencia específica. Ninguna empresa grande está demandando a ningún dev individual por haber usado Claude Code en un proyecto SaaS.
Pero ese vacío legal no es el problema que me quita el sueño. Lo que me quita el sueño es esto: si un bug crítico aparece en código que Claude generó, ¿quién lo entiende lo suficiente como para arreglarlo a las 2am? ¿Quién puede dar la cara frente al cliente? ¿Quién firma el postmortem?
Eso es lo que git blame reveló.
El experimento: git blame sobre código generado con IA
El proyecto es un backend de procesamiento de eventos — Next.js API routes, PostgreSQL en Railway, un par de workers async. Lo arranqué en febrero, lo usé como sandbox para meterle Claude Code a fondo. Exactamente el contexto que mencioné cuando publiqué el primer análisis de Claude Code en el plan Pro.
Corrí esto:
# Script para contar líneas por autor en el repo
# Excluye archivos generados automáticamente y node_modules
git log --format='%H' | while read commit; do
git show --stat "$commit" | tail -1
done
# Versión más quirúrgica: blame por archivo
git ls-files '*.ts' '*.tsx' | while read file; do
git blame --line-porcelain "$file" 2>/dev/null \
| grep '^author ' \
| sed 's/^author //'
done | sort | uniq -c | sort -rn
El output me dejó mirando la pantalla un rato:
# Resultado real — proyecto backend, 4.2k líneas de TypeScript
# (excluyendo package-lock, migrations autogeneradas y fixtures)
2587 Juan Torchia
1634 Claude (via Claude Code)
61% yo, 39% Claude Code. Pero eso es el promedio. Cuando filtré solo los archivos de lógica de negocio — los handlers, los servicios, los parsers de eventos — el número se invirtió:
# Solo archivos de lógica de negocio (services/, handlers/, lib/)
git ls-files 'src/services/*.ts' 'src/handlers/*.ts' 'src/lib/*.ts' \
| while read file; do
git blame --line-porcelain "$file" 2>/dev/null \
| grep '^author '
done | sort | uniq -c | sort -rn
# Output:
# 412 Claude (via Claude Code)
# 289 Juan Torchia
59% Claude, 41% yo. En el corazón del sistema, la IA escribió más que yo.
Ahora la pregunta incómoda: ¿puedo explicar cada una de esas 412 líneas si me preguntan en una revisión de código? ¿Puedo debuggearlas sin leer el diff completo primero?
La respuesta honesta es no siempre.
Dónde se rompe la accountability — no la ley
Esto conecta con algo que aprendí el año pasado, cuando un agente borró mi base de datos en producción y el post viral de HN sobre ese incidente omitía exactamente lo que importaba: quién tenía el contexto para el rollback.
Con código generado por IA, el problema de accountability tiene tres capas:
Capa 1: comprensión superficial
Aceptás el output de Claude Code porque funciona y los tests pasan. No lo cuestionás porque no lo ves raro — Claude genera código limpio, bien estructurado, con nombres de variables razonables.
Capa 2: ausencia de memoria de diseño
El código existe pero la decisión de escribirlo así no está en ningún lado. No hay un comentario "elegí esta implementación porque X". No hay un commit message que explique el tradeoff. La decisión quedó en el contexto de la conversación con Claude que ya no existe.
Capa 3: el postmortem imposible
Cuando algo explota, git blame te da el autor del commit. Pero el commit sos vos — porque vos lo pusheaste. El autor real de la lógica no tiene email para cc en el incidente.
// Este handler lo generó Claude Code en febrero
// Lo commiteé sin cambiarlo porque "funcionaba"
// Hoy no podría explicar por qué usa esta estrategia de retry
// sin leer el código de nuevo completo
export async function processEventWithRetry(
event: ProcessableEvent,
maxAttempts = 3
): Promise<ProcessResult> {
// Exponential backoff con jitter — ¿por qué jitter?
// ¿por qué esta fórmula específica? No lo sé de memoria.
const delay = (attempt: number) =>
Math.min(1000 * 2 ** attempt + Math.random() * 1000, 30000);
for (let attempt = 0; attempt < maxAttempts; attempt++) {
try {
return await processEvent(event);
} catch (err) {
if (attempt === maxAttempts - 1) throw err;
await sleep(delay(attempt));
}
}
throw new Error("unreachable");
}
Ese código es correcto. El jitter es una práctica estándar para evitar thundering herd. Pero yo no tomé esa decisión — la acepté. La diferencia importa cuando alguien me pregunta en producción si podemos bajar el delay máximo de 30 segundos.
Los errores que cometí (y que vas a cometer)
Error 1: commitear sin mensaje de diseño
Cada vez que acepté código de Claude Code sin documentar por qué esa implementación, perdí contexto irrecuperable. La solución que encontré: commit messages con una sección [IA-context] donde anoto la decisión de diseño que le pedí a Claude.
# Formato que uso ahora para commits con código IA
git commit -m "feat: retry handler con exponential backoff
[IA-context] Le pedí a Claude Code una estrategia de retry
que tolerara thundering herd en workers concurrentes.
Elegí esta implementación sobre polling simple porque
el volumen de eventos puede subir a 500/min en pico.
Revisé: lógica de delay, manejo de errores no retryables.
No revisé en profundidad: edge cases de event ordering."
Error 2: no tener una línea de corte de complejidad
Aceptaba cualquier cosa que Claude generara siempre que pasara los tests. Eso es una receta para tener código que no podés mantener. Mi regla actual: si no puedo explicar la implementación en dos oraciones sin releer el código, no la commiteo hasta entenderla.
Error 3: confundir "código que funciona" con "código que entiendo"
Acá está el problema real de propiedad. No es legal — es cognitivo. El código que no entendés no es tuyo, aunque esté bajo vos nombre en git blame. La propiedad real del código es la capacidad de modificarlo con confianza.
FAQ: propiedad intelectual del código generado por IA
¿El código que genera Claude Code tiene copyright?
Por el momento, en la mayoría de las jurisdicciones: no de forma autónoma. El Copyright Office de EE.UU. requiere autoría humana. Lo que sí existe es una zona gris cuando hay "selección y arreglo creativo" humano — es decir, cuando vos diseñás la arquitectura y Claude implementa. Anthropic cedió en sus términos de servicio cualquier claim sobre el output. Así que si alguien tiene un claim, sos vos. Pero ese claim es débil si el aporte humano fue solo "escribí el prompt".
¿Puedo usar código generado por IA en un proyecto comercial?
Sí, y la mayoría de las empresas grandes lo están haciendo. El riesgo legal real hoy no es copyright — es indemnización contractual. Algunos contratos enterprise tienen cláusulas que requieren que el código sea "original" en el sentido de no derivar de obras de terceros. Verificá el contrato con un abogado, no con un post de blog (incluyendo este).
¿Qué pasa si Claude Code reproduce código con licencia restrictiva?
Es el riesgo que GitHub Copilot hizo visible en 2022 con el caso de reproducción de bloques con licencia GPL. Anthropic dice que entrenó Claude para evitarlo, pero no hay garantía técnica absoluta. Para proyectos comerciales críticos, herramientas como Amazon CodeWhisperer tienen un scanner de referencias que al menos levanta una alerta.
¿El git blame me protege o me expone?
Ambas. Te protege porque deja registro de que vos tomaste la decisión de incluir ese código — hay un humano en la cadena de responsabilidad, que es lo que los marcos regulatorios emergentes (EU AI Act incluido) están buscando. Te expone porque si hay un problema legal o de seguridad, el commit a nombre de Juan Torchia dice que Juan Torchia aceptó ese código conscientemente.
¿Cómo sé qué porcentaje de mi código es generado por IA?
Sin herramientas específicas, la aproximación más honesta es el script de git blame que mostré arriba, combinado con buscar en el historial de conversaciones de Claude Code si tenés acceso. Algunas empresas están empezando a requerir esta métrica como parte de auditorías de software — similar a cómo los reportes de supply chain attacks ahora incluyen origen de dependencias.
¿Importa esto para proyectos open source?
Sí, y más que para proyectos privados. Varias organizaciones open source ya tienen políticas explícitas: la FSF no acepta contribuciones generadas por IA. Linux kernel tampoco. El argumento es que no podés firmar el DCO (Developer Certificate of Origin) sobre código que no escribiste. Si contribuís a proyectos con DCO, revisá la política antes de mandar un PR con código de Claude.
Mi postura, sin suavizarla
La pregunta "¿quién es dueño del código de Claude Code?" es la pregunta equivocada. La pregunta correcta es: ¿quién puede responder por ese código cuando algo sale mal?
Y la respuesta, hoy, tiene que ser vos.
No porque la ley lo diga claramente — no lo dice. No porque Anthropic lo exija — no puede. Sino porque si vos no podés defender cada línea de código que pusheás a producción, estás construyendo un sistema que no controlás. Y eso, tarde o temprano, tiene consecuencias reales que van más allá de un thread de HN con 407 upvotes.
Lo que cambié en mi flujo después de este experimento: reviso activamente el código que genera Claude Code antes de commitearlo, documento las decisiones de diseño en el commit message, y mantengo una línea mental de "¿puedo explicar esto a las 3am si hay un incidente?". No es perfecto. Pero es honesto.
El 39% de mi proyecto que escribió Claude Code sigue ahí. No lo voy a reescribir — sería perder tiempo en código que funciona. Pero sí voy a conocerlo mejor, línea por línea, antes del próximo deploy a producción.
Así como revisé mis backups de Postgres después del tema de pgbackrest — no porque hubiera un incidente, sino porque descubrí que tenía confianza en algo que no había auditado. El patrón es el mismo: la herramienta está bien, el problema es la confianza ciega en ella.
Si usás Claude Code en producción y nunca corriste git blame para saber qué porcentaje de líneas son realmente tuyas, este es el momento. El número que encontrés probablemente va a ser incómodo. Eso está bien. La incomodidad es información.
¿Corriste el experimento en tu propio repo? Los números que encontraste me interesan más que cualquier discusión teórica sobre copyright.
Este artículo fue publicado originalmente en juanchi.dev
Top comments (0)