Az elmúlt két évben a modern adatplatformok commit-történetét nézve világos változás történt: megszűnt az a korábbi súrlódás, ami a szintaxis megírásához kapcsolódott. Olyan eszközök és munkafolyamatok — például Cursor, Claude Code és agentikus munkamenetek — kerültek be a fejlesztők helyi környezetébe, Docker-konténerekbe és IDE-kbe, hogy egy elosztott streamelési pipeline vagy egy összetett API-integráció első megvalósítása már nem jelenti a legnagyobb akadályt.
Az ügynökök képesek repozitóriumokat bejárni, tesztlefedettséget létrehozni, stack trace-eket elemezni és refaktorálási javaslatokat tenni. Egy egyszerű, angol nyelvű leírás a Kafka‑to‑Iceberg sink-mappolásról gyakran elegendő ahhoz, hogy az ügynök hiteles kezdőpontot állítson elő, még mielőtt a mérnök minden kapcsolódó fájlt megnyitna.
Ez más megvilágításba helyezi a szoftvermérnökök munkáját. Ha az ügynök lesz a helyi rendszerlogika elsődleges szerzője, mi marad a mérnökre? Csak véleményezők leszünk, akik sorra igazolják az ügynökök által előállított pull requesteket? Vagy a munka elmozdult az implementációs részletek megírásától egy absztraktabb feladathoz — a rendszerek határainak és visszacsatolásának megtervezéséhez?
Az ügynök, mint hőgép
Ha levetkőzzük az antropomorfizmust, az AI-ügynök egyszerűen egy számítási motor: irányt kap, és azt cselekvéssé alakítja. Egy nagy nyelvi modell adatközpontban ülve nagy kapacitással bír, de hasznos munkát csak akkor végez, ha szándékot adunk hozzá: prompt, üzleti követelmény, rendszerutasítás vagy egy sikertelen teszt ad irányt. Az ügynök ezt lefordítja kódra, eszközhívásokra, lekérdezésekre, tesztekre és futó rendszerbeli változtatásokra.
Mint minden motor, az ügynökök működése is veszteségekkel jár. A nehezen kezelhető repozitóriumokkal dolgozó ügynököknél gyakran látható jelenség: egy tiszta feladatból elindulva az ügynök régi feltételezésekhez ragaszkodik, tüneteket javít a valódi ok helyett, egy régi migrációt aktuális viselkedésnek vesz, és saját „múltat” kezd felhalmozni. Néhány eszközhívás után a kontextus tele lesz valószerű, de ellentmondó részletekkel, és a következő lépés bizonytalanabb lesz, mint az első volt.
Ezt hívhatjuk operatív entrópiának: a régi feltételezések, ágazó kontextusok és megoldatlan függőségek felhalmozódása egy olyan körben, amely mégis előre próbál haladni. Emberi beavatkozás azért segít, mert új információt vezet be; ugyanígy segít egy sikertelen teszt, egy pontos adat‑szerződés, egy determinisztikus eszköz vagy egy értékelés, amely megmondja az ügynöknek, mit rontott el. Jelző nélkül az ügynök tovább termelhet outputot, miközben eltávolodik a helyes eredménytől.
A végtelen majom és a növekvő keresési tér
A végtelen majom tétele szemléletes képet ad a cselekvések ismétléséről, a véges korlátokról és a visszacsatolásról. A modern ügynökök sokkal okosabb majmok: rendelkeznek fordítókkal, eszközökkel, repozitóriumokkal, tesztcsomagokkal és visszacsatolási hurkokkal. Munkájuk nem véletlenszerű — a visszacsatolás irányítja a következő próbálkozást — de a dinamikája hasonló: javasol, végrehajt, megfigyel, korrigál és próbálkozik újra.
Egy jól behatárolt feladatnál ez a kör rendkívül hatékony. Ha az ügynök ismeri a bemeneti sémát, a célsémát, a kisméretű kódbázist és olyan teszteket kap, amelyek elkapják a releváns hibákat, képes vizsgálni a kódot, módosítani, futtatni a teszteket, feldolgozni az eredményeket és konvergálni a megoldás felé. Ott a „kész” definíciója látható, a keresési tér szűk, és a hurok összeérhet.
A vállalati rendszerek azonban ritkán ilyen statikusak. Egy valós idejű árképzési motor működési állapota változik, harmadik fél API‑k jöhetnek és mennek, régióspecifikus szabályok és üzleti logikák lehetnek elosztva kódban és emberek fejében. Egy data lakehouse lehet fizikai értelemben konzisztens, de szemantikailag hibás. Egy pipeline átmehet a tesztjein, mégis olyan számokat adhat, amelyeket a pénzügy nem ismer fel. A környezet változik, miközben az ügynök „gépel”.
Az enterprise logika háromtest‑problémája
Ezért jó metafora az úgynevezett háromtest‑probléma a vállalati szoftvernél. Két test esetén — egy bolygó és egy csillag — a mozgás előre jelezhető matematikai leírással. Ha egy harmadik testet adunk hozzá, az általános, zárt formájú megoldás eltűnik és egyes konfigurációk kaotikussá válhatnak: kis változtatások nagy eltéréseket okozhatnak.
A modern adatplatformok hasonlóan viselkednek. A clickstream változik a termék viselkedésével, az operatív adatbázis változik a felhasználói műveletektől, az API‑k verziót váltanak, a sémák fejlődnek, a biztonsági irányelvek módosulnak, és a legacy rendszerekben olyan szabályok lehetnek, amelyeket senki sem dokumentált. Minden rendszer nyomást gyakorol a többire: egy helyi változtatás megváltoztathatja egy másik rész jelentését vagy működését.
Példaként képzeljük el, hogy egy ügynöknek azt a feladatot adják, hogy adjon hozzá egy customer_tier mezőt egy revenue modellhez. Az ügynök megtalál egy status mezőt az operatív adatbázisban, belevezeti azt a transzformációba, és a meglévő típus‑ és nullabilitási teszteken átmegy. A kód tiszta, a pipeline zöld — mégis a válasz helytelen lehet. Egy szemantikai adatszerződés kimondhatja, hogy a customer_tier a legutóbbi tizenkét hónapbeli költésből származik, van hozzárendelt üzleti tulajdonosa, és nem tölthető fel az account status alapján. Ez az adatszerződés elutasítja a változtatást. Ebben a történetben a mérnök értéke nem a transzformáció megírásában volt, hanem abban a határban, amely az ügynök hibáját láthatóvá, specifikussá és helyrehozhatóvá tette.
Az új mandátum: az egyensúly tervezése
A szoftvermérnök feladata tehát nem tűnik el azzal, hogy a kódgenerálás olcsóbbá és gyorsabbá válik — ellenkezőleg: a mérnöki érték láthatóbb lesz. Az új mandátum az „egyensúly tervezése”: olyan feltételek létrehozása, amelyek között az ügynok által generált logika megbízhatóan működhet.
Amikor egy üzleti követelmény gyorsabban változik, mint az ügynök képes visszacsatolást feldolgozni, a mérnöknek tartomány‑szűkítő szerkezeteket kell felépítenie. A szigorú szemantikai rétegek, az immutábilis eseménynaplók, az adatszerződések, az idempotens API‑k és a determinisztikus állapotgépek nem csupán jó platform‑higiénia elemei: ezek csökkentik azon feltételezések számát, amelyet az ügynöknek egyszerre kell kezelnie.
Ezek a megoldások a laza kapcsolódású problémákat korlátozott doménekké alakítják, ahol világos a bemenet, explicitek a szabályok és megbízható a visszajelzés. Ha ilyen domén létezik, az ügynök valóban hatékony: megírhatja a transzformációt, futtathatja a teszteket, javíthatja a hibákat és deployolhat anélkül, hogy ki kéne következtetnie az összes íratlan történetet minden tábláról és szolgálatról.
Autonóm rendszerek egyre többet fognak automatikusan generálni. De azok a szerződések, visszacsatolási hurkok és határok, amelyek eldöntik, hogy ez a szoftver sikeres lesz‑e vagy káoszba sodródik, továbbra is a szoftvermérnökök által tervezettek és felügyeltek maradnak.
Ananth Packkildurai data engineering vezető, író és a Data Engineering Weekly szerkesztője; munkáiban a modern adatplatformokkal, nagy‑skálájú pipeline‑okkal és AI‑vezérelt architektúrákkal kapcsolatos tapasztalatait osztja meg.
