Tim O’Brien eredeti cikke a Mediumon jelent meg; az alábbi anyag az ő engedélyével jelenik meg újraközlésben.
A fejlesztők „haláláról” sokat beszélnek, de a valóság árnyaltabb: a rutin kódolási feladatokat egyre gyorsabban és olcsóbban elvégzik modellek, így azok a munkák el fognak tűnni. Ugyanakkor új szakmai szerep bontakozik ki: az architektákból és fejlesztőkből egyre gyakrabban lesznek orchestrátorok — olyan szakemberek, akik nem elsősorban saját sorokig kódolnak, hanem rendszereket, eszközöket és ügynököket koordinálnak úgy, hogy a végeredmény működő, üzemeltethető termék legyen.
Mi a különbség a fejlesztő és az orchestrátor között?
Az orchestrátor továbbra is ért a szoftverfejlesztéshez, de munkája főként az autonóm vagy félautonom rendszerek felügyelete, a delegált intelligencia rendszerek irányítása és az üzemszerű működés biztosítása. Míg a korábbi technikai szakértelem adatbázis-sémák vagy objektummodellek tervezésére koncentrálódott, az orchestrátor a részrendszerek együttműködését és szabványait határozza meg: például DESIGN.md fájlokkal, amelyek előírják, hogy egy önálló részrendszer miként egyesítse az analitika és a vásárlói visszajelzések adatait a weboldal-változtatások javaslásához, teszteléséhez és élesítéséhez.
Delegált intelligencia — miért fontos ez a kifejezés?
A szerző szerint a „delegált intelligencia” jobban írja le a mai gyakorlati helyzetet, mint az általános „mesterséges intelligencia” vagy „generatív AI”. Az ilyen rendszerek memóriával és bizonyos fokú autonómiával rendelkeznek: a „delegált” szó hangsúlyozza, hogy ezek a rendszerek mindig visszavezethetők egy felelős üzemeltetőre — az orchestrátorra. Ahogy szervezetek kritikus infrastruktúrát bíznak autonóm ügynökökre, növekedni fog az igény az elszámoltathatóságra: egy hiba vagy kiesés esetén meg kell tudni mondani, „kinek az engedélyén működött ez a delegált intelligencia?”.
Orchestrátorok ökoszisztémája: általános szakértelem és specialisták
A jövőben az orchestrátorok inkább generalisták lesznek: több évtizedes, end-to-end tapasztalattal rendelkező szakemberek, akik átlátják a szoftveréletciklust. A specialisták szerepe nem szűnik meg teljesen, de a rutin képességek nagy része modellekben fog létezni. Egy orchestrátor képes lesz 20–30 fejlesztő munkáját irányítani; egyes speciális területekhez viszont továbbra is lesz szükség szakértőkre, köztük „specialist orchestratorokra”.
Gyakorlati példa: DRM és vízjelezés néhány perc alatt
O’Brien saját tapasztalatát ismertetve elmondja, hogy nemrég audiokönyveihez hallhatatlan (inaudible) vízjelezést (order-specific watermark) kellett hozzáadnia: korábban ez hetekbe vagy hónapokba telt volna és specialistákat igényelt volna. Amikor két héttel ezelőtt orchestrálta a rendszer létrehozását, a folyamat 20–40 percet vett igénybe. Az első 20 percben öt különböző megközelítést kért a rendszertől, majd az egyes opciók hosszú távú költségét, operabilitását és a vevői élményt értékelte, végül javaslatot kapott.
A rendszer, amely ezt előállította, több hónapja követte a tartalomfejlesztést és felhasználta az analitikát, a termékdesignt és a vásárlói ismereteket, mielőtt nekilátott volna az implementációnak.
A munka fókusza: nem a kódolás, hanem az orchestráció
Az orchestrátor feladata ma már kiterjed az ötletelésre, terméktervezésre és minőségbiztosításra is. Az ember feladata, hogy megtalálja a megfelelő kérdéseket, mérlegelje a irányokat, és vállalja a felelősséget. O’Brien bevallja, hogy ma sokszor nem olvassa el sorra a generált kódot — mert „nem az ő kódja” — de meg kell értenie, mi történt, és képesnek kell lennie a hibakeresésre és visszaállításra, ha szükséges.
Nem mindenki orchestrátor: a befejezés szakértelme
Nem igaz az a feltételezés, hogy bárki rövid tréning után képes eljuttatni egy rendszert éles, skálázható és biztonságos állapotig. Sokkal könnyebb elindítani projekteket generatív AI-val, nehezebb befejezni és üzemeltethetővé tenni őket. Ha egy bonyolult rendszert úgy hoznak létre, hogy nincs felelős, aki orchestrálja annak életciklusát, egyszer el kell fizetni valakit, aki ezt megteszi — és ennek magas ára lesz.
Offline-tervek és üzemeltetési felelősség
A DRM-példában O’Brien kikötötte, hogy az ügynök dokumentálja a kód helyét, az architektúrát, az alkalmazott megközelítést és készítsen támogató dokumentációt, hogy ha az AI nem áll rendelkezésre, lehessen hibát keresni és támogatást nyújtani. Nem olvasta végig a teljes "pilóta kézikönyvet", de megérti az alapokat, és ha kell, képes „kiállni a repülőgépet” autopilot nélkül.
Ez a gyakorlat azt is mutatja, hogy az orchestrátoroknak képesnek kell lenniük úgy támogatni rendszereket, hogy azok nélkülözni tudják az AI-t — különösen szabályozott és kritikus területeken.
Szervezeti és szabályozási következmények
Az orchestrátori szerep átformálja az IT-szervezeteket: egy orchestrátor több tucat fejlesztő munkáját képes kiváltani, ezért a képzés, a biztosítási kockázatok és a szabályozás is változni fog. O’Brien szerint ez a szerep nem tanítható meg egy hathetes tanfolyamon; hosszú gyakornoki rendszerre lesz szükség, hasonlóan az orvosok vagy jogászok képzéséhez. Mivel orchestrátorok döntései nagy hatással lehetnek rendszerekre és felhasználókra, e felelősség miatt nőni fognak a biztosítási díjak, a minősítési és engedélyezési követelmények.
Jövőkép
Ha 20–30 évre előre nézünk, a ma programozónak nevezett szakemberekből orchestrátorok lesznek, szerepük közelebb áll majd az orvosokéhoz vagy ügyvédekéhoz, semmint a mai kódíró közösségéhez. A kód továbbra is a munkájuk része marad, de már nem a döntő többség.
Szerző: Tim O’Brien (eredeti közlés: Medium)
