Prieš metus terminas „vibe coding” beveik niekam nieko nesakė. Šiandien apie jį kalba ir startuolių įkūrėjai, ir universitetų dėstytojai, ir tie patys programuotojai, kurie dar visai neseniai juokėsi iš minties, kad kodą galima rašyti „jausmais”. O paaiškėjo, kad galima – ir tai jau nebe pokštas, o realus darbo metodas, kurį naudoja tūkstančiai žmonių kasdien.
Terminą į apyvartą paleido Andrej Karpathy, buvęs OpenAI ir Tesla inžinierius, kai 2025 metų pradžioje socialiniame tinkle X parašė, kad dabar programuoja „pasiduodamas vibe’ui, apkabindamas eksponentes ir netgi pamiršdamas, kad kodas apskritai egzistuoja”. Skambėjo kaip pokštas, bet frazė prigijo per savaitę ir tapo visos naujos darbo kultūros pavadinimu.
Kas iš tikrųjų yra tas vibe coding
Paprastais žodžiais – tai procesas, kai vietoj to, kad pats rašytum funkcijas, klases ir sąlygas, tu tiesiog paaiškini dirbtiniam intelektui, ką nori gauti, o jis pats sugeneruoja kodą. Tu netikrini kiekvienos eilutės, nesigilini, kodėl ten stovi ta konkreti kilpa – tu žiūri į rezultatą. Ar puslapis atrodo taip, kaip įsivaizdavai? Ar mygtukas veikia? Ar aplikacija neišmeta klaidos? Jeigu taip – gerai, judam toliau.
Skirtumas nuo įprasto darbo su AI asistentu (pavyzdžiui, GitHub Copilot autocomplete rėžimu) yra būtent tas pasitikėjimo lygis. Klasikinis būdas: AI pasiūlo eilutę, tu ją perskaitai, įvertini, priimi arba atmeti. Vibe coding būdas: tu duodi užduotį natūralia kalba, gauni visą failą ar net visą modulį, paleidi, žiūri, ar veikia, ir jei ne – vėl rašai promptą, prašydamas pataisyti. Kodo skaitymas tampa nebeprivalomas žingsnis, o kartais net visai išnyksta iš proceso.
Svarbu pabrėžti – tai nėra tiesiog „low-code” ar „no-code” platformų (tipo Bubble ar Webflow) tąsa. Ten tu vis tiek dirbi su vizualiais blokais, kurie apriboja, ką gali padaryti. Vibe coding metu generuojamas realus, pilnavertis kodas – Python, JavaScript, React komponentai, SQL užklausos – tik pats žmogus jo nerašo ranka ir dažnai net nesupranta iki galo.
Kodėl tai tapo įmanoma būtent dabar
Prieš dvejus metus panašus eksperimentas būtų baigęsis fiasko per pusvalandį. Modeliai kliedėdavo, generuodavo neveikiantį kodą, pamiršdavo kontekstą po kelių žinučių. Tai, kas pasikeitė – vadinamieji agentiniai modeliai (agentic models), kurie geba ne tik parašyti kodą, bet ir patys jį paleisti, pamatyti klaidą terminale, ją perskaityti ir pataisyti be žmogaus įsikišimo.
Claude Sonnet ir Opus versijos, GPT-4.1 bei o3 serija, Gemini 2.5 – visi jie žymiai geriau laiko kontekstą, geriau supranta visos projekto architektūros vaizdą, ne tik vieną izoliuotą failą. O tokie įrankiai kaip Cursor, Windsurf, Replit Agent, Bolt.new ar Lovable sujungia tai su realiu darbo aplinkos priėjimu – modelis gali kurti failus, trinti juos, paleisti terminalo komandas, tikrinti, ar serveris pakyla. Tai jau nebe pokalbis su chatbotu, o pilnavertis darbo procesas, kuriame AI yra ne patarėjas, o vykdytojas.
Pridėkime ir kainą – token’ų kaina krito taip smarkiai, kad generuoti tūkstančius eilučių kodo per dieną tapo pigiau nei samdyti valandą juniorą. Ekonomiškai tai tiesiog daro sprendimą savaime suprantamą daugeliui, ypač smulkiems projektams, prototipams ir eksperimentams.
Kaip tai atrodo praktikoje
Įsivaizduokim tipišką sceną. Žmogus, neturintis programavimo išsilavinimo, atsidaro Replit ar Lovable, parašo: „Noriu aplikacijos, kur vartotojai galėtų registruotis, kelti nuotraukas ir jas komentuoti, panašiai kaip Instagram, bet paprasčiau”. Per kelias minutes gauna veikiantį prototipą su registracijos forma, duomenų baze ir nuotraukų įkėlimo funkcija. Jis pamato, kad spalvos ne tos, kokias norėjo – parašo: „padaryk tamsų foną ir mėlynus mygtukus”. Modelis pakeičia CSS. Jis pamato, kad komentarų laukas neatsinaujina automatiškai – parašo apie tai, gauna pataisymą.
Visas šis ciklas gali užtrukti valandą vietoj savaičių, kurias reikėtų skirti mokantis React, Node.js, duomenų bazių dizaino. Būtent dėl to vibe coding taip patiko produktų vadybininkams, dizaineriams, rinkodaros specialistams – žmonėms, kurie turi idėją, bet neturi (ir nenori turėti) inžinerinio pasiruošimo.
Kita realija – patys programuotojai naudoja tą patį metodą greitiems prototipams, vidinių įrankių kūrimui, vienkartiniams skriptams. Kam rašyti duomenų parsinimo skriptą pačiam, jeigu Claude Code jį parašys per minutę ir dar pats patikrins, ar veikia su tavo CSV failu?
Kur slypi pavojai, apie kuriuos mažai kalbama
Čia prasideda mažiau romantiška dalis. Kodas, kurio niekas neskaitė, gali veikti puikiai demonstracijoje ir katastrofiškai sugriūti realybėje. Yra jau ne vienas garsus atvejis, kai vibe coding būdu sukurta aplikacija turėjo atvirą duomenų bazę be autentifikacijos, arba API raktus, palikus tiesiai front-end kode, matomus bet kam, kas atidaro naršyklės developer tools.
Saugumo specialistai vadina tai „confidence gap” – pasitikėjimo spraga tarp to, kaip aplikacija atrodo (veikia gerai, spalvota, greita), ir to, kas iš tikrųjų vyksta po gaubtu. AI modeliai linkę generuoti kodą, kuris „veikia dabar”, bet ne visada kodą, kuris saugus, efektyvus ar tvarus ilgalaikėje perspektyvoje. Jis nemąsto apie edge case’us, kurių jam nepaminėjai, nemąsto apie tai, kas nutiks, jei prisijungs tūkstantis vartotojų vienu metu, jei nepaklausei būtent apie tai.
Antras dalykas – techninė skola auga nematomai. Kai žmogus pats rašo kodą, jis bent apytiksliai žino, kur kas guli, kodėl priimtas vienas ar kitas sprendimas. Vibe coding metu, ypač kai projektas auga, susikaupia sluoksniai kodo, kurio niekas iki galo nesupranta – net pats AI, paklaustas po savaitės, gali „pamiršti”, kodėl parašė būtent taip, nes kiekvienas prašymas buvo atskiras kontekstas.
Trečia – priklausomybė nuo įrankio. Jeigu visas projektas gyvuoja tik todėl, kad AI moka jį palaikyti, o žmogus, valdantis produktą, negali savarankiškai perskaityti kodo bazės, atsiranda rizika – ką daryti, jeigu reikia skubaus taisymo, o modelis tą dieną „nesupranta” problemos taip, kaip norėtųsi?
Kada šis metodas tikrai veikia, o kada – ne
Nėra prasmės demonizuoti reiškinį – jis puikiai tinka tam tikroms situacijoms. Prototipavimui, MVP kūrimui, idėjos validavimui prieš rinkos analizę – čia vibe coding yra tiesiog nepamainomas. Jeigu nori per savaitgalį patikrinti, ar žmonėms apskritai įdomus tavo produktas, nėra prasmės samdyti komandą ir mėnesį rašyti architektūrą – geriau sukurk veikiantį prototipą, parodyk žmonėms, gauk atsiliepimų.
Taip pat puikiai veikia vidiniams įrankiams, kurių niekas iš išorės nematys – automatizacijos skriptai, duomenų analizės pagalbinės priemonės, vienkartiniai konvertavimo įrankiai. Rizika čia minimali, nes klaida paveiks tik tave patį arba mažą vidinę komandą.
O štai kur tikrai reikėtų sustoti ir pagalvoti du kartus – finansinės sistemos, mokėjimų apdorojimas, vartotojų asmeninių duomenų saugojimas, medicininė informacija, bet kas, kas susiję su autentifikacija ir prieigos teisėmis. Čia „veikia demonstracijoje” ir „saugu produkcijoje” yra du visiškai skirtingi dalykai, o kaina už klaidą – ne prarastas laikas, o galimai reali žala žmonėms.
Įrankių žemėlapis – kas ką geriausiai daro
Rinkoje jau susiformavo tam tikra specializacija. Cursor ir Windsurf – tai redaktoriai, orientuoti į programuotojus, kurie nori greičio, bet vis tiek dirba su tikru kodu ir gali bet kada pažiūrėti, kas vyksta. Replit Agent ir Lovable orientuoti į žmones be techninio išsilavinimo – jie labiau paslepia kodą ir fokusuojasi į galutinį rezultatą. Bolt.new ir v0 nuo Vercel puikiai tinka greitam front-end prototipavimui – vieno puslapio aplikacijoms, kraštinukams, dizaino idėjų realizacijai. Claude Code nuo Anthropic labiau orientuotas į terminalo aplinką ir gilesnį darbą su esamomis kodo bazėmis, todėl jį dažnai renkasi tie, kurie nori vibe coding taikyti ir rimtesniuose projektuose, ne tik pradėjus nuo nulio.
Visi šie įrankiai per praėjusius kelis mėnesius sparčiai vystosi, ir riba tarp jų kasdien vis labiau miglosta – kiekvienas bando pridėti tai, kas gerai veikia pas konkurentą.
Vibe’as praeis, kodas liks – ką su tuo daryti jau šiandien
Jeigu nori pabandyti šį metodą, keli praktiniai patarimai, kurie realiai gali apsaugoti nuo skaudžių netikėtumų. Pirma – niekada nedėk į produkciją nieko, ko bent minimaliai neperskaitei, ypač jeigu tai liečia autentifikaciją, duomenų bazę ar mokėjimus. Paprašyk AI paaiškinti, ką jis parašė – geri modeliai tai padaro puikiai, tereikia paklausti.
Antra – naudok versijų kontrolę (git) nuo pat pirmos minutės, net jei projektas atrodo kaip žaislas. Kai AI kažką sugadina (o tai anksčiau ar vėliau nutiks), galimybė grįžti atgal per vieną komandą yra neįkainojama.
Trečia – jei projektas auga iš prototipo į kažką rimtesnio, ateis momentas, kai reikės sustoti ir peržiūrėti visą architektūrą su žmogumi, kuris supranta, kas vyksta po gaubtu. Vibe coding puikiai tinka pradžiai, bet retai kada tinkamas ilgalaikei sistemos priežiūrai be jokios žmogiškos priežiūros.
Ketvirta – neišmesk mokymosi iš lygties visai. Paradoksalu, bet žmonės, kurie geriausiai naudoja vibe coding, dažnai patys turi bent bazinį supratimą apie programavimą. Jie žino, ko klausti, atpažįsta, kai atsakymas atrodo įtartinai, moka paprašyti paaiškinti neaiškią vietą. Tie, kurie visiškai nieko nesupranta apie kodą, dažniau susiduria su situacijomis, kai AI juos tiesiog nuveda klaidingu keliu, o jie to nepastebi, kol nesugriūna visa sistema.
Vibe coding – ne grėsmė programavimui kaip profesijai, bet ir ne stebuklingas raktas, atveriantis visas duris be pastangų. Tai naujas įrankis, kuris keičia, kur programuotojas ir ne programuotojas praleidžia savo laiką – mažiau sintaksės, daugiau sprendimų priėmimo, mažiau rankinio rašymo, daugiau dėmesio, ar sprendimas iš viso teisingas. Kaip ir su bet kuriuo galingu įrankiu, klausimas ne „ar naudoti”, o „kada, kiek ir su kokiu atsargumu”. Tie, kurie tai supras anksčiau nei kiti, tikriausiai ir laimės daugiausiai iš šio perversmo, o ne tie, kurie tiesiog paskęs entuziazme, kad kodo rašyti nebereikia.
