El Mite del Pipeline 'Self-Healing' Sense Humans: Lectura Crítica des de DevOps
Cada dotze mesos torna el mateix paper. Aquesta vegada és AI-Driven DevOps for Intelligent Automation in Continuous Software Delivery Pipelines (Kiran Raj K M et al., ICECMSN 2025), publicat a l'IEEE el febrer de 2026. La tesi és la mateixa que llegíem el 2019, només actualitzada amb LLMs i reinforcement learning a la nomenclatura:
"...emerging technologies such as generative AI enable fully automated pipeline capable of code generation, error detection, deployment, and performance monitoring with minimal human intervention. ... a future where software systems evolve into self managing, self improving ecosystems driven by continuous learning and intelligent automation."
És una visió, no un paper empíric. I com a tota visió, és útil llegir-la pel que assumeix més que pel que conclou. Vaig a fer-ho des d'on em toca: porto anys fent DevOps en producció a una empresa amb operacions complexes i el suficient com per saber on la IA encaixa al pipeline i, sobretot, on no ha encaixat encara malgrat sis anys de promeses molt similars.
La paraula que fa tota la feina retòrica: "minimal"
"Minimal human intervention" és la frase que carrega tota la promesa del paper i de la categoria sencera. Si la lleges com a CTO, la pregunta operativa és: minimal respecte de què? Comparat amb un pipeline manual de 2012, qualsevol pipeline modern amb GitHub Actions, Argo CD, Terraform i un test runner ja és "minimal human intervention" — l'humà només toca el sistema per als canvis d'intencionalitat (què construïm, quina política, com prioritzem) i per als incidents.
Així que la pregunta no és si redueixes la intervenció humana — el pipeline modern ja l'ha reduïda. La pregunta és si redueixes l'ownership humà sobre el sistema. I la resposta empírica, que els papers de visió sistemàticament eviten, és: no.
On la IA sí que ha empès el pipeline
Sigues just amb el paper. Hi ha àrees on l'addició d'IA al CI/CD ha donat resultats reals i mesurables el 2024–2026. Aquestes les implemento i les recomano:
Generació i revisió de codi en PRs. Copilot/Claude/Cursor aporten productivitat a l'autor del PR i lleugeresa al revisor en comentaris triviales (estil, naming, cas òbvi de null). El paper té raó en aquesta capa.
Detecció d'anomalies en mètriques i logs. Els models de séries temporals i embedding-based clustering són clarament millors que els thresholds estàtics que dominaven l'AIOps 2018. La detecció d'anomalies és la franja del pipeline on AIOps brilla més — bé estructurada, baix blast radius, fàcil de validar.
Triatge inicial d'alertes. Aquí la IA pot fer una primera classificació, agrupar alertes correlacionades, i baixar el soroll que arriba a l'enginyer de guàrdia. És una capa estructuralment defensiva — si s'equivoca, l'alerta encara passa.
Generació de runbooks i documentació post-incident. Convertir post-mortems narrats en documentació estructurada és un cas d'ús quasi ideal: humà al loop al final, baix cost d'error.
Optimització de configuració. Tuning de paràmetres de scheduler, autoscaling, mida de pools — petits espais de cerca on RL té sentit i on l'error és reversible.
Tot això és real i compatible amb la meva tesi. La IA augmenta el pipeline. Cap d'aquestes coses elimina enginyers. Totes augmenten la palanca de l'enginyer.
On la promesa del paper trencaria contra la realitat operacional
Hi ha quatre afirmacions del paper que cal mirar-se a la cara, no perquè siguin tècnicament impossibles, sinó perquè operacionalment són naïves.
1. "Code generation amb mínima intervenció humana"
El primer mig minut d'un PR generat per IA pot estar bé. El que la IA no resol — perquè estructuralment no en té el context — és la part que ocupa el 80% del temps real d'un canvi seriós: entendre per què el sistema és com és, quines invariants no escrites depenen d'aquesta funció, quin equip serà afectat upstream, què passa si això es desplega un divendres a les 17:00. La generació de codi és la part fàcil. El context i la negociació són la part difícil, i no s'han resolt.
L'evidència empírica que tinc, i que qualsevol head d'enginyeria que estigui mesurant pot validar: la corba de temps total entre PR obert i PR mergeat no s'està plegant tan ràpid com la corba de temps entre tasca rebuda i PR obert. Vol dir que la IA ha accelerat una part del cicle, no el cicle. La part lenta s'ha desplaçat de "escriure" a "revisar i acomodar a producció".
2. "Error detection amb mínima intervenció humana"
L'AIOps és bo detectant anomalies. És notòriament feble decidint què fer-hi. La distinció és exactament la que veiem al paper d'ActionNex que llegia en paral·lel a aquest: precision del 71%, recall del 53% sobre la mateixa decisió que el paper IEEE descriu com "minimal intervention". El sistema veu que alguna cosa va malament; la meitat de les vegades, no proposa l'acció correcta. Aquesta és la frontera. La IA ja és força millor que un humà detectant — i pitjor que un humà decidint, especialment sobre situacions noves.
3. "Deployment amb mínima intervenció humana"
Aquí és on la promesa més fàcilment es trenca. Els deploys complexos no fallen perquè algú no va clicar el botó correcte. Fallen perquè:
- Una migració de schema és incompatible amb el rolling deploy.
- Un feature flag està en un estat inconsistent entre regions.
- Una dependència externa té rate limiting que només es manifesta a producció.
- Un canvi de configuració interactua de manera no documentada amb un job de cron de fa cinc anys.
Tots aquests casos requereixen judgment sobre el sistema, no execució del runbook. La IA pot accelerar el runbook quan el runbook és correcte. No detecta quan el runbook és incorrecte per a aquesta combinació concreta. L'enginyer sí, perquè coneix la història del sistema. I la història del sistema no està entrenada al model.
4. "Self-improving ecosystems"
Aquesta és la part de la visió que requereix més atenció crítica. "Self-improving" en sentit estricte només funciona quan tens un senyal de reward ben definit, fitxa la decisió, i un loop de millora ràpid. El CI/CD no és això. La "qualitat" d'un pipeline no és una mètrica univariada — és un trade-off entre velocitat, fiabilitat, cost, satisfacció dels desenvolupadors, conformitat, blast radius dels deploys, etc. Aquests trade-offs els decideix la direcció d'enginyeria, no es descobreixen autònomament.
Un sistema que "s'auto-millora" sobre una funció de reward que no representa correctament aquests trade-offs no és un sistema que millora. És un sistema que optimitza una proxy fins que la proxy es trenca. He vist suficients projectes d'auto-tuning per saber que la part difícil mai és l'algoritme; sempre és definir la funció objectiu de manera que no col·lapsi en un local optimum desagradable.
El cost ocult d'apostar pel "self-managing"
Hi ha un cost de carrera que els CTOs joves de vegades no veuen i que sí que veuen els seus directors financers després. Si el teu lead operacional és "automatitzem-ho i ja decidirà el sistema", al cap de divuit mesos no tens algú a l'organització que entengui per què el sistema decideix el que decideix.
Tothom que ha gestionat un equip d'operacions sap aquesta dinàmica: quan una capa s'automatitza, l'expertise sobre aquella capa s'erosiona. Si el sistema funciona, ningú la necessita. Quan el sistema no funciona — i passarà —, no tens ningú que sàpiga reparar-la des de primers principis. La dependència del proveïdor d'IA esdevé un risc estructural.
Aquesta és una conversa diferent de "la IA substituirà els enginyers". La pregunta és: quin perfil d'enginyer necessites mantenir per fer servir bé la IA? I la resposta no és menys senior; sovint és més senior. Els junior poden delegar feina a la IA i obtenir output decent. Els senior són els que poden detectar quan l'output decent és estructuralment incorrecte. Aquest discerniment és exactament el que el "self-managing" assumeix com a resolt — i no ho és.
Què recomanaria a un CTO que llegeix el paper
Tres preses pràctiques que faria amb l'equip executiu:
Primer: separa el discurs del producte. Els teus proveïdors d'eines de pipeline et vendran "self-managing" com a feature. Llegeix-ho com "augmentation amb interfície més neta". No assignis pressupost basat en la promesa; assigna pressupost basat en l'augmentació concreta que mesures (temps de PR, MTTR, cost per deploy, satisfacció del developer). Si la mètrica no es mou, la promesa no s'està complint.
Segon: mantén la ownership del sistema en humans, sempre. L'agent IA pot suggerir, executar accions reversibles, generar drafts. La decisió sobre canvis amb blast radius gran (deploys de major version, migracions, canvis d'autenticació, polítiques de seguretat) requereix aprovació humana per defecte. Aquesta política s'escriu, no s'assumeix.
Tercer: inverteix en seniority, no en headcount. L'apalancament de la IA és asimètric — un enginyer senior amb IA produeix significativament més que un junior amb IA. Si has de triar entre un equip de 12 amb seniority mixta i un equip de 8 amb seniority alta més una bona pila d'eines IA, el segon serà més fiable per a sistemes amb consequence real. La IA aplana la part baixa de la corba; no aplana la part alta.
La línia que defenso
La IA és implementable a tot el pipeline. La he implementat i la implementaré més. No és substitutiva dels enginyers, perquè la part del pipeline que importa més — el judgment sobre canvis amb blast radius gran, l'ownership dels incidents, la negociació entre velocitat i risc — no és la part que els models actuals saben fer. I no sembla que ho sàpiguen fer aviat, perquè el coll d'ampolla no és la mida del model; és la representació del context operacional.
Els papers de visió com el de l'IEEE serveixen una funció: ens donen un norte aspiracional i ens fan articular per què la nostra realitat empírica encara no hi és. Però si el teu pla operatiu de 2026 es basa en treure enginyers perquè el "pipeline serà self-managing", la lectura crítica del mateix paper i del de Microsoft sobre ActionNex haurien de fer-te recalibrar. Hi ha un futur d'augmentació molt fort. No hi ha encara un futur d'autonomia, i pretendre el contrari és pressupostari, no tècnic.
L'enginyer continua sent la peça que no es pot lliurar a un proveïdor.
Fonts:
- Kiran Raj K M, Karthik K Poojary, Abhay, Aishwarya R S, Lathesh Kumar S R. AI-Driven DevOps for Intelligent Automation in Continuous Software Delivery Pipelines. ICECMSN 2025, IEEE Xplore (febrer 2026). DOI:10.1109/ICECMSN68058.2025.11382867
- Lin, Z., Hu, H., Hao, M., et al. ActionNex: A Virtual Outage Manager for Cloud Computing. arXiv:2604.03512 (2026). arxiv.org/abs/2604.03512
Tens un pipeline CI/CD que vols apalancar amb IA sense perdre l'expertise senior que el manté fiable? Parla amb un CTO sobre desplegar un squad nearshore amb la combinació adequada de seniority i tooling modern.
