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. 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. 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". 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 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 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 "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. 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. El problema del threshold El incentivo perverso del badge "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 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 ¿Qué es exactamente el programa Spotify Verified Human Artist? ¿Esto va a llegar a GitHub o npm antes de lo que pensamos? 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"? ¿El problema de autoría en código es realmente comparable al de la música? ¿Tiene sentido agregar un bloque de proceso a cada post técnico ya? ¿El kernel de Linux o las distros van a adoptar algo así? 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: 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