Las contribuciones de GitHub ya no sirven para contratar

Las contribuciones en GitHub ya no son una puntuación fiable para contratar. El gráfico de actividad registra el volumen de acciones muy distintas, no la calidad técnica, y la IA abarata la actividad visible. Usa GitHub para localizar una o dos muestras de trabajo y puntúa su relevancia, comprensión, verificación, respuesta a los comentarios, impacto y responsabilidad. Ofrece una vía equivalente a quienes no puedan mostrar su mejor trabajo porque es privado.

El cuadrado verde no ha muerto. El atajo, sí.

¿Por qué el recuento de contribuciones en GitHub dejó de servir como atajo para contratar?

El recuento de contribuciones en GitHub dejó de servir como atajo para contratar porque generar actividad visible se abarató, mientras que revisar su valor siguió siendo costoso. Ese cambio agravó un defecto que siempre estuvo ahí: el recuento mide acciones, no si esas acciones mejoraron un proyecto.

Neil Alexander resumió la tensión en una publicación de junio de 2026 sobre tres pull requests coescritas con Claude. Una persona había corregido la ortografía y la gramática de comentarios en el código. Los cambios eran inocuos y correctos, pero Alexander los cerró porque consumían tiempo de revisión sin mejorar el proyecto de forma sustancial. Sospechaba que aquella actividad pretendía engrosar un CV.

Eso último es una deducción, no un hecho. La persona que contribuyó no confirmó ninguna motivación profesional. Cuando la publicación llegó a Hacker News, varios comentaristas cuestionaron la decisión, defendieron que corregir erratas sí aporta cierto valor y señalaron que las contribuciones basura son anteriores a la IA generativa. Esas objeciones importan. Un proceso de selección justo no puede deducir que hubo engaño a partir de un pequeño parche ni penalizar a un candidato por el mero hecho de usar un asistente.

El problema general de la atención sí es real. En enero de 2026, GitHub afirmó que los mantenedores recibían cada vez más contribuciones de baja calidad, incluidas propuestas que ignoraban las directrices del proyecto, quedaban abandonadas o se generaban con IA. En mayo, GitHub describió el cuello de botella con mayor precisión: generar pull requests, incidencias, comentarios e informes se había vuelto mucho más fácil, mientras que la revisión seguía dependiendo de una atención humana escasa. GitHub señaló expresamente que el problema iba más allá de la IA.

Después, la empresa lanzó controles para desactivar o restringir las pull requests y limitar cuántas podían abrir a la vez las personas sin acceso de escritura. Estos cambios en el producto no demuestran que los candidatos estén inflando sus CV. Sí demuestran que el volumen de contribuciones puede imponer un coste real antes de que nadie sepa si un cambio resulta útil.

Los datos más sólidos y recientes sobre el ecosistema apuntan en la misma dirección, aunque con limitaciones importantes. Una prepublicación de julio de 2026 estudió 294 repositorios populares y activos, además de más de 1,2 millones de pull requests. Al comparar los datos con un escenario contrafactual generado por un modelo, los autores estimaron que el volumen de pull requests creció un 6,80 % en 2025, mientras que la proporción total de fusiones cayó un 1,06 %. Las pull requests de personas que habían contribuido una sola vez aumentaron un 5,84 % y su tasa de fusión descendió un 18,18 %.

Estas cifras no demuestran que la IA provocara el cambio. Los investigadores utilizaron 2025 como aproximación a la adopción generalizada de la IA, no observaron el uso individual de herramientas y no pudieron descartar el crecimiento de la plataforma ni otros cambios en el ecosistema. Además, la muestra sobrerrepresenta los repositorios populares y orientados a nuevos colaboradores. La conclusión prudente es más limitada: en esa muestra, una mayor actividad visible aportaba menos información sobre la probabilidad de que una propuesta acabara fusionándose.

Las contribuciones basura tampoco son nuevas. El resumen de Hacktoberfest 2020 de DigitalOcean registró 621 104 pull requests, de las cuales 9 598 se clasificaron como contribuciones basura o no válidas y 34 595 quedaron sin aceptar. Tras el aluvión de propuestas de baja calidad, los organizadores exigieron que los proyectos se inscribieran expresamente para participar. La IA no inventó el problema de los incentivos. Redujo el coste de aprovecharse de él.

¿Qué mide en realidad un cuadrado verde?

Un cuadrado verde de GitHub mide la actividad que cumple las reglas de visualización de GitHub. No mide dificultad, corrección, utilidad, autoría ni rendimiento laboral. Dos gráficos idénticos pueden representar trabajos muy distintos, y dos profesionales con la misma capacidad pueden tener gráficos completamente diferentes.

La referencia de contribuciones de GitHub deja claro el desajuste. Crear un repositorio o un fork siempre cuenta. Las incidencias, pull requests, revisiones, conversaciones, respuestas y commits solo cuentan cuando cumplen determinadas condiciones. Una pull request no tiene que fusionarse para aparecer. Algunos tipos de eventos visibles tienen límites.

La visibilidad de los commits impone sus propias condiciones. La dirección de correo asociada al commit debe estar vinculada a la cuenta. El trabajo debe encontrarse en un repositorio independiente, normalmente en la rama predeterminada o en gh-pages, y la persona tiene que cumplir otra condición relativa a su vínculo con el proyecto. El trabajo privado puede aparecer como una cifra sin detalles que permitan revisarlo. Al fusionar cuentas puede perderse la atribución de incidencias, pull requests y conversaciones. Un rebase puede atribuir la contribución tanto al autor original como a quien lo ejecutó.

Eso genera dos errores si utilizas el gráfico como puntuación de cribado:

• Falsos positivos: un gráfico denso puede contener forks, pull requests sin fusionar, actividad automatizada, cambios cosméticos o trabajo cuyo valor no has revisado.
• Falsos negativos: un gráfico poco poblado puede ocultar años de trabajo privado para empresas, restricciones de seguridad, correos de commits desvinculados, trabajo en ramas que GitHub no cuenta o, sencillamente, ninguna intención de colaborar gratis en público.

Una mayor actividad todavía puede conducirte a pruebas útiles. Lo que no puede es constituir la prueba por sí misma. No cuentes estrellas, repositorios, commits, rachas ni pull requests fusionadas para convertir el total en una clasificación de candidatos. Incluso asignarle un peso numérico pequeño hace que una actividad que no es comparable lo parezca y la convierte en parte de la decisión de contratación.

Una investigación anterior sobre contratación muestra por qué persiste el atajo. En un estudio de 2016, nueve participantes evaluaron cinco perfiles de desarrolladores. Ocho utilizaron el número o la frecuencia de commits durante el cribado inicial porque eran señales fáciles de comparar. Los participantes de empresas grandes tendían más a revisar después el tipo y la calidad de las contribuciones; los de empresas pequeñas se quedaban sobre todo con la amplitud de los trabajos y la reputación de los proyectos. El estudio es diminuto y no analiza el rendimiento laboral posterior, pero revela un fallo conocido: lo más fácil de contar desplaza la información que de verdad necesitas.

Ningún estudio localizado para este artículo demuestra que el volumen de contribuciones en GitHub prediga el rendimiento en el puesto. El trabajo público puede mostrar comportamientos valiosos. El recuento no te dice cuáles.

¿Sigue contando el trabajo de código abierto realizado con ayuda de IA?

Sí. El trabajo de código abierto realizado con ayuda de IA puede ser una prueba sólida en un portafolio cuando el candidato lo entiende, lo verifica y se responsabiliza de él. La frontera útil está entre el trabajo que alguien entiende y asume como propio y los resultados que nadie comprende bien, no entre el código escrito por una persona y el generado de forma automática.

Un estudio de 2026 sobre directrices de contribución revisó 1 000 repositorios populares de GitHub y encontró 118 políticas explícitas sobre IA. De esas políticas, el 78 % permitía el trabajo con ayuda de IA, el 51 % exigía declararlo y el 74 % requería supervisión humana. La muestra no representa a todos los repositorios, pero contradice directamente la idea de que los proyectos consolidados rechazan por regla general el uso de IA.

Las políticas actuales de los proyectos coinciden en el tipo de pruebas que exigen:

• LLVM pide que quien contribuya lea, revise y explique el trabajo generado. Considera «extractiva» una contribución cuando el coste de revisión previsto supera el beneficio para el proyecto.
• Linux exige el visto bueno de una persona. Los errores encontrados con ayuda de IA deben incluir un caso reproducible, una corrección, pruebas de compilación o tests y una explicación honesta de todo lo que no se haya verificado.
• pytest acepta de buen grado la ayuda de IA, pero cierra las propuestas enviadas íntegramente por agentes cuando ninguna persona puede participar de manera significativa en la revisión.
• OpenXLA acepta trabajo etiquetado como generado con IA y vinculado a un problema, test o prueba de rendimiento real cuando el autor lo entiende.
• curl acepta pull requests realizadas con ayuda de IA bajo sus normas habituales de calidad del código, tests y documentación.

curl también aporta un contrapunto útil. En su programa de recompensas por vulnerabilidades, la tasa de informes confirmados cayó desde más del 15 % histórico hasta menos del 5 % en 2025, en medio de informes con un uso intensivo de IA y motivados por la recompensa. Esto contribuyó a la decisión de eliminar las recompensas económicas. En abril de 2026, el mantenedor Daniel Stenberg señaló que el volumen se había duplicado y que la tasa de informes confirmados se había recuperado hasta el 15–16 %, aunque casi todos los informes parecían contar con ayuda de IA.

Es la experiencia de un proyecto, no una proporción universal. Aun así, muestra por qué «¿se utilizó IA?» aporta poco al contratar. Los incentivos, la verificación, la relevancia y la responsabilidad humana son los factores que determinan si el resultado ayuda. La revisión del portafolio debe comprobar esos mismos factores.

Evaluar cómo trabaja alguien con IA durante una prueba en directo es otro problema de diseño. Nuestra guía sobre entrevistas técnicas con IA lo explica. Para revisar un portafolio, no intentes detectar la IA. Pide al candidato que explique y defienda la muestra de trabajo.

¿Cómo debes revisar el portafolio de GitHub de un desarrollador?

Revisa una o dos muestras relevantes para el puesto con los mismos seis criterios para todos los candidatos. Una muestra bien elegida revela más que un recuento de todo el perfil y mantiene la revisión lo bastante acotada como para hacerla con cuidado.

Empieza por elegir una muestra con contexto suficiente para revisarla. Puede ser una pull request, un debate sobre el diseño, un informe de error con un caso reproducible, una versión que el candidato haya mantenido o un repositorio bajo su responsabilidad. Prioriza el trabajo relacionado con el puesto, pero no des por sentado que los proyectos famosos aportan mejores pruebas. Un parche modesto puede revelar muy buen criterio técnico.

Después, puntúa estos seis criterios:

No trates una pull request fusionada como prueba automática de calidad. Las decisiones de fusión reflejan el alcance del proyecto, la disponibilidad de los mantenedores, el momento de la propuesta y el contexto social, además del código. Una propuesta rechazada todavía puede aportar pruebas sólidas si el candidato encontró un problema real, probó un enfoque defendible, respondió bien a los comentarios y sabe explicar por qué el proyecto eligió otro camino.

También sucede al revés. Corregir una errata en una propuesta fusionada puede resultar útil para el proyecto, pero dice poco sobre el criterio para diseñar sistemas. Puntúa lo que la muestra demuestra para ese puesto, no la etiqueta que lleva asociada.

Haz las mismas tres preguntas a todos los candidatos:

1. ¿Qué problema intentabas resolver y cómo supiste que era importante?
2. ¿Qué prueba demostraría que tu cambio era incorrecto?
3. ¿Qué cambió después de la revisión y qué harías de otra forma ahora?

Estas preguntas hacen que simular la autoría sirva de poco. Quien haya copiado una respuesta que no entiende tendrá dificultades para relacionar el problema, las pruebas y el historial de revisiones. Quien haya utilizado la IA de forma responsable podrá explicar con claridad esa misma secuencia. Un principiante también puede obtener una buena puntuación con una contribución pequeña porque los criterios premian el juicio y el aprendizaje, no el tamaño.

Registra la muestra, las respuestas y las pruebas que justifican cada puntuación. No se trata de convertir trabajo cualitativo en una falsa precisión. Se trata de impedir que la reputación, la duración de una racha, la marca del empleador o el entusiasmo del primer revisor cambien el criterio sin que nadie lo advierta.

¿Qué debes hacer cuando un candidato no tiene trabajo público en GitHub?

Ofrece a quienes no tengan trabajo público útil una forma equivalente de demostrar las mismas competencias. Un perfil de GitHub debe ser opcional, porque la ausencia de actividad pública no demuestra falta de capacidad.

Pide una muestra de cualquiera de estas fuentes aceptables:

• trabajo público de código abierto;
• trabajo profesional privado que el candidato pueda describir sin revelar información confidencial;
• un proyecto académico, de voluntariado o personal;
• una nota de arquitectura, una retrospectiva de incidente o una decisión técnica que pueda explicar;
• un ejercicio equivalente y breve proporcionado por tu equipo.

Permite que los candidatos omitan nombres, cifras y detalles confidenciales. Necesitas conocer el problema, su actuación concreta, el método de verificación, el resultado y lo que aprendieron. No necesitas el código fuente de su anterior empresa.

Cuando ninguna muestra existente sirva, utiliza una tarea representativa que evalúe una competencia imprescindible para incorporarse al puesto. Debe ser breve, evitar trabajo gratuito para tu producto y no examinar algo que la persona podría aprender razonablemente después de incorporarse. Nuestra guía sobre cómo estructurar ejercicios de código explica el alcance de la tarea, las instrucciones para el candidato y la mecánica de revisión. El ejercicio ofrece otra forma de demostrar la competencia; no es un castigo por tener trabajo privado.

Aplica la misma familia de criterios en todas las vías. En el código abierto, la verificación puede consistir en un caso reproducible y la revisión de un mantenedor. En un proyecto privado, puede ser un plan de pruebas y el resultado de la respuesta a un incidente. En un ejercicio breve, puede ser un test de regresión y una explicación. Las muestras cambian, pero la competencia no.

Esta equivalencia también impide convertir el tiempo disponible en un criterio de mérito. La contribución pública favorece a quienes tienen permiso, tiempo libre y trabajo que pueden enseñar. Un proceso justo no exige trabajo público no remunerado para que la experiencia privada pueda evaluarse.

¿Cómo conviertes las pruebas de un portafolio en una decisión de contratación defendible?

Convierte la revisión de la muestra en un registro estructurado de pruebas y mantén su peso dentro de unos límites. Las pruebas del portafolio deben responder a una pregunta acotada sobre lo que demuestra ese trabajo. No deben transformarse en un juicio general sobre el carácter ni decidir por sí solas la contratación.

Haz que los revisores puntúen de forma independiente antes de hablar del candidato. Exige una breve nota con las pruebas que justifican cada criterio. Durante la puesta en común, céntrate en las diferencias de puntuación relevantes: ¿qué detalle de la muestra vio un revisor que otro pasó por alto? ¿Hace falta aclarar la pauta de puntuación?

En este punto, la revisión del portafolio encaja con el resto del proceso de selección sin acapararlo. Una muestra sólida puede orientar una pregunta de seguimiento concreta. No debe servir para ignorar pruebas débiles en ámbitos esenciales para el puesto que la muestra no cubre. Una pull request de backend puede mostrar la capacidad de depuración y cómo reacciona una persona durante una revisión, pero no dice nada sobre la comunicación con las partes interesadas ni sobre la responsabilidad operativa.

La investigación general sobre selección favorece la estructura frente a la improvisación. Una síntesis de 2023 estimó una validez operativa corregida de 0,42 para las entrevistas estructuradas, 0,33 para las muestras de trabajo y 0,19 para las entrevistas no estructuradas. Son estimaciones generales para distintas profesiones, con una variación sustancial, no garantías específicas para el desarrollo de software. Respaldan un principio de diseño, no una promesa sobre estos criterios concretos.

Define los criterios antes de revisar a los candidatos. Formula las mismas preguntas. Forma a los revisores para que apliquen las pautas de puntuación. Conserva las puntuaciones independientes antes de la puesta en común. Nuestra guía sobre cuadros de evaluación para entrevistas estructuradas explica el sistema de puntuación más amplio. Los criterios del portafolio deben alimentar ese sistema como una fuente de pruebas, no quedarse a su lado como un veto informal.

Audita el proceso después de varias contrataciones. Comprueba si los revisores aplican las pautas de puntuación de forma coherente, si una vía hace avanzar a más candidatos que otras equivalentes y si las puntuaciones del portafolio guardan relación con las pruebas de etapas posteriores. No atribuyas una validez predictiva que no hayas medido.

¿Cómo puede Kit gestionar la trazabilidad de las pruebas sin fingir que verifica la autoría?

Kit puede estandarizar la trazabilidad de las pruebas: un repositorio privado para el ejercicio, un plazo claro, revisores designados, cuadros de evaluación a ciegas y una decisión humana con autor identificado. No detecta IA, no captura prompts ni demuestra quién escribió el código.

Cuando un candidato necesite la vía de trabajo equivalente, la integración de GitHub de Kit puede crear un repositorio privado a partir de tu plantilla, invitar al candidato, hacer un seguimiento del plazo y las prórrogas, añadir a los revisores que cumplan los requisitos y archivar el repositorio al terminar. Las instrucciones para el candidato aparecen en el portal y en los materiales del ejercicio. Kit crea el repositorio, no una pull request.

Combina la etapa de ejercicio de código con una etapa de revisión del equipo. Incluye los seis criterios en esa revisión, pide a los revisores que puntúen de forma independiente y habla de las pruebas solo después de que envíen sus puntuaciones. Kit admite revisiones a ciegas hasta que cada revisor envía la suya, criterios ponderados, comentarios, umbrales y una decisión humana con autor identificado. Los criterios estructurados no se añaden directamente a la etapa de ejercicio de código, por lo que es importante combinar ambas etapas.

Incluye la norma sobre IA en las instrucciones dirigidas al candidato. Pide a los candidatos que indiquen qué herramientas utilizaron si ese contexto ayuda a revisar su trabajo, pero no presentes esa declaración como una verificación de autoría. Las pruebas siguen procediendo de lo que pueden explicar, comprobar, revisar y asumir como propio.

GitHub sigue siendo útil porque el código público y el historial de revisiones pueden hacer visible el trabajo técnico real. Lo que ha dejado de funcionar es tratar la actividad acumulada como una puntuación. Examina una muestra del trabajo, aplica los mismos seis criterios, ofrece una vía equivalente para la experiencia privada e incorpora las pruebas a una decisión estructurada.

Empieza tu prueba gratuita para aplicar el mismo proceso a todos los candidatos de ingeniería e integrar la revisión del portafolio o del ejercicio en tu proceso de selección.