- GitHub ha evolucionat de simple repositori a infraestructura completa de desenvolupament, integrant CI/CD, seguretat i agents d'IA al propi flux de treball.
- La combinació d'Agent HQ, Mission Control, GitOps i eines de IaC permet orquestrar infraestructura, desplegaments i agents amb Git com a font única de debò.
- La governança, la seguretat avançada i el mesurament de limpacte de la IA són claus per escalar aquests models en organitzacions grans i entorns regulats.
- Sorgeixen enfocaments complementaris com Pixeltable, Ephyr i arquitectures híbrides o descentralitzades per equilibrar productivitat, control de dades i resiliència.
La forma en què GitHub entén i dissenya la infraestructura ha canviat radicalment el desenvolupament de programari: ja no es tracta només d'allotjar repositoris, sinó de convertir el control de versions, l'automatització i la integració d'IA i la seguretat en una capa estructural del cicle de vida de les aplicacions. Des de la planificació de la infraestructura al núvol fins a la governança d'agents d'intel·ligència artificial, tot passa per GitHub com a eix central.
Al mateix temps, altres enfocaments com GitOps, els data stacks multimodals o les arquitectures descentralitzades estan reconfigurant com es concep la infraestructura moderna. Git és el punt d'ancoratge, però al seu voltant apareixen peces com GitHub Actions, GitHub Copilot, Agent HQ, eines de tercers (ArgoCD, Terraform, Helm, Argo, Flux) i solucions de dades avançades tipus Pixeltable, que s'integren o s'inspiren directament a la filosofia de GitHub.
GitHub com a infraestructura operativa: de repositori a capa central
En pocs anys, GitHub ha passat de ser “el lloc on hi ha el codi” a comportar-se com una infraestructura completa per construir, provar, securitzar i desplegar programari. La combinació de GitHub Actions, Projects, Advanced Security i Copilot fa que bona part del cicle de desenvolupament s'executi sense sortir de la plataforma.
En les pròpies paraules de la comunitat i dels anuncis d'Universe, la IA ja no s'ofereix com un afegit, sinó com una peça de la infraestructura del desenvolupador. GitHub orquestra agents que creen branques, executen proves, obren pull requests i responen comentaris com un col·laborador més, integrant-se al mateix flux que segueixen les persones.
Aquest enfocament es veu reforçat per lús intern de la plataforma: GitHub utilitza GitHub per construir GitHub. Els equips de la companyia automatitzen fluxos amb Actions, gestionen treball amb Projects, protegeixen repos amb Advanced Security i donen suport a l'escriptura de codi amb Copilot, demostrant que el mateix producte serveix com a referència de com operar una infraestructura moderna de desenvolupament.
Així, la infraestructura deixa de ser només servidors i xarxes per convertir-se en un conjunt de primitius de desenvolupament: repositoris, issues, pull requests, pipelins CI/CD, polítiques de seguretat, dashboards de qualitat i ara també agents intel·ligents que treballen colze a colze amb els equips.
IA com a part de la infraestructura: GitHub Copilot, Agent HQ i Mission Control
Una de les peces clau de l'enfocament actual de GitHub a infraestructura és la integració profunda de la intel·ligència artificial al cicle de desenvolupament. GitHub Copilot ja no és només un assistent que suggereix línies de codi: amb Agent HQ i Mission Control, la IA es converteix en un pla d'execució més dins de la infraestructura.
Agent HQ actua com la capa que connecta agents de diversos proveïdors (Anthropic, OpenAI, Google, Cognition, xAI i d'altres dins de l'ecosistema MCP) amb el flux de treball existent a GitHub. Aquests agents no viuen en una eina separada: s'incrusten en issues, branques i pull requests, i s'executen a GitHub Actions oa runners autohostats, amb permisos acotats i governats.
Durant les demos d'Universe es van mostrar agents que creen branques, llancen tests, obren PRs i responen feedback com si fossin un membre més de lequip. La diferència amb altres assistents aïllats és que aquests agents s'acoblin a la canonada CI/CD ia les polítiques del repositori, cosa que resulta essencial per a organitzacions que necessiten complir requisits de compliance i auditoria.
Sobre aquesta base apareix Control de la missió, una consola unificada des de la qual es poden coordinar totes les sessions d'agents: assignar tasques, seguir el seu progrés, reorientar execucions a mig camí i revisar el codi generat. Des de Mission Control es gestionen també aspectes com els controls de branca (quan es dispara la integració contínua del codi dels agents), la resolució de conflictes de fusió o la navegació pels canvis aplicats.
L'editor VS Code, molt lligat a GitHub, també s'està transformant en una superfície “AI-native”. El mode Pla permet co-dissenyar amb Copilot un enfocament pas a pas abans d'escriure codi, formulant preguntes, emplenant llacunes i, quan està tot clar, executant el pla localment o delegant-lo en un agent. A més, s'introdueixen agents personalitzats definits amb fitxers AGENTS.md versionats al costat del codi, que fixen regles d'estil, convencions de proves o polítiques específiques per a cada dipòsit.
Aquest ecosistema es completa amb l'adopció total del Protocol de context model (MCP) i un registre MCP a GitHub, amb servidors com Stripe, Figma o Sentry instal·lables amb un clic. La idea és clara: els agents IA han d'operar allà on ja treballa el desenvolupador, sense forçar salts entre plataformes ni contextos dispersos.
Governança, mètriques i seguretat: el pla de control de la infraestructura a GitHub
Convertir la IA en infraestructura només té sentit si va acompanyada de bon govern, mètriques clares i seguretat integrada. GitHub ha anat reforçant aquest pla de control amb diverses peces que s'acoblen de forma nativa a la plataforma.
D'una banda, GitHub Code Quality ofereix visibilitat i governança sobre mantenibilitat, fiabilitat i cobertura de proves a nivell organitzatiu. Aquestes mètriques s'integren a cada pull request i es recolzen a CodeQL ia les comprovacions de seguretat per evitar que canvis aparentment innocus degraden la salut del codi.
D'altra banda, el Copilot Metrics Dashboard permet mesurar limpacte real de Copilot i dels agents de codificació: ús, adopció, possibles millores en temps de desenvolupament, densitat de bugs, etc. Això dóna peu a dissenys dexperiments tipus A/B per entendre en quina mesura la IA redueix el temps fins al merge, la taxa derrors o la càrrega de manteniment.
En el pla de seguretat, es reforça el concepte de AI Controls o plànol de control per a agents, on és possible definir polítiques centralitzades: quins agents hi poden accedir, quins models estan autoritzats, sobre quins repositoris poden operar i sota quines condicions. Aquests controls són especialment rellevants per a sectors regulats i organitzacions amb requisits estrictes de confidencialitat.
Les dades de l'Octoverse 2025 reflecteixen que aquest enfocament té resultats: els temps de correcció de vulnerabilitats crítiques s'han reduït un 30% a l'últim any, amb Dependabot duplicant adopció i Copilot Autofix aplicant correccions a fallades comunes (com Broken Access Control) en milers de repositoris al mes. La tendència és passar d'un simple “shift left” a un model de “secure by default”, on la seguretat ve integrada i automatitzada des del propi tooling.
No obstant això, la plataforma no és immune a errors de configuració: pipelins mal definits o scaffolds generats per IA sense la supervisió adequada continuen sent vectors de risc. Aquí entra el paper de les polítiques organitzatives i la revisió sistemàtica de plantilles, repos base i regles de branching.
GitHub Modernization Agent: infraestructura, contenidors i desplegament a Azure
Un altre exemple clar de l'enfocament de GitHub en infraestructura és el agent de modernització de GitHub Copilot, pensat per ajudar a migrar i modernitzar aplicacions cap a Azure seguint un flux estructurat “pla create → pla execute”. Aquest agent cobreix dues grans fases: preparació de la infraestructura i contenidorització + desplegament.
En la Fase 1 (preparació de la infraestructura), l'agent genera un pla per proveir la infraestructura d'Azure requerida per l'aplicació. Aquest pla pot dissenyar una zona d'aterratge (landing zone) d'Azure adaptada al context del projecte, incloent-hi bases de seguretat, identitat, governança i xarxes.
Per construir el pla, l'agent es pot recolzar en múltiples entrades: codi font de l'aplicació (per inferir pila tecnològica, dependències i recursos), informes d'avaluació (Modernize Assess, Azure Migrate o altres eines), diagrames d'arquitectura existents i documentació de requisits de compliment i seguretat escrita en llenguatge natural o emmagatzemada al repositori.
l'ordre modernize pla create arrenca aquest procés, generant una arquitectura proposada d'Azure i una llista detallada de recursos a proveir. Per defecte, el pla inclou tant la generació d'arxius d'Infrastructure as Code (IaC) com el propi aprovisionament, tot i que és possible limitar-ho només a la creació d'arxius IaC.
Abans d'executar, l'equip pot revisar els artefactes generats: un arxiu de pla en .github/modernize/<plan-name>/plan.md que descriu l'estratègia d'infraestructura, i un arxiu de tasques en .github/modernize/<plan-name>/tasks.json amb les accions concretes de lagent. Tots dos es poden editar per ajustar recursos, paràmetres de xarxa, mides d'instàncies o polítiques de seguretat.
Un cop validat, s'executa modernize pla execute, que aplica el pla i aprovisiona la infraestructura a Azure. És recomanable validar resultat i canvis amb ordres com git status y git diff main, i contrastar recursos amb Azure Portal o la CLI oficial.
La Fase 2 (contenidorització i implementació) defineix un altre pla dedicat a empaquetar l'aplicació a contenidors i implementar-la a Azure. L'ordre modernize plan create "containerize and deploy my app to azure, subscription: <sub-id>, resource group: <rg-name>" --plan-name deploy genera un flux que pot abastar des de la creació del Dockerfile fins als manifestos de desplegament per al servei de hosting escollit.
En aquest context, la part de contenidorització genera i valida el Dockerfile i la imatge, mentre que la fase de implementació construeix fitxers de configuració, manifestos (per exemple, per a Kubernetes o App Service), executa la implementació i crea un script de desplegament reutilitzable. De nou, es produeix un fitxer plan.md i un tasks.json revisables abans de llançar modernize plan execute --plan-name deploy.
Per als que prefereixin un enfocament més guiat, l'agent també ofereix un mode interactiu (TUI) que unifica ambdues fases sota un assistent visual, accessible simplement executant modernize i seleccionant “Crear pla de modernització”.
GitHub Actions i l'evolució dels pipelins: del CI/CD clàssic als agents
L'enfocament de GitHub sobre infraestructura està íntimament lligat a GitHub Actions com a motor d'automatització. A Universe i altres recursos oficials s'insisteix que les Actions no són només una alternativa a Jenkins, sinó una forma d'integrar el pipeline en el propi disseny de l'aplicació.
El canvi de paradigma és que el pipeline deixa de ser una cosa externa que s'injecta al final, i passa a ser part fonamental del disseny tècnic des del principi. Les Actions, els workflows i la integració amb eines com CodeQL, secret scanning o linters de qualitat encaixen com a peces del mateix repositori, versionades al costat del codi.
El Marketplace de GitHub Actions aporta velocitat amb responsabilitat: milers d'accions llistes per utilitzar permeten muntar pipelines complexos en poc temps, però amb el control de codi font i polítiques organitzatives que poden auditar què s'instal·la, de qui i amb quins permisos.
Tot i que GitHub Actions cobreix una gran part de les necessitats, també es reconeix que no sempre és la millor opció per a tots els contextos. Entorns amb requisits molt específics d'infraestructura, pipelins extremadament personalitzats o integracions amb sistemes heretats poden necessitar solucions híbrides o fonts d'orquestració diferents.
En paral·lel, l'adopció de models tipus GitOps reforça aquesta visió. A GitOps, Git actua com a font única de debò tant per a l'aplicació com per a la infraestructura, amb eines com ArgoCD, Flux, Terraform, Helm o Kustomize per sincronitzar de manera declarativa l'estat desitjat amb allò que realment corre en producció. GitHub, com a origen de repositoris, encaixa de manera natural com el centre de comandament d'aquest model.
Estratègies de ramificació amb GitHub Flow en entorns multicompte i CI/CD
Una altra dimensió clau de l'enfocament de GitHub a infraestructura és la gestió de branques i entorns a gran escala. Documentació i guies d'AWS il·lustren com fer servir GitHub Flow com a estratègia de ramificació en organitzacions amb múltiples comptes i entorns (sandbox, desenvolupament, test, staging i producció).
GitHub Flow es basa en un model simple però potent: una branca principal desplegable en tot moment, de la qual es deriven branques feature, bugfix o hotfix que tornen a integrar-se mitjançant pull requests revisats. L'objectiu és habilitar un lliurament continu en què qualsevol branca de funcionalitat pugui anar a producció quan superi les validacions.
En arquitectures multicompte al núvol, es poden alinear branques amb entorns usant diagrames tipus “quadre de Punnett”: en un eix es col·loquen les branques (feature, main, release, etc.) ia l'altre els entorns (desenvolupament, test, producció). La intersecció indica quines accions s'executen (desplegaments, tests, validacions automàtiques) i en quin ordre.
L'automatització amb pipelins CI/CD és essencial. Serveis com AWS CodePipeline i CodeBuild, integrats amb repositoris a GitHub, permeten orquestrar compilacions, test i implementacions de forma completament automatitzada. A cada etapa, la canalització pot proveir infraestructura addicional temporal o permanent, i coordinar l'aplicació de canvis de configuració.
Les millors pràctiques recomanades per AWS i GitHub passen per alinear aquestes branques amb els estàndards de l'organització, aplicar revisions sistemàtiques a PRs, reforçar la seguretat (incloent-hi escanejats amb CodeQL o eines equivalents) i mantenir diagrames de procés que els equips puguin consultar. També es ressalta la necessitat de definir fluxos específics per a correcció d'errors i hotfix, que solen requerir revisions accelerades però igualment segures.
Independència, descentralització i riscos de monocultura a GitHub
L'enorme èxit de GitHub com a plataforma planteja un repte estratègic: la dependència d'un únic repositori central per allotjar el codi de projectes crítics. Per a moltes organitzacions, aquesta monocultura implica riscos en disponibilitat, seguretat i sobirania de dades.
Empreses centrades en desenvolupament i serveis cloud assenyalen que quan una sola plataforma acumula prop del 90% del codi obert, qualsevol interrupció o canvi de política pot tenir conseqüències sistèmiques: caiguda de pipelins dintegració contínua, bloquejos de repositoris per decisions automatitzades de moderació, o augments de latència en zones geogràfiques concretes.
Per això estan guanyant tracció arquitectures híbrides i descentralitzades que combinen GitHub amb repositoris locals autogestionats o instàncies privades al núvol (per exemple, sobre AWS o Azure). Solucions com Gitea, Forgejo o SourceHut ofereixen alternatives lleugeres que permeten mantenir el control de la infraestructura i les dades, sense renunciar a la col·laboració distribuïda.
Un altre factor emergent és l'impacte dels agents d'intel·ligència artificial i els assistents de codi que generen un alt volum de trànsit i peticions als servidors compartits. Aquest ús intensiu pot afectar el rendiment i incrementar el risc de scraping indiscriminat de repositoris públics. Com a resposta, algunes empreses opten per desplegar els seus propis stacks d'IA privats i agents on-premise o en núvols controlats, evitant enviar dades sensibles a serveis externs.
En aquest context, cobra importància la construcció de solucions d'IA per a empreses que s'integrin de manera segura en infraestructures pròpiescombinant control de versions descentralitzat, serveis de ciberseguretat (auditories, pentesting) i eines d'intel·ligència de negoci (com Power BI) per obtenir visibilitat en temps real sense exposar la propietat intel·lectual.
Data infrastructure i GitHub: Pixeltable i l'stack multimodal
Més enllà del codi, l'enfocament modern d'infraestructura inspirada per GitHub arriba també al món de les dades. Pixeltable és un exemple clar de com aplicar principis similars (declarativitat, incrementalitat i versionat) a la gestió de dades multimodals per a aplicacions d'IA.
Pixeltable és una biblioteca open source a Python que ofereix una interfície tabular declarativa per a dades com imatges, vídeos, àudios i documents. En comptes de mantenir múltiples sistemes (bases de dades relacionals, emmagatzematge de fitxers, bases vectorials) amb integracions fràgils, la solució proposa una única vista tabular on cada columna pot ser d'un tipus multimodal diferent.
En aquestes taules es poden definir columnes computades que executen transformacions de manera incremental, per exemple, detecció d'objectes sobre imatges, transcripció d'àudio o classificació de documents. Quan arriba una nova dada, només es processa aquest element i s'actualitzen les columnes derivades, evitant reprocessar el dataset complet cada cop.
La plataforma s'integra amb APIs externes com OpenAI Vision per a anàlisi en temps real (per exemple, descripció automàtica d'imatges), i amb models de machine learning de Hugging Face per a tasques avançades de visió per ordinador o processament de llenguatge. En entorns com e-commerce, això permet gestionar catàlegs de productes amb fotos, vídeos, ressenyes i enregistraments de suport en una sola infraestructura de dades.
Des del punt de vista de l'arquitectura, Pixeltable es concep com una infraestructura de dades declarativa i incremental que segueix la mateixa filosofia que GitOps o GitHub: el desenvolupador se centra a definir la lògica i les transformacions, mentre que el sistema s'ocupa de la gestió, orquestració i actualització de dades conforme arriben nous esdeveniments.
GitOps, Kubernetes i l'equilibri entre automatització i simplicitat
GitOps ha sorgit com un model que encaixa molt bé amb lenfocament de GitHub en infraestructura. El principi és senzill: tot el que defineix la infraestructura i les aplicacions viu a Git. Des de xarxes i servidors fins a desplegaments de microserveis, tot es versiona com a codi i s'actualitza mitjançant commits i pull requests.
eines com Terraform permeten descriure i administrar la infraestructura com a codi, garantint reproductibilitat i consistència entre entorns. Per a les aplicacions sobre Kubernetes, s'utilitzen solucions com Helm o Kustomize per empaquetar i configurar serveis, mentre que operadors GitOps com ArgoCD o Flux vigilen contínuament l'estat del clúster i el sincronitzen amb allò declarat a Git.
Aquest enfocament redueix errors manuals i millora la traçabilitat: qualsevol canvi queda enregistrat, es pot auditar i revertir amb un rollback controlat. A més, elimina bona part de la bretxa entre desenvolupament i operacions: tots dos equips treballen sobre el mateix repositori, amb la mateixa font de veritat, i amb processos de revisió compartits.
Tot i això, la realitat és que GitOps no és una solució màgica. A mesura que s'adopten arquitectures multinúvol, desenes de microserveis i clústers de Kubernetes, la complexitat de la infraestructura es pot disparar. Integrar múltiples eines per etapa i mantenir un volum creixent de fitxers de configuració requereix un alt nivell d'especialització i una estratègia clara per no caure en la sobreenginyeria.
Un punt especialment delicat és la gestió de secrets i credencials. Automatitzar desplegaments sense intervenció humana obliga a utilitzar solucions avançades com HashiCorp Vault o AWS Secrets Manager, afegint-hi més components i possibles punts de fallada. També és crític definir estratègies de rollback i recuperació davant d'errors en desplegaments per minimitzar impacte en servei.
La recomanació pràctica és adoptar un enfocament pragmàtic: prioritzar simplicitat i mínim viable, triar només les eines necessàries al principi, documentar de manera exhaustiva i revisar periòdicament l'arquitectura per eliminar capes innecessàries. Sovint, simplificar una solució porta més beneficis que afegir una altra abstracció més.
Seguretat de credencials i delegació d'agents: la proposta d'Ephyr
La proliferació d‟agents d‟IA operant sobre infraestructures reals planteja preguntes de seguretat molt serioses: com delegar tasques sense regalar credencials permanents? Aquí entren en joc projectes com Ephyr, que busquen aplicar idees de delegació segura a agents autònoms.
Ephyr es presenta com una implementació de codi obert, inspirada per investigacions de Google DeepMind sobre “Intelligent AI Delegation”, que se situa entre els runtimes d'agents i la infraestructura. En lloc de lliurar claus estàtiques o sessions SSH obertes, utilitza Macaroons com a “tokens de capacitat de delegació” que es poden atenuar criptogràficament i limitar a una tasca concreta.
El disseny posa molt èmfasi a reduir superfície d'atac: implementació pròpia de Macaroons només amb stdlib de Go (crypto/hmac i crypto/sha256) per minimitzar riscos a la cadena de subministrament, amb unes poques dependències directes i un codi prou lleuger per córrer fins i tot en dispositius modestos.
Per afrontar problemes de revocació, es fa servir un mapa de Marca d'Aigua d'Època per ULID de tasca: la validació recorre la cadena de llinatge del token en temps proporcional a la profunditat, permetent matar tots els descendents d'un pare revocat amb una sola entrada de mapa, evitant l'explosió de memòria típica de les llistes de bloqueig JTI.
Com que Macaroons tokens portadors, s'afegeix una capa de proof of possession (PoP) amb vinculació en dues fases: el pare genera un token sense vincular, el fill crea parell de claus Ed25519 efímeres i associa la clau pública a la tasca. A partir d'aquí, totes les peticions exigeixen signatura sobre un nonze i el hash del cos, mitigant atacs de repetició.
El broker ja suporta emissió de certificats SSH efímers, injecció de credencials HTTP i encaminament federat de servidors MCP, amb latències molt baixes en autenticació i verificació. Tot això s'acompanya de whitepapers de seguretat i models d'amenaces detallats al repositori, reflectint una aproximació en què la infraestructura per a agents IA es tracta amb el mateix rigor que qualsevol sistema crític de ciberseguretat.
Impacte global i paper d'Espanya a l'ecosistema GitHub i IA
L'enfocament de GitHub en infraestructura té un reflex directe al mapa global de desenvolupament. Les dades del Octubre vers 2025 mostren màxims històrics: més de 180 milions de desenvolupadors, més d'un nou usuari per segon, 1.120 milions de contribucions públiques i més de 43 milions de pull requests fusionats al mes.
En l'àmbit de la intel·ligència artificial, el creixement encara és més acusat: 4,3 milions de repositoris relacionats amb IA i 1,13 milions de repos públics que importen SDKs de models de llenguatge, amb un increment del 178% interanual. La IA s'integra a la pràctica com a part de l'estructura del desenvolupament, no com a experiment aïllat.
Espanya juga un paper destacat en aquest escenari: més de 2,3 milions de desenvolupadors a GitHub, 470.000 nous registres recents (un creixement proper al 25%) i el novè lloc global en contribucions a repos d'IA, amb més de 139.000 aportacions a l'últim any. Això situa el país a la conversa internacional sobre runtimes, orquestració i eines d'IA.
Per a proveïdors de serveis, ISVs i equips interns, la disponibilitat de agents de tercers integrats a GitHub Copilot redueix el cost d'avaluació d'eines i en limita el lock-in. Alhora, obliga a reforçar la governança: documentació de repos, plantilles de README, estàndards de proves, convencions de seguretat i ús disciplinat de AGENTS.md i polítiques de IA.
Satya Nadella, al tancament d'Universe 2025, va emmarcar aquest moment històric comparant la transició actual cap a agents cognitius amb el salt anterior des d'assemblador a compiladors. Els agents generen codi, però continuem pensant en codi; el que canvia és on i com passa aquesta cognició, i GitHub aspira a ser la casa on s'articulin patrons, pràctiques i governança per evitar la fragmentació caòtica de l'ecosistema.
Tot aquest conjunt de tendències —la IA com a infraestructura, GitHub com a pla de control del desenvolupament, GitOps i IaC com a base operativa, nous models de seguretat per a agents, i una comunitat global en creixement amb Espanya en primera línia— dibuixa un panorama en què la infraestructura ja no és només maquinari o cloud, sinó una capa viva d'eines, fluxos, polítiques.
