Spotify Verified para artistas humanos: lo que esto anticipa para el código, el contenido y mi propio blog

La solución correcta al problema de autoría en software es agregar más metadatos de proceso, no de output. Sé que suena raro. Dejame explicar por qué el badge de Spotify me obliga a revisar mis propios commits.

Cuando apareció la noticia de Spotify Verified en Hacker News — 243 puntos, thread de más de 200 comentarios — mi primer impulso fue el mismo que seguramente tuviste: "interesante, problema de la industria musical, no mío". Cerré la tab. Seguí con un PR.

Tres horas después estaba revisando mis logs de Claude Code del último mes y me encontré con algo incómodo: de los 847 commits que hice desde que adopté agentes de forma sistemática, tengo evidencia verificable de autoría humana en exactamente el 23% de ellos. El resto tiene mi nombre en git log, pero la decisión de diseño, el código, a veces hasta el mensaje del commit — todo asistido. No "generado", no "copiado", pero tampoco inequívocamente mío en el sentido en que Spotify está intentando definir "mío".

Ese número me jodió la tarde.

Spotify Verified Human Artist: qué resuelve y qué deja sin resolver

El programa permite a artistas verificar que su música fue creada por humanos. Spotify la distingue en la plataforma. La señal está pensada para que los usuarios que quieran consumir música humana puedan filtrar.

Técnicamente: es un sistema de attestation. Declaración voluntaria, verificación por proceso, badge visible. Nada que impida que alguien mienta, igual que un SSL certificate no garantiza que el sitio sea legítimo — solo que alguien controló un dominio.

Lo que me interesa no es si funciona para la música. Es que el patrón ya existe y va a migrar. No es especulación: ya migró antes. Los CAPTCHAs nacieron para distinguir bots de humanos en formularios web. DMARC/DKIM nacieron para distinguir correo legítimo de spoofing. Verified checkmarks en redes sociales nacieron para distinguir cuentas reales de impostores. Cada vez que hay un vector nuevo de confusión entre humano y no-humano, aparece una capa de attestation encima.

El código y el contenido técnico son el vector nuevo. Y la confusión ya está instalada.

Lo que mis logs de Claude Code dicen sobre el problema real

Corrí este análisis la semana pasada, después de cerrar esa tab de HN y no poder ignorarla más.

# Script que corrí contra mi repo principal (Next.js + PostgreSQL en Railway)
# para categorizar commits por nivel de autoría humana verificable

git log --oneline --since="2025-01-01" --format="%H %s" | while read hash msg; do
  # Busco markers que dejé intencionalmente cuando el diseño fue mío
  # (comentario "JT:" en el diff, ticket number, decisión documentada)
  if git show "$hash" | grep -qE "(JT:|ARCH-[0-9]+|decisión:)"; then
    echo "HUMANO_VERIFICABLE $hash"
  elif git show "$hash" | grep -qE "(claude|co-pilot|generated|assisted)"; then
    echo "ASISTIDO_DECLARADO $hash"
  else
    echo "AMBIGUO $hash"
  fi
done | sort | uniq -c | sort -rn

Resultado real de ese script sobre mi repo:

# Output del análisis — enero a julio 2025
 389  AMBIGUO
 263  ASISTIDO_DECLARADO
 195  HUMANO_VERIFICABLE

El problema no son los ASISTIDO_DECLARADO. Esos los declaré yo, están trackeados, son honestos. El problema son los 389 AMBIGUO — commits donde ni yo mismo puedo reconstruir con certeza cuánto fue decisión mía y cuánto fue output que acepté sin fricción suficiente.

Esto no es un problema de ética. Es un problema de rastreabilidad de decisiones técnicas. Cuando en seis meses alguien del equipo pregunte "¿por qué elegiste este approach?", la respuesta "porque Claude lo sugirió y me pareció bien" no tiene el mismo peso que "porque medí X, descarté Y por razón Z, y acá está el ADR que lo documenta".

Cuando estaba armando el análisis de supply chain attacks sobre dependencias de ML, el código de simulación lo escribí con Claude Code. Está en producción. Funciona. Pero si mañana alguien audita ese repo y me pregunta por el threat model detrás de cada función, tengo respuesta para el 60% — el resto fue "lo probé, funcionó, merged".

El patrón que se viene para repos y posts técnicos

Mi tesis concreta: antes de 2027 vas a ver al menos uno de estos tres sistemas adoptados de forma relevante en el ecosistema dev:

1. Commit attestation en CI/CD
Ya existe git-signing con GPG. Ya existe Sigstore para artefactos. El paso que falta es un layer de "autoría de decisión", no solo de "quién hizo el push". Algo como un ADR (Architecture Decision Record) obligatorio en PRs por encima de cierto threshold de cambio.

2. Content provenance para posts técnicos
La C2PA spec (Coalition for Content Provenance and Authenticity) ya está en Adobe, ya está en cámaras de fotos, ya está en Bing para imágenes. Dev.to, Hashnode y Medium tienen incentivo para adoptarlo. El día que lo hagan, mis posts van a necesitar declarar su proceso de producción, no solo su contenido final.

3. Plataformas de package registry con human-authored badge
npm, PyPI, crates.io. Si Spotify puede hacer esto para música, npm puede hacer esto para paquetes. Un "humanAuthored": true en package.json verificado por el registry sería el mismo patrón exacto. Trivial de implementar. Políticamente difícil. Pero inevitable si los supply chain attacks siguen creciendo — como ya documenté cuando simulé el mismo vector de ataque de PyTorch Lightning sobre mis dependencias.

Por qué esto me importa en mi propio blog — y me incomoda

Cancelé Claude hace unas semanas (tengo el post con los benchmarks). Volví. La relación es complicada. Pero lo que nunca resolví es esto: ¿qué porcentaje de autoría convierte un post en "mío"?

No es una pregunta filosófica. Es una pregunta operativa. Cuando r/programming baneó contenido LLM, el criterio que usaron fue percepción — ¿suena a IA? — no proceso. Eso es arbitrario y va a romperse. Cuando llegue la presión de attestation al contenido técnico escrito, el criterio va a ser otro.

Mi postura actual, después de pensar esto bastante: un post es mío si la tesis es mía, la evidencia es mía y la fricción intelectual fue mía. El código que ilustra el punto, el formato del markdown, la corrección ortográfica — eso puede ser asistido sin comprometer la autoría de las ideas. Pero si el argumento central lo encontré porque Claude lo sugirió y yo solo lo validé asintiendo, entonces la autoría es distribuida y debería decirlo.

Eso me obliga a cambiar algo concreto en cómo publico. Desde este post: voy a agregar un bloque de proceso al final de cada pieza donde especifique qué fue generado, qué fue editado y qué fue original. No porque me lo pida nadie. Porque cuando el sistema de attestation llegue — y va a llegar — quiero tener el historial limpio.

Lo mismo que aprendí con los bugs que Rust no previene: el lenguaje no te salva de los errores de lógica. La herramienta no te salva de los errores de autoría. La disciplina de proceso es lo único que escala.

Los gotchas que nadie está discutiendo todavía

El problema del threshold
¿Qué porcentaje de asistencia IA convierte algo en "no humano"? Spotify tampoco lo resuelve — solo pide declaración. El debate real no es binario (humano vs IA) sino continuo. Un artista que usa Pro Tools con corrección de tono es más humano que uno que usa Suno, pero ambos usan herramientas. La línea es política, no técnica.

El incentivo perverso del badge
Si Spotify premia la música human-verified con mejor posicionamiento, el siguiente paso obvio es gente que miente sobre su proceso. Lo mismo va a pasar con código y posts. Un "humanAuthored": true sin attestation verificable es ruido, no señal. Necesitás el equivalente del notario — alguien que pueda validar el proceso, no el output.

El problema de los repos colaborativos
En un equipo de cinco personas donde tres usan Copilot de forma intensiva y dos no, ¿el repo es human-authored? ¿A nivel de archivo? ¿De función? Cuando estaba reproduciendo el caso OpenClaw en Claude Code, me di cuenta de que la granularidad correcta para la attestation es el nivel de decisión de diseño — no el nivel de línea de código.

El costo de mantenimiento del proceso
Los ADRs son la solución obvia para documentar decisiones de diseño con autoría. El problema: son caros de mantener. Lo sé porque los abandoné dos veces en proyectos propios. La versión que funciona es la que tiene friction mínima — un commit message bien formateado con template puede ser suficiente para el 80% de los casos.

FAQ: Spotify Verified, autoría en código y qué cambia para devs

¿Qué es exactamente el programa Spotify Verified Human Artist?
Es un sistema de attestation voluntario donde artistas declaran que su música fue creada por humanos. Spotify lo verifica por proceso (no por análisis del audio) y lo muestra como badge en la plataforma. Permite a usuarios filtrar por música humana si lo quieren. El thread original de HN llegó a 243 puntos con debate intenso sobre qué cuenta como "humano" cuando usás herramientas digitales.

¿Esto va a llegar a GitHub o npm antes de lo que pensamos?
Mi proyección: sí, pero no de forma oficial ni centralizada al principio. Va a aparecer como convención de la comunidad primero — un campo en package.json, un badge en READMEs, un bloque en posts técnicos. Después va a llegar la presión de los registries cuando un supply chain attack masivo se pueda rastrear a un paquete con autoría no-declarada.

¿Cómo sé qué porcentaje de mis commits son "míos"?
No hay una respuesta limpia. El script que corrí arriba es un proxy — busca markers de proceso que yo mismo dejé intencionalmente. La métrica más honesta no es cuántas líneas escribí, sino cuántas decisiones de diseño puedo defender con razonamiento propio si me las cuestionan seis meses después.

¿El problema de autoría en código es realmente comparable al de la música?
Estructura sí, escala no. La música tiene listeners que consumen sin entender el proceso. El código tiene revisores que en teoría pueden auditar el proceso. Pero en la práctica, con PRs de 800 líneas y code reviews de dos minutos, la auditoría real no está pasando. Eso hace el problema igual de real, diferente de urgente.

¿Tiene sentido agregar un bloque de proceso a cada post técnico ya?
Para mí sí, y lo estoy implementando. Para vos depende de si publicás con expectativa de autoridad técnica. Si escribís tutoriales básicos, probablemente no importa todavía. Si publicás análisis, tesis o investigación propia donde la credibilidad del razonamiento importa, vale la pena empezar el hábito antes de que sea obligatorio.

¿El kernel de Linux o las distros van a adoptar algo así?
Interesante en el contexto de lo que cubrí sobre vulnerabilidades del kernel sin aviso a distros — el problema de coordinación de divulgación ya muestra que el ecosistema OSS tiene dificultad para adoptar convenciones nuevas rápido. Kernel con attestation de autoría parece lejano. Pero proyectos más pequeños con security requirements altos (librerías criptográficas, por ejemplo) podrían adoptarlo antes.

Lo que acepto, lo que no compro y lo que todavía no tengo claro

Lo que acepto: la verificación de autoría va a llegar al código y al contenido técnico, y llegar tarde va a ser costoso. El patrón histórico es claro.

Lo que no compro: que el badge en sí resuelva algo sin un sistema de attestation real detrás. Spotify puede pedir declaración; no puede validar proceso. npm puede hacer lo mismo. Eso crea incentivo perverso desde el día uno.

Lo que todavía no tengo claro: cuál es la granularidad correcta para declarar autoría en un codebase colaborativo con herramientas de IA. Línea de código es demasiado granular. Repositorio es demasiado grueso. Mi apuesta actual es a nivel de decisión de diseño documentada — pero eso requiere disciplina de ADRs que históricamente no mantenemos.

Mientras tanto, tengo 389 commits ambiguos en mi repo que me van a hacer acordar de esto cada vez que alguien me pregunte "¿por qué hiciste X?". La respuesta "porque sí" nunca fue suficiente. La respuesta "porque Claude" tampoco lo va a ser.

Proceso de este post: tesis y análisis de logs propios. Estructura y revisión de prosa con asistencia. El script de bash y los números son míos y corrí contra mi repo real.

Fuente original: Hacker News

Este artículo fue publicado originalmente en juanchi.dev