GitHub sigue siendo una pieza central del desarrollo de software. Business Insider lo describe como una plataforma líder de desarrollo que Microsoft adquirió en 2018 ^[14]. Por eso conviene separar el ruido de la señal: la historia no es que GitHub se haya acabado. La historia es que GitHub tiene un problema de confianza.

Copilot ya no se discute únicamente como una ayuda opcional de autocompletado dentro del editor. Las quejas se concentran en su presencia dentro de los flujos del repositorio: incidencias, pull requests o PR, revisiones, comentarios y disparadores de agentes. Es decir, justo en los espacios donde los mantenedores esperan controlar qué ocurre en sus proyectos ^[7][8].

Hay enfado, pero no pruebas de una estampida

Los datos disponibles sostienen mejor una lectura de frustración que una narrativa de abandono masivo.

The Register informó de que las funciones de IA percibidas como inevitables estaban llevando a algunos desarrolladores a mirar alternativas de alojamiento de código, sobre todo porque los mantenedores querían formas de bloquear o desactivar comportamientos de Copilot dentro de sus repositorios ^[8]. Slashdot, al resumir la misma controversia, citó una afirmación según la cual el traslado de GitHub desde una filial diferenciada al grupo CoreAI de Microsoft habría empujado a parte de la comunidad open source a pasar de quejarse de Copilot a moverse activamente fuera de GitHub ^[1].

Son señales de alerta reales. Pero no equivalen a una prueba de abandono generalizado. Las fuentes disponibles no aportan cifras de migraciones, datos de pérdida de clientes empresariales ni evidencia a nivel de repositorio que muestre un derrumbe material de la posición de GitHub. La conclusión más prudente es más estrecha: muchos desarrolladores están reconsiderando cuánto margen de confianza quieren dar a GitHub mientras Microsoft empuja la IA más adentro de la plataforma ^[8][14].

Por qué Copilot se convirtió en el punto de fricción

La reacción no va solo de si la generación de código con IA es útil. Va de dónde se le permite actuar a Copilot.

The Register señaló que la discusión más popular de GitHub Community durante los 12 meses anteriores pedía una forma de impedir que Copilot generara incidencias y pull requests en repositorios ^[8]. También informó de que la segunda discusión más popular, medida por votos positivos, reclamaba una solución a la imposibilidad de desactivar las revisiones de código de Copilot ^[8].

La diferencia importa. Un asistente que sugiere código en un editor privado es una cosa. Un sistema de IA que aparece en la cola de incidencias, en el flujo de PR y en las superficies de revisión pasa a formar parte de la gobernanza del proyecto. Para los mantenedores, la pregunta no es solo si Copilot escribe buen código. Es si los propietarios del proyecto pueden fijar las reglas de su propia comunidad ^[8].

Si la calidad genera dudas, la automatización molesta más

Parte del malestar también viene de problemas percibidos de fiabilidad. Una discusión en GitHub Community incluye acusaciones de usuarios según las cuales Copilot en VS Code era poco fiable y había causado daños en un proyecto ^[9]. Ese tipo de hilo no es una evaluación independiente de la calidad de Copilot en todos los usuarios y flujos de trabajo. Pero ayuda a explicar por qué algunos desarrolladores ya no ven la actividad no solicitada de Copilot como una automatización inocua ^[9].

Cuando una herramienta parece difícil de evitar y, además, algunos usuarios la consideran poco fiable, la conversación deja de ser solo de productividad. Pasa a ser una conversación sobre consentimiento.

Los agentes de IA ya son una dependencia operativa

La propia página de estado de GitHub muestra por qué los flujos con agentes elevan el riesgo. El 22 de abril de 2026, entre las 18:49 y las 19:32 UTC, las sesiones de Copilot Cloud Agent para el agente Codex de Agent HQ no pudieron iniciarse desde puntos de entrada como la asignación de incidencias y las menciones con @copilot en comentarios ^[7]. GitHub dijo que se vio afectado el 0,5 % del total de trabajos de Copilot Cloud Agent, unos 2.000 trabajos fallidos, mientras que Copilot y otras sesiones de agentes no se vieron afectadas ^[7].

No fue un colapso de todo GitHub. Pero ilustra el riesgo operativo que aparece cuando los equipos canalizan trabajo real a través de agentes de IA. Si los desarrolladores asignan incidencias a agentes o disparan tareas desde comentarios en pull requests, la disponibilidad de Copilot entra en la planificación de entregas ^[7]. La página de noticias de GitHub también ha reconocido incidentes recientes de disponibilidad y ha señalado que las interrupciones afectan a sus clientes ^[10].

La hoja de ruta de Microsoft cambia la ecuación de confianza

Business Insider informó de que Microsoft está reorganizando equipos para reforzar GitHub y replantearlo alrededor de la programación con IA y los agentes, en un contexto de competencia con herramientas como Cursor y Claude Code ^[14]. Desde la estrategia de producto, el movimiento tiene lógica: repositorios, pull requests, incidencias y revisiones son lugares naturales para integrar asistentes de programación.

Culturalmente, es más delicado. Muchos desarrolladores tratan GitHub como infraestructura compartida del software. Cuando las funciones de Copilot parecen difíciles de esquivar, los mantenedores pueden leerlas menos como herramientas opcionales de productividad y más como el uso de la posición central de GitHub para distribuir la estrategia de IA de Microsoft ^[8][14].

Los AI Credits convierten los límites en asunto de presupuesto

GitHub dice que Copilot pasará a facturación basada en uso y que, a partir del 1 de junio, el uso de Copilot consumirá GitHub AI Credits ^[10]. Eso no prueba que todos los equipos vayan a pagar más. Sí significa que las organizaciones necesitan entender dónde puede ejecutarse Copilot, quién puede activarlo y cómo se traduce el uso de IA en presupuesto ^[10].

Para equipos que ya están molestos por la actividad de Copilot en espacios compartidos del repositorio, la medición del uso puede hacer que la dirección de GitHub parezca menos un asistente opcional y más una capa facturable integrada en el flujo de desarrollo ^[8][10].

No toda historia contra las grandes plataformas es una salida de GitHub

Algunas narrativas más amplias sobre independencia tecnológica terminan mezclándose con la polémica de GitHub aunque no traten específicamente de GitHub. El perfil de David Heinemeier Hansson en HEY lo identifica como copropietario y CTO de 37signals, además de creador de Ruby on Rails ^[26]. Sus textos recientes hablan de la salida de 37signals de la nube, incluida la llegada de veinte servidores Dell R7625 y un plan para dejar atrás la complejidad cloud ^[17][22].

Esos textos tratan de infraestructura cloud, no de una salida documentada de GitHub. La distinción importa: puede estar creciendo el escepticismo hacia las plataformas centralizadas de software, pero eso no demuestra que los desarrolladores estén abandonando GitHub en masa ^[17][22].

Qué deberían hacer ahora los equipos de ingeniería

La respuesta práctica no es entrar en pánico. Es hacer explícitas las suposiciones sobre GitHub y Copilot.

• Auditar los puntos de entrada de Copilot. Revisar dónde puede aparecer o actuar Copilot: incidencias, pull requests, revisiones de código, comentarios, asignación de incidencias y flujos con @copilot ^[7][8].
• Definir política a nivel de repositorio. Decidir qué funciones de Copilot están aprobadas, restringidas o prohibidas, especialmente en proyectos open source y repositorios sensibles por cumplimiento ^[8].
• Revisar los AI Credits antes del 1 de junio. El uso de Copilot consumirá GitHub AI Credits, así que ingeniería, plataforma y finanzas deberían entender cómo se contabiliza ese uso ^[10].
• Planificar incidentes de agentes de IA. Si la entrega depende de asignar incidencias, comentar en PR o iniciar sesiones de agentes, la disponibilidad de Copilot debe tratarse como una dependencia operativa ^[7].
• Mantener alternativas humanas sencillas. Los repositorios críticos deberían conservar responsables claros, procedimientos de publicación documentados y rutas de recuperación cuando la automatización falle.

En resumen

La afirmación de que los desarrolladores están abandonando GitHub en masa no queda respaldada por la evidencia disponible. La conclusión más sólida es que GitHub afronta una crisis de confianza: Copilot se está metiendo en flujos compartidos de desarrollo, Microsoft estaría reorganizando GitHub alrededor de la programación con IA y los agentes, los incidentes de fiabilidad importan más cuando los agentes realizan trabajo real, y llega la facturación de IA basada en uso ^{[7][8][10][14]}.

GitHub sigue importando. La pregunta abierta es cuánto control exigirán los desarrolladores a medida que la plataforma se vuelva más agresivamente orientada a la IA.