A legtöbb vállalat azt hiszi, hogy szoftvergyárat épít. Valójában csak a hibákat szállítják gyorsabban.

Az iparosított gyárak megváltoztatták, hogyan állítja elő a világ a fizikai termékeket: több kibocsátás, alacsonyabb költségek, gyorsabb, mint bármi, ami korábban létezett. Most hasonló elmozdulás zajlik a szoftverek terén. Az LLM-ek csökkentették a kódírás belépési küszöbét, növelték az egyéni teljesítményt, és arra ösztönözték a szervezeteket, hogy a szoftverfejlesztést termelési rendszerként tekintsék. Az évtizedek óta érvényben lévő standard szoftverfejlesztési életciklus és a CI/CD gyakorlatok nem fogják bírni ezt a nyomást. Itt jön a szoftvergyár: és hasonlóan a fizikai gyárakhoz, itt is több szükséges a tényleges működéshez, mint a sebesség. A „szoftvergyár” fogalma az elmúlt évben kezdett megfogalmazódni. Luca Rossi "A Szoftvergyár Kora" című munkája világosan megfogalmazta: az AI nem csupán azt változtatja meg, milyen gyorsan írnak az emberek kódot — megváltoztatja az egész szoftver körüli termelési rendszert. A fogalom különböző dolgokat jelenthet: kódoló ügynökök és készségi fájlok gyűjteményét; gyorsabb CI/CD-t; jobb felülvizsgálati rendszereket; vagy több automatizálást a szoftver szállítása körül. Jobb keret, ha ezt nem pusztán eszközkategóriaként, hanem inkább alapelvek halmazaként értelmezzük. A szoftvergyár nem lehet csupán laza gyűjteménye promptoknak, ügynököknek és plugineknek. Szüksége van egy platformra, amely meghatározza, hogyan mozog a munka a rendszerben, és hogyan generálódik, ellenőrizhető, tesztelhető, nyomon követhető, telepíthető és javítható a kód, amikor valami rosszul sül el. Ellenkező esetben csak egy újabb egyszemélyes gépet teszünk egy üres szobába, és hívjuk gyárnak. Miért történik ez most? Számos erő hat egy időben. A cégek mindig is többet akartak a szoftverből, mint amit a mérnökök elő tudtak állítani. Emiatt léteznek olyan eszközök, mint az Excel: gyakran kitöltik azt a hiányt, amit sok cég szeretne létrehozni. Az AI emellett csökkentette a kód létrehozásának belépési küszöbét, és ez az a rész, amire mindenki összpontosít. A kód létrehozása most könnyebb, bár nem mindig olcsóbb vagy jobb, amit sok magas rangú cég aggódása a magas AI költségek miatt bizonyít. A funkcionális kód írásának küszöbe gyakorlatilag összeomlott. Ami még fontosabb, egyetlen mérnök több kódot tud generálni, mint néhány évvel ezelőtt. Ez megváltoztatja a szűk keresztmetszetet: már nem az a kérdés, "Mennyi idő alatt tud valaki ezt megírni?" vagy akár, egyes esetekben, "Tud valaki kódot írni?" Helyette az a kérdés, "El kell ezt írni?" Még inkább, tudunk-e valójában tartós és megbízható végtermékeket létrehozni, amelyek nem csak technológiai adósságot halmoznak fel? Vagy csak gyorsan dobálunk ki még több AI „kedveskedést”? Itt rejlik a veszély. A modern szoftvergyár veszélyei Mindez remekül hangzik. A gyárak végülis gyorsabbá és következetesebbé tették a termelést. Lehetővé tették több autó és termék olcsóbb előállítását, ami miatt több ember képes lett autót és terméket vásárolni. Környezeti hatásokat félretéve, érvelhetünk, hogy ez pozitív volt. De, mint sok dolog a mérnöki tudományban, mindig vannak kompromisszumok, és ebben az esetben új kockázatok is megjelennek. Amikor egyetlen ember kibocsátását növeled gépekkel, digitális vagy más módon, akkor a hibák számát is növeled, amelyek az egyéntől vagy a gépezettől származhatnak. A kód kiadásának sebessége most ipari méretekben mozog. Még a kisebb szervezetek is hirtelen a technológiai cégek kódalapjainak méretével összevethető kódalapokkal szembesülhetnek, mint egy évtizeddel ezelőtt. Az adatok már problémákat mutatnak. A Faros AI megállapította, hogy míg a fejlesztőnkénti feladatátvitel 33,7%-kal nőtt és a PR egyesítési arány 16,2%-kal emelkedett, az incidens-PR arány 242,7%-kal nőtt, a hibák fejlesztőnként pedig 54%-kal emelkedtek. A Google DORA kutatása arra az eredményre jutott, hogy az AI alkalmazásának növekedése valójában rosszabb szállítási stabilitással volt összefüggésben. V fractional head of data-ként engem éppen ezeknek a kérdéseknek a megoldására hoztak. Az elmúlt évben két olyan projekten dolgoztam, ahol az AI által generált adat-infrastruktúra idővel lassan kezdett átalakulni. Több mérnök próbálta gyorsan előmozdítani a dolgokat, miközben a szabványok hiánya miatt ezek a projektek kaotikussá váltak. A kódalapok rendszerint bizonyos evolúción mennek át, de ahogy a különböző stílusok keverednek, az LLM-ek saját mutációikat kezdik létrehozni. A kódalapok öt-hat különböző stílust alakítottak ki hónapokon belül — egy folyamat, amely korábban évekig tartott. Rétegről rétegre a mérnökök lassan már nem értették, mi is történik pontosan. A minta visszhangozza, ami egy évtizeddel ezelőtt a self-service eszközökkel történt: korai termelékenységi nyereségek, amelyek elfedték az utólagos bonyolultságot. És ezért a szoftvergyár nem lehet pusztán a sebességről szóló helyzet. Mi teszi a szoftvergyárat működőképessé Számos kulcsfontosságú alapelvet kell figyelembe venni a szoftvergyár felépítésekor. Platform az eszközök felett: Számos csapat lassan integrálja az AI-t a kódolási munkafolyamataikba az élek mentén — PR felülvizsgálati ügynök vagy készségi fájl hozzáadásával a repoikhoz. De egy igazi szoftvergyár építése platformot igényel, nem csupán eszközök gyűjteményét az éleken. A platform egységes alapot biztosít, ahol az eszközök nincsenek szétszórva különböző sarkokba. Ehelyett aktívan megosztják az adatokat, beszélgetnek egymással, és egyetlen koherens rendszert alkotnak — a standardok, folyamatok és maga a munka mind összekapcsolódik. Ismételhetőség és nyomon követhetőség: Egy igazi platform megkívánja, hogy bármely futásba vissza lehessen menni, azonosítani kell, mi ment rosszul, és újra futtatni — ezért az egyszeri ügynökök nem képeznek gyárat. A rendszernek támogatnia kell egy sorozatszám követését, annak megkeresését és pontos nyomon követését, hogyan jutott el a termelt kimenethez. Ezért a állapotgépek értelmesebbek, mint a ciklusok az AI munkafolyamatokhoz: sokkal könnyebb újrafuttatni egy folyamatot és megérteni, mi történt minden egyes lépésben. Biztonság és keretek: A gyárak nem biztonságos helyek. A szoftvergyár sem. Ahogy egyre többen dolgoznak ezeken a platformokon, a jobb kereteket és biztonsági intézkedéseket be kell építeni. A tesztelésnek és a minőségellenőrzésnek előtérbe kell kerülnie — a bugok a lehető legalacsonyabb szinten történő észlelése csökkenti a javítás költségeit és korlátozza a robbanási távolságot. Szabványosítás: Vállalati szinten minden kódalapnak megvan a saját íze. Egy kódasszisztens rétegezése szabványok nélkül különböző stílusok amalgámját eredményezi. A szabványosításnak a folyamatba kell épülnie a kezdetektől fogva. Minőségellenőrzés: A régi gyártási modellekben a minőségellenőrzés a folyamat végén zajlott. A termék elkészült, ellenőrizték, a hibákat később találták meg és javították. A Toyota megközelítése más volt. A minőséget a folyamatba építették — a dolgozóknak meg kellett állítaniuk a sort, ha valami nem volt rendben. A cél nem a végén a hibák kiszűrése volt; az volt a cél, hogy megakadályozza, hogy azok egyáltalán továbbfolyjának. Ugyanez igaz a szoftvergyárra is. A QC-nek az egész folyamatba be kell épülnie, kezdve attól, hogy hogyan írják a specifikációt. Ez magában foglalja a statikus kódelemzést, amely észleli a nyilvánvaló hibákat, és sablonokat ad az LLM-eknek, hogy tudják, milyen struktúrát kell követnie a kódnak. Enélkül a szűk keresztmetszet a végső felülvizsgálat lesz — vagy a csapatok csak még több AI „kedveskedést” hoznak létre. Sebesség minőség nélkül nem termelékenység A kód kibocsátásának sebességének növelése nem valódi termelékenység, ha az utólagos problémákat nem kezelik. Egy cég nem termelékenyebb, csak azért, mert millió autót gyárt, hogy azokat mind 100 mérföld után látja szétesni. Az sem termelékenyebb, ha csak egy végtelen mennyiségű proof-of-conceptet állít elő, amelyek soha nem kerülnek be a termelésbe. A valódi termelékenység azt jelenti, hogy a szoftvergyár átveszi az ephemerális tokeneket és tartós kimenetekké alakítja őket. Könnyű arról beszélni, hány kódsort írunk, és hogy a csapatunk mennyivel gyorsabban mozog. Az a szoftvergyár nyer, amely nem a legtöbb kódot generálja, hanem a legkevesebb hibát hozza létre lefelé a folyamatban.