Kuulen aina sagedamini lauset: "Rakendus on mul juba olemas, see töötab, vaja on ainult viimast lihvi." Ja sageli see tõesti töötab: ilus liides, nupud vajutatavad, andmed ilmuvad, kõik kokku pandud paari päevaga Lovable'iga, peaaegu ilma ühtegi koodirida kirjutamata. Probleem on selles, et "viimane lihv" on tegelikult kõik see, mis lahutab demot tootest. Ja seda "kõike" on tavaliselt rohkem kui kogu varasem töö.
Sellel nähtusel on juba nimi: vibe coding ehk eesti keeli vaibkoodimine. UX Estonia annab selleteemalisi kursusi, sellest räägitakse Eesti podcastides ja blogides, nii et sõna ennast siin tutvustama ei pea. Selles artiklis selgitan, miks see on geniaalne prototüübi jaoks ja ohtlik toote jaoks, mida vibe-coded rakendusel konkreetselt napib, millal sellest täiesti piisab (jah, vahel tegelikult piisab) ja kuidas sellisest prototüübist teha päris, toodangus toimiv toode Eesti turul.
Mis on vibe coding
Vibe coding on programmeerimise viis, kus sa ei loo rakendust koodi kirjutades, vaid kirjeldades loomulikus keeles AI tööriistale, mida soovid. "Tee mulle ülesannete nimekirja rakendus sisselogimise ja tumeda režiimiga" ja paari sekundi pärast on sul toimiv ekraan. Värv ei meeldi, palud muuta. Nupp on puudu, palud lisada. Sa ei kirjuta koodi rida-realt, vaid juhid tunde järgi: palud, vaatad tulemust, palud parandada.
Tööriistad, mis seda teevad, on juba tuttavad ka Eestis: Lovable ja Bolt genereerivad terve rakenduse, v0 liidese, Cursor, Replit ja ChatGPT kirjutavad koodi vestluse põhjal. See on tugev tehnoloogia ja ma ei pisenda seda — tunnen neid tööriistu hästi. Küsimus pole kunagi olnud "kas AI oskab koodi kirjutada". Küsimus on "kas see, mille ta kirjutas, peab vastu päris maailmas".
Sest vibe codingul on üks nähtamatu omadus: see on optimeeritud selleks, et näeks välja, nagu töötaks. AI genereerib koodi, mis läbib ilmselge testi: sa vajutad nuppu ja midagi juhtub. Aga "töötab minu ekraanil" ja "töötab toodangus päris kasutajatele" on kaks täiesti eri asja, ja nende vahel peitub just see töö, mida AI ise ära ei tee.
Miks see on suurepärane prototüübile ja ohtlik tootele
Prototüübi ülesanne on üks: tõestada idee. Sellele piisab, et see töötab sulle, ühe korra, õnnelikku rada pidi (nii nimetan stsenaariumi, kus kasutaja teeb kõik õigesti ja miski ei lähe katki). Kui tahad investorile näidata, kuidas su teenus välja näeb, või ise kontrollida, kas ideel üldse on mõtet, on vibe coding siin asendamatu. See, milleks varem kulus nädal ja paar tuhat eurot, saab nüüd tehtud ühe päevapooliku jooksul. See on päris, suur pluss.
Toote ülesanne on hoopis teine. Toode peab töötama mitte sulle, vaid võõrastele. Halva internetiga. Valesti sisestatud andmetega. Inimesega, kes üritab sind petta. Öösel, kui sa magad. Poole aasta pärast, kui teek vahetus. Tuhande kasutajaga korraga, mitte ühega. Just siin hakkab vibe-coded prototüüp pudenema, ja pudeneb mitte seal, kus näha on, vaid seal, kus ei näe, kuni on liiga hilja.
Vibe codingu kõige ohtlikum illusioon
Kui rakendus näeb välja 90% valmis, ütleb intuitsioon, et jäänud on 10% tööd. Tegelikkuses on vastupidi: nähtav osa (liides, nupud, ekraanid) on see kerge pool, mille AI teeb hästi. Nähtamatu osa aga, turvalisus, andmed, äärejuhud, deploy, on nii kõige raskem kui ka kõige kallim. Seda rasket 30% kirjeldasin eraldi artiklis "Alustasid rakendust AI-ga ja jäid kinni? Mida edasi teha".
7 asja, mida vibe-coded rakendusel napib
Vibe-coded prototüüpides, mida inimesed mulle näitavad, on peaaegu alati puudu samad seitse asja. Mitte sellepärast, et AI oleks "halb", lihtsalt ta genereerib seda, mida palud, ja neid asju ei palu keegi, sest sa ei teagi neist, kuni need probleemiks ei muutu.
| Mida napib | Miks see toodangus loeb |
|---|---|
| 1. Automaattestid | Ilma testideta on iga muudatus hasartmäng. Parandad ühe koha, nähtamatult läheb katki teine. Vibe-coded koodis pole teste peaaegu kunagi, nii et projekt läheb seda habrasemaks, mida rohkem seda puudutad. |
| 2. Vigade käsitlus | Mis juhtub, kui internet katkeb, server ei vasta või kasutaja sisestab prahti? Prototüübis valge ekraan või krahh. Tootes peab olema selge teade, varutee ja vaikne vea logimine taustal. |
| 3. Turvalisus | Koodi sisse kirjutatud API-võtmed, kaitseta andmebaas, kust igaüks saab võõrad andmed kätte, mingit sisendi valideerimist pole. See on sagedaseim ja ohtlikeim vibe-coded auk, ning Eestis tähendab see otse GDPR-rikkumist, mida jälgib Andmekaitse Inspektsioon. |
| 4. Andmemigratsioonid | Kui lisad uue välja või muudad struktuuri, peavad olemasolevad kasutajaandmed "ümber kolima" ilma kadudeta. Vibe-prototüübis muudetakse andmeskeemi kustutades ja uuesti luues, toodangus tähendaks see kustutatud kliente. |
| 5. Monitooring | Toodangus pead probleemist teada saama enne kasutajat. Ilma vigade jälgimise ja logideta sa ei näe, et pool inimesi ei saa sisse logida, saad teada alles siis, kui nad enam tagasi ei tule. |
| 6. Mastaap | Kood, mis töötab ühe kasutajaga, võib saja kasutajaga kokku variseda. Optimeerimata päringud, mingit puhverdamist, kõik ühes lõimes, prototüübile pole vahet, tootele saatuslik just esimesel õnnestunud päeval. |
| 7. Hooldus | Teegid vananevad, tekivad turvaaugud, muutuvad maksete ja sisselogimise reeglid. Toode nõuab pidevat hooldust. Vibe-coded kood, millest keegi aru ei saa, muutub parandamatuks pärast esimest tõsist riket. |
Pane tähele: ühtegi neist seitsmest asjast kasutaja ei näe, kuni kõik on hästi. Kõik need ilmnevad sel ühel halval päeval, ja just nende pärast on toodet ehitada kallim ja aeglasem kui prototüüpi. See pole "lakk" lõpuks, see on vundament.
Millal vibe codingust tegelikult piisab
Nüüd selle artikli kõige tähtsam ja ausam osa. Vibe coding pole "halb". On palju olukordi, kus sellest mitte ainult ei piisa, vaid see on kõige targem valik. Kui tabad mõne neist, ära palka mind, hoia raha kokku ja ehita ise.
Siin vibe codingust tegelikult piisab
- Sisemine tööriist paarile inimesele. Arvutus, tabel, lihtne süsteem, mida kasutab sinu meeskond. Kui see ei hoia võõraste andmeid ega võta raha, ehita AI-ga ja ära muretse.
- Demo investorile või kliendile. Vaja näidata, kuidas idee välja näeb. Kellelegi pole vahet, mis kapoti all on, kui eesmärk on veenda, mitte teenindada.
- Idee visualiseerimine endale. Tahad näha, kas su ideel üldse on mõtet, enne kui investeerid tõsist raha. Vibe-prototüüp vastab sellele küsimusele kõige odavamalt.
- Isiklik projekt. Hobi, isiklik päevik, tööriist endale. Kui katki läheb, läheb katki sinul üksi, ja sa talud seda.
Üldreegel on lihtne: kui rakendus ei hoia võõraste andmeid ega võta vastu raha, piisab sulle vibe codingust suure tõenäosusega.
Millal vibe codingust enam ei piisa
Ja nüüd teine pool. On piir, mille taga "näeb välja, et töötab" muutub riskiks, mis maksab palju rohkem, kui sa ehitades säästsid. Sa ületad selle hetkel, kui rakendust hakkavad kasutama inimesed, keda sa ei tunne, või kui selle kaudu liigub raha. Eestis on latt eriti kõrge: ostja ootab Smart-ID sisselogimist, pangalingiga kassat ja e-arvet kui iseenesestmõistetavust, mitte ekstrana.
| Vibe codingust piisab | Vaja on professionaalset ümberehitust |
|---|---|
| Kasutad ainult sa ise või kitsas usaldatud ring | Kasutavad võõrad, päris kliendid |
| Süsteemis mingit raha pole | Maksed Montonio kaudu, pangalingid, tellimused, arveldused |
| Andmed pole olulised või on avalikud | Isikuandmed, GDPR, AKI, klientide privaatsus |
| Kokkuvarisemine ei maksa midagi | Seisak tähendab kaotatud kliente või mainet |
| Elab paar nädalat | Peab töötama ja olema hooldatud aastaid |
Niipea kui tekivad päris kliendid või maksed, muutub iga neist seitsmest puuduvast asjast vastutuseks. Kaitseta andmebaas sinu klientidega pole enam tehniline pisiasi, vaid GDPR-rikkumine, millest tuleb Andmekaitse Inspektsioonile teatada 72 tunni jooksul. Maksed ilma vigade käsitluseta on raha, mis kaob sinu ja panga vahele. Just seetõttu pole see enam vibe codingu küsimus, vaid toote küsimus.
Kuidas vibe-prototüübist toode teha
Hea uudis: vibe-prototüüp pole sageli raisatud töö, vaid suurepärane stardipakk. Sa oled juba otsustanud, mida rakendus teeb, kuidas näeb välja, milline on loogika. See on kõige väärtuslikum ja kõige raskemini kirjapandav spetsifikatsiooni osa, ja see on juba olemas. Jääb kinni panna see raske 30%, mille tõttu prototüüp pole toode.
Kui minu poole pöördutakse vibe-coded projektiga, ma selle koodi üle ei võta ega lapi — ehitan toote puhtalt nullist ning prototüüp saab spetsifikatsiooniks ja visuaalseks juhiseks. Üldine loogika, mida tasub ka sinul teada: kas ehitada olemasolevale koodile edasi või teha puhtalt ümber, ei määra koodi hulk, vaid selle struktuur. Kui loogika ja andmemudel on terved, saad puuduva kihi olemasolevale koodile lisada ise või koos inimesega, kes selle kirjutas. Kui kood on kaootiline, lahtiste võtmetega ja kontrollimatu state'iga, tuleb puhas ümberehitus kiiremini ja odavamalt kui lappimine. Lähemalt sellest, mis juhtub, kui AI kood hakkab varisema ja "parandamine" varistab veel rohkem, kirjutan eraldi artiklis "Lovable, Bolt, v0, Cursor, mida teha, kui AI kood läheb katki".
Tee prototüübist toodanguni
- Spetsifikatsioon. Võtan prototüübist ekraanid, vood ja loogika, mille juba välja mõtlesid, ja panen kirja, mida toode peab tegema — ka selle, mida prototüüp ei teinud.
- Kindel vundament. Turvaline andmebaas, korralik sisselogimine (Eestis sageli Smart-ID, Mobiil-ID või ID-kaart TARA kaudu), peidetud võtmed, sisendi valideerimine, see, millele saab ehitada.
- Raske 30%. Maksed, integratsioonid, vigade käsitlus, äärejuhud. Eestis lisanduvad siia tihti kohalikud integratsioonid: Montonio või Maksekeskus kassas, pangalingid (SEB, Swedbank, LHV, Luminor), e-arve ja EMTA-le KMD-deklaratsioon, mida AI ise külge ei pane.
- Kaitse. Testid, monitooring ja logid, et probleemist saaksid teada sina, mitte su klient.
- Deploy ja hooldus. Päris domeen, päris hosting, varukoopiad ja selge kokkulepe, kes edasi hooldab.
Minu pakkumine pole kunagi "korrastan su koodi". See on "ehitan nii, et töötaks ja teeniks". Vahe on põhimõtteline: koodi korrastamine on kosmeetika, toote püstipanek aga tähendab, et su kliendid saavad rahulikult kasutada, maksta ja tagasi tulla, ja sina saad rahulikult magada.
Päris numbrid
Konkreetselt hinnast, sest ikkagi seda küsid. Puhas ümberehitus sinu vibe-prototüübi järgi — autentimise, turvalisuse ja juurutusega — maksab alates 2 900 € (MVP / PWA, iOS ja Android ühest koodibaasist). Ärirakendus maksete, kohalike integratsioonide ja admin-paneeliga alates 6 900 €, keerukas platvorm alates 14 900 €. Võrdluseks Eesti turu tüüpilised hinnad: lihtne maandumisleht 1500-3000 €, turundussait blogi ja CMS-iga 2000-5000 €, kohandatud veebirakendus alates 5000 €. Tähtajad enamasti 2-6 nädalat, sõltuvalt mahust ja sellest, kui selgelt prototüüp juba näitab, mida toode peab tegema. Pea meeles, et turuhinnad on B2B-le tavaliselt ilma käibemaksuta, ning käibemaks tõusis juulist 2025 22%-lt 24%-le.
See võib tunduda paljuna "peaaegu valmis" projekti eest. Aga tuleta meelde tabelit seitsme puuduva asjaga, sa ei maksa lakkimise eest, vaid selle vundamendi eest, ilma milleta rakendus pole toode, vaid ainult selle foto. Tasuta Lovable prototüüp peidab just selle tegeliku kulu, mis kulub rakenduse turvaliseks, GDPR-vastavaks ja hooldatavaks tegemiseks.
Sul on vibe-coded prototüüp? Teen sellest päris toote.
Sinu Lovable'i, Bolti, v0 või Cursori prototüüp saab spetsifikatsiooniks: ekraanid ja vood jäävad alles, nende alla ehitan nullist tugeva vundamendi — turvalisuse, andmed, maksed ja juurutuse. MVP alates 2 900 €. Kirjuta, mida ehitad, ja 24 tunni jooksul saad pakkumise koos hinna ja tähtajaga.
Ehita minu prototüüp ümberKorduma kippuvad küsimused
Mis on vibe coding ehk vaibkoodimine?
Vibe coding ehk vaibkoodimine on programmeerimise viis, kus sa ei kirjuta koodi rida-realt, vaid kirjeldad loomulikus keeles AI tööriistale (Lovable, Bolt, v0, Cursor, ChatGPT), mida soovid, ja see genereerib koodi. Sa juhid arendust tunde järgi: palud, vaatad tulemust, palud parandada. See sobib suurepäraselt kiireks prototüübiks, kuid genereeritud koodil napib sageli seda, mida toodang nõuab: teste, vigade käsitlust ja turvalisust.
Mille poolest prototüüp tootest erineb?
Prototüüp peab tõestama ideed, piisab et see töötab sinu ekraanil õnnelikku rada pidi. Toode peab töötama toodangus päris kasutajatega, halva internetiga, vigaste sisenditega ja pahatahtlikega. Vahe teevad testid, vigade käsitlus, turvalisus, andmemigratsioonid, monitooring, mastaap ja hooldus, just seda vibe-coded prototüübil tavaliselt napib. Eestis lisandub veel Smart-ID sisselogimine, pangalingid ja e-arve, mida AI ise külge ei pane.
Kas vibe-coded prototüüpi võib toodangusse lasta?
Tehniliselt saab, kuid päris klientide ja maksete jaoks ma seda ei soovita. Vibe-prototüübil napib enamasti turvalisust (koodi külge kirjutatud API-võtmed, kaitseta andmebaas), vigade käsitlust ja monitooringut. Eestis on lisariskiks GDPR ehk isikuandmete kaitse, mida jälgib Andmekaitse Inspektsioon ja kus rikkumisest tuleb teatada 72 tunni jooksul. Enne käivitamist on vaja inimest, kes paneb paika selle raske 30 protsenti: turvalisuse, andmed, deploy ja äärejuhud.
Millal vibe codingust tegelikult piisab?
Vibe codingust piisab siis, kui rakendus ei hoia võõraste andmeid ega võta vastu raha: sisemine tööriist paarile inimesele, demo investorile, idee visualiseerimine, isiklik projekt. Kui seda kasutad ainult sina ise või kitsas usaldatud ring, säästab vibe-coded lahendus palju aega ja raha. Sellisel juhul ma ausalt ei soovita arendajat palgata, ehita ise edasi.
Kui palju maksab vibe-prototüübist päris toote tegemine?
See sõltub sellest, mida toode peab tegema. Puhas ümberehitus sinu prototüübi järgi — autentimise, turvalisuse ja juurutusega — maksab alates 2 900 € (MVP / PWA, iOS ja Android ühest koodibaasist). Ärirakendus maksete, kohalike integratsioonidega (Montonio, Smart-ID, e-arve) ja admin-paneeliga maksab alates 6 900 €, keerukas platvorm alates 14 900 €. Kõige raskem ja kallim osa on alati see viimane 30 protsenti, mitte algus. Tasuta Lovable prototüüp peidab tegelikku kulu, mis kulub selle turvaliseks, GDPR-vastavaks ja hooldatavaks tegemiseks.
Kas vibe-coded koodile tasub edasi ehitada või nullist ümber teha?
Otsuse määrab mitte koodi hulk, vaid selle struktuur. Kui prototüübi loogika ja andmemudel on terved, võib puuduva toodangukihi lisamine olemasolevale koodile olla mõistlik — seda saad teha ise või koos inimesega, kes koodi kirjutas. Kui kood on kaootiline, lahtiste võtmetega ja kontrollimatu state'iga, on puhas ümberehitus kiirem ja odavam kui lappimine. Eesti kõrge lati tõttu (e-ID, e-arve, korralik andmekaitse) nõuab vibe-prototüüp tihti puhast ümberehitust. Mina töötan ainult seda teist teed pidi: võõrast koodi ma üle ei võta, vaid ehitan toote nullist ja kasutan sinu prototüüpi spetsifikatsioonina.