Az LLM-ek és a programozás jövője

A kiindulás

Ami már megtörtént, csak nem mondjuk ki hangosan

Az elmúlt években végigkísértem néhány fejlesztőcsapatot azon az úton, ahogy az LLM-ek beépültek a napi munkájukba. Az elején mindenki ugyanazt a félelmet fogalmazta meg. Elveszi a gép a munkámat. A gyakorlatban egészen más történt. A kód egy része tényleg átkerült a modellhez, a fejlesztő viszont nem tűnt el, hanem feljebb lépett egy szinttel. Onnantól nem soronként írta a megoldást, hanem megfogalmazta, mit akar, elindította a modellt, és megnézte, hogy a végeredmény állja-e a sarat.

Ez a váltás sok helyen már lezajlott, csak ritkán beszélünk róla nyíltan. A fejlesztők egy része még mindig úgy tesz, mintha minden sort ő gépelne be, közben napi szinten használ egy modellt, ami a munka jó részét leveszi a válláról. A kérdés régóta nem az, hogy jön-e ez a változás. Az a kérdés, hogy ki érti meg időben, mi lesz ettől a fejlesztő dolga.

A modell dolga

A kód egy részét már a modell állítja elő

Ma egy jól megírt feladatleírásból az LLM percek alatt felépíti egy funkció vázát. Megírja a rutinokat, amelyek eddig a fejlesztő idejének nagy részét elvitték, az adatlekérést, a formázást, a hibakezelés csontozatát, a teszteset első verzióját. Ez a munka nem volt haszontalan, de ritkán igényelt valódi ítéletet. Pontosan az a fajta strukturális, ismétlődő feladat, amiben a modell erős.

Amit a modell visszaad, az ritkán kész megoldás. Sokkal inkább egy erős kiindulópont, egy hetven százalék körüli váz, amiből már látszik az irány. A maradékot a fejlesztő teszi hozzá, mert ott dőlnek el a nehéz kérdések, ott bonyolódik a logika, és ott a legnagyobb a tévedés ára. A modell tehát nem a fejlesztő helyére lép, hanem elviszi előle az ismétlődő terhet, hogy a nehezebbik felére maradjon energia.

Ez a mozgás egyre feljebb kúszik a munka rétegein. Kezdetben csak egy-egy függvényt írt meg helyettünk a modell. Ma már egész modulokat vázol fel, és a fejlesztő inkább a szerkezetről dönt, mint az egyes sorokról. A gépelés, ami korábban a szakma nagy részét kitöltötte, egyre kisebb szeletté zsugorodik.

Az új szerep

A fejlesztő a célt fogalmazza meg, és a rendszert irányítja

Ahogy a gépelés terhe csökken, előtérbe kerül egy másik képesség. Pontosan megfogalmazni, mit akarunk. Ez nehezebb, mint amilyennek elsőre hangzik. Egy modell annyit ér, amennyit a feladat leírása megenged neki. Ha a fejlesztő homályosan kér valamit, homályos kódot kap vissza. Ha viszont tisztán látja a rendszer felépítését, a határokat és az elvárásokat, akkor a modell is pontosabban dolgozik.

Ez a munka közelebb áll a tervezéshez, mint a gépeléshez. A fejlesztő eldönti, milyen legyen az architektúra, hol húzódnak a modulok határai, mi kerüljön egy szolgáltatásba és mi maradjon külön. A modell ezen a vázon belül mozog. Az irányítás azt jelenti, hogy a fejlesztő végig fenntartja a rálátást az egészre, miközben a részleteket delegálja. Ha elveszti ezt a rálátást, a modell gyorsan olyan irányba viszi a kódot, ami később fájni fog.

Sokan azt hiszik, hogy a jó feladatleíráshoz elég néhány mondat. A tapasztalatom más. A pontos irányítás megköveteli, hogy a fejlesztő fejben tartsa a rendszer működését, tudja, mi hol csatlakozik, és lássa előre, milyen következménnyel jár egy döntés. Ez a fajta gondolkodás korábban is a szakma magja volt, most viszont a napi munka középpontjába kerül.

Az ellenőrzés

A végeredményért továbbra is ember felel

Az LLM magabiztosan ír le olyat is, ami nem igaz. Kitalál egy függvényt, ami nem létezik, hivatkozik egy mezőre, amit senki nem definiált, vagy olyan feltételezéssel él, ami a cég szabályai szerint helytelen. A modell ezt nem rosszindulatból teszi, hanem mert nincs valódi rálátása az üzleti kontextusra. Ezért az ellenőrzés nem a folyamat végére biggyesztett lépés, hanem a fejlesztő egyik legfontosabb munkája.

Az ellenőrzés itt nem a régi kódfelülvizsgálattal egyenlő. A fejlesztőnek fel kell tennie a kérdést, hogy a modell megoldása illik-e a rendszer egészébe, betartja-e a biztonsági szabályokat, és azt csinálja-e, amit az üzlet valóban kér. Ehhez érteni kell a kódot akkor is, ha nem az ember írta. Aki csak átfut a generált soron és bólint, idővel elenged egy hibát, ami éles környezetben derül ki, ott, ahol a legdrágább javítani.

Van itt egy csendes veszély is. Amikor a modell rendre használható kódot ad, könnyű ellustulni és megbízni benne. A jó fejlesztő pontosan ekkor élesíti a figyelmét. Minél gördülékenyebben dolgozik a modell, annál fontosabb, hogy valaki kritikusan nézze, mit enged tovább. Ez a fajta felelősség nem delegálható a gépnek.

A gyakorlatban

Egy budapesti fejlesztőcsapatnál mit jelentett a váltás

Tavaly egy budapesti szoftvercéghez hívtak, ahol egy nyolcfős fejlesztőcsapat dolgozott egy logisztikai rendszeren. Már használtak LLM-eket, de mindenki a maga módján. Volt, aki egész funkciókat generáltatott, aztán napokig kereste bennük a hibát. Volt, aki elvből nem nyúlt hozzá, mert nem bízott benne. A csapat sebessége szórt, a felülvizsgálati körök pedig elhúzódtak, mert a triviális hibák is a kollégákon csattantak.

Amikor leültünk, gyorsan kiderült, hogy nem az eszközzel van a baj, hanem a szerepekkel. Senki nem tette fel a kérdést, mi a dolga az embernek, ha a kód egy részét a gép írja. Átalakítottuk a munkamenetet. A tapasztaltabb fejlesztők átvették a feladatok megfogalmazását és a rendszer felügyeletét, a fiatalabbak pedig megtanulták, hogyan ellenőrizzék a generált kódot úgy, hogy közben értsék is, mi történik benne.

Néhány hét alatt a szerepek letisztultak. A csapat egyik senior tagja, aki korábban a legtöbb kódot írta, egyre inkább arra fordította az idejét, hogy jó feladatleírásokat adjon a modellnek, és átnézze, ami visszajött. Eleinte furcsán érezte magát, mintha kevesebbet dolgozna. Aztán rájött, hogy a döntések, amelyeket most hoz, súlyosabbak a régi napi gépelésnél. A junior fejlesztők közben nem kihulltak a rendszerből, hanem megtanultak kérdezni, ellenőrizni és felelősséget vállalni a végeredményért. A csapat gyorsabban szállított, és kevesebb hiba jutott át az éles rendszerbe.

A legérdekesebb visszajelzés a csapatvezetőtől jött. Azt mondta, korábban a fejlesztők egy része a kódmennyiséggel mérte a saját értékét. A váltás után rájöttek, hogy a valódi értékük nem a legépelt sorokban van, hanem abban, hogy jó irányba terelik a rendszert, és megfogják a hibát, mielőtt kárt okoz. Ez a felismerés többet ért, mint bármelyik új eszköz, amit bevezettünk.

Ami felértékelődik

Az ítélőképesség és a rendszerszemlélet ára megnő

Ha a gépelés olcsóbbá válik, akkor az lesz értékes, amit a gép nem tud. Az ítélőképesség, hogy egy megoldás jó irányba visz vagy zsákutcába. A rendszerszemlélet, hogy a fejlesztő átlátja, hogyan hat egy döntés a rendszer többi részére. És a felelősség, hogy valaki a nevét adja a végeredményhez, és vállalja, ha baj van.

Ezek a képességek eddig is számítottak, de gyakran elvesztek a napi gépelés tömegében. Amikor a rutinmunka nagy részét átveszi a modell, ugyanezek a képességek kerülnek a középpontba. Egy fejlesztő, aki érti a rendszert és felelősen dönt, sokkal többet ér annál, aki csak gyorsan gépel. A piac lassan erre kezd fizetni, mert a puszta kódmennyiség egyre olcsóbb, a jó ítélet viszont ritka marad.

Ehhez tartozik egy kényelmetlen igazság a szakma tanulásáról is. A rendszerszemlélet nem születik meg magától. Eddig a fejlesztők a rutinfeladatokon keresztül szedték fel, apró javításokon és egyszerű funkciókon. Ha ezt a réteget elviszi a modell, tudatosan kell megteremteni a helyzeteket, ahol a fiatalabbak megtanulnak nagyban gondolkodni. Aki ezt elmulasztja, néhány év múlva ott áll majd tapasztalatlan fejlesztők nélkül, akik átvennék a nehezebbik munkát.

A csapatok

Mi lesz a fejlesztőcsapatokkal

A csapatok mérete és felépítése is mozdul. Egy tapasztalt fejlesztő ma több munkát tud levinni, mert a modell felgyorsítja azt, ami eddig lassú volt. Ez nem azt jelenti, hogy szükségszerűen kevesebb emberre lesz szükség, hanem azt, hogy a munka másképp oszlik el. Kevesebb idő megy a mechanikus kódírásra, több a tervezésre, az ellenőrzésre és a döntésekre.

A belépő szint viszont valóban változik. Régen egy kezdő fejlesztő a rutinfeladatokon tanult, apró javításokon, egyszerű funkciókon. Ezt a réteget most a modell viszi el. A kezdőnek hamarabb kell megtanulnia azt, ami eddig a tapasztaltabbak dolga volt, a rendszerben gondolkodást és a kritikus ellenőrzést. Ez nehezebb belépő, de aki átjut rajta, értékesebb fejlesztő lesz, mint a korábbi generációk ugyanannyi idő alatt.

A csapatok belső dinamikája is átrendeződik. A régi hierarchia sokszor a gépelési sebességre és a technikai rutinra épült. Az új felállásban az a fejlesztő húz maga után másokat, aki jól látja az egészet, tisztán fogalmaz, és felelősséget mer vállalni a döntéseiért. Ez más típusú embert emel meg, mint a régi világ, és a jó vezetők már most figyelnek erre, amikor csapatot építenek.

A természet változása

A munka természete alakul át, nem a fejlesztő tűnik el

Amikor valaki azt kérdezi, elveszi-e az LLM a fejlesztő munkáját, rossz kérdést tesz fel. A munka nem eltűnik, hanem áthelyeződik. A kód egy részét a modell írja, a cél megfogalmazása, a rendszer irányítása és a végeredmény ellenőrzése viszont emberi feladat marad. Ráadásul ezek fontosabbak lesznek, mint valaha voltak.

A fejlesztő, aki ezt időben megérti, nem védekezik a technológia ellen, hanem feljebb lép. Átadja a gépnek azt, amit a gép jobban csinál, és megtartja magának azt, amiben ő az erős. A döntést, az ítéletet és a felelősséget. Ebben a felállásban az LLM nem a fejlesztő ellenfele, hanem a legerősebb eszköze, amit valaha a kezébe kapott, feltéve, hogy tudja, mihez kezdjen vele.