Vibe-koodauskriisi: Miksi CS:stä valmistuneet eivät voi enää koodata ilman tekoälyä?

Maaliskuussa 2026 julkaistussa Reddit-ketjussa, joka keräsi nopeasti yli 8 000 upvote-ääntä, Series-B-vaiheen startupin senior-ohjelmoija jakoi kuvakaappauksia hylkäämästään kotitehtävähaastattelusta. Hakija, vastavalmistunut CS-kandidaatti ankkuroituna 3,9:n GPA:han arvostetusta ohjelmasta, oli palauttanut koodia, joka toimi täydellisesti kaikkein perustavanlaatuisimmassa tapauksessa (happy path), mutta hiljaa korruptoi dataa jokaisessa kantatilanteessa (edge case). Kun hakijaa pyydettiin selittämään logiikkaa seuranneessa puhelussa, hän ei osannut kertoa, miksi yksi hänen omista funktioistaan käytti rekursiota. Koko ketjun pysäyttänyt lause oli hänen rehellinen vastauksensa: „Pyysin vain Claudea kirjoittamaan sen mitä tarvitsimme, ja se teki tämän. Luen koodia yleensä vain silloin, jos se ei toimi.“

Tämä on „vibe codingin“ kriisi, ja vuoteen 2026 mennessä se on siirtynyt kehittäjien Twitteristä HR-pipelineihin, rekrytointikeskusteluihin ja yhä useammin tietojenkäsittelyn osastojen johtajien pöydille, jotka yrittävät selvittää, mitä heidän valmistuneilleen on juuri tapahtunut. Termi on Andrej Karpathyn helmikuussa 2025 luoma kuvaamaan uutta positiivista tapaa työskennellä: kuvaile tavoitteesi, hyväksy mallin tuotos, julkaise. Vuoden kuluessa samasta ilmaisusta tuli alan vakiintunut nimitys sille kehittäjäsukupolvelle, joka osaa prompata sujuvasti mutta ei pysty rännikseen hahmottamaan, mitä heidän koodinsa todellisuudessa tekee.

Ohjelmoinnin opettajille tämä ei ole hypotetinen ongelma työn tulevaisuudesta. Se on akuutti pedagoginen hätätilanne nykyhetkessä niiden opiskelijoiden kohdalla, joita valmistatte juuri nyt. Tässä artikkelissa tarkastellaan, mitä tutkimukset ja käytännön raporteista saatu näyttö todella osoittavat tekoälyn aiheuttamasta taitojen atrofiasta, miksi kurssit perusteista (CS1) aina lopputöihin saakka ovat erityisen haavoittuvia ja miten pieni mutta kasvava ryhmä opettajia omistaa fag-suunnittelunsa uudelleen varmistaakseen, että opiskelijat osaavat valmistuttuaan koodata — eivätkä vain prompata.

Mitä „vibe coding“ todella tarkoittaa (ja miksi Karpathy sanoi, että sen pitäisi olla hauskaa)

Karpathyn alkuperäinen muotoilu oli tarkka. Vibe coding tarkoitti sen hyväksymistä, että ohjelmointi henkilökohtaisissa projekteissa voisi nyt tuntua luovalta leikiltä: kerrot mallille mitä haluat, se tuottaa koodia, säädät mieluummin kehotetta kuin koodia ja julkaiset jotakin toimivaa. Hän totesi nimenomaisesti, ettei hän enää lukenut koodia linja linjalta omissa sivuprojekteissaan. Muotoilu liittyi iloon, tuottavuuteen ja siihen perusteltuun havaintoon, että vähäpätöisessä kertakoodissa huolellinen manuaalinen tarkistus on yksinkertaisesti turhaa.

Termi levisi sen jälkeen laajemmalle alalle ja päätyi kahteen hyvin erilaiseen kontekstiin:

• Senioritason kehittäjät, jotka käyttävät sitä tietoisesti: Kohtelevat tekoälyn luomaa koodia alustavana luonnoksena, lukevat ja refaktoroivat sen ennen commitia, ja käyttävät tekoälyä välttääkseen rutiinikoodia, mutta soveltavat vuosikymmenten mønsterintunnistusta tuotoksen arviointiin. Tämä oli se, mitä Karpathy kuvaili, ja se toimii.
• Junioritason kehittäjät ja opiskelijat, jotka ottavat sen oletusarvokseen: Kohtelevat tekoälyn luomaa koodia valmiina artefaktina, hyväksyvät sen lukematta, tekevät vianmääritystä vain testien epäonnistuessa ja tukeutuvat senioriin tai opettajaan vasta kun tekoäly ei pysty korjaamaan omaa tuotostaan. Tämä ei ollut sitä, mitä Karpathy kuvaili, eikä se toimi.

Pedagoginen ongelma on tämä toinen ryhmä, ja he muodostavat enemmistön tietojenkäsittelyn ohjelmiin vuonna 2026 aloittavista opiskelijoista. Karpathy itse perääntyi muotoilustaan myöhemmin vuonna 2025 huomauttaen, että vibe coding on järkevää asiantuntijoille omissa projekteissaan, mutta se on myrkyllistä kaikille muille.

Osaamisen heikkeneminen reelleinä lukuina

Näyttö tästä on nyt merkittävää, ja se osoittaa yhteen suuntaan. CodeRabbitin joulukuussa 2025 julkaisema analyysi, joka tutki pull requesteja sadoissa avoimen lähdekoodin repositorioissa, totesi, että generatiivisen tekoälyn kanssa kirjoitettu koodi sisälsi noin 1,7-kertaisesti enemmän „vakavia“ ongelmia kuin puhtaasti ihmisen kirjoittama koodi. Logiikkavirheet (virheelliset riippuvuudet, virheellinen ohjausvirta) ja tietoturva-aukot olivat molemmat merkittävästi koholla, ja tietoturvavirheitä esiintyi 2,74-kertainen määrä ihmisen kirjoittamaan koodiin verrattuna.

TechSpotin raportti loppuvuodesta 2025 kysyi aktiivisilta kehittäjiltä pakotettujen vibe coding -työnkulkujen kognitiivisista vaikutuksista. Yleinen raportoitu kaava: kasvanut vianmääritysaika, heikentynyt kyky simuloida koodia mentaalisesti omassa päässä ja heikentynyt intuitio siitä, miltä tuotantolaatuinen koodi todellisuudessa näyttää. Eräs kehittäjä kuvaili kokemustaan kuuden kuukauden vibe-first-työn jälkeen kokonaan „ongelmanratkaisun lihasmuistin katoamiseksi“.

Selkein esimerkki saatiin kehittäjältä, joka suoritti 30 päivän kokeilun vuoden 2026 alussa: ei tekoälyapua kuukauteen, ja sen jälkeen pohdinta erosta. Kirjoituksesta dev.to-sivustolla, I Coded Without AI for 30 Days: The Results Were Embarrassing, tuli yksi vuoden jaetuimmista kehittäjäesseistä. Tärkein havainto: kahdeksan vuoden kokemuksella toimiva senior-kehittäjä ei enää pystynyt kirjoittamaan yksinkertaista binääripuun läpikäyntiä (binary tree traversal) suoraan muistista. Taito oli ulkoistettu ja sen jälkeen hiljaisesti kuihtunut.

Jos kokeneen senior-kehittäjän vianmäärityslihas surkastuu muutamassa kuukaudessa tekoälyriippuvuuden myötä, kuvittele polku CS1-opiskelijalle, jolle ei ole koskaan edes ehtinyt muodostua tuota lihasta — jonka koko kokemus ohjelmoinnista on kulkenut sellaisen LLM-mallin läpi, joka antaa toimivan ratkaisun kymmenessä sekunnissa ongelman näkemisen jälkeen.

Miksi ohjelmointikoulutus on poikkeuksellisen haavoittuvaa

Muut tieteenalat selviytyvät tekoälystä opetuksessa vaihtelevasti, mutta useimmilla on edelleen ehjät arviointikehykset. Kirjallisuuden opiskelijaa voidaan edelleen pyytää keskustelemaan tekstistä seminaarissa. Kemian opiskelijaa voidaan pyytää tekemään laboratoriotyö. Matematiikan opiskelijaa voidaan pyytää johtamaan kaava tavalla tai toisella liitutaululla. Ohjelmointiopetuksessa ei ole mitään näistä ehjistä arviointitavoista. Lähes jokainen ohjelmointitehtävä on kotitehtävä, joka arvioidaan sen mukaan, läpäiseekö koodi testit — ja vuoden 2026 tekoäly läpäisee nuo testit triviaalisti.

Tämä luo kolme sähköistä ja ohjelmointikohtaista haavoittuvuutta:

• Tehtävä-testi-silmukka on täysin automatisoitavissa. Codex, Claude Code ja Cursor lukevat tehtävän, kirjoittavat koodin, ajavat testit, iteroivat virheiden yli ja palauttavat toimivan ratkaisun. Koko se sykli, joka opiskelijan kuuluisi suorittaa — ymmärtää vaatimukset, suunnitella ratkaisu, toteuttaa se ja fejlsöge se — tapahtuu tekoälyllä nopeammin kuin opiskelija ehtii edes lukea tehtävänkuvauksen.
• Live-arviointi on logistisesti kallista. 200 opiskelijan CS1-kurssilla ei voida realistisesti suorittaa viiden minuutin suullista puolustusta jokaisesta tehtävästä ilman, että assistenttien aikaa palaa kymmeniä tunteja tehtäväsykliä kohden. Suurten CS-kurssien talousmalli olettaa asynkronisen kotitehtäväarvioinnin.
• Sääntöjen vastaisuus on näkymätöntä opiskelijalle itselleen. Esseetä kopioiva opiskelija tietää tekevänsä väärin. Opiskelija, joka prompaa tekoälyä ratkaisemaan tehtävän, ei ehkä koe sitä huijaamisena — sosiaalinen normi on muuttunut nopeammin kuin säännöt, ja toiminta tuntuu samalta kuin tiedon etsiminen. Kun he saavuttavat viimeisen vuoden ja heidän pitäisi ajatella itse, he ovat viettäneet neljä vuotta rakentamatta mitään merkityksellistä osaamista.

Tuloksena on valmistumisputki, joka tuottaa opiskelijoita, joiden tutkintotodistukset eivät enää korreloi osaamisen kanssa. Vuonna 2026 rekrytoijat ohittavat yhä useammin CV:t ja arvosanat live-koodaustestien eduksi, juuri siksi, että tutkintojärjestelmä on irronnut alla olevasta kyvykkyydestä.

Miltä „oppimisen puute“ näyttää vastaanotolla

Jos undervisoit ohjelmointia, olet varmasti nähnyt tämän mønsterin, vaikka et ehkä olisi vielä nimennyt sitä. Olemme koonneet yleisimmät diagnostiikkamerkit opettajilta peruskursseista (CS1), tietorakenteista ja lopputöistä loppuvuodesta 2025 ja alkuvuodesta 2026.

• Opiskelija ei löydä omaa virhettään. Palautus toimi täydellisesti. Uusi yksikkötesti epäonnistuu. Opiskelija avaa tiedoston, katsoo koodia ikään kuin näkisi sen ensimmäistä kertaa, scroller ylös ja alas ilman mitään hypoteesia ja sanoo lopulta: „Kysyn vain Claudelta, mikä tässä on vialla.“ Ensimmäinen reaktio epäonnistuneeseen testiin on eskaloida tekoälylle sen sijaan, että muodostettaisiin hypoteesi.
• Opiskelija ei osaa vastata kysymykseen „miksi“. Kysyttäessä: „Miksi käytit tässä hash mapia etkä taulukkoa?“ vastauksena on: „Sitä tekoäly ehdotti.“ Valinta tehtiin, mutta sen taustalla olevaa logiikkaa ei koskaan internalisoitu. Koodin taustalla ei ole kognitiivista mallia.
• Opiskelija ei pysty tekemään pientä muunnelmaa. „Modifioi tämä käsittelemään myös negatiivisia lukuja“ pitäisi olla kolmenkymmenen sekunnin muutos. Tekoälystä riippuvaiselle opiskelijalle tästä tulee viiden minuutin prompte-sessio, koska heidän täytyy syöttää uusi rajoitus takaisin mallille sen sijaan, että he miettisivät, mihin kohtaan olemassa olevaa koodia muutos kuuluisi tehdä.
• Opiskelija hallitsee työkalut, mutta ei ymmärrä ongelmia. He osaavat konfiguroida Vercelin, rakentaa React-komponentin, pystyttää Postgres-tietokannan ja udrullettaa Dockerilla. He osaavat käyttää koko modernia työkaluputkea. Pyydä heitä implementoimaan quicksort. Taushed.
• Paljastus lopputyössä. Lopputyö — se hetki, jolloin kerätyn osaamisen pitäisi bärä hedelmää — on yhä useammin hetki, jolloin täydellinen osaamisen puute paljastuu. Ryhmät, jotka ovat vibe-koodanneet tiensä CS1-kursseilta kolmannelle vuodelle saakka, saapuvat lopputyöhön kykenemättä suunnittelemaan järjestelmää, jakamaan toimintoja osiin tai käsittelemään niitä ohjelmoinnin osia, joita tekoäly hoitaa huonoiten.

Pedagoginen korjaus: kohtele tekoälyhallintaa reellisenä taitona (ja tee siitä ansaittava)

Ne opettajat, jotka hallitsevat tämän siirtymän hyvin, eivät ole niitä, joilla on kaikkein tiukimmat tekoälyn kieltävät säännöt. He ovat niitä, jotka ovat rakentaneet kurssinsa selvän erottelun ympärille: tekoäly on työkalu, jota opiskelijoiden tulisi oppia käyttämään hyvin, JA opiskelijoiden on itsenäisesti pystyttävä osoittamaan ne kognitiiviset taidot, joita tekoäly suorittaa. Nämä kaksi vaatimusta eivät ole ristiriidassa — ne täydentävät toisiaan, ja ne kurssit, jotka tekevät tämän oikein, tuottavat valmistuneita, jotka suoriutuvat paremmin kuin vibe-koodarit ja täysin tekoälyn kieltävät ryhmät.

Ne erityiset suunnittelukaavat, joita näemme toimivan ohjelmointikursseilla vuonna 2026:

• 1. Tosporeinen tehtävä. Jokaisessa tehtävässä on „soolo“-osa (tekoäly kielletty, usein pieni osa luokassa) ja „työkalu“-osa (tekoäly sallittu, mutta dokumentoitu). Soolo-osa mittaa sen, mitä opiskelija todella osaa. Työkalu-osa opettaa heitä saavuttamaan enemmän.
• 2. Tekoälyhallinta arvioitavana kompetenssina. Opiskelijat palauttavat käyttämänsä AI-promptit, saamansa vastaukset sekä analyysin siitä, missä tekoäly oli väärässä tai tehoton. Tekoälyn tuotoksen kriittistä lukemista kohdellaan kurssin oppimistavoitteena, ei kiertotienä.
• 3. Vapaat vianmääritysarvioinnit. Opiskelijoille annetaan toimivaa tekoälyn luomaa koodia, jossa on subtileja virheitä (off-by-one, väärä perustapaus, puuttuva null-tarkistus, tietoturva-aukko) ja he saavat arvosanan kyvystään löytää ja korjata ne. Tämä trénere sitä taitoa, jota tekoäly suorittaa heikoiten ja jota työnantajat arvostavat eniten.
• 4. Prosessi-synkkä arviointi. Vaatimus versiohistoriasta, pakolliset kommentit, jotka dokumentoivat designvalintoja, tallennetut selitykset. Pelkkä koodi itsessään ei enää muodosta koko arvosanaa.
• 5. Live tekniset keskustelut. Lyhyt, strukturoitu suullinen osa jokaisessa merkittävässä tehtävässä. Viisi minuuttia per opiskelija, fokusoituna yhteen tai kahteen diagnostiseen kysymykseen. Vaivannäkö on reellisesti palkitsevaa ja signaali on erinomainen.
• 6. Autenttisuuden varmistus järjestelmätasolla. Vastaavat työkalut kuin Plagly.ai skannaavat palautuksia tekoälyluonteen mønsterien, kohorttitason tyylillisen yhdenmukaisuuden sekä niiden iteratiivisten kirjoitusjälkien puuttumisen varalta, joita reellinen opiskelijatyö yleensä osoittaa. Tämä ei ole arvosana; se on flagi, joka nostaa esiin ne palautukset, joista on syytä keskustella kontortiden puitteissa.

Työkalukerros, joka tekee tästä käytännöllistä

Suurin vastustus yllä olevaa mallia kohtaan on logistista. Oikeilla kursseilla on satoja opiskelijoita; oikeilla opettajilla ei ole aikaa lukea jokaista palautusta linja linjalta, järjestää suullista puolustusta jokaisesta tehtävästä tai havaita kohorttikaavoja paljaalla silmällä. Työkalujen on tehtävä alustava skannaus, jotta ihminen voi kohdistaa arvostelukykynsä niihin tapauksiin, joissa sillä on merkitystä.

Miltä tämä näyttää käytännössä 200 opiskelijan CS1-kurssilla:

• Automaattinen palautusten skannaus: Jokainen ladattu tiedosto ajetaan tekoälytunnistuksen läpi, joka palauttaa konfidenssipisteet ja merkinnät lohkoittain. Plagly.ai suorittaa tämän analyysin 99 % tarkkuudella kaikissa suurissa malleissa, mukaan lukien GPT-5.5, Claude 4.6, Gemini 3.1 ja muut, huomioiden myös näiden mallien suosimat koodivariaatiot.
• Dashboard kohorttitasolla: Opettaja näkee tyylillisten kaavojen kypsemmän kytkennän ryhmän kesken. Kun kahdeksan palautusta jakaa idiomaattisen ilmaisun, identtisen kommenttityylin ja saman defensivisen mønsterin kantatilanteissa, tämä ryhmittymä nostetaan esiin tarkistusta varten.
• Kirjoitusjäljet: Plagly.ai:n Agentic Council — seitsemän domääniasiasiantuntijamallia, jotka analysoivat palautusta kirjoituksen laadun, rakenteen, tekoälytunnistuksen, alkuperäisyyden ja yhtenäisyyden osalta — tuottaa viitteellisen raportin. Raportti ei syytä akateemisesta vilpistä; se dokumentoi ne mønsterit, joita opettaja voi tutkia.
• Kohdistetut keskustelut vastaanotolla: Opiskelijat, joiden palautukset merkitään, saavat viiden minuutin suullisen tsekkaamisen. Useimmat selvitetään nopeasti; ne harvat, joita ei selvitetä, muuttuvat niiksi tapauksiksi, joita opettaja käsittelee huolellisesti ja virallisesti.

Tarkoituksena ei ole saada kiinni jokaista huijaria. Tarkoituksena on pitää oppimisprosessi intaktina niille opiskelijoille, jotka haluavat oppia. Ryhmä ilman verifikointia on ryhmä, jossa järjestelmää kiertävät opiskelijat asettavat riman ja rehellisesti työskentelevät jäävät sorteperiksi. Ryhmä verifioinnilla on ryhmä, jossa sosiaalinen normi pitää — tehtävät opettavat edelleen, arvosanat merkitsevät edelleen jotain, ja valmistuneet osaavat rentoutuneesti koodata.

Ohjelmointiopetuksen näkymät 18 kuukauden jaksolla

Useimmat aktiiviset ohjelmointiopettajat, joiden kanssa keskustelemme vuonna 2026, jakavat tunteen siitä, että nykyinen tila on epävakaa. Kotitehtävä, joka arvioidaan pelkästään suoritettujen testien perusteella, on rakenteellisesti yhteensopimaton agentillisten koodaustyökalujen olemassaolon kanssa. Jonkin on joustettava. Kolme uskottavaa suuntaa, nousevassa järjestyksessä todennäköisyyden mukaan:

• Täydelliset tekoälykiellot: Jotkut laitokset yrittävät, ja useimmat epäonnistuvat. Kiellot ovat täytäntöönpanokelvottomia, käytännöistä tulee epäjohdonmukaisia, ja sääntöjä noudattavat opiskelijat valmistuvat heikommin taitaviksi kuin ne, jotka eivät noudata. Tämä on molempien maailmojen pahin tulos, ja se on jo huonontanut itsensä useissa yliopistoissa, jotka kokeilivat sitä vuosina 2023-2024.
• Valmiuksien muutos alaspäin opetussuunnitelmassa: CS1 alkaa myöhemmin, ja siinä painotetaan enemmän käsitteellisiä perusteita. CS2 kattaa sen, mitä CS1 aiemmin kattoi. Syventävät kurssit muuttuvat teoreettisemmiksi, koska toteutusosio ei ole enää siellä, missä oppiminen tapahtuu. Tämä tapahtuu, hitaasti.
• Arviointi siirtyy kohti esittelyä: Kotiin otetuista tehtävistä tulee muotoilevia. Summatiiviset arvosanat määräytyvät ohjatun live-koodauksen, suullisen puolustuksen ja prosessin näkyvän työn avulla. Tähän suuntaan vahvimmat CS-ohjelmat ovat jo siirtymässä, ja se on suunta, johon uskomme useimpien ohjelmien lopulta asettuvan.

Mikään näistä tuloksista ei ratkaise kysymystä siitä, mitä tehdä tällä lukukaudella opiskelijoiden kanssa. Käytännön siirto on sitä varten hybridi: säilytä nykyiset tehtäväsi, lisää todentamiskerros, joka havaitsee pahimmat tapaukset, kerro yksi tai kaksi henkilökohtaisen arvioinnin komponenttia kurssia kohti ja aloita hitaampi opetussuunnitelman uudelleensuunnittelu maailmalle, jossa agentti AI on lähtökohtana. Vahvistustyökaluilla varataan aikaa opetussuunnitelman uudelleensuunnitteluun menettämättä tällä välin tätä kohorttia vibe-koodaukseen.

Usein kysytyt kysymykset

Onko vibe coding aina huonoa, vai onko se joskus perusteltua?

Se on täysin perusteltua kokeneille kehittäjille, jotka työskentelevät vähäpätöisten omien projektiensa parissa, joissa virheiden kustannukset ovat pienet ja kehittäjällä on alla oleva osaaminen tuotoksen arviointiin silloin kun sillä on väliä. Se on tuhoisaa opiskelijoille, jotka vasta rakentavat tuota alla olevaa osaamista, koska se oikosulkee kognitiivisen työn, jota ohjelmointi-opetuksen on tarkoitus kehittää. Ero on pitkälti sama kuin erolla siinä, että kokki tilaa noutoruokaa (hienoa) ja kokkiopiskelija tilaa noutoruokaa loppukokeeseensa (ei hienoa). Molemmat vastaanottavat ruokaa, jota eivät itse valmistaneet. Mutta vain toinen undergraver oppimisprojektia.

Voivatko opiskelijat väittää, että he ovat itse kirjoittaneet tekoälytunnistetun koodin?

Voivat, ja joskus he ovat oikeassa. Vääriä positiivisia koodintunnistuksessa esiintyy useimmiten silloin, kun opiskelijat kirjoittavat hyvin „oppikirjamaista“ koodia, joka sattuu vastaamaan niitä kaavoja, joita tekoäly tyypillisesti tuottaa. Oikea työkulku ei käsittele tunnistuspisteitä lopullisena tuomiona — se kohtelee niitä aiheena viiden minuutin keskustelulle. Opiskelija, joka kirjoitti oman koodinsa, osaa selittää sen, muuttaa sitä paikan päällä ja seurata sen suoritusta. Opiskelija, joka prompasi sen, ei melkein koskaan osaa. Keskustelu, ei pisteet, ratkaisee asian. Raportit kohteesta Plagly.ai on suunniteltu tukemaan tuota keskustelua, eivät korvaamaan sitä.

Miten tekoälyn tunnistus koodissa eroaa proosan tunnistuksesta?

Koodintunnistus käyttää vastaavaa tilastollista perustaa — perplexity, burstiness, stilometriset sormenjäljet — mutta soveltaa niitä muihin pintapiirteisiin. Koodissa kaikkein informatiivisimmat signaalit ovat rakenteellisia pikemminkin kuin leksikaalisia: mønsterit muuttujien nimeämisessä, kommenttien tiheys ja tyyli, idiomatiset kirjastovalinnat, virheidenkäsittely ja idiomaattisten rakenteiden valinta. Ensemblesysteemimme saavuttavat 90-95 % tarkkuuden yksittäisissä koodipalautuksissa vuonna 2026, mikä nousee selvästi yli 95 % silloin, kun ryhmätason kaavioanalyysi yhdistetään filitason pisteytykseen.

Entä ne opiskelijat, jotka aidosti käyttävät tekoälyä tutorina kopioimatta suoraan sen tuotoksia?

Tämä on juuri se ryhmä, jota varmistuskerros on suunniteltu olemaan rankaisematta. Opiskelija, joka käyttää tekoälyä käsitteen ymmärtämiseen ja kirjoittaa sen jälkeen itse oman ratkaisunsa, luo koodia, joka ei vastaa tekoälytuotoksia linjatasolla. Tunnistussignaalit ottavat kiinni tuotteen, eivät itse oppimisprosessia. Jos ryhmäsi säännöt sallivat tekoälyn tutorina — kuten mielestämme pitäisi — tämä työnkulku toimii edelleen. Kontrolloit palautusta, et opiskelijan oppimismenetelmää.

Toimiiko tämä projektipohjaisilla kursseilla ja huippukivillä?

Kyllä, mukautumalla. Useamman viikon ja usean tiedoston projektityössä hyödyllisimmät signaalit siirtyvät kohti prosessin näkyvyyttä: toimitushistorian analyysi (näkyykö koodi yhdessä suuressa toimituksessa vai kehittyikö se ajan myötä?), tekijän johdonmukaisuus eri tiedostoissa (lukeeko koodikanta samalla tavalla kuin yksi henkilö kirjoitti sen, vai ommeltuuko eri paikat yhteen?) ja suunnittelu-päätös selittää, miksi opiskelijan valintoja tehtiin? Capstone-tyyliset projektit hyötyvät eniten rakenteellisesta suullisesta puolustuksesta sekä kirjallisesta suunnitteluperusteesta, jossa tekoälyn havaitseminen on kolmannen asteen signaali ensisijaisen signaalin sijaan.