„Vibe coding“ krizė: kodėl informatikos absolventai nebemoka programuoti be DI

„Reddit“ gijoje 2026 m. kovą, kuri greitai viršijo 8 000 teigiamų įvertinimų (upvotes), vyresnysis inžinierius iš „Series-B“ startuolio paskelbė namų užduoties ekrano nuotraukas, kurią jis ką tik atmetė. Kandidatas, neseniai baigęs CS studijas su 3.9 vidurkiu iš gerbiamos programos, atsiuntė kodą, kuris idealiai veikė sėkmingu scenarijumi (happy path), bet tyliai gadino duomenis prie kiekvieno ribinio atvejo (edge case). Kai kandidato paprašė paaiškinti logiką kito skambučio metu, jis negalėjo paaiškinti, kodėl viena iš jo paties funkcijų naudoja rekursiją. Eilutė, kuri privertė giją sprogti, buvo jo sąžiningas atsakymas: “Aš tiesiog pasakiau Claude, ko mums reikia, ir jis parašė tai. Aš paprastai skaitau kodą tik jei jis neveikia.”

Tai „vibe coding“ krizė, ir 2026 metais ji migravo iš programuotojų „Twitter“ į įdarbinimo procesus, vertinimus po interviu ir vis dažniau į CS katedrų vedėjų kabinetus, kurie bando suprasti, kas būtent nutiko jų absolventams. Terminą įvedė Andrejus Karpatis 2025 m. vasarį, apibūdindamas naują teigiamą darbo būdą su LLM — jūs apibūdinate savo ketinimą, priimate tai, ką sugeneruoja modelis, ir siunčiate. Per metus ta pati frazė tapo pramonės etikete programuotojų kartai, kuri gali laisvai rašyti užklausas, bet negali paaiškinti, ką iš tikrųjų daro jų kodas.

Programavimo dėstytojams tai nėra hipotetinė problema apie darbo ateitį. Tai aštri šiuolaikinė pedagoginė krizė dėl studentų, kuriuos išleidžiate tiesiog dabar. Šiame straipsnyje nagrinėjama, ką iš tikrųjų rodo tyrimai ir lauko ataskaitos apie DI sukeltą įgūdžių atrofiją, kodėl kursai nuo CS1 iki baigiamųjų projektų yra unikaliai pažeidžiami, ir kaip nedidelė, bet auganti dėstytojų grupė pertvarko savo kursus, kad garantuotų, jog studentai baigia studijas su gebėjimu programuoti — o ne tiesiog su gebėjimu rašyti užklausas.

Ką iš tikrųjų reiškia „vibe coding“ (ir kodėl Karpatis sakė, kad tai turi būti smagu)

Originalus Karpato formulavimas buvo specifinis. Vibe coding reiškė priimti faktą, kad programavimas asmeniniams projektams dabar gali jaustis kaip kūrybinis žaidimas: jūs sakote modeliui, ko norite, jis sukuria kodą, jūs koreguojate užklausą vietoj kodo ir atiduodate kažką veikiančio. Jis tiesiogiai pažymėjo, kad nebeskaito kodo eilutė po eilutės savo paties šalutiniams projektams. Formulavimas buvo apie malonumą, našumą ir teisėtą pastebėjimą, kad mažiau svarbiems vienkartiniams projektams kruopšti rankinė analizė yra perteklinė.

Vėliau terminas išplito į platesnę sritį, kur jis nusileido dviejuose labai skirtinguose kontekstuose:

• Vyresnieji inžinieriai, kurie naudoja jį sąmoningai: Žiūri į DI sugeneruotą kodą kaip į juodraštį, skaito ir pertvarko jį prieš kodo pakeitimą (commit), naudoja DI, kad išvengtų rutininio šabloninio kodo rašymo, bet taiko dešimtmečius modelių atpažinimo rezultatui įvertinti. Tai yra tai, ką aprašė Karpatis, ir tai veikia.
• Jaunesnieji inžinieriai ir studentai, kurie priima jį kaip numatytąjį režimą: Žiūri į DI sugeneruotą kodą kaip į galutinį rezultatą, priima jį be skaitymo, šalina klaidas tik tada, kai testai nepraeina, kreipiasi į vyresnįjį kolegą ar dėstytoją tik tada, kai DI negali ištaisyti savo paties kodo. Tai yra tai, ko Karpatis neaprašė, ir tai neveikia.

Pedagoginė problema — tai antroji grupė, ir jie sudaro daugumą studentų, pradedančių mokytis CS programose 2026 metais. Pats Karpatis atsitraukė nuo savo formulavimo 2025 m. pabaigoje, pažymėdamas, kad vibe coding turi prasmę ekspertams asmeniniams projektams, bet yra pavojingas visiems kitiems.

Įgūdžių atrofija realiais skaičiais

Įrodymai šiuo metu yra svarūs, ir visi jie rodo viena kryptimi. „CodeRabbit“ 2025 m. gruodžio mėn. analizė, kuri ištyrė pull requests šimtuose projektų su atviru kodu, nustatė, kad kodas, parašytas kartu su generatyviniu DI, turėjo maždaug 1,7 karto daugiau “didelių” problemų nei žmogaus parašytas kodas. Loginės klaidos (neteisingos priklausomybės, defektinis vykdymo kontroliavimas) ir saugumo spragos buvo žymiai padidėjusios, saugumo skylėms atsirandant 2,74 karto dažniau, palyginti su kodu, sukurtu išskirtinai žmogaus.

„TechSpot“ ataskaita 2025 m. pabaigoje apklausė profesionalius programuotojus dėl kognityvinių efektų, sukeltų priverstinių vibe coding darbo procesų. Bendras užfiksuotas modelis: ilgesnis klaidų šalinimo laikas, sumažėjęs gebėjimas mintyse simuliuoti kodo vykdymą ir susilpnėjęs instinktas, kaip turi atrodyti gamybos kokybės kodas. Vienas programuotojas aprašė savo patirtį po šešių mėnesių darbo vibe-first režime kaip visišką „raumenų atminties“ praradimą problemų sprendimui.

Ryškiausia iliustracija atkeliavo iš programuotojo, kuris atliko 30 dienų eksperimentą 2026 m. pradžioje: jokios DI pagalbos mėnesį, o po to refleksija apie skirtumą. Straipsnis dev.to pavadinimu I Coded Without AI for 30 Days: The Results Were Embarrassing tapo vienu populiariausių to meto programuotojų esė. Pagrindinis rezultatas: aktyvus vyresnysis inžinierius su aštuonerių metų patirtimi nebegalėjo iš atminties parašyti paprasto dvejetainio medžio apėjimo (binary tree traversal). Įgūdis buvo atiduotas autorsorsui ir vėliau tyliai išblėso.

Jei aktyvaus vyresniojo inžinieriaus klaidų šalinimo raumuo atrofuoja per kelis mėnesius priklausomybės nuo DI, įsivaizduokite CS1 studento trajektoriją, kuris niekada neturėjo šio raumens iš pat pradžių — kurio visa programavimo patirtis buvo tarpininkaujama per LLM, kuri pateikia veikiantį sprendimą per dešimt sekundžių po uždavinio formuluotės peržiūros.

Kodėl programavimo mokymas yra unikaliai pažeidžiamas?

Kitos disciplinos su DI švietime susiduria ne idealiai, bet dauguma jų vis dar turi integruotus vertinimo karkasus. Literatūros studentą vis tiek galima paprašyti aptarti ištrauką seminare. Chemijos studentą vis tiek galima paprašyti atlikti procedūrą laboratorijoje. Matematikos studentą vis tiek galima paprašyti išvesti įrodymą prie lentos. Programavimo mokymas neturi nė vieno iš šių integruotų vertinimo režimų. Beveik kiekviena programavimo užduotis — tai namų darbas, vertinamas pagal tai, ar kodas praeina testus — o DI 2026 metais praeina šiuos testus neįtikėtinai lengvai.

Tai sukuria tris pažeidžiamumus, specifinius programavimui:

• Užduoties-testo ciklas visiškai automatizuotas. „Codex“, „Claude Code“ ir „Cursor“ skaito užduotį, rašo kodą, paleidžia testus, keičia kodą esant klaidoms ir atiduoda veikiantį sprendimą. Pilnas ciklas, kurio tikimasi iš studento — suprasti reikalavimus, suprojektuoti sprendimą, realizuoti jį, šalinti klaidas — gali būti atliktas DI greičiau, nei studentas perskaitys specifikaciją.
• Asmeninis vertinimas yra logistiškai brangus. CS1 klasė su 200 studentų negali realiai vykdyti penkių minučių žodinio gynimo kiekvienai užduočiai be dvidešimties valandų dėstytojo padėjėjų laiko sudeginimo vienam užduočių ciklui. Ekonominis didelių CS kursų modelis numato asinchroninį namų darbų vertinimą.
• Nusirašinėjimas studentui yra nematomas. Studentas, kuris kopijuoja esė, žino, kad nusirašinėja. Studentas, kuris rašo užklausas DI problemos sprendimui, gali nelaikyti to nusirašinėjimu — socialinė norma pasikeitė greičiau už taisykles, ir veiksmas jaustis taip pat, kaip informacijos ieškojimas „Google“. Kai jie pasiekia baigiamąjį kursą ir turi galvoti patys, jie praleido ketverius metus be atitinkamų įgūdžių formavimo.

Rezultatas yra vertinimo grandinė, kuri kuria studentus su diplomais, kurie nebesikoreliuoja su įgūdžiais. Įdarbinimo vadybininkai 2026 metais vis dažniau apeina gyvenimo aprašymus ir vidurkį gyvo techninio vertinimo naudai būtent todėl, kad diplomų sistema pasirodė atsiplėšusi nuo bazinių gebėjimų.

Kaip „nieko neišmokti“ atrodo per CS konsultacijų valandas

Jei dėstote programavimą, tikriausiai matėte šį modelį, net jei dar nepavadinote jo. Mes surinkome dažniausiai pasitaikančius diagnostinius signalus iš dėstytojų CS1, duomenų struktūrose ir baigiamųjų projektų klasėse 2025 m. pabaigoje ir 2026 m. pradžioje.

• Studentas negali rasti savo paties klaidos. Darbas atiduotas ir veikė idealiai. Naujas unit testas patiria nesėkmę. Studentas atidaro failą, žiūri į kodą taip, lyg matytų jį pirmą kartą, slenka aukštyn ir žemyn be jokios hipotezės ir galiausiai sako: “Aš tiesiog paklausiu Claude, kas blogai.” Pirmoji reakcija į nesėkmingą testą — kreipimasis į DI vietoj hipotezės formavimo.
• Studentas negali atsakyti „kodėl“. Paklausus “kodėl panaudojote čia hash map vietoj array,” atsakymas skamba kaip “tai tai, ką pasiūlė DI.” Pasirinkimas buvo padarytas; logika už jo niekada nebuvo įsisavinta. Po kodu nėra kognityvinio modelio.
• Studentas negali padaryti nedidelės variacijos. “Modifikuokite tai taip, kad apdorotų ir neigiamus skaičius” turi būti trisdešimties sekundžių redagavimas. Nuo DI priklausomam studentui tai virsta penkių minučių užklausų sesija, nes jie turi įvesti apribojimą į modelį vietoj to, kad pagalvotų, kur esamame kode reikia padaryti pakeitimą.
• Studentas valdo įrankius, bet bejėgis prieš uždavinius. Jie gali sukonfigūruoti Vercel, sukurti React komponentą, paleisti Postgres duomenų bazę, supakuoti į Docker. Jie gali naudoti visą šiuolaikinį įrankių rinkinį. Paprašykite jų realizuoti quicksort. Tyla.
• Atskleidimas baigiamajame projekte. Baigiamasis kursas, momentas, kai sukauptas meistriškumas turi atnešti vaisių, vis dažniau tampa momentu, kai atskleidžiamas sukauptas meistriškumo trūkumas. Komandos, kurios užsiėmė vibe coding nuo CS1 iki trečio kurso, ateina į baigiamąjį projektą be gebėjimo projektuoti sistemą, be gebėjimo suskaidyti funkciją, be gebėjimo susitvarkyti su programavimo dalimis, kurias DI atlieka blogiausiai.

Pedagoginis sprendimas: Vertinti laisvą DI valdymą kaip realų įgūdį (ir priversti jį užsitarnauti)

Dėstytojai, kurie gerai tvarkosi su šiuo perėjimu, — tai ne tie, pas kuriuos griežčiausi DI draudimai. Tai tie, kurie perstatė savo kursus aplink aiškų atribojimą: DI — tai įrankis, kurį studentai turi išmokti naudoti gerai, IR studentai turi nepriklausomai demonstruoti kognityvinius įgūdžius, kuriuos atlieka DI. Šie du reikalavimai neprieštarauja vienas kitam — jie papildo vienas kitą, ir kursai, kurie daro tai teisingai, sukuria absolventus, kurie lenkia tiek vibe coder-ius, tiek grupes su DI draudimu.

Konkretūs dizaino modeliai, kuriuos matome veikiant programavimo kursuose 2026 metais:

• 1. Dvikryptė užduotis. Kiekviena užduotis turi dalį “solo” (be DI naudojimo, dažnai nedidelė dalis auditorijoje) ir dalį “įrankis” (DI leidžiamas, bet dokumentuojamas). Solo dalis atskleidžia tai, ką studentas iš tikrųjų gali daryti pats. Įrankio dalis moko jį daryti daugiau.
• 2. Laisvas DI valdymas kaip vertinama kompetencija. Studentai atiduoda užklausas, kurias naudojo, gautus atsakymus ir analizę, kur DI suklydo ar buvo neefektyvus. Kritinis DI išvesties skaitymas traktuojamas kaip kurso tikslas, o ne trumpiausias kelias.
• 3. Vertinimai tik iš klaidų šalinimo. Studentams duodamas veikiantis DI sugeneruotas kodas su subtiliomis klaidomis (off-by-one, neteisingas bazinis atvejis, trūkstamas null patikrinimas, saugumo spraga) ir vertinamas jų gebėjimas rasti bei ištaisyti jas. Tai treniruoja įgūdį, kurį DI atlieka blogiausiai ir kurį darbdaviai vertina labiausiai.
• 4. Griežtas proceso vertinimas. Privaloma kodo pakeitimų istorija (commit history), privalomi komentarai, dokumentuojantys sprendimus dėl dizaino, įrašyti paaiškinimai. Pats savaime kodo šaltinis nebeužima viso įvertinimo.
• 5. Gyvi techniniai pokalbiai. Trumpa, sustruktūruota žodinė dalis kiekvienai didelei užduočiai. Penkios minutės studentui, sufokusuotos į vieną–du diagnostinius klausimus. Pastangos realios; rezultatas puikus.
• 6. Verifikacija sistemos lygyje. Tokie įrankiai kaip Plagly.ai skenuoja darbus dėl DI generavimo modelių, stilistinio vienodumo grupės lygiu ir iteracinio kūrimo pėdsakų nebuvimo, kurį paprastai demonstruoja autentiškas studento darbas. Tai nėra įvertinimas; tai žymė, kuri išskiria darbus, vertus pokalbio konsultacijų valandomis.

Įrankių lygmuo, kuris daro tai praktiška

Didžiausias prieštaravimas modeliui aukščiau — logistinis. Realios klasės turi šimtus studentų; realūs dėstytojai neturi laiko skaityti kiekvieno darbo eilutė po eilutės, vykdyti žodinio gynimo kiekvienai užduočiai ar pastebėti grupinių modelių plika akimi. Įrankis turi atlikti pirminį nuskaitymą, kad žmogus galėtų pritaikyti savo vertinimą atvejams, kurie turi reikšmės.

Kaip tai atrodo praktikoje CS1 kohortai su 200 studentų:

• Automatinis darbų nuskaitymas: Kiekvienas įkeltas failas praeina DI aptikimą, kuris grąžina pasitikėjimo įvertinimą ir vėliavėles blokui. Plagly.ai atlieka šią analizę su 99% tikslumu GPT-5.5, Claude 4.6, Gemini 3.1 ir kituose pirmaujančiuose modeliuose, įskaitant specifinius kodo variantus, kuriuos teikia šie modeliai.
• Panelė grupės lygiu: Dėstytojas mato stilistinių modelių grupavimą grupėje. Kai aštuoni darbai turi vienodas idiomatiškas frazes, vienodą komentarų tankumą ir vienodą gynybinio kodo šabloną, ši grupė iškeliama peržiūrai.
• Kūrimo pėdsakas: Agentic Council iš Plagly.ai — septyni ekspertiniai modeliai, analizuojantys darbą remiantis rašymo kokybe, struktūra, DI aptikimu, originalumu ir nuoseklumu — sugeneruoja ataskaitą su nuorodomis. Ataskaita nekaltina akademiniu nesąžiningumu; ji dokumentuoja modelius, kuriuos dėstytojas gali ištirti.
• Tiksliniai pokalbiai konsultacijų valandomis: Studentai, kurių darbai buvo pažymėti, praeina penkių minučių žodinį patikrinimą. Didžioji dalis išsprendžiama greitai; nedidelė dalis tų, kurie ne, tampa atvejais, kuriais dėstytojas vadovaujasi išmintingai bei formaliai.

Esmė ne ta, kad pagauti kiekvieną pažeidėją. Esmė ta, kad išlaikyti mokymosi ciklą nepažeistą studentams, kurie nori mokytis. Klasė be verifikacijos — tai klasė, kur studentai, eksploatuojantys sistemą, nustato normą, o studentai, dirbantys sąžiningai, tampa pralaimėjusiais. Klasė su verifikacija — tai klasė, kur socialinė norma laikosi — užduotys vis tiek moko kažko, įvertinimai vis tiek kažką reiškia, o absolventai vis tiek gali programuoti.

18 mėnesių prognozė programavimo mokymui

Dauguma aktyvių programavimo dėstytojų, su kuriais kalbamės 2026 metais, dalijasi jausmu, kad dabartinė situacija yra neilgalaikė. Namų užduotys, kurios vertinamos per testų išlaikymą, struktūriškai nesuderinamos su autonominių programavimo įrankių egzistavimu. Kažkas turi nusileisti. Trys galimos kryptys pagal tikimybės didėjimą:

• Visiški DI draudimai: Kai kurios įstaigos bandys, ir didžioji dalis patirs nesėkmę. Draudimai yra neįgyvendinami, taisyklės tampa nenuoseklios, o studentai, kurie laikosi taisyklių, baigia studijas su mažesniais įgūdžiais nei tie, kurie ne. Tai blogiausias rezultatas iš abiejų pasaulių ir jau diskreditavo save keliuose universitetuose, kurie bandė tai 2023–2024 metais.
• Įgūdžių perslinkimas žemyn mokymo programoje: CS1 prasideda vėliau, su didesniu akcentu į konceptualius pagrindus. CS2 apima tai, ką anksčiau apėmė CS1. Pažengę kursai tampa labiau teoriniai, nes realizacijos dalis nebėra ta vieta, kur vyksta mokymasis. Tai vyksta, lėtai.
• Vertinimo perslinkimas į gyvas demonstracijas: Namų darbai tampa formuojantys. Galutiniai įvertinimai nustatomi gyvu programavimu su priežiūra, žodiniais gynimais ir griežtu procesiniu darbu. Tai kryptis, kurią jau pasirinko stipriausios CS programos, ir tai kryptis, kurioje, kaip mes tikime, galiausiai atsidurs dauguma programų.

Nė vienas iš šių scenarijų neišsprendžia klausimo, ką daryti šį semestrą su studentais, kuriuos turite. Tam praktiškas žingsnis yra hibridinis: išlaikykite jūsų dabartines užduotis, pridėkite verifikacijos lygmenį, kuris užfiksuoja blogiausius atvejus, pridėkite vieną ar du gyvus vertinimo komponentus kursui ir pradėkite lėtesnį darbą dėl mokymo programos perprojektavimo pasauliui, kur autonominis DI yra bazinė linija. Verifikacijos įrankis nuperka jums laiko mokymo programos perprojektavimui, neprarandant šios kohortos vibe coding tuo tarpu.

Dažnai užduodami klausimai

Ar vibe coding visada blogas, ar jis kartais teisėtas?

Jis teisėtas patyrusiems programuotojams, dirbantiems prie asmeninių projektų su žema rizika, kur klaidų kaina maža, ir programuotojas turi bazinį įgūdį rezultatui įvertinti, kai tai svarbu. Jis kenksmingas studentams, kurie vis dar kuria bazinį įgūdį, nes jis sutrumpina kognityvinį darbą, kurį programavimo mokymas turi vystyti. Skirtumas maždaug toks pat, kaip skirtumas tarp virtuvės šefo, užsisakančio maistą išsinešimui (visiškai normalu), ir kulinarinio fakulteto studento, užsisakančio maistą išsinešimui savo baigiamajam egzaminui (ne normalu). Abu variantai numato maisto gavimą, kurio jie negamino patys. Tik vienas sugriauna mokymąsi.

Ar studentai gali teigti, kad jie patys parašė kodą, aptiktą kaip DI?

Jie gali, ir kartais jie teisingi. Klaidingai teigiami rezultatai aptinkant kodą dažniausiai kyla tada, kai studentai rašo kodą labai vadovėliniu stiliumi, kuris atsitiktinai sutampa su modeliais, kuriuos paprastai generuoja DI. Darbo eiga, kurią galima apginti, nevertina aptikimo balo kaip nuosprendžio — ji vertina jį kaip atspirties tašką penkių minučių pokalbiui. Studentas, kuris parašė savo kodą, gali jį paaiškinti, modifikuoti jį vietoje ir sekti jo vykdymą. Studentas, kuris sugeneravo jį užklausa, beveik niekada negali. Pokalbis, o ne balas, — tai tai, kas išsprendžia klausimą. Plagly.ai ataskaitos sukurtos palaikyti šį pokalbį, o ne jį pakeisti.

Kaip DI aptikimas kodui skiriasi nuo DI aptikimo prozai?

Kodo aptikimas naudoja panašius statistinius pagrindus — perplexity, burstiness, stilometriniai parašai — bet taiko juos kitoms paviršiaus charakteristikoms. Kode labiausiai diagnostiniai signalai yra struktūriniai, o ne leksiniai: kintamųjų įvardijimo modeliai, komentarų tankumas bei stilius, idiomatinis bibliotekų pasirinkimas, klaidų apdorojimo šablonai ir idiomatinis konstrukcijų pasirinkimas. Aukštesnio lygio daugiamodeliai detektoriai pasiekia 90-95% tikslumą atskiruose kodo darbuose 2026 metais ir pakyla žymiai virš 95%, kai modelių analizė grupės lygiu sujungiama su vertinimu failo lygiu.

Kaip dėl studentų, kurie teisėtai naudoja DI kaip tutorių be jo išvesties kopijavimo?

Tai grupė, kuriai verifikacijos lygmuo buvo sukurtas taip, kad nebaustų. Studentas, kuris naudojo DI koncepcijos supratimui, o po to parašė savo sprendimą, sukurs kodą, kuris nesutampa su DI generavimo modeliais eilučių lygyje. Aptikimo signalas fiksuoja rezultatą, o ne tyrimo procesą. Jei jūsų kurso politika leidžia DI kaip tutorių — ir mes manome, kad taip turi būti — darbo eiga tęsiasi. Jūs kontroliuojate darbą, o ne studento mokymosi metodą.

Ar tai veikia projektiniams kursams ir baigiamiesiems darbams?

Taip, su korekcija. Kelių savaičių, kelių failų projektams labiausiai naudingi signalai persikelia į proceso autentiškumą: kodo pakeitimų istorijos analizė (ar kodas atsirado viename dideliame kodo pakeitime, ar vystėsi laikui bėgant?), autorystės konsistencija tarp failų (ar kodo bazė skaitosi taip, lyg ją rašė vienas žmogus, ar ji atrodo kaip susiūti lopai?) ir dizaino sprendimų dokumentavimas (ar studentas gali paaiškinti, kodėl buvo pasirinktas konkretus architektūros pasirinkimas?). Baigiamieji projektai gauna didžiausią naudą iš struktūruoto žodinio gynimo plius rašytinio dizaino pagrindimo, su DI aptikimu kaip tretiniu signalu, o ne pagrindiniu.