El mite del pipeline «self-healing» sense humans: una lectura crítica des del 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 per l'IEEE el febrer del 2026. La tesi és la mateixa que ja llegíem el 2019, només que ara 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 tota visió, és més útil llegir-la pel que assumeix que pel que conclou. Deixa'm fer-ho des d'on soc: fa anys que faig DevOps en producció en una empresa amb operacions complexes i prou escala per saber on encaixa la IA al pipeline i, sobretot, on encara no ha encaixat malgrat sis anys de promeses molt semblants.

La paraula que fa tota la feina retòrica: «minimal»

«Minimal human intervention» és la frase que sosté tota la promesa del paper i de la categoria sencera. Si la llegeixes com a CTO, la pregunta operativa és: minimal respecte de què? Comparat amb un pipeline manual del 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'intenció (què construïm, quina política, com prioritzem) i per als incidents.

Per tant, la pregunta no és si redueixes la intervenció humana — els pipelines moderns ja l'han reduïda. La pregunta és si redueixes l'ownership humà del sistema. I la resposta empírica, que els papers de visió eviten sistemàticament, és que no.

On la IA sí que ha empès el pipeline

Siguem justos amb el paper. Hi ha àrees on afegir IA al CI/CD ha donat resultats reals i mesurables entre el 2024 i el 2026. Aquestes les implemento i les recomano:

Generació i revisió de codi als PRs. Copilot/Claude/Cursor donen productivitat a l'autor del PR i descarreguen el revisor dels comentaris trivials (estil, naming, el cas obvi de null). En aquesta capa, el paper té raó.

Detecció d'anomalies en mètriques i logs. Els models de sèries temporals i el clustering basat en embeddings són clarament millors que els llindars estàtics que dominaven l'AIOps de l'era 2018. La detecció d'anomalies és la franja del pipeline on l'AIOps brilla més — ben delimitada, amb un blast radius baix, fàcil de validar.

Triatge inicial d'alertes. Aquí la IA pot fer una primera classificació, agrupar alertes correlacionades i reduir el soroll que arriba a l'enginyer de guàrdia. És una capa estructuralment defensiva — si s'equivoca, l'alerta passa igualment.

Generació de runbooks i documentació post-incident. Convertir post-mortems narrats en documentació estructurada és un cas d'ús gairebé ideal: human-in-the-loop al final, cost d'error baix.

Optimització de configuració. Tuning de paràmetres del scheduler, autoscaling, mides de pool — espais de cerca petits on el RL té sentit i l'error és reversible.

Tot això és real i compatible amb la meva tesi. La IA augmenta el pipeline. Cap d'aquestes coses no elimina enginyers. Totes multipliquen la palanca de l'enginyer.

On la promesa del paper toparia amb la realitat operativa

Quatre afirmacions del paper demanen una mirada directa, no perquè siguin tècnicament impossibles, sinó perquè operativament són ingènues.

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 té el context — és la part que s'emporta el 80% del temps real d'un canvi seriós: entendre per què el sistema és com és, quins invariants no escrits depenen d'aquesta funció, quin equip es veurà 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 estan resolts.

L'evidència empírica que tinc, i que qualsevol head d'enginyeria que mesuri podrà validar: la corba del temps total entre que s'obre el PR i es fa el merge no baixa tan de pressa com la corba del temps entre que arriba la tasca i s'obre el PR. Això vol dir que la IA ha accelerat una part del cicle, no el cicle. La part lenta s'ha desplaçat d'«escriure» a «revisar i encaixar-ho a producció».

2. «Error detection amb mínima intervenció humana»

L'AIOps és bo detectant anomalies. És notòriament feble a l'hora de decidir què fer-ne. La distinció és exactament la que veiem al paper d'ActionNex que llegia en paral·lel a aquest: un 71% de precision i un 53% de recall sobre la mateixa decisió que el paper de l'IEEE descriu com a «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 sensiblement millor que un humà detectant — i pitjor que un humà decidint, sobretot davant de situacions noves.

3. «Deployment amb mínima intervenció humana»

Aquí és on la promesa es trenca més fàcilment. Els deploys complexos no fallen perquè algú no ha clicat 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 criteri 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 és dins del model.

4. «Self-improving ecosystems»

Aquesta és la part de la visió que demana més atenció crítica. «Self-improving» en sentit estricte només funciona quan tens un senyal de reward ben definit, decisions fixes i un bucle 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, compliance, blast radius dels deploys, i així successivament. Aquests trade-offs els decideix la direcció d'enginyeria; no es descobreixen de manera autònoma.

Un sistema que «s'automillora» contra una funció de reward que no representa correctament aquests trade-offs no és un sistema que millora. És un sistema que optimitza un proxy fins que el proxy es trenca. He vist prou projectes d'auto-tuning per saber que la part difícil no és mai l'algorisme; sempre és definir la funció objectiu de manera que no col·lapsi en un òptim local desagradable.

El cost ocult d'apostar pel «self-managing»

Hi ha un cost que els CTO joves de vegades no veuen i que els seus CFO acaben veient divuit mesos més tard. Si la teva aposta operativa és «automatitzem-ho i que decideixi el sistema», d'aquí a divuit mesos ja no tindràs ningú a l'organització que entengui per què el sistema decideix el que decideix.

Qualsevol que hagi portat un equip d'operacions coneix aquesta dinàmica: quan s'automatitza una capa, l'expertesa sobre aquella capa s'erosiona. Mentre el sistema funciona, ningú no la troba a faltar. Quan el sistema deixa de funcionar — i ho farà —, no tens ningú capaç de reparar-lo des dels fonaments. La dependència del proveïdor d'IA es converteix en un risc estructural.

Aquesta és una conversa diferent de «la IA substituirà els enginyers». La pregunta és: quin perfil d'enginyeria necessites conservar per fer servir bé la IA? I la resposta no és menys sènior; sovint és més sènior. Un júnior pot delegar feina a la IA i obtenir un resultat decent. El sènior és qui detecta quan el resultat decent és estructuralment incorrecte. Aquest discerniment és exactament el que el «self-managing» dona per resolt — i no ho està.

Què recomanaria a un CTO que llegeixi el paper

Tres decisions pràctiques que treballaria amb l'equip executiu:

Primer: separa el màrqueting del producte. Els teus proveïdors d'eines de pipeline et vendran el «self-managing» com a feature. Llegeix-ho com a «augmentació amb una interfície més neta». No assignis pressupost segons la promesa; assigna'l segons l'augmentació concreta que mesuris (temps de PR, MTTR, cost per deploy, satisfacció dels desenvolupadors). Si la mètrica no es mou, la promesa no s'està complint.

Segon: mantén l'ownership del sistema en mans humanes, sempre. L'agent d'IA pot suggerir, executar accions reversibles, generar esborranys. La decisió sobre canvis amb un blast radius gran (deploys de versió major, migracions, canvis d'autenticació, polítiques de seguretat) requereix aprovació humana per defecte. Aquesta política s'escriu, no se suposa.

Tercer: inverteix en seniority, no en headcount. La palanca de la IA és asimètrica — un enginyer sènior amb IA produeix significativament més que un júnior amb IA. Si has de triar entre un equip de 12 amb seniority mixta i un de 8 amb seniority alta i una bona pila d'eines d'IA, el segon serà més fiable per a sistemes amb conseqüències reals. La IA aplana la part baixa de la corba; no n'aplana la part alta.

La línia que defenso

La IA es pot implementar a tot el pipeline. L'he implementada i n'implementaré més. No substitueix els enginyers, perquè la part del pipeline que més importa — el criteri sobre canvis amb un 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 la sàpiguen fer aviat, perquè el coll d'ampolla no és la mida del model; és la representació del context operatiu.

Els papers de visió com el de l'IEEE compleixen una funció: ens donen un nord aspiracional i ens obliguen a articular per què la nostra realitat empírica encara no hi és. Però si el teu pla operatiu per al 2026 es basa a retallar enginyers perquè «el pipeline serà self-managing», la lectura crítica d'aquest mateix paper i del de Microsoft sobre ActionNex t'hauria de fer recalibrar. Hi ha un futur d'augmentació molt sòlid. Encara no hi ha un futur d'autonomia, i fer veure el contrari és una decisió pressupostària, no tècnica.

L'enginyer continua sent la peça que no es pot externalitzar a cap 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 del 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 potenciar amb IA sense perdre l'expertesa sènior que el manté fiable? Parla amb un CTO sobre com desplegar una squad nearshore amb la combinació adequada de seniority i tooling modern.