Las contribuciones exitosas a proyectos de código abierto son una especie de moneda. Git Hub en particular lo fomenta de varias maneras: mostrando avatares de contribuyentes en las páginas de repositorios, mostrando tus contribuciones a tus seguidores a través del feed de actividad y señalando las contribuciones por día en el gráfico de actividad de tu perfil. Los gerentes de contratación potenciales a menudo toman nota de esto.

Los reclutadores a menudo encuentran y evalúan candidatos de esta manera. Si eres un desarrollador de software (existente o aspirante) que busca trabajo, ajustar estas señales a menudo puede trabajar a tu favor. Como mantenedor de código abierto, es bastante notable cómo ha cambiado el patrón de contribuciones externas en el último año.

Es mucho más probable que recibamos pull requests en lugar de issues. Si recibimos issues, a menudo vienen con un análisis generado por IA adjunto. Estamos recibiendo muchos más informes de vulnerabilidades de seguridad que nunca y, a menudo, incluso vienen con propuestas de corrección generadas por IA adjuntas.

No dudo de que algunas de estas contribuciones provienen de personas que están genuinamente interesadas en lo que hacemos, pero la parte cínica de mí cree que una cantidad sustancial de esto se debe a que la gente se está dando cuenta de que la IA se puede usar para manipular Git Hub en su propio beneficio. Ahora es fácil pedirle a Claude que genere una lista de proyectos de código abierto interesantes, luego pedirle a Claude que encuentre algunos problemas en ellos, y luego pedirle a Claude que plantee algunos PRs para solucionarlos. Ni siquiera tienes que usar los proyectos o preocuparte por ellos, pero puedes crear fácilmente la ilusión a los forasteros de que te importa, o que encontraste un problema, o que dedicaste tiempo a solucionarlo.

En internet, nadie sabe que eres un perro, pero con la ayuda de los LLMs, puedes exagerar sin esfuerzo tus habilidades humanas en tu perfil de Git Hub. Recientemente, un contribuidor con prácticamente ninguna contribución en todo Git Hub desde finales de 2018 hasta hace un par de semanas, sin interacción previa con nuestro proyecto que conozcamos, planteó tres PRs separados para corregir errores ortográficos y gramaticales en los comentarios. Claude hizo las correcciones, presumiblemente escribió las descripciones de los PR, incluso firmó los commits en nombre del usuario y luego insertó amablemente su co-autoría en los trailers de los mensajes de commit.

Tal vez incluso abrió los PRs por sí mismo, quién sabe. Me fascinaría saber si el prompt era para "ir a buscar problemas" o si se centró en problemas ortográficos y gramaticales en particular por alguna razón. Los cambios fueron inofensivos y correctos, pero eso no me hizo sentir mejor acerca de aceptarlos o fusionarlos.

En cambio, no pude evitar preguntarme: ¿por qué esto, por qué ahora? ¿Por qué, de entre todos los issues, TODOs y FIXMEs en nuestro código base, están enviando esto? Y entonces se me ocurrió que estas contribuciones no tenían nada que ver con nuestro proyecto. Cerré los tres PRs sin comentarios. Tal vez esto fue irrazonable, pero sinceramente, simplemente no estoy interesado en animar a la gente a quitarnos el tiempo con este tipo de trabajo trivial.

No quiero sentar un precedente de aceptar PRs que no mejoran materialmente nada, ni quiero que nuestra lista de contribuyentes se convierta en una recompensa por pedirle a un robot que corrija erratas. El mismo patrón ha surgido con los informes de vulnerabilidades de seguridad. Los CVEs tradicionalmente acreditan a sus reporteros, pero todos los informes que hemos recibido recientemente han sido obviamente generados por IA.

Las correcciones de seguridad siempre son importantes, por supuesto, pero de nuevo me pregunto si esto está sucediendo porque a la gente le importan las correcciones o porque están buscando un crédito fácil. Hemos sido mucho más selectivos últimamente al evaluar la severidad de tales informes y, en algunos casos, negarnos a emitir avisos CVE para elementos de baja severidad. Tengo algunas opiniones sobre el hecho de que la divulgación privada está muriendo de todos modos, sobre las que podría escribir en otra ocasión, pero el esfuerzo involucrado en coordinar correcciones privadas, avisos de divulgación y lanzamientos es lo suficientemente sustancial como para requerir que seamos selectivos.

En última instancia, el código abierto se basa en la confianza.