Lovable, Bolt, v0, Cursor - Mida Teha, Kui AI Kood Läheb Katki

Stseen, mida näen peaaegu iga nädal. Inimene teeb nädalavahetusega Lovable'i, Bolti või v0-ga toimiva demo, rõõmu täis, näitab sõpradele. Siis tahab lisada ühe asja - makse, sisselogimise, uue ekraani - ja kõik hakkab lagunema. Palub AI-l parandada. Parandab. Tunni pärast läheb katki midagi, mis töötas. Palub uuesti parandada. Kümnenda ringi järel on kood juba selline, et ei tema ega AI enam aru ei saa, mis toimub.

Kui tundsid end siin ära - see ei ole sinu süü ega rumaluse märk. Need tööriistad on tehtud just selleks: idee kiiresti näidata. Probleem algab siis, kui proovid demost teha päris, kasutajatele antavat toodet. Selles artiklis panen ausalt kirja, kus konkreetselt iga tööriist oma seina vastu jookseb, miks AI parandab ja jälle lammutab, mida valmis panna enne abi otsimist ja millal üldse tasub olemasolevat koodi päästa ning millal on odavam puhtalt uuesti ehitada.

Ma ei räägi teooriast. Selliseid projekte näen pidevalt ja minu tee nendega on alati sama: katkist Lovable'i või Bolti koodi ma üle ei võta ega lapi, vaid kasutan prototüüpi spetsifikatsioonina ja ehitan toote nullist - nii, et see töötaks toodangus, päris kasutajate ja päris rahaga. Eesti on maailma kõige digitaalsem väiketurg, nii et siin on ka latt kõrge - su klient ootab Smart-ID sisselogimist, pangalingi maksevõimalust ja e-arvet mitte lisana, vaid endastmõistetavusena. Just see ongi see osa, kus AI demo komistab.

Miks AI viib 80%-ni ja jääb sinna seisma

Lovable, Bolt ja v0 teevad uskumatult kiiresti seda osa, mis on nähtav - nupud, vormid, ekraanid, ilus paigutus. See on umbes 80% sellest, mis näeb välja nagu rakendus. Aga ülejäänud 20% - maksed, autentimine, andmebaas, deploy, turvalisus, GDPR, äärejuhud - on kõige raskem, kõige kallim ja täpselt see osa, mille pärast rakendus üldse päris inimestega töötab. AI seal ei hiilga - seal ta põrkab vastu.

Põhjus on lihtne. See nähtav kiht on šablooniline: sarnaseid vorme ja ekraane on internetis miljoneid, AI on neid näinud ja kordab silmapilkselt. Ülejäänud 20% on aga sinu projektile unikaalne ja nõuab otsuseid, mida pead tegema tervikut mõistes - kuidas andmed liiguvad, kus neid hoitakse, kes mida näeb, mis juhtub, kui makse ebaõnnestub. See ei ole kopeerimine, vaid inseneritöö. Ja just seal hakkab kõik katki minema.

Kus läheb katki - tööriista kaupa

Igal tööriistal on oma iseloom ja oma tüüpiline murdumiskoht. Seda teades saad palju kiiremini aru, mis sul tegelikult käes on.

Lovable - deploy ja andmebaas

Lovable ehitab terve rakenduse (React + Supabase) ja korraldab paljutki ise, seetõttu näeb alguses maagiline välja. Aga katki läheb tavaliselt kahes kohas. Esiteks - Supabase andmebaas: kui andmemudel läheb keerulisemaks, algab RLS-i (ridade tasandi turvalisuse) reeglite segadus, tabelite seosed takerduvad ja päringud tagastavad kas liiga palju või mitte midagi. Teiseks - deploy ja keskkonnad: lokaalselt või Lovable'i eelvaates töötab, aga päris domeenil päris muutujatega enam mitte, sest võtmed, lingid või CORS on seadistatud ainult demorežiimile.

Bolt - state ja integratsioonid

Bolt genereerib suurepäraselt interaktiivse frontendi väga kiiresti. Sein tuleb siis, kui rakendusse tekib palju olekut (state): ostukorv, sisseloginud kasutaja, filtrid, vormid, mis teineteisest sõltuvad. See state hakkab pagema - vajutad ühes kohas, uueneb seostamata asi teises. Bolti teine valus koht on integratsioonid päris süsteemidega: maksed, e-post, väline API. Demo tasandil näitab Bolt, kuidas see välja näeks, kuid päris ühendamiseks on vaja serveripoolt, saladuste haldust ja veakaitset, mida kiire genereerimine ei tee. Eesti e-poe puhul tähendab see, et Bolti ilus checkout ei tea midagi Montonio või Maksekeskuse pangalingist - ja just see on koht, kus päris kasutaja maksmata jääb.

v0 - ilus UI, aga backendi tuleb kontrollida

v0 (Verceli oma) on selle grupi parim ühe asja jaoks - luua tõeliselt ilus React/Next.js liidese komponent või terve lehevaade. Ta oskab genereerida ka andmebaasi, sisselogimise ja serveriloogika, kuid tema tugevus on liides. Inimesed jäävad kinni, sest neil on imeilus ekraan ja nad arvavad, et jääb üle ainult ühendada - aga tegelikult on kõige raskem osa (turvalisus, andmeloogika, vigade käsitlus) veel kontrollimata.

Cursor - genereerib, aga sina pead aru saama

Cursor on teistsugune kui kolm ülevalpool - see on võimsa AI-ga redaktor inimesele, kes juba oskab koodi lugeda. Ta võib kirjutada palju ja kiiresti. Aga kui sa ei oska hinnata, mida ta kirjutas, laseb ta sul lihtsalt kiiremini juurde luua seda, millest aru ei saa. Tüüpiline stsenaarium: Cursor genereerib keerulise loogika, see peaaegu töötab, sa palud parandada detaili, ta kirjutab ümber rohkem kui vaja, ja korraga on sul 2000 rida, mida ei oska lugeda ega turvaliselt muuta. Cursor on imeline professionaalile ja ohtlik sellele, kes loodab, et ta paneb ise kõik korda.

Miks AI parandab ja jälle lammutab

See on üks sagedasemaid küsimusi, mida kuulen: miks ta parandab ühe ja lammutab teise? Vastus on konteksti kadu. AI ei näe kogu su projekti korraga kui terviklikku süsteemi. Igas paranduses töötab ta piiratud nähtava osaga, mäletab vaid niipalju, kui mahub, ja oletab ülejäänu kohta. Kohta A parandades muudab ta teadmatult midagi, millest sõltub koht B, mille kohta ta sel hetkel ei teadnud.

Mida suurem on projekt, seda kiiremini see ring käivitub. Alguses, kui faile on vähe, hoiab AI veel kõik peas ja näeb imeline välja. Teatud suuruse järel on igal uuel parandusel üha suurem tõenäosus midagi murda. Sa palud sagedamini parandada, ta kirjutab üha rohkem ümber, kood läheb üha laialivalguvamaks - ja korraga oledki rattas, millest AI sind välja ei too, sest tema isegi on selle ratta põhjus.

Inimene murrab selle ratta lihtsalt: hoiab kogu arhitektuuri peas, mõistab põhjust, mitte ainult sümptomit, ja parandab üks kord nii, et jääks parandatuks. Seal, kus AI lappib kümme korda, parandab mõistev inimene ühe korra.

Mida teha ENNE pöördumist

Kui otsustasid, et olemasolevat koodi peab parandama inimene - kas see, kes selle tegi, või mõni teine arendaja -, on kolm asja, mille valmis pannes käib hindamine kiiresti ja täpselt, mitte kalli oletamisena. Selle saad ise ära teha poole tunniga.

Nende kolme asjaga ütleb arendaja üsna kiiresti, kas piisab punktparandustest või on odavam uuesti ehitada, ja milline on päris hind. Ilma nendeta - ainult üldised fraasid, mida kellelgi vaja pole. Kui valid puhta ümberehituse minu juures, on sellest loendist vaja ainult kolmandat punkti ja linki prototüübile: koodi ma üle ei võta, seega ligipääsu repole pole vaja.

Päästa või uuesti ehitada?

Kõige tähtsam otsus - ja selle saad teha ise. Vastupidi oodatule ei ole õige vastus alati "viska kõik minema ja kirjuta nullist". Loogika on umbes selline.

Olukord	Mida valida
UI on korras, probleemid lokaalsed (makse ei ühendu, deploy läheb katki, üks integratsioon)	Päästa. Punktparandused - ise või koos inimesega, kes koodi tegi. Sageli odavaim tee.
Frontend on hea, aga pole päris backendi ega andmemudelit	Segatud. Frontendi alles hoida ja selle alla puhta backendi ehitada saab koodi autor või mõni teine arendaja.
Loogika on laiali, iga parandus lammutab muud, keegi ei mõista struktuuri	Ehitada uuesti. Visuaal saab spetsifikatsiooniks, kood kirjutatakse puhtalt nullist - just see ongi minu töö.
See on sisemine tööriist või demo, mitte päris klientide ja raha jaoks	Võib-olla piisab sulle AI-st. Ütlen ausalt, kui mind vaja pole.

Tahan rõhutada viimast rida. Kui su projekt on hobi, sisemine tööriist paari inimese tiimile või idee visualiseering - AI sulle tegelikult piisab, ja ma ütlen sulle seda. Ma ei püüa tööd müüa seal, kus seda vaja pole. Sama ausalt ütlen, mida ise teen: ainult puhast ümberehitust nullist - päästmise ja lappimise jätan sulle või inimesele, kes koodi tegi.

Milline tööriist millele sobib - ja kus on tema sein

Lühike tabel, et valides ära ei segaks. See ei ole edetabel "parim-halvim", vaid kaart sellest, millise töö jaoks iga tööriist mõeldud on ja kus tema võimalused lõpevad.

Tööriist	Millele sobib	Kus on sein
Lovable	Täielik demo andmebaasi ja sisselogimisega, kiire MVP idee kontrollimiseks	Supabase reeglid, deploy päris domeenile, kasvav andmemudel
Bolt	Interaktiivne frontend-prototüüp, kiire vaade, kuidas töötaks	Keeruline state, päris integratsioonid, maksed, serveripool
v0	Ilusad React/Next.js komponendid ja lehed, UI-alus	Backendi, andmebaasi, sisselogimist pole üldse - ainult esikülg
Cursor	Kiirem arendus sellele, kes oskab koodi lugeda ja hinnata	Ilma mõistmiseta kuhjad kiiresti juurde seda, mida enam ei valitse

Kui tahad rohkem sellest, miks AI prototüüp ei ole veel toode ja mis eristab "töötab mu ekraanil" omast "töötab päris kasutajatele", olen sellest kirjutanud eraldi - vaata vaibkoodimise artiklit AI prototüübist versus päris tootest.

Päris hinnaraamid Eestis

Ausalt, sest seda ei ütle keegi otse. Olemasoleva koodi parandamist ega lõpuni viimist ma ei paku, seega siin on minu hinnad puhtale nullist ümberehitusele, kus sinu prototüüp saab spetsifikatsiooniks:

• MVP / PWA sisselogimise, andmete ja juurutusega (iOS ja Android ühest koodibaasist): alates 2 900 €
• Ärirakendus Smart-ID sisselogimise, pangalingi makse ja integratsioonidega, hea visuaal säilib spetsifikatsioonina: alates 6 900 €
• Keerukas platvorm mitme kasutajatüübi ja paljude integratsioonidega: alates 14 900 €

Hind sõltub sellest, mida toode peab tegema, mitte sinu koodi seisukorrast - seega pakkumise jaoks pole mul koodi vajagi. Kohalikud integratsioonid (Montonio, Smart-ID, e-arve) kuuluvad projekti mahtu - tavaliselt on see ärirakenduse tase alates 6 900 €. "Tasuta" Lovable'i prototüüp varjab päris hinda: turvaliseks, GDPR-vastavaks ja hooldatavaks tegemine on see, mis maksab.

Lühidalt

Lovable, Bolt, v0 ja Cursor on suurepärased tööriistad selleks, milleks mõeldud - idee kiiresti näidata. Nad lähevad katki mitte sellepärast, et on halvad, vaid sellepärast, et proovid demost teha seda, milleks on vaja inseneritööd: turvalist backendi, päris integratsioone (Montonio, Smart-ID, e-arve), korralikke andmeid. AI lappib sümptomeid ja kaotab konteksti; inimene parandab põhjust. Kui su projekt jäi kinni - ära tee kahekümnendat ringi. Otsusta, milline tee sulle sobib: parandada olemasolevat koodi (ise või koos inimesega, kes selle tegi) või ehitada puhtalt ümber. Kui valid teise - kirjelda, mida soovisid, ja sinu prototüüp saab spetsifikatsiooniks: hea töö säilib ja selle alla ehitan nullist selle, mis ei lase uuesti laguneda - et see töötaks ja teeniks, mitte ainult ei näeks hea välja.