Hol van valójában az ember helye a folyamatban
A kérdés, amelyet jelenleg a leggyakrabban hallunk a vállalati IT-csapatoktól: honnan tudod, hogy az AI által generált kód valóban biztonságos?
Jogos kérdés. A legtöbb szállító még mindig gyengén válaszol rá.
A rossz válasz: "az AI-unkat biztonságos kódolási gyakorlatokra tanítottuk." Ez egy marketingmondat, nem folyamat.
A Webtown válasza három elemre épül: spec-driven fejlesztés, a Liferay és az Ibexa platformok biztonsági modellje, és szigorú governance. Nézzük, hogyan működik mindegyik.
Mi az a spec-driven fejlesztés?
A spec-driven fejlesztés egy olyan módszertan, amelyben az emberi felülvizsgálat súlypontja eltolódik a kész kódról a specifikáció és a terv felé. A fejlesztő nem tekinti át egyenként a generált sorokat. Ehelyett azt validálja, ami a kód létezése előtt jön létre: mit csinál a funkció, milyen bemenetet fogad el, ki férhet hozzá, és mi történik érvénytelen bemenet esetén.
Miért nem a kész kód áll a felülvizsgálat középpontjában a Webtownnál? Mert minden egyes generált sor manuális átnézése pontosan azt a sebességnyereséget ölné meg, amit az AI-nak nyújtania kellene.
Egy specifikáció önmagában nem elég ehhez. Egy részletes szabálykészlettel párosul, amely meghatározza, mitől lesz a kód hatékony, karbantartható és biztonságos: kódolási konvenciók, architektúrai elvek, biztonsági szabályok, amelyeket a Webtown fejlesztői állítottak fel. Az AI ezen a szabálykészleten belül működik, nem azon kívül. A cél az, hogy az eredmény ne csak megfeleljen a specifikációnak, hanem úgy hasson, mintha egy Webtown-fejlesztő írta volna, mert végső soron ugyanazokat a szabályokat követi.
A specifikáció és a terv validálása lehetőséget teremt arra, hogy egy jogosultsági hiányosság vagy egy hiányzó adatkezelési szabály már azelőtt felszínre kerüljön, mielőtt egyetlen sor kód is megszületne.
Hol jön képbe a tesztelés?
A tesztelés a Webtown folyamatában AI-támogatással zajlik. Az a viszonyítási alap, amelyhez méri magát, már átment az emberi jóváhagyáson. A cél az, hogy csak az előzetesen jóváhagyott specifikációnak megfelelő kód juthasson élesbe. Ez más kérdést tesz fel, mint a hagyományos kódfelülvizsgálat: nem azt, hogy "jó ez a kód?", hanem azt, hogy "megfelel-e annak, amit jóváhagytunk?"
A klasszikus minőségbiztosítás ezzel párhuzamosan fut: funkcionális, teljesítmény- és biztonsági tesztek zajlanak a szokásos módon. Amit a specifikáció hozzáad, az egy előzetesen jóváhagyott, auditálható viszonyítási alap, amelyhez minden mérhető, így a QA nemcsak azt mutatja meg, hogy a kód működik, hanem azt is, hogy pontosan azt teszi, amiben megállapodtunk.
A teljes folyamat auditálható és nyomon követhető, ami jelentősen számít a vállalati környezetekben, ahol a megfelelőség és a dokumentáció alapkövetelmény.
Miért számít a platform: a Liferay és az Ibexa biztonsági modellje
A Liferay és az Ibexa érett, jól dokumentált biztonsági modelleken fut: jogosultságok, hitelesítés, adathozzáférés. Ha valaki ezen a modellen belül épít, nem pedig körülötte, akkor sok olyan biztonságot örököl, amit egyébként minden egyes projektben saját magának kellene felépítenie és karbantartania.
Ez a Webtown megközelítésének második pillére: maga a platform csökkenti azt a felületet, ahol hibák keletkezhetnek.
Governance és megfelelőség: miért nem opcionális
Vállalati környezetben a jogi megfelelőség nem egy plusz extra, hanem alapkövetelmény. Alapelv, hogy érzékeny ügyféladat soha nem jut be egyetlen AI-eszközbe sem, és hogy az adatvédelmi garanciák szerződésben is rögzítve vannak, bármilyen eszközt is használunk éppen.
Milyen kérdést érdemes feltenni egy fejlesztési partnernek?
A helyes kérdés nem az, hogy "használtok AI-t?" Hanem az, hogy "hol van az ember helye a folyamatban, és mit validál valójában?"
Ha egy fejlesztési partner nem tud erre egyértelmű választ adni, érdemes ezt már a projekt indulása előtt tudni.
Ha az AI-asszisztált fejlesztés mellett azt is fontolgatod, hogyan integrálj egy vállalati AI-megoldást - például az IBM watsonx-et - a rendszereidbe, abban is szívesen segítünk.
