A Talking Postgres podcast egy múlt heti epizódjában Claire Giordano és "Simon" (a beszélgetés résztvevője) a "How AI is changing software development" témáról beszélgettek. Az alábbiakban az epizódból készült, enyhén szerkesztett átirat kiemelt részeit ismertetem (a szerkesztés célja a beszédhibák eltávolítása volt).
Sorok száma mint mérőszám
A beszélgetés körvonalaz egy érvet amellett, hogy bizonyos esetekben érdemes lehet mégis sorok száma (lines of code) alapján mérni a termelékenységet olyan környezetben, ahol kódoló ügynököket (coding agents) használunk. A hangsúly a "bizonyos esetekben" kifejezésen van.
Simon szerint a korábbi időszakokban egy szoftvermérnök napi néhány száz sor éles, működő, debugolt kódot volt képes előállítani — és 200 sor olyan nap volt, amikor igazán jól ment a munka. Általában inkább 50–60 sor volt egy tipikus nap. Ha az ügynökök lehetővé teszik, hogy ezer sor debugolt kód készüljön el naponta, az valódi, mérhető előrelépés lehet — feltéve, hogy a kód minősége azonos marad (karbantartható, tesztelt stb.).
A beszélgetés rámutat, hogy ehhez jelentős szakértelem és tapasztalat szükséges: a magas minőségű kód létrehozása ügynökök mellett is a tapasztalt, senior mérnökök feladata lehet.
A kognitív kapacitás és a csapat-szükségessége
Simon felveti azt a logikus kérdést is: ha egyetlen mérnök képes sokkal több kódot előállítani ügynökökkel, miért kellene mégis több mérnököt foglalkoztatni? A válasz a "bus factor"-on túl a kognitív kapacitás: ugyan egy mérnök százszor annyi kódot tud előállítani, de nincs meg hozzá az a kognitív kapacitás, hogy százszor annyi kódot áttekintsen és karbantartson. Ezért továbbra is szükség van csapatokra, hogy a mentális terhelést megosszák.
Koncepcionális integritás és a Winchester Mystery House-analógia
A beszélgetés másik fontos pontja a koncepcionális integritás (conceptual integrity) kérdése. Simon a The Mythical Man-Month fogalmára hivatkozva elmondja, hogy a jól megtervezett szoftvernek van egy egységessége: nincsenek benne meglepetések, a domén pontosan lefedett, az elemek illeszkednek és logikusan rendeződnek.
Ennél nehezebb fenntartani ezt az integritást olyan környezetben, ahol ötlet után gyors prompt, majd perceken belül működő feature áll rendelkezésre. Ilyenkor a szoftver "kis furcsa dudorokkal" nő különböző irányokba — vagy ahogy Claire Giordano fogalmazott, olyan, mint a Winchester Mystery House.
Az analógia: a Winchester Mystery House-t évtizedeken át folyamatosan bővítették, mert az építtető hitte, hogy ezzel elkerüli a lelki nyugtalanságot. A párhuzam arra világít rá, hogy amint az új „szobák” (funkciók) hozzáadása olcsó és gyors lesz, könnyű habitussá válni a folyamatos bővítésre. Ennek következménye, hogy a koncepcionális integritás felbomlik, és nehezebb lesz később átgondolt döntéseket hozni a rendszerről.
Fegyelem mint problémamegoldás
A vitában többször visszatér a fegyelem kérdése: korábban a megvalósítás időigénye önmagában visszatartotta a fejlesztőt attól, hogy minden felmerülő ötletet megvalósítson. Ha egy új funkció megvalósítása egy hét lenne, gyakran elvetették azt; ha ugyanaz egy órára csökken, könnyebben igazolhatóvá válik a bevezetése. Az AI-gyorsítás ezt a természetes féket eltünteti, tehát a fegyelem és az architekturális kontroll tudatos fenntartása válik kulcsfontosságúvá.
Záró megjegyzések
A beszélgetés hangsúlyozza, hogy bár az ügynökök növelhetik a fejlesztési teljesítményt (mérhetően több kódot lehet előállítani), ez önmagában nem jelenti azt, hogy a szoftver jobb lesz. A minőség, a karbantarthatóság és a koncepcionális integritás fenntartása továbbra is szakértelmet és fegyelmet igényel.
(Side-note: a Wikipedia cikk, amelyre Claire utalt, olyan forrásokat is tartalmaz, amelyek vitatják a médiumhoz kapcsolódó történet hitelességét.)
