Az AI olcsóbbá teszi a kódírást, de drágítja a döntéshozatalt — a GitHub szerint

A szoftverfejlesztésben korábban a kód megírása volt a legköltségesebb feladat egy apró funkciókérés esetén. Ma már inkább a kód megírásáról szóló vita kerül többe, ami alapvetően változtatja meg a mérnöki megközelítéseket — írja a GitHub Blog.

A mérnökök korán megtanulják, hogy a kisebbnek tűnő kérések is jelentős erőforrásokat emészthetnek fel: teszteket, bevezetési terveket igényelnek, és valakinek viselnie kell a felelősséget a működésért a kiadás után. Egy kétórásnak tűnő változtatás akár kéthetes halasztássá is válhat, ha rossz helyen nyúl a rendszerhez. Ezért a mérnökök gyakran visszautasítják az ilyen kéréseket, megkérdőjelezve azok szükségességét vagy időzítését.

Kapcsolódó: CPC hirdetések a ChatGPT-nél

A vita többe kerül, mint a javítás

Egy tipikus forgatókönyv szerint valaki egy apró változtatást kér, például egy beállítási oldalon megjeleníteni egy már létező timestampet. A csapat egy szálon vitatkozik, amely negyven percig is eltarthat. Felmerül a kockázat, előkerülnek korábbi migrációs tapasztalatok, és végül alacsony bizonyossággal arra jutnak, hogy a feladat „valószínűleg egy-két napig tart, de lehet több is”. Ez a folyamat akkor volt értelmes, amikor a kipróbálás volt a drága lépés. Most, hogy az első kódgenerálás olcsó, a határok védelme többe kerülhet, mint az átlépésük. Egy AI-ügynök képes lehet az első kódrészletet legenerálni, míg a vita felmelegszik. Ez a kód nem ingyenes és nem is tökéletes, de elég olcsó ahhoz, hogy érdemes legyen megnézni egy valós diffet a találgatás helyett.

Kapcsolódó: AI a kódgyártásban

Az AI-generált kód csak egy árleszámolás, nem a végtermék

A hiba abban rejlik, ha a legenerált kódrészletet kezeljük a végső termékként. Ez csupán egy „probe”, egy eszköz, amellyel az absztrakt hatókör-érvet konkrét artefaktummá alakíthatjuk. Megvizsgálhatjuk, hogy a változtatás a várt fájlokat érinti-e, vagy öt csomagot szövedékbe, hogy a tesztek nyilvánvalóak-e, vagy ellenállnak a tesztelésnek, és hogy megőrzi-e a meglévő absztrakciókat. Ezek a kérdések sokkal jobb alapokon nyugszanak, mint a „érezhetően hatókör-bővítés?” kérdés. Ha az eredmény egy négy soros diff, amelyen a teszt sikeresen fut, akkor a kérés valószínűleg kicsi volt, és a vita volt a drága. Ha viszont a kód az autentikációs middleware-t érinti, akkor a kérés sosem volt kicsi, és ezt harminc perc alatt megtudtuk, nem két nap alatt. Ez nem azt jelenti, hogy az AI dönt, hanem hogy az AI olcsóbbá és jobb információval ellátottá teszi az emberi ítélőképességet.

Kapcsolódó: Codex árazás OpenAI-nál

Az olcsó generálás nem egyenlő az olcsó birtoklással

A változtatás nem olcsó csak azért, mert a kód generálása volt az. Csak akkor olcsó, ha egy ember magabiztosan képes áttekinteni és birtokolni az eredményt. Egy ezer soros diff, amely technikailag megfelel, de senki sem akarja birtokolni, nem olcsó változtatás — ez elhalasztott költség. A megosztó vonal tehát nem az, hogy „képes-e egy ügynök ezt megírni?”, hanem az, hogy „képes-e egy ember validálni?”. Egy új kijelzőmező hozzáadása, amely már létezik a háttérben, általában olcsó. Az engedélyezési viselkedés megváltoztatása nem olcsó, függetlenül a diff tisztaságától. A jól tesztelt segédfüggvények refaktorálása általában olcsó. Az adatmegőrzési szemantika megváltoztatása nem olcsó. Sok változtatás továbbra is határozott nemet érdemel, még akkor is, ha a kód triviális. Ez magában foglalja mindazt, ami a termékszerződést módosítja, támogatási terhet jelent, vagy érinti az adatvédelmet, számlázást vagy megfelelőséget. Az AI csökkenti a jelölt előállításának költségét, de nem csökkenti a birtoklás költségét.

Kapcsolódó: Apple ingyenes AI-t ad

A hatókör-fegyelmet közelebb kell hozni a bizonyítékokhoz

Hagyományosan a hatókör-fegyelem a megvalósítás előtt történt, mert a megvalósítás volt az, amit védeni kellett. Most már a fegyelem egy része az ellenőrzéshez költözhet. Ez nem jelenti a tervezés kihagyását, hanem azt, hogy pontosítjuk, melyik tervezés hozza meg az igazi hasznot. Egy kis változtatás újratárgyalása előtt kérjünk egy korlátozott próbálkozást. A korlátok a lényeg: hozzuk létre a lehető legkisebb javítást, tartsuk a meglévő feature flag mögött, ne változtassuk meg a nyilvános szerződést, adjunk hozzá vagy frissítsünk teszteket, soroljunk fel minden érintett fájlt, és jelöljünk meg minden kockázatos elemet. Ha az ügynök nem tud ilyen korlátok között tiszta javítást produkálni, a kérés nagyobb volt, mint gondoltuk, és tudjuk, hogy valódi birtoklási költséggel jár, mielőtt bárki elköteleződne mellette. Ha sikerül, az is sokat elárul. Így a „benne van-e a hatókörben?” kérdés helyett a „itt a költsége. Akarjuk kifizetni?” kérdésre kapunk választ.

Kapcsolódó: GitHub Copilot token díj

Az új készség a bizonytalanság árazása

Az AI-asszisztált világ legjobb mérnökei nem azok lesznek, akik mindenre igent mondanak, és nem is azok, akik reflexből nemet. Azok lesznek, akik gyorsan képesek árazni a bizonytalanságot. Tudni fogják, mikor egy kérés egy megvalósítási jelmezbe bújt termékdöntés, mikor lesz az ellenőrzés nehezebb, mint az írás, és mikor elég kicsi egy változtatás ahhoz, hogy a leggyorsabb, felelős válasz az, hogy „csak próbáljuk ki”. Ez utóbbi valóban új. A „próbáld ki és nézd meg” korábban azt jelentette, hogy egy fejlesztőt elvontak más munkától. Most, a megfelelő feladatoknál, ez azt jelenti, hogy egy ügynöknek határolt feladatot adunk, és az eredményt használjuk fel egy jobb döntés meghozatalára. Kevesebb idő a találgatásra, több az ellenőrzésre. Kevesebb idő a megvalósítást feketedobozként kezelni, több az artefaktumok értékelésére. A hatókör-bővülés még mindig valós. De a „nem, mert bármilyen új kód túl drága” sokkal gyengébb érv, mint két évvel ezelőtt volt. A kód előállításának költsége csökkent. A megértés, az ellenőrzés és a birtoklás költsége nem. Tehát a kérdés áttevődött arról, hogy „ez több munka?”, arra, hogy „hol van az igazi költség?”. És néha, egy kis, határolt változtatás esetében, az igazi költség csak a kiderítés. A „igent mondani” költsége megváltozott. A „nemet mondani” költségének is ehhez kell igazodnia.