Ar galima susikurti programą vien su AI? „Reddit" istorijos

„Ar tikrai galima susikurti programą vien su AI?" Šį klausimą man užduoda vis dažniau, ypač po istorijų apie „vibe coding", kai programa kuriama tiesiog aprašant, ko nori. Kad atsakyčiau sąžiningai, surinkau, ką apie tai realiai pasakoja žmonės r/webdev ir r/vibecoding bendruomenėse, tarp jų ir tie, kurie patys tokias programas kūrė. Toliau tikrų istorijų santrauka su nuorodomis ir mano komentaras.

Trumpas atsakymas: taip, bet su sąlygomis

Bene taikliausiai apibendrina gija „Do People Really Just Create An Entire App just Vibe Coding?": „vibe coding" puikiai tinka prototipams ir demonstracijoms, o didesniems projektams veikia tik tada, kai pirmiausia apgalvojama architektūra, o AI naudojamas jau jos rėmuose. Kitaip tariant, ne pats kodo rašymas yra sunkiausia dalis, o sprendimas, kaip visa tai turi būti sudėliota.

Panašią mintį randame gijoje „Is it wishful thinking to try building a fully functional software with AI": tai įmanoma, bet reikia realių lūkesčių. Paprastos programos ir automatizavimo įrankiai gaunasi gerai.

Kur dažniausiai lūžta

Kelios istorijos sutampa: pradžia būna lengva ir įkvepianti, o problemos prasideda augant. Kai reikia pridėti naują funkciją, sutvarkyti saugumą ar sujungti su kita sistema, projektas be apgalvotos struktūros tampa sunkiai valdomas. Tai nėra AI kaltė, tiesiog be plano bet kuris projektas anksčiau ar vėliau įklimpsta.

Ką patiria tie, kuriems pavyko

Naudinga gija „What I Learned Building an App Without Coding", kur autorius po daugybės klaidų aprašo, kas jam suveikė: viską dokumentuoti ir suderinti visus naudojamus AI įrankius pagal tą pačią medžiagą. Kitaip tariant, sėkmė atėjo ne iš „magijos", o iš tvarkos ir aiškaus proceso.

Kur eina riba tarp prototipo ir produkto

Diskusijose ši riba dažnai lieka neapibrėžta, nors praktikoje ji gana aiški. Prototipas virsta produktu tada, kai atsiranda bent vienas iš šių dalykų:

• Realūs vartotojai, kurie nėra jūs. Nuo to momento klaida kainuoja ne jūsų vakarą, o kliento pasitikėjimą.
• Asmens duomenys. Vardai, el. paštai, sutarčių fragmentai. Čia jau kalbama apie prieigos teises, saugojimo vietą ir BDAR.
• Pinigai. Bet koks mokėjimas ar sąskaita reiškia, kad klaida turi tiesioginę kainą.
• Priklausomybė. Jei įrankiui sustojus sustoja darbas, tai nebe eksperimentas.
• Daugiau nei vienas redaktorius. Kai kodą keičia du žmonės, reikia tvarkos, kaip pakeitimai sugula vienas ant kito.

Kol nė vieno iš šių punktų nėra, kurkite drąsiai ir negalvokite apie architektūrą. Kai atsiranda bent du, verta stabtelėti.

Skaičiavimo pavyzdys: kiek kainuoja abu keliai

Paimkime konkretų vidinį įrankį. Trys žmonės kas savaitę praleidžia po 4 valandas perkeldami ir tvarkydami duomenis tarp dviejų sistemų. Tai 12 valandų per savaitę arba apie 52 valandas per mėnesį. Prie 15 eurų valandos kaštų tai 780 eurų per mėnesį.

Prototipas su AI: savininkas ar techniškesnis komandos narys sugaišta savo vakarus, tarkime, 30 valandų. Jei jo valandos kaštai 25 eurai, tai 750 eurų vienkartinių, plius maždaug 40 eurų per mėnesį įrankiams.

Tarkime, įrankis nuima 60 procentų rankinio darbo. Sutaupoma apie 470 eurų per mėnesį, atėmus prenumeratą lieka 430. Vienkartinė investicija atsiperka per antrą mėnesį. Šitas kelias beveik visada pasiteisina, ir būtent todėl verta jį bandyti.

Dabar antra dalis, kurios diskusijose dažnai nebūna. Praeina pusmetis, įrankiu naudojasi ne trys, o dešimt žmonių, ir jo prireikia klientams. Atsiranda prisijungimai, teisės, atsarginės kopijos, klaidų stebėjimas ir kažkas, kas sutvarkys gedimą penktadienio vakarą. Čia valandos skaičiuojamos jau ne dešimtimis, o šimtais, ir prototipo perrašymas dažnai kainuoja daugiau nei tvarkingas sprendimas nuo pradžių.

Išvada nuobodi, bet teisinga: pigiausias kelias yra prototipas patiems, o po to sąmoningas sprendimas, ar jį perdaryti tvarkingai, ar palikti kaip vidinį įrankį ir daugiau neplėsti. Brangiausias kelias yra augti su prototipu, apsimetant, kad tai produktas.

Ką daryti žingsnis po žingsnio

1. Aprašykite, ką įrankis turi daryti, vienu puslapiu. Ne technologijas, o veiksmus ir duomenis. Šis puslapis vėliau bus medžiaga tiek jums, tiek AI įrankiams.
2. Susikurkite prototipą su AI. Tikslas yra atsakyti į vieną klausimą: ar tai apskritai naudinga. Kokybė šiame etape nesvarbi.
3. Duokite jį trims realiems žmonėms. Ne demonstracijai, o darbui savaitę. Dauguma idėjų miršta būtent čia, ir tai pigiausia vieta joms mirti.
4. Užrašykite, kas lūžo. Ne pojūčius, o konkrečius atvejus. Šis sąrašas yra vertingiausias dokumentas visame procese.
5. Priimkite sprendimą sąmoningai. Palikti kaip vidinį įrankį, perdaryti tvarkingai arba mesti. Trečias variantas yra normalus rezultatas, ne nesėkmė.

Visos aukščiau minėtos gijos sutampa vienoje vietoje: sėkmingiausi atvejai buvo tie, kur žmogus vedė tvarkingą dokumentaciją ir žinojo, ko nori, dar prieš rašydamas pirmą užklausą. Panašią logiką aprašome ir straipsnyje apie vidines sistemas su AI.

Dažniausios klaidos

• Prototipas paleidžiamas klientams. Veikia demonstracijoje, todėl atrodo, kad veiks ir realybėje. Pataisymas: prieš paleidimą peržiūrėkite penkių punktų sąrašą iš aukščiau.
• Nėra atsarginių kopijų. Duomenys guli vienoje vietoje be jokios kopijos, ir vieną dieną jų nebelieka. Pataisymas: kopijos sutvarkomos anksčiau nei bet kuri nauja funkcija.
• Kiekviena nauja funkcija sugriauna seną. Tai ženklas, kad projektas peraugo prototipo formą. Pataisymas: sustokite ir spręskite dėl struktūros, o ne prašykite AI dar vieno pataisymo.
• Jautrūs duomenys keliami nepatikrinus sąlygų. Pataisymas: prieš keliant klientų duomenis patikrinkite, kur jie apdorojami. Pagrindus aprašome atskirai: duomenų saugumas naudojant AI.
• Įrankiai keičiami kas savaitę. Naujas įrankis atrodo greitesnis, todėl darbas prasideda iš naujo. Pataisymas: pasirinkite vieną rinkinį ir laikykitės jo bent iki prototipo pabaigos. Apie tai atskirai: no-code ir AI programų kūrimo įrankiai.
• Nėra nė vieno žmogaus, kuris supranta, kaip tai veikia. Kai vienintelis kūrėjas išeina atostogų, sustoja viskas.

Prieštaravimai, kuriuos girdime

"Programuotojas kainuoja per brangiai." Dažnai taip, todėl prototipą ir verta daryti patiems. Bet palyginimas turi būti sąžiningas: lyginkite ne prototipo kainą su produkto kaina, o dvejų metų bendrą kaštą, įskaitant jūsų pačių valandas, praleistas taisant.

"AI juk kasmet tobulėja, gal palaukti." Laukimas nekainuoja nieko tik tada, kai problema neskubi. Jei rankinis darbas atima 50 valandų per mėnesį, laukimas kainuoja būtent tiek.

"Neturiu techninių žinių, man tai nepasieks." Prototipui dažniausiai pasieks. Ribą pasieksite ne rašydami kodą, o tada, kai reikės nuspręsti, kaip sudėlioti duomenis ir kas nutinka, kai kažkas sulūžta. Būtent tas sprendimas, o ne kodo rašymas, ir yra sunkiausia dalis.

Lietuvos konteksto pastaba

Lietuvoje šis klausimas turi savo specifiką. Rinka maža, todėl vidiniam įrankiui skirtas sprendimas retai turi šansų tapti produktu, kuris pats save išlaikytų. Praktinė išvada: dauguma LT įmonių AI kūrimo įrankius naudingiausiai panaudoja vidinei rutinai, o ne bandydamos sukurti startuolį.

Antra: kalba. Lietuviškas tekstas sąsajoje, klaidų pranešimuose ir dokumentuose beveik visada reikalauja žmogaus peržiūros. Automatiškai sugeneruotas lietuviškas tekstas atpažįstamas iš karto, o vidiniam įrankiui tai nesvarbu, klientams matomam produktui labai.

Trečia: BDAR. Jei įrankis liečia klientų duomenis, reikia žinoti, kur jie saugomi ir kas turi prieigą. Prototipe tai dažniausiai neapgalvota, ir būtent tai yra pagrindinė priežastis, kodėl prototipo nereikėtų paleisti klientams. Kaip tuos pačius klausimus sprendžia sektorius su griežčiausiais reikalavimais, aprašome tekste apie AI Lietuvos bankuose ir finansuose. Kaip apsispręsti tarp paruošto sprendimo ir savo kūrimo, aprašome atskirai: paruoštas įrankis ar individualus sprendimas.

Ką iš to pasiimti Lietuvos verslui

Sąžininga išvada tokia:

• Prototipui ar vidiniam įrankiui dažnai visiškai užtenka pasidaryti pačiam su AI. Tai greita ir pigu.
• Rimtam produktui su klientais, mokėjimais ar jautriais duomenimis reikia apgalvotos architektūros, saugumo ir priežiūros.

Kaip pradėti: jei turite idėją, pirmiausia pasidarykite paprastą prototipą su AI, kad patikrintumėte, ar žmonėms to reikia. Kai idėja pasitvirtins ir programa taps svarbi verslui, verta ją sudėlioti tvarkingai.

Būtent čia ir padedame: naudojame AI, kad kurtume greičiau ir pigiau, bet architektūrą, saugumą ir kokybę užtikriname taip, kad programa augtų kartu su jūsų verslu, o ne subyrėtų augdama. Turite idėją ar prototipą, kurį norite paversti rimtu sprendimu? Konsultacija nemokama.