Képzeld el, hogy megkérsz egy AI-kódoló ügynököt (egy olyan programot, amely szoftvert ír és módosít helyetted), hogy készítsen el egy funkciót. Néhány órával később több tízezer sornyi kódot ad át. Ki ellenőrzi mindezt? Gyakran senki nem olvassa végig sorról sorra — ezt a hiányt próbálja kezelni a PDD Kit.
A probléma: nem lehet minden sort átnézni
A legtöbb csapat ma inkább a tervet ellenőrzi, nem a kódot. Elmondják, mit szeretnének, addig egyeztetnek, amíg a terv és a javasolt tesztek megfelelőnek nem tűnnek, majd hagyják, hogy az ügynök megépítse a megoldást.
A bejelentés szerint a gond ezután kezdődik. Az ügynök eltérhet a tervtől, létrehozhat valami kissé mást, majd olyan teszteket írhat, amelyek a saját változatán sikeresen lefutnak. A tesztkészlet egészségesnek tűnik, de a kért és a ténylegesen elkészült megoldás közötti különbség rejtve marad, amíg fel nem bukkan egy hiba.
A készítők kétféle hibát emelnek ki, amelyeket egy alapos ellenőrző általában észrevenne. A kódból hiányozhat valami szükséges, vagy nyilvánvalóan rosszul működhet. A hagyományos tesztek csak egy kis részét vizsgálják annak, amire egy program képes, ezért önmagukban nem szüntetik meg ezt a problémát.
Így működik a bizonyítékvezérelt fejlesztés
A PDD Kit készítői erre egy általuk Proof-Driven Developmentnek (PDD), vagyis bizonyítékvezérelt fejlesztésnek nevezett módszert kínálnak. A legfontosabb gondolat az, hogy a bizonyítás (matematikai érvelés, amely megmutatja, hogy a kód a specifikáció szerint működik) más kérdésre válaszol, mint az ellenőrzés. Az ellenőrzés azt kérdezi: „Jónak tűnik ez?” A bizonyítás pedig ezt: „Valóban helyes ez?”
A munkafolyamat két részből áll:
- A cél pontosítása. Az eszközkészlet felteszi azokat a kérdéseket, amelyeket egy alapos ellenőrző is feltenne, a válaszokat pedig rögzíti egy célleíró dokumentumban. A cél azon részei, amelyek pontosan megfogalmazhatók, formális specifikációvá (annak pontos, géppel olvasható leírásává, hogy mit kell tennie a kódnak) válnak. A többi részből tesztleírások készülnek.
- A kód számonkérése. A bejelentés szerint a Verus nevű ellenőrző a formális specifikáció alapján vizsgálja a kódot. A Verus a Rust programozási nyelvhez készült bizonyítási nyelv. Ahol a bizonyítás nem alkalmazható — például egy külső könyvtár vagy egy felhasználói felület esetében —, az eszközkészlet teszteket használ, és ezeket bizonyíték, nem pedig bizonyítás címkével látja el.
A készítők egy Trusted Computing Base-t is bemutatnak (ez az a kis kódrészlet-készlet, amelynek helyes működését a bizonyítás egyszerűen feltételezi). A PDD Kit láthatóvá teszi ezt a határt, és arra kéri az embert, hogy minden egyes elemnél hagyja jóvá a döntést. Gondolj rá úgy, mint azon dolgok listájára, amelyekben megbízol.
Mit teszteltek a készítők?
A bejelentés egy kísérletről számol be. A csapat a PDD Kit segítségével ellenőrizte egy Rustban írt, kis onlineáruház-alkalmazás bejelentkezési logikáját a GitHub Next tervezőeszközén, a Chopinen belül. A készítők szerint a Verus segített megerősíteni a kódot, és meglévő hibákat is feltárt, miközben a fejlesztő a generált kód soronkénti elolvasása nélkül ellenőrizte a célleírást.
Ne feledd, hogy ez egyetlen, a készítők által bemutatásra kiválasztott eset. A bejelentés nem közöl szélesebb körű eredményeket.
Összegzés
A PDD Kit készítői így próbálják számonkérhetővé tenni az AI-kódoló ügynököket azzal kapcsolatban, amit a csapat kért tőlük: ahol lehet, bizonyításokat, ahol pedig nem, teszteket használnak. A módszer új, a bejelentés pedig széles körű eredmények helyett egyetlen példát mutat be. Következő lépésként olvasd el te magad a hivatalos bejelentést, és jegyezz fel egy kérdést, amelyre választ szeretnél kapni, mielőtt a saját munkádban megbíznál az AI által írt kódban.
