A tény
Mi hangzott el pontosan
Lesse a Grafana Labs ObservabilityCON rendezvényén beszélt, és nem arról, hogy a fejlesztők gyorsabban dolgoznak. Azt mondta, hogy a csapatában a gép írja a kódot, az emberek pedig a rendszereket tervezik és a kimenetet ellenőrzik.
Konkrét példát is hozott. Egy nagy kódbázist vittek át Pythonról Rustra, és ebben a munkában a mérnökök azt dolgozták ki, hogyan lehet a végeredményt igazolni, az átírást és a figyelést viszont ügynökök végezték.
Elhangzott az is, hogy a cégnél az ügynökök már emberi beavatkozás nélkül javítják a hibás teszteket, és azt mérlegelik, hogy a jövőben az éles kódbázison is engedjenek önálló változtatást. A mérnöki vezetők ezzel óvatosak, a határ viszont mozog.
Érdemes a méretet is érteni. Kétszáz ember platform mérnökségben nem kis csapat, és ez a terület adja egy cégnél azt a réteget, amin a többi fejlesztés fut. Ha valahol kockázatos lenne a gépre bízni a munkát, akkor az pont ez a terület volna.
Az időzítés is beszédes. Ez a mondat nem egy marketing eseményen hangzott el, hanem egy üzemeltetési és megfigyelhetőségi konferencián, ahol a közönség nagy része napi szinten tartja életben rendszereket. Az ilyen helyen a nagy ívű állításokat azonnal kérdések követik.
A félreértés
Amit ebből rosszul szokás kiolvasni
A hír első olvasatra úgy hangzik, hogy a fejlesztői munka megszűnt. Ott viszont kétszáz ember dolgozik, és egyikük sem tétlenkedik.
Ami megszűnt, az a billentyűzeten történő átváltás, vagyis az a lépés, amikor a fejben megszületett megoldás sorokká alakul. Ez a lépés korábban a munkaidő nagy részét vitte, és most a gépre került.
Ami megmaradt, az a nehezebbik fele. El kell dönteni, mit építsünk, milyen szerkezetben, milyen kompromisszumokkal, és meg kell tudni állapítani, hogy a kapott eredmény jó-e. Az ellenőrzés pedig ennél a munkánál nem olvasgatást jelent, hanem azt, hogy felépítünk egy módszert, amivel a végeredmény igazolható.
Ilyen bejelentéseknél az a szokásos hiba, hogy a végeredményt másoljuk, a hozzá vezető utat viszont nem. Attól, hogy náluk a gép ír mindent, egy magyar középvállalatnál ugyanez holnaptól nem fog működni, mert a feltételek mások.
Érdemes a számot is a helyén kezelni. A száz százalék arra vonatkozik, hogy a sorokat a gép gépeli le, nem arra, hogy ember nélkül születik a megoldás. Emberi munka maradt a terv, a határok kijelölése és a visszamérés is, csak nem az a része látszik, ami régen a képernyőn futott.
Egy dolgot érdemes kimondani a kétszázas létszámmal kapcsolatban. Ha a kódírás tényleg elhagyható lenne emberek nélkül, akkor ez a csapat ma nem kétszáz fős volna. Az a tény, hogy ennyien dolgoznak ott, miközben a sorokat a gép írja, pont azt mutatja, hogy a munka mennyisége nem csökkent, csak a jellege változott meg. A tervezés, a határok kijelölése és a visszamérés ugyanúgy embert kíván, mint korábban a gépelés.
Feltételek
Miért működik ez pont ott
Érdemes észben tartani, hol hangzott el ez. Egy AI laborban, ahol a saját modelljüket használják, a kódbázisuk a legjobban dokumentáltak közé tartozik, a tesztkultúra erős, és a mérnökök fele valószínűleg maga tanítja azokat a modelleket, amikkel dolgozik.
Átlagos cégnél ezek a feltételek nincsenek meg. Ott a kód sokszor dokumentálatlan, a tesztek hiányosak, és a rendszer működését két ember tartja fejben. Ilyen közegben a gépi kódírás nem száz százalékot hoz, hanem hibát termel, méghozzá gyorsan.
A különbség nem a modell minőségében van, hanem abban, hogy van-e mihez mérni a kimenetet. Ahol van teszt, van mérés és van leírt elvárás, ott a gép bátran dolgozhat. Ennek hiányában az ember marad az egyetlen ellenőrzési pont, és ő lassabb, mint a gép.
A másik, amit nehéz lemásolni, az a munkamód. Ott a mérnökök napi szinten dolgoznak ügynökökkel, ismerik a határaikat, és tudják, mikor kell beavatkozni. Ez a gyakorlat hónapok alatt épül fel, nem egy bevezetési projektben.
Van ennek egy kimondatlan feltétele is. Az ilyen csapatban a kolléga meg meri mondani, ha a gép rosszat írt, és nem fél attól, hogy emiatt lassúnak tűnik. Ahol az ellenőrzés gyanakvásnak számít, ott a gépi munka minősége csendben romlani fog.
Ellenőrzés
Az ellenőrzés lett a szűkítő pont
Ha a kódírás ára lenullázódik, akkor a rendszer teljesítményét az fogja megszabni, milyen gyorsan tudjuk eldönteni, hogy a kapott eredmény jó-e. Ez a klasszikus korlát logika, csak most a fejlesztésben.
Ebből következik, hogy a befektetés iránya megfordul. Korábban a fejlesztői kapacitás bővítése hozta a legtöbbet, most az, ha az ellenőrzés gyorsul. Automata teszt, mérés, naplózás, visszagörgetés, és olyan környezet, ahol egy hibás változtatás nem visz magával semmit.
Egy szegedi szoftverfejlesztő cégnél tavaly ezzel a sorrenddel indultunk. Előbb épült fel a tesztkörnyezet és a mérés, utána engedtük rá a gépet a feladatokra. A kollégák először furcsállták, hogy három hétig nem született látványos eredmény, a negyedik héttől viszont a kiadások száma a háromszorosára nőtt, és a hibabejelentések nem emelkedtek.
Mérés nélkül ráadásul nem is derül ki, hogy javult-e valami. Ha a kiadások száma nő, a hibabejelentéseké viszont vele együtt, akkor a cég gyorsabban termel problémát, és ezt csak az adatokból lehet időben észrevenni.
Ennek a befektetésnek van egy kellemes mellékhatása. A jó tesztkörnyezet és a gyors visszagörgetés akkor is érték, ha a cég egyetlen sort sem írat géppel, mert a kiadások kockázatát általánosan csökkenti.
Szerepek
Mi marad az embernek
A tervezés marad. Milyen rendszert építünk, milyen határokkal, mit vállalunk és mit nem. Ezt a döntést nem lehet kiadni, mert a következményét is az ember viseli.
Az ellenőrzés marad. Nem a sorok átolvasása, hanem annak eldöntése, hogy a megoldás helyes-e, és annak a módszernek a felépítése, amivel ez belátható.
A felelősség marad. Amikor valami elromlik, nem a modell áll ki az ügyfél elé, és nem a modell magyarázza el a hatóságnak, hogy mi történt. Ez a pont egyetlen bevezetéssel sem tolható át a gépre.
Ezekhez a szerepekhez más készség kell, mint tíz éve. A szintaxis ismerete helyett az építészeti gondolkodás, a határok kijelölése és a kritikus olvasás számít. Aki csak a kódolást tudta, annak most tényleg nehéz, aki a problémát értette, annak könnyebb lett.
A csapatszerkezetre is hat mindez. Kevesebb kéz kell a végrehajtáshoz, viszont több ember kell ahhoz, hogy a döntések és az ellenőrzés ne egyetlen emberen torlódjanak össze. Ez a két hatás nem oltja ki egymást, hanem más arányokat hoz.
Következmény
Mit jelent ez a nem szoftveres cégeknél
Ugyanez a mintázat jelenik meg az irodai munkában is. Az ajánlatírás, a jelentéskészítés, az adatgyűjtés és a levelezés az a réteg, amit a gép elvégez, és marad a döntés meg az ellenőrzés.
Ebből két teendő következik. Az egyik, hogy a cégnek tudnia kell, mihez méri a kimenetet, tehát mi a jó ajánlat és mi a jó jelentés. A másik, hogy az ellenőrzésre szánt időt be kell tervezni, mert az nem szabadidőben történik.
Ide tartozik a belépő szintű munka kérdése is. Ha a fiatalok nem írják meg az első ötszáz rossz változatot, akkor máshogy kell felépíteni a tanulásukat, erről külön is írtam, lásd ha az AI viszi a junior munkát, kiből lesz senior.
Jó hír, hogy ez a réteg a legtöbb cégnél rosszul van kihasználva. Ha a kollégák ideje felszabadul a gépi munka alól, akkor az ügyfélre, a döntésre és a minőségre jut belőle, feltéve, hogy valaki ezt tudatosan elrendezi. Magától ugyanis nem így alakul, hanem több megbeszélés lesz belőle.
Érdemes azzal a folyamattal kezdeni, ahol a kimenet jól körülírható. Egy ajánlat vagy egy havi riport ilyen, mert van mintája, van elvárt szerkezete, és egy tapasztalt kolléga néhány perc alatt meg tudja mondani, hogy jó-e. A nehezen megítélhető, egyedi feladatok maradjanak későbbre.
Mérce
Hogyan tudod megnézni, hol tartasz
Három kérdés elég hozzá. Van-e olyan próba, ami fél órán belül megmondja, hogy egy elkészült munka jó-e. Tudja-e a csapat leírni, mi a jó megoldás ismérve. Van-e visszaút, ha egy változtatás rosszul sül el.
Ahol mindháromra igen a válasz, ott a gépi munka aránya bátran emelhető. Ha bármelyikre nem, akkor azzal kell kezdeni, és nem a modellválasztással.
A kétszáz fős csapat esete attól érdekes, hogy náluk ez a három feltétel évek óta adott. Ez a mondat tehát nem a fejlesztés megszűnéséről szól, hanem arról, hogy a felkészült környezetben a gép átveheti a végrehajtást.
Ezt a hármat egy délelőtt alatt végig lehet nézni bármelyik folyamatra, nem csak fejlesztésnél. Ugyanez a kérdéssor érvényes egy ajánlatkészítésre, egy riportra vagy egy ügyfélválaszra is, és a válaszokból rögtön kiderül, hol érdemes kezdeni.
Ha a válasz bármelyik kérdésnél bizonytalan, akkor az első lépés nem AI projekt, hanem az ellenőrzés megépítése. Ez általában hetekben mérhető munka, és utána minden további bevezetés olcsóbb lesz tőle. A sorrend felcserélése viszont két-három hónap veszteséget hoz, mert a hibákat utólag kell visszafejteni.
Forrás
Ahol ez elhangzott
Katelyn Lesse, az Anthropic platform mérnöki csoportjának vezetője a Grafana Labs ObservabilityCON rendezvényén beszélt erről, a Business Insider számolt be róla. A csapat létszáma a nyári adat szerint kétszáz fő.