El 44% de Deezer es IA. Corrí git blame sobre mis commits y encontré algo incómodo

El 44% de las canciones que se suben a Deezer por día son generadas por IA. Cuando leí eso tuve que releer dos veces. No porque me parezca imposible, sino porque el número es tan concreto y tan incómodo al mismo tiempo.

Después hice algo que no debería haber hecho si quería dormir bien: corrí git blame sobre mis commits del último mes.

Contenido generado por IA en plataformas: el problema no es la calidad

El debate que levantó el número de Deezer fue predecible. Artistas enojados, ejecutivos con discursos preparados, think pieces sobre el futuro de la música. Todos apuntando al mismo blanco: la calidad del contenido generado por IA.

Y ahí creo que está el error de framing.

El problema no es si el código generado por un agente funciona. A esta altura, mayormente funciona. El problema es otro: ¿qué significa que algo sea tuyo cuando no lo pensaste vos?

En música es más fácil de ver porque la autoría es cultural, casi romántica. Pero en software tendemos a esconderlo detrás de pragmatismo. "Si pasa los tests, está bien." Ya escribí sobre eso — los agentes que pasan tus tests son exactamente el problema, no la solución.

Así que fui a buscar el número real en mis proyectos.

El git blame que no quería hacer

# Revisión de commits del último mes
# Quería saber cuánto código "mío" era realmente mío

git log --since="1 month ago" --author="Juan Torchia" --pretty=format:"%H %s" | head -50

# Después, por cada commit, revisé el diff
git show --stat <hash>

# Y finalmente, la pregunta honesta:
# ¿Cuántas líneas de este diff pensé yo?
# ¿Cuántas pegué de un agente sin leer del todo?

No tengo un script que detecte automáticamente si el código lo escribí yo o lo generó Claude. Ojalá. Lo que hice fue más artesanal y más incómodo: revisé commit por commit y traté de ser honesto conmigo mismo.

¿Este bloque de TypeScript lo diseñé yo o le pedí al agente que generara "una función que valide el schema" y después ajusté el nombre de una variable?

// Este tipo de código es el que me generó la duda
// Lo reconozco porque es demasiado prolijo para ser mío de primera pasada
// Y porque el nombre de la función es exactamente lo que yo le habría pedido a un agente

function validarSchemaContratos(data: unknown): data is ContratoInput {
  if (!data || typeof data !== 'object') return false;

  const contrato = data as Record<string, unknown>;

  // ¿Escribí esta validación? ¿O la pedí?
  // Honestamente: la pedí. Y la mergué sin pensar mucho más.
  return (
    typeof contrato.id === 'string' &&
    typeof contrato.monto === 'number' &&
    contrato.monto > 0 &&
    typeof contrato.fechaVigencia === 'string'
  );
}

El número al que llegué: alrededor del 38% de las líneas mergeadas ese mes tenían algún grado de generación por agente donde mi contribución real fue el prompt, no el diseño.

No el 44% de Deezer. Pero lo suficientemente cerca como para que la incomodidad sea real.

Cuando migré el monorepo a pnpm entendí la diferencia

En 2024 migré un monorepo de npm a pnpm. El install pasó de 14 minutos a 90 segundos. El equipo no lo podía creer. Y ese cambio lo entendí completamente: cada decisión, cada trade-off, cada razón por la que pnpm maneja el hoisting diferente. Ese conocimiento es mío.

Ahora pienso en cuánto del código que mergeo hoy puedo defender con ese mismo nivel de entendimiento. Y la respuesta honesta es: no todo.

Eso no es un problema de los agentes. Es un problema mío de proceso.

La distinción que importa no es "escribí yo cada caracter" vs "lo generó una IA". Esa es una discusión falsa. La distinción real es:

¿Puedo defender cada decisión de diseño en code review? ¿Entiendo los trade-offs? ¿Si este código falla a las 3am, sé por dónde empezar a buscar?

Si la respuesta es no, el problema no es de autoría filosófica. Es operacional.

Los errores que cometés cuando no sabés qué mergeaste

Acá están los gotchas reales que encontré en mi revisión:

1. El agente optimiza para el caso que describiste, no para tu sistema

// El agente generó esto cuando le pedí paginación
// Funciona perfecto para la descripción que le di
// El problema: mi DB tiene 2M de rows y OFFSET es devastador en escala

// Lo que el agente generó (correcto para el enunciado)
const resultados = await db.query(
  `SELECT * FROM contratos 
   ORDER BY created_at DESC 
   LIMIT $1 OFFSET $2`,
  [pageSize, page * pageSize]
);

// Lo que necesitaba (cursor-based pagination)
// Esto lo sé porque sé mi sistema — el agente no
const resultados = await db.query(
  `SELECT * FROM contratos 
   WHERE created_at < $1
   ORDER BY created_at DESC 
   LIMIT $2`,
  [cursor, pageSize]
);

Mergué la primera versión. La encontré en producción tres semanas después cuando el endpoint de contratos empezó a tardar 8 segundos en la página 50.

2. El código generado no tiene memoria de tus decisiones anteriores

Esto lo conecto con algo que analicé en el diff de system prompts de Claude entre versiones — los modelos no tienen contexto de por qué tu arquitectura tomó ciertas decisiones históricas. Eso lo noté cuando estaba viendo cómo evolucionan los prompts de sistema entre versiones de Claude: el modelo sabe mucho, pero no sabe tu historia.

Resultado: el código generado es técnicamente correcto y arquitecturalmente inconsistente con decisiones que tomaste hace seis meses.

3. La deuda técnica generada es más difícil de rastrear

Cuando yo escribo código malo, generalmente sé por qué lo escribí. Contexto de tiempo, legacy, trade-off consciente. Cuando un agente genera código subóptimo que yo mergué sin pensarlo, no tengo esa memoria. El git blame me dice que soy el autor. Mi cabeza no recuerda la decisión.

Esto tiene implicancias directas en la seguridad. Si no entendés completamente lo que mergeaste, tampoco entendés tu superficie de ataque. Lo que pasó con Vercel en abril y la supply chain es un ejemplo de cómo la tercerización sin comprensión real crea vectores que no ves venir.

4. La confianza en las herramientas reemplaza el juicio propio

Este es el más sutil. Cuando la herramienta genera el código y los tests pasan, hay una presión implícita para mergear. El CI está verde. ¿Qué más querés? Escribí algo sobre esto con relación a la confianza en herramientas de configuración de entorno y agentes: la pregunta no es si la herramienta funciona, es si vos entendés qué está haciendo y por qué.

Lo que haría diferente (y estoy implementando)

No voy a decir "usá menos IA" porque eso es una respuesta emocionalmente satisfactoria y prácticamente inútil. Lo que sí hago:

Code review propio antes de mergear, sin el contexto del chat con el agente

Cierro la conversación. Abro el diff. Me pregunto: ¿puedo explicar cada línea? Si no puedo, no mergeo hasta poder.

Separo commits de "agente revisado" y "mío"

No en el mensaje del commit público, sino en mi proceso mental. Los commits donde el agente tuvo peso significativo los marco mentalmente para revisión más profunda en el futuro.

El agente genera borradores, yo diseño la arquitectura

Cambié cómo formulo los prompts. En lugar de "generame una función que haga X", uso "explicame los trade-offs entre approach A y B para este caso" y después escribo la implementación basándome en esa discusión. Más lento. Más mío.

El paralelismo con Deezer no es que el contenido generado por IA sea malo. Es que cuando no sabés distinguir qué es tuyo y qué no, perdés algo importante — y en software ese algo se llama comprensión del sistema que mantenés.

FAQ: Contenido generado por IA en plataformas y en código

¿El código generado por IA es menos confiable que el código escrito por humanos?

No necesariamente. El código generado por IA puede ser perfectamente confiable en términos funcionales. El problema no es la confiabilidad del output sino la comprensión del autor. Código que no entendés completamente — independientemente de quién lo generó — es código que no podés mantener, debuggear ni defender en un incidente de producción.

¿Cuánto del código en proyectos profesionales es generado por IA hoy?

No hay un número oficial y consistente para software como sí lo hay para música en Deezer. GitHub Copilot reportó en 2023 que el 46% del código en proyectos que usan la herramienta es generado por IA. Mi experiencia personal ese mes específico fue alrededor del 38% con algún grado de generación por agente. El número varía enormemente por equipo, rol y tipo de tarea.

¿Qué diferencia hay entre usar IA para generar código y usar Stack Overflow?

Es una pregunta legítima y la diferencia es de grado, no de tipo. Con Stack Overflow generalmente entendés lo que copiás porque el contexto es más limitado y debés adaptarlo. Con un agente la generación es tan completa y tan adaptada a tu caso que la ilusión de comprensión es mayor. El riesgo no es copiar — es creer que entendés cuando no entendés.

¿Cómo afecta esto a la seguridad del código?

Significativamente. Si no entendés completamente lo que mergeaste, no podés razonar sobre tu superficie de ataque. Los agentes generan código correcto para el caso descrito pero pueden introducir vulnerabilidades en contextos que no conocen — tu modelo de datos específico, tus políticas de autenticación, tu arquitectura de permisos. Revisá los commits generados con el mismo rigor que revisarías el código de un desarrollador externo que no conoce tu sistema.

¿Debería preocuparme si el 44% de lo que sube a Deezer es IA?

Depende de qué te preocupa. Si te preocupa la calidad técnica del audio, probablemente no. Si te preocupa el ecosistema creativo y la sustentabilidad económica de los artistas humanos, sí hay razones para pensarlo. En software el análogo sería: si el 44% de tu codebase fue generado sin comprensión real del equipo, tenés un problema de mantenibilidad y un equipo que no conoce su propio sistema — eso sí debería preocuparte.

¿Hay alguna forma de detectar automáticamente qué código fue generado por IA en un repositorio?

Hoy no de forma confiable. Existen detectores pero tienen tasas de falso positivo y falso negativo altas. La pregunta más útil no es "¿lo generó una IA?" sino "¿el autor puede defender cada decisión de diseño?". Eso no lo detecta ningún script — lo revela el code review y los incidentes de producción.

La incomodidad tiene nombre

El 44% de Deezer molesta porque hace visible algo que preferimos no cuantificar. Cuando es música es fácil señalarlo. Cuando es nuestro propio código, la resistencia a hacer el análisis es mayor.

Hice el git blame. No me gustó todo lo que encontré. Pero ahora sé dónde estoy parado.

Lo que haría diferente no es usar menos agentes — es tener más honestidad sobre la diferencia entre "mergeé código que funciona" y "entiendo el sistema que estoy construyendo". La primera es ejecución. La segunda es ingeniería.

Y si en Deezer el 44% es IA, la pregunta que me hago para el año que viene no es cómo reducir ese número. Es cómo asegurarse de que quien lo sube, lo entiende.

En mi caso, eso empieza por no cerrar la sesión del agente antes de cerrar el diff.

¿Corriste git blame sobre tu último mes? ¿Qué número encontraste? Escribime — genuinamente quiero saber si es solo mi proyecto o si estamos todos en el mismo lugar.

Este artículo fue publicado originalmente en juanchi.dev