Vibe coding krīze: kāpēc datorzinātņu absolventi vairs nemāk programmēt bez DI

„Reddit“ pavedienā 2026. gada martā, kas ātri pārsniedza 8 000 pozitīvu vērtējumu (upvotes), vecākais inženieris no „Series-B“ jaunuzņēmuma publicēja ekrānuzņēmumus no mājas uzdevuma, kuru viņš tikko bija noraidījis. Kandidāts, kurš nesen absolvēja CS studijas ar 3.9 vidējo vērtējumu no cienījamas programmas, nosūtīja kodu, kas ideāli darbojās veiksmīgajā scenārijā (happy path), bet klusi sabojāja datus pie katra robežgadījuma (edge case). Kad kandidātam lūdza izskaidrot loģiku nākamā zvana laikā, viņš nespēja izskaidrot, kāpēc viena no viņa paša funkcijām izmanto rekursiju. Rindiņa, kas lika pavedienam uzsprāgt, bija viņa godīgā atbilde: “Es vienkārši pateicu Claude, ko mums vajag, un tas to uzrakstīja. Es parasti lasu kodu tikai tad, ja tas nedarbojas.”

Tā ir „vibe coding“ krīze, un 2026. gadā tā ir migrējusi no programmētāju „Twitter“ uz darbā pieņemšanas procesiem, vērtējumiem pēc intervijām un arvien biežāk uz CS katedru vadītāju kabinetiem, kuri mēģina saprast, kas tieši noticis ar viņu absolventiem. Terminu ieviesa Andrejs Karpatijs 2025. gada februārī, aprakstot jaunu pozitīvu darba veidu ar LLM — jūs aprakstāt savu nodomu, pieņemat to, ko izveido modelis, un nosūtāt. Gada laikā tā pati frāze kļuva par nozares etiķeti programmētāju paaudzei, kas spēj brīvi rakstīt vaicājumus, bet nespēj izskaidrot, ko patiesībā dara viņu kods.

Programmēšanas pasniedzējiem tā nav hipotētiska problēma par darba nākotni. Tā ir asa mūsdienu pedagoģiskā krīze par studentiem, kurus jūs izlaižat tieši tagad. Šajā rakstā aplūkots, ko patiesībā rāda pētījumi un lauka ziņojumi par MI izraisītu prasmju atrofiju, kāpēc kursi no CS1 līdz baigajiem projektiem ir unikāli paaugstināta riska zonā, un kā neliela, bet augoša pasniedzēju grupa pārkārto savus kursus, lai garantētu, ka studenti absolvē ar spēju programmēt — nevis vienkārši ar spēju rakstīt vaicājumus.

Ko patiesībā nozīmē „vibe coding“ (un kāpēc Karpatijs teica, ka tam jābūt jautram)

Oriģinālais Karpatija formulējums bija specifisks. Vibe coding nozīmēja pieņemt faktu, ka programmēšana personīgajiem projektiem tagad var justies kā radoša spēle: jūs sakāt modelim, ko vēlaties, tas izveido kodu, jūs koriģējat vaicājumu koda vietā un nododat kaut ko strādājošu. Viņš tieši atzīmēja, ka vairs nelasa kodu rindiņu pa rindiņai saviem blakus projektiem. Formulējums bija par prieku, produktivitāti un pamatotu novērojumu, ka mazāk svarīgiem vienreizējiem projektiem rūpīga manuāla analīze ir pārmērīga.

Vēlāk termins izplatījās plašākā jomā, kur tas nolaidās divos ļoti atšķirīgos kontekstos:

• Vecākie inženieri, kuri to izmanto apzināti: Skatās uz MI uzģenerēto kodu kā uz melnrakstu, lasa un pārkārto to pirms koda pakeša (commit), izmanto MI, lai izvairītos no rutīnas šablonu koda rakstīšanas, bet piemēro desmitgadēm uzkrāto modeļu atpazīšanu rezultāta vērtēšanai. Tas ir tas, ko aprakstīja Karpatijs, un tas darbojas.
• Jaunākie inženieri un studenti, kuri to pieņem kā noklusēto režīmu: Skatās uz MI uzģenerēto kodu kā uz galīgo rezultātu, pieņem to bez lasīšanas, novērš kļūdas tikai tad, ja testi neiziet, vēršas pie vecākā kolēģa vai pasniedzēja tikai tad, ja MI nespēj izlabot savu kodu. Tas ir tas, ko Karpatijs neaprakstīja, un tas nedarbojas.

Pedagoģiskā problēma — tā ir otrā grupa, un tie veido lielāko daļu studentu, kuri sāk mācīties CS programmās 2026. gadā. Pats Karpatijs atkāpās no sava formulējuma 2025. gada beigās, norādot, ka vibe coding ir jēga ekspertiem asinsrites projektos, bet ir bīstams visiem pārējiem.

Prasmju atrofija reālos skaitļos

Pierādījumi šobrīd ir smagi, un tie visi norāda vienā virzienā. „CodeRabbit“ 2025. gada decembra analīze, kas izpētīja pull requests simtiem projektu ar atvērtu kodu, atklāja, ka kods, kas uzrakstīts kopā ar ģeneratīvo MI, saturēja aptuveni 1,7 reizes vairāk “lielu” problēmu nekā cilvēka uzrakstītais kods. Loģiskās kļūdas (nepareizas atkarības, defektīva izpildes kontrole) un drošības sprāgas bija ievērojami palielinājušās, drošības caurumiem parādoties 2,74 reizes biežāk, salīdzinot ar kodu, ko radījis tikai cilvēks.

„TechSpot“ atskaite 2025. gada beigās aptaujāja profesionālus programmētājus par kognitīvajiem efektiem, ko izraisījuši piespiedu vibe coding darba procesi. Kopējais reģistrētais modelis: ilgāks kļūdu novēršanas laiks, samazināta spēja prātā simulēt koda izpildi un novājināts instinkts, kā jāizskatās ražošanas kvalitātes kodam. Viens programmētājs aprakstīja savu pieredzi pēc sešiem mēnešiem darba vibe-first režīmā kā pilnīgu „muskuļu atmiņas“ zudumu problēmu risināšanai.

Visspilgtākā ilustrācija nāca no programmētāja, kurš veica 30 dienu eksperimentu 2026. gada sākumā: nekādas MI palīdzības mēnesi, bet pēc tam refleksija par atšķirību. Raksts dev.to ar nosaukumu I Coded Without AI for 30 Days: The Results Were Embarrassing kļuva par vienu no populārākajām tā laika programmētāju esejām. Galvenais rezultāts: aktīvs vecākais inženieris ar astoņu gadu pieredzi vairs nevarēja no atmiņas uzrakstīt vienkāršu binārā koka apstaigāšanu (binary tree traversal). Prasme tika atdota ārpakalpojumā un pēc tam klusi izdzisa.

Ja aktīvam vecākajam inženierim kļūdu novēršanas muskulis atrofē dažu mēnešu laikā pēc atkarības no MI, iedomājieties CS1 studenta trajektoriju, kuram nekad šī muskuļa nav bijis pašā sākumā — kura visa programmēšanas pieredze tika nodrošināta caur LLM, kas sniedz strādājošu risinājumu desmit sekundes pēc uzdevuma formulējuma apskates.

Kāpēc programmēšanas mācīšana ir unikāli paaugstināta riska zonā?

Citas disciplīnas ar MI izglītībā saskaras ne ideāli, bet lielākajai daļai no tām joprojām ir iebūvēti vērtēšanas karkasi. Literatūras studentam joprojām var lūgt apspriest fragmentu seminārā. Ķīmijas studentam joprojām var lūgt veikt procedūru laboratorijā. Matemātikas studentam joprojām var lūgt izvest pierādījumu pie tāfeles. Programmēšanas mācīšanai nav neviena no šiem iebūvētajiem vērtēšanas režīmiem. Gandrīz katrs programmēšanas uzdevums — tas ir mājasdarbs, kas tiek vērtēts pēc tā, vai kods iziet testus — bet MI 2026. gadā iziet šos testus neticami viegli.

Tas rada trīs paaugstinātus riska faktorus, kas ir specifiski programmēšanai:

• Uzdevuma-testa cikls ir pilnībā automatizēts. „Codex“, „Claude Code“ un „Cursor“ lasa uzdevumu, raksta kodu, palaiž testus, maina kodu kļūdu gadījumā un nodod strādājošu risinājumu. Pilns cikls, ko sagaida no studenta — saprast prasības, izstrādāt risinājumu, realizēt to, novērst kļūdas — var tikt veikts ar MI ātrāk, nekā students izlasīs specifikāciju.
• Personīgais vērtējums ir loģistiski dārgs. CS1 klase ar 200 studentiem nevar reāli nodrošināt piecu minūšu mutisku aizstāvēšanu katram uzdevumam, nesadedzinot divdesmit stundas pasniedzēja palīgu laika vienā uzdevumu ciklā. Lielo CS kursu ekonomiskais modelis paredz asinhronu mājasdarbu vērtēšanu.
• Norakstīšana studentam ir neredzama. Students, kurš kopē eseju, zina, ka noraksta. Students, kurš raksta vaicājumus MI problēmas risināšanai, var neuzskatīt to par norakstīšanu — sociālā norma ir mainījusies ātrāk par noteikumiem, un darbība šķiet līdzīga informācijas meklēšanai „Google“. Kad tie sasniedz baigo kursu un tiem jādomā pašiem, tie ir pavadījuši četrus gadus bez attiecīgo prasmju veidošanas.

Rezultāts ir vērtēšanas ķēde, kas rada studentus ar diplomiem, kuri vairs nekorelē ar prasmēm. Darbā pieņemšanas vadītāji 2026. gadā arvien biežāk apej dzīvesgaitas aprakstus un vidējo vērtējumu par labu dzīvajam tehniskajam vērtējumam tieši tāpēc, ka diplomu sistēma izrādījusies atrauta no bāzes spējām.

Kā „nekā neiemācīšanās“ izskatās CS konsultāciju stundās

Ja mācāt programmēšanu, droši vien esat redzējuši šo modeli, pat ja vēl neesat to nosaukuši. Mēs apkopojām biežāk sastopamos diagnostiskos signālus no pasniedzējiem CS1, datu struktūrās un baigo projektu klasēs 2025. gada beigās un 2026. gada sākumā.

• Students nevar atrast savu kļūdu. Darbs nodots un darbojās ideāli. Jauns unit tests piedzīvo neveiksmi. Students atver failu, skatās uz kodu tā, it kā redzētu to pirmo reizi, ritina uz augšu un uz leju bez jebkādas hipotēzes un galu galā saka: “Es vienkārši pajautāšu Claude, kas par vainu.” Pirmā reakcija uz nesekmīgu testu — vēršanās pie MI, nevis hipotēzes veidošana.
• Students nevar atbildēt „kāpēc“. Pajautājot “kāpēc jūs šeit izmantojāt hash map, nevis array,” atbilde skan kā “tas ir tas, ko ieteica MI.” Izvēle tika izdarīta; loģika aiz tās nekad netika apgūta. Zem koda nav kognitīvā modeļa.
• Students nevar veikt nelielu variāciju. “Modificējiet to tā, lai tas apstrādātu arī negatīvos skaitļus” jābūt trīsdesmit sekunžu rediģēšanai. No MI atkarīgam studentam tas pārvēršas piecu minūšu vaicājumu sesijā, jo viņiem jāievada ierobežojums modelī, nevis jāpadomā, kur esošajā kodā jāveic izmaiņas.
• Students pārvalda rīkus, bet ir bezpalīdzīgs pret uzdevumiem. Tie var konfigurēt Vercel, izveidot React komponentu, palaist Postgres datubāzi, iepakot Docker. Tie var izmantot visu mūsdienu rīku klāstu. Palūdziet tiem realizēt quicksort. Klusums.
• Atklāšana baigajā projektā. Pēdējais kurss, brīdis, kad uzkrātajai meistarībai jānes augļi, arvien biežāk kļūst par brīdi, kad tiek atklāts uzkrātās meistarības trūkums. Komandas, kas nodarbojās ar vibe coding no CS1 līdz trešajam kursam, nāk uz baigo projektu bez spējas izstrādāt sistēmu, bez spējas sadalīt funkciju, bez spējas tikt galā ar programmēšanas daļām, kuras MI veic vissliktāk.

Pedagoģiskais risinājums: Vērtēt brīvu MI pārvaldību kā reālu prasmi (un likt to nopelnīt)

Pasniedzēji, kuri labi tiek galā ar šo pāreju, — tie nav tie, pie kuriem ir visbargākie MI aizliegumi. Tie ir tie, kuri pārstatīja savus kursus ap skaidru nodalījumu: MI — tas ir rīks, kuru studentiem jāiemācās izmantot labi, UN studentiem neatkarīgi jādemonstrē kognitīvās prasmes, kuras veic MI. Šīs divas prasības nav pretrunā viena otrai — tās papildina viena otru, un kursi, kas to dara pareizi, rada absolventus, kuri apsteidz gan vibe coder-us, tie gan grupas ar MI aizliegumu.

Konkrēti dizaina modeļi, kurus redzam strādājam programmēšanas kursos 2026. gadā:

• 1. Divvirzienu uzdevums. Katram uzdevumam ir daļa “solo” (bez MI izmantošanas, bieži vien neliela daļa auditorijā) un daļa “rīks” (MI atļauts, bet tiek dokumentēts). Solo daļa atklāj to, ko students patiešām spēj darīt pats. Rīka daļa māca viņu darīt vairāk.
• 2. Brīva MI pārvaldība kā vērtējama kompetence. Studenti nodod vaicājumus, kurus izmantoja, saņemtās atbildes un analīzi, kur MI kļūdījās vai bija neefektīvs. Kritiska MI izvades lasīšana tiek traktēta kā kursa mērķis, nevis īsākais ceļš.
• 3. Vērtējumi tikai no kļūdu novēršanas. Studentiem tiek dots strādājošs MI uzģenerēts kods ar smalkām kļūdām (off-by-one, nepareizs bāzes gadījums, trūkstoša null pārbaude, drošības sprāga) un tiek vērtēta viņu spēja tās atrast un izlabot. Tas trenē prasmi, kuru MI veic vissliktāk un kuru darba devēji vērtē visaugstāk.
• 4. Stingrs procesa vērtējums. Obligāta koda izmaiņu vēsture (commit history), obligāti komentāri, kas dokumentē lēmumus par dizainu, ierakstīti paskaidrojumi. Pats par sevi koda avots vairs neaizņem visu vērtējumu.
• 5. Dzīvās tehniskās sarunas. Īsa, strukturēta mutiskā daļa katram lielam uzdevumam. Piecas minūtes studentam, koncentrētas uz vienu–diviem diagnostiskiem jautājumiem. Pūles ir reālas; rezultāts lielisks.
• 6. Verifikācija sistēmas līmenī. Tādi rīki kā Plagly.ai skenē darbus pret MI ģenerēšanas modeļiem, stilistisko vienveidību grupas līmenī un iteratīvās izstrādes pēdu trūkumu, ko parasti demonstrē autents studenta darbs. Tas nav vērtējums; tā ir zīme, kas izceļ darbus, kuri vērti sarunas konsultāciju stundās.

Rīku līmenis, kas padara to praktisku

Lielākais iebildums modelim augstāk — loģistiskais. Reālām klasēm ir simtiem studentu; reāliem pasniedzējiem nav laika lasīt katru darbu rindiņu pa rindiņai, veikt mutisko aizstāvēšanu katram uzdevumam vai pamanīt grupu modeļus ar neapbruņotu aci. Rīkam jāveic sākotnējā noskenēšana, lai cilvēks varētu piemērot savu vērtējumu gadījumiem, kuriem ir nozīme.

Kā tas izskatās praksē CS1 kohortai ar 200 studentiem:

• Automātiska darbu noskenēšana: Katrs augšupielādētais fails iziet MI noteikšanu, kas atgriež uzticības novērtējumu un karodziņus blokam. Plagly.ai veic šo analīzi ar 99% precizitāti GPT-5.5, Claude 4.6, Gemini 3.1 un citos vadošajos modeļos, ieskaitot specifiskos koda variantus, kurus sniedz šie modeļi.
• Skydelis grupas līmenī: Pasniedzējs redz stilistisko modeļu grupēšanos grupā. Kad astoņi darbi satur vienādas idiomātiskas frāzes, vienādu komentāru blīvumu un vienādu aizsardzības koda šablonu, šī grupa tiek izcelta pārskatīšanai.
• Izstrādes pēdas: Agentic Council no Plagly.ai — septiņi ekspertu modeļi, kas analizē darbu, balstoties uz rakstīšanas kvalitāti, struktūru, MI noteikšanu, oriģinalitāti un konsekvenci — uzģenerē atskaiti ar atsaucēm. Atskaite neapsūdz akadēmiskajā negodīgumā; tā dokumentē modeļus, kurus pasniedzējs var izpētīt.
• Mērķtiecīgas sarunas konsultāciju stundās: Studenti, kuru darbi tika atzīmēti, iziet piecu minūšu mutisko pārbaudi. Lielākā daļa tiek atrisināta ātri; neliela daļa to, kas nē, kļūst par gadījumiem, kuros pasniedzējs vadās prātīgi un formāli.

Būtība nav tajā, lai noķertu katru pārkāpēju. Būtība ir tajā, lai saglabātu mācīšanās ciklu neskartu studentiem, kuri vēlas mācīties. Klase bez verifikācijas — tā ir klase, kur studenti, kas ekspluatē sistēmu, nosaka normu, bet studenti, kas strādā godīgi, kļūst par zaudētājiem. Klase ar verifikāciju — tā ir klase, kur sociālā norma turas — uzdevumi joprojām kaut ko māca, vērtējumi joprojām kaut ko nozīmē, bet absolventi joprojām prot programmēt.

18 mēnešu prognoze programmēšanas mācīšanai

Lielākā daļa aktīvo programmēšanas pasniedzēju, ar kuriem runājam 2026. gadā, dalās ar sajūtu, ka pašreizējā situācija ir neilgtspējīga. Mājas uzdevumi, kas tiek vērtēti pēc testu iziešanas, ir strukturāli nesaderīgi ar autonomu programmēšanas rīku eksistenci. Kaut kam ir jāpiekāpjas. Trīs iespējamie virzieni pēc varbūtības pieauguma:

• Pilnīgi MI aizliegumi: Dažas iestādes mēģinās, un lielākā daļa piedzīvos neveiksmi. Aizliegumi ir neīstenojami, noteikumi kļūst nekonsekventi, bet studenti, kuri ievēro noteikumus, absolvē ar mazākām prasmēm nekā tie, kuri nē. Tas ir sliktākais rezultāts no abām pasaulēm un jau diskreditējis sevi vairākās universitātēs, kas to mēģināja 2023.–2024. gadā.
• Prasmju novirzīšanās uz leju mācību programmā: CS1 sākas vēlāk, ar lielāku uzsvaru uz konceptuālajiem pamatiem. CS2 aptver to, ko agrāk aptvēra CS1. Padziļinātie kursi kļūst teorētiskāki, jo realizācijas daļa vairs nav tā vieta, kur notiek mācīšanās. Tas notiek, lēnām.
• Vērtēšanas novirzīšanās uz dzīvajām demonstrācijām: Mājas darbi kļūst formējoši. Galīgie vērtējumi tiek noteikti ar dzīvo programmēšanu uzraudzībā, mutiskām aizstāvēšanām un stingru procesa darbu. Tas ir virziens, kuru jau izvēlējušās spēcīgākās CS programmas, un tas ir virziens, kurā, kā mēs ticam, galu galā nonāks lielākā daļa programmu.

Neviens no šiem scenārijiem neatrisina jautājumu, ko darīt šajā semestrī ar studentiem, kuri jums ir. Tam praktiskais solis ir hibrīds: saglabājiet jūsu pašreizējos uzdevumus, pievienojiet verifikācijas līmeni, kas fiksē sliktākos gadījumus, pievienojiet vienu vai divus dzīvos vērtēšanas komponentus kursam un sāciet lēnāku darbu pie mācību programmas pārveides pasaulei, kur autonomais MI ir bāzes līnija. Verifikācijas rīks nopērk jums laiku mācību programmas pārveidei, nezaudējot šo kohortu vibe coding tajā pašā laikā.

Biežāk uzdotie jautājumi

Vai vibe coding vienmēr ir slikts, vai tas ir reizēm leģitīms?

Tas ir leģitīms pieredzējušiem programmētājiem, strādājot pie personīgajiem projektiem ar zemu risku, kur kļūdu izmaksas ir mazas, un programmētājam ir bāzes prasme rezultāta vērtēšanai, kad tas ir svarīgi. Tas ir kaitīgs studentiem, kuri joprojām veido bāzes prasmi, jo tas saīsina kognitīvo darbu, kuru programmēšanas mācīšanai jāattīsta. Atšķirība ir aptuveni tāda pati kā atšķirība starp virtuves šefpavāru, kurš pasūta ēdienu uz mājām (pilnīgi normāli), un kulinārijas fakultātes studentu, kurš pasūta ēdienu uz mājām savam baigajam eksāmenam (nav normāli). Abi varianti paredz ēdiena saņemšanu, kuru tie negatavoja paši. Tikai viens sagrauj mācīšanos.

Vai studenti var apgalvot, ka viņi paši uzrakstīja kodu, kas noteikts kā MI?

Tie var, un reizēm tiem ir taisnība. Kļūdaini pozitīvi rezultāti, nosakot kodu, visbiežāk rodas tad, kad studenti raksta kodu ļoti mācību grāmatu stilā, kas nejauši sakrīt ar modeļiem, kurus parasti ģenerē MI. Darba gaita, kuru var aizstāvēt, nevērtē noteikšanas vērtējumu kā spriedumu — tā vērtē to kā sākumpunktu piecu minūšu sarunai. Students, kurš uzrakstīja savu kodu, var to izskaidrot, modificēt to uz vietas un sekot tā izpildei. Students, kurš to uzģenerēja ar vaicājumu, gandrīz nekad nevar. Saruna, nevis vērtējums, — tas ir tas, kas atrisina jautājumu. Plagly.ai atskaites ir izveidotas, lai atbalstītu šo sarunu, nevis to aizstātu.

Kā MI noteikšana kodam atšķiras no MI noteikšanas prozai?

Koda noteikšana izmanto līdzīgus statistiskos pamatus — perplexity, burstiness, stilometriskie paraksti — bet piemēro tos citām virsmas raksturlielumiem. Kodā visvairāk diagnostiskie signāli ir strukturālie, nevis leksiskie: mainīgo nosaukumu modeļi, komentāru blīvums un stils, idiomātiskā bibliotēku izvēle, kļūdu apstrādes šabloni un idiomātiskā konstrukciju izvēle. Augstākā līmeņa daudzmodeļu detektori sasniedz 90-95% precizitāti atsevišķos koda darbos 2026. gadā un paceļas ievērojami virs 95%, kad modeļu analīze grupas līmenī tiek apvienota ar vērtējumu faila līmenī.

Kā ar studentiem, kuri leģitīmi izmanto MI kā tutoru bez tā izvades kopēšanas?

Tā ir grupa, kurai verifikācijas līmenis tika izveidots tā, lai nesodītu. Students, kurš izmantoja MI koncepcijas izpratnei un pēc tam uzrakstīja savu risinājumu, izveidos kodu, kas nesakrīt ar MI ģenerēšanas modeļiem rindiņu līmenī. Noteikšanas signāls fiksē rezultātu, nevis izpētes procesu. Ja jūsu kursa politika atļauj MI kā tutoru — un mēs uzskatām, ka tā tam jābūt — darba gaita turpinās. Jūs kontrolējat darbu, nevis studenta mācīšanās metodi.

Vai tas darbojas projektveida kursiem un baigajiem darbiem?

Jā, ar korekciju. Vairāku nedēļu, vairāku failu projektiem visnoderīgākie signāli pārvietojas uz procesa autentiškumu: koda izmaiņu vēstures analīze (vai kods parādījās vienā lielā izmaiņā, vai attīstījās laika gaitā?), autorības konsekvence starp failiem (vai koda bāze lasās tā, it kā to būtu rakstījis viens cilvēks, vai tā izskatās kā sašūti ielāpi?) un dizaina lēmumu dokumentēšana (vai students var izskaidrot, kāpēc tika izvēlēta konkrēta arhitektūras izvēle?). Baigie projekti gūst vislielāko labumu no strukturētas mutiskās aizstāvēšanas plus rakstiska dizaina pamatojuma, ar MI noteikšanu kā terciāro signālu, nevis galveno.