Így veszünk át egy AI-val épített kódbázist: a felmérési checklistünk

Új, és teljesen legitim kiindulópont

Két éve egy nem fejlesztő alapító pitch deckkel érkezett hozzánk. Ma egyre gyakrabban működő alkalmazással: AI segítségével rakta össze, demózni lehet, néha már valódi felhasználók kezében van. Ez egy valóban új kiindulópont, és a legrosszabb, amit tehetünk vele, ha mérnöki fölénnyel lekezeljük. Az alapító értékes dolgot csinált: validált egy ötletet, és több hónapnyi termékgondolkodást öntött működő szoftverbe.

Csakhogy szinte mindig olyat épített, ami nem tud tovább nőni. Ez a minta olyan következetesen ismétlődik, hogy ma már minden ilyen esetben ugyanazt a felmérést végezzük el, és négy konkrét problémát keresünk. Ugyanazt a négyet, amelyet az Invoice Gurunál is megtaláltunk, amikor AI-val épített Flutter-appként hozzánk került.

Az a négy dolog, amit elsőként megnézünk

Az AI-támogatással épült kódbázisok jellegzetes módon mennek tönkre. Az AI-asszisztens ugyanis arra optimalizál, hogy az aktuális kérés működjön, nem arra, hogy a teljes rendszer értelmes formát kapjon:

• —Architektúra: el van-e választva egymástól a felület, az üzleti logika és az adat, vagy minden képernyő mindent maga csinál? Ha a rétegek összegabalyodtak, egyetlen módosítás sem marad lokális.
• —Állapotkezelés: egyetlen, tudatosan választott mechanizmus kezeli az állapotot, vagy minden képernyő ad hoc módon oldja meg? Az ad hoc állapotkezelésben laknak a reprodukálhatatlan hibák.
• —Adatréteg: mennyire vannak biztonságban a felhasználói adatok? A törékeny, migrációs út nélküli lokális tárolás időzített bomba minden olyan appban, amelyre a felhasználók valódi adatokat bíznak.
• —Duplikáció: hányféleképpen van megoldva ugyanaz a probléma? Egy asszisztens, amelyik nem látja át a teljes kódbázist, gond nélkül újra feltalálja azt, ami már létezik.

A termék marad, az alapok cserélődnek

A csábító mérnöki válasz a nulláról újraírás. Mi ritkán javasoljuk. A prototípus kódja lehet eldobható, de maga a prototípus nem az: benne vannak a validált folyamatok, a képernyők, amelyeket a felhasználók már ismernek, és azok a határesetek, amelyeket az alapító a saját kárán tanult meg. Ha mindezt kidobjuk, ugyanazokért a tanulságokért kétszer fizetünk.

Nálunk az alapértelmezett út a részleges újraírás: a termék viselkedése megmarad, az alatta lévő rétegeket építjük újra. Először a tesztek készülnek el, hogy rögzítsék, minek nem szabad megváltoznia. Utána az alapokat rétegről rétegre cseréljük, miközben a termék nem áll meg. Az Invoice Gurunál ez rétegzett architektúrát, Riverpod-alapú állapotkezelést, megbízható lokális adatréteget és automatizált teszteket jelentett – egy olyan app alatt, amelynek felhasználói semmit sem vettek észre a műtétből.

Mit érdemes ebből megjegyezned alapítóként

Az első verziót AI-val megépíteni nem hiba. Talán ez a valaha volt legolcsóbb termékvalidáció. A hiba az, ha azt várod, hogy ez a verzió a skálázásig is elvisz, vagy ha addig halogatod a mérnöki segítséget, amíg a kódbázis teljesen beragad. Minél korábban történik a felmérés, annál több marad meg az AI-val épített munkából.

És ha alapítóként éppen a lassulás fázisában vagy – amikor minden új funkció tovább tart az előzőnél, és minden javítás elront valami mást –, az nem a kudarc jele. Ez a 60%-os pont. A hátralévő 40% ismert, megoldható mérnöki feladat.