Ha egy ötletből sokkal rövidebb idő alatt lehet működő alkalmazás, megváltozik, mit érdemes kipróbálni, megépíteni és piacra vinni. Közben ugyanúgy el kell dönteni, hogy jó problémát oldunk-e meg, érthető-e a rendszer, és ki fogja karbantartani. A Banivo Podcast első adásában az AI-val felgyorsított szoftverfejlesztés lehetőségeiről és következményeiről beszélgettünk. Az alábbi cikk az adás témáit járja körül.
Vibe coding: forradalom vagy időzített bomba?
Nézd meg a teljes beszélgetést itt, vagy a fejezetlinkekkel nyisd meg a YouTube-on azt a részt, amelyik érdekel.
A gyors első verzió új lehetőségeket nyit
A vibe coding vonzereje könnyen érthető: leírod, mit szeretnél, az AI kódot készít, te pedig a működő felület alapján kéred a következő módosítást. Rövidebb lehet az út egy elképzeléstől addig, hogy valamit ténylegesen ki lehessen próbálni. Egy belső eszköz vagy egy új termékötlet így hamarabb kerülhet azok elé, akik használni fogják.
Ez különösen az elején értékes. Egy kipróbálható változatból kiderülhet, hogy a felhasználónak egészen más információra van szüksége, vagy hogy a tervezett funkció helyett egy egyszerűbb megoldás is elég. Ha kevesebb munka az első változat, könnyebb elengedni azt is, ami nem vált be.
A kockázat ott jelenik meg, amikor a képernyőn látható működés alapján az egész rendszert késznek tekintjük. Egy sikeres próba még keveset mond arról, mi történik hibás adatokkal, több egyidejű felhasználóval vagy megszakadó kapcsolattal. A jogosultságok, a tesztelés és a hibák követhetősége akkor is része a fejlesztésnek, ha az első képernyők gyorsan elkészültek.
Egy ötlet kipróbálásához és egy napi használatban lévő üzleti rendszerhez más mélységű ellenőrzés kell. Érdemes előre tisztázni, melyik változatot építjük, és milyen feltételekkel léphetünk tovább.
Egy nagy termék vagy több kisebb?
Ha rövidül egy első verzió elkészítése, csábító lehet egyszerre több ötletet megvalósítani. Egy szűk feladatra készülő terméknél könnyebb megfogalmazni, kinek segít és miben. Az első visszajelzések is célzottabbak lehetnek: használják-e, mire használják, mi hiányzik belőle?
Minden új termékkel együtt új kötelezettségek is születnek. Lesznek frissítések, ügyfélkérdések, működtetési feladatok és későbbi fejlesztési igények. Ha ugyanazok az emberek visznek öt külön alkalmazást, az idejük ezek között oszlik meg. Az indulás egyszerűsége önmagában nem dönti el, mennyit érdemes párhuzamosan vállalni.
A határokat ezért a felhasználó munkája felől érdemes meghúzni. Egy önállóan is hasznos feladat jó alap lehet egy kisebb termékhez. Ha viszont a napi munka közben állandóan át kell lépni másik alkalmazásba, és ugyanazokat az adatokat több helyen kell kezelni, akkor az összekapcsolás vagy a közös rendszer kérdését is meg kell oldani.
A technikai adósság gyorsabban is felhalmozódhat
Technikai adósságról akkor beszélünk, amikor egy mai megoldás megnehezíti a későbbi módosítást. Ilyen lehet egy több helyre bemásolt üzleti szabály, egy nehezen követhető függőség vagy egy fontos működést védő teszt hiánya. A következménye akkor válik igazán láthatóvá, amikor egy aprónak tűnő kérés miatt több helyen kell változtatni.
Egy átmeneti megoldás lehet tudatos döntés. Egy kipróbálásra szánt változatnál elfogadható lehet olyan egyszerűsítés, amelyet később rendezni kell. Ehhez viszont tudni kell, hol van a kompromisszum, és mi jelzi majd, hogy eljött az ideje foglalkozni vele.
Az AI-val generált kódnál ugyanez a kérdés nagyobb tempó mellett jelentkezhet. Ha az új funkciók gyorsabban érkeznek, mint ahogy átnézzük és egységesítjük őket, a rendszer egyre nehezebben követhetővé válhat. A gyors kódírás előnye ilyenkor a következő fejlesztéseknél veszhet el: több idő megy el annak kiderítésére, mi miért működik úgy, ahogy.
Az AI a kódbázis rendbetételében is segíthet
AI-t meglévő kód megértéséhez, ismétlődések kereséséhez vagy egy átalakítás előkészítéséhez is lehet használni. Javasolhat teszteseteket, és segíthet végiggondolni, milyen részeket érint egy módosítás. Ezeknek a javaslatoknak ugyanúgy ellenőrizhetőnek kell lenniük, mint egy új funkciónak.
A nehézséget sokszor az jelenti, hogy a kódban nem látszik minden üzleti ok. Egy furcsának tűnő elágazás mögött lehet egy régi ügyfélmegállapodás vagy egy külső rendszer sajátossága. Ha ez az összefüggés kimarad a feladatból, egy szebbnek látszó átalakítás fontos működést is eltüntethet.
Ezért hasznosak a kisebb, átnézhető módosítások, az egyértelmű rendszerhatárok és a tényleges üzleti viselkedést ellenőrző tesztek. A fejlesztő feladata marad megérteni a változtatás hatását, és eldönteni, hogy a kapott eredmény illeszkedik-e a rendszer egészéhez.
Ha több szoftver készül, nehezebb lehet választani
Az adás egyik kérdése, mi történhet a piacon, ha egyre több gyorsan elkészített AI-szoftver jelenik meg. Elképzelhető, hogy több szűk igényre lesz külön megoldás, és olyan ötletek is eljutnak a felhasználókhoz, amelyekre korábban nem jutott volna fejlesztés.
A választásnál közben nagyobb súlyt kaphat mindaz, ami egy rövid bemutatón kevésbé látszik. Ki javítja a hibákat? Hogyan követhetők az adatok változásai? Kapcsolódik-e a program a meglévő eszközökhöz? Ki tudjuk-e vinni belőle az adatainkat? Van-e mögötte folyamatos támogatás?
Egy vállalkozás hosszabb távon együtt él az általa választott szoftverrel. A kipróbálásnál ezért a mindennapi használat és a későbbi változtatások szempontjait is érdemes elővenni. A gyors elkészülésből akkor lesz tartós érték, ha a termék működtetésére és továbbfejlesztésére is jut figyelem.
Egy rendezetlen folyamat az AI-tól sem lesz egyértelmű
A fejlesztés mellett az AI céges bevezetéséről is beszélgettünk. Ha egy folyamatnál nem világos, ki dönt, milyen adatból dolgozik, és mikor tekinthető lezártnak egy ügy, ezeket a kérdéseket az automatizálás előtt kell tisztázni. Különben a bizonytalanságot visszük tovább a rendszerbe.
Vegyünk egy egyszerű példát: az AI feldolgozza a beérkező ügyfélkéréseket, és feladatokat készít belőlük. Ha nincs megállapodás arról, kihez kerül egy sürgős ügy, vagy mi történik hiányzó adatok esetén, attól még nem lesz követhetőbb a munka, hogy gyorsabban keletkeznek feladatok. Először a felelőst, a szükséges adatokat és a kivételek kezelését kell meghatározni.
Egy ilyen, körülhatárolt lépésnél már meg lehet mondani, mit várunk az AI-tól, hol kell emberi ellenőrzés, és miből látjuk, hogy segített-e. A bevezetés határairól a Mire nem jó az AI a cégedben? című cikkünkben is írtunk.
Több idő juthat a jó döntésekre
A gyorsabb fejlesztés lehetőséget ad arra, hogy hamarabb kapjunk visszajelzést, több megoldást próbáljunk ki, és kevesebb időt töltsünk ismétlődő munkával. A felszabaduló időből a tesztelésre, a felhasználók megértésére és a rendszer egyszerűsítésére is juthat.
Hogy milyen problémát oldunk meg, hol húzzuk meg a termék határait, és milyen működésért vállalunk felelősséget, továbbra is döntés kérdése. Az AI támogatásával ezekhez a döntésekhez gyorsabban lehet kézzelfogható tapasztalatot szerezni. A tartósan használható szoftverhez ezt a lehetőséget is ki kell használni.
