Arendajate haridus ja hindamine agentide ajastul

Arendajate haridus ja hindamine agentide ajastul

See analüüs peegeldab haridus- ja sertifitseerimismaastikku seisuga 26. juuli 2026.

Sissejuhatus

Autonoomsed kodeerimisagendid muudavad tarkvaraarendust ülesandest, mis keskendub koodi tippimisele, ülesandeks, mis keskendub töö spetsifitseerimisele, ülesannete delegeerimisele, täitmise järelevalvele ja tulemuste ülevaatamisele.

Kaasaegsed kodeerimisagendid suudavad kontrollida repositooriumi, koostada juurutusplaani, muuta mitut faili, käivitada teste, reageerida vigadele ja avada tõmbepäringu (pull request) inimese ülevaatamiseks. GitHubi praegune dokumentatsioon kirjeldab töövooge, kus arendajad määravad agentidele ülesandeid, jälgivad nende tööd, taotlevad koodi ülevaatamist, annavad tagasisidet ja kinnitavad või lükkavad tulemuse tagasi. (docs.github.com)

See tekitab haridusele keerulise küsimuse:

Kui õpilane saab paluda agendil luua töötava programmi, siis mida peaks õpilane mõistma?

Vastus ei ole programmeerimise alustest loobumine. See on nende aluste kasutusotstarbe muutmine.

Õpilased peavad endiselt mõistma andmestruktuure, algoritme, programmeerimiskeeli, süsteemidisaini, turvalisust, testimist ja silumist. Kuid nad peavad seda teadmist üha enam rakendama järgmiste valdkondade puhul:

• Segaste probleemide jaotamine hallatavateks ülesanneteks
• Täpsete spetsifikatsioonide ja vastuvõtukriteeriumide kirjutamine
• Kasuliku konteksti pakkumine kodeerimisagentidele
• Hinnata, kas genereeritud kood on korrektne ja hooldatav
• Testide disainimine, mis paljastavad varjatud vead
• Turvalisuse, privaatsuse, jõudluse ja arhitektuuriliste riskide ülevaatamine
• Mitme agendi või tööriista koordineerimine kontrolli kaotamata
• Tehniliste otsuste selgitamine ja kaitsmine

Arendajate hariduse järgmine põlvkond hindab seetõttu vähem õpilase võimet toota suuri koguseid koodi ja rohkem õpilase võimet mõista, suunata, kontrollida ja parandada tarkvarasüsteeme.

Keskne nihe: koodi tootmisest inseneriotsustuseni

Kodeerimisagendid ei ole lihtsalt kiirem automaatne täitmine

Traditsioonilised kodeerimisassistendid pakuvad välja rea, funktsiooni või väikese koodiploki. Autonoomsed kodeerimisagendid töötavad suuremas skaalas. Nad suudavad töötada üle failide, käivitada arendustööriistu, täita teste, uurida dokumentatsiooni ja jätkata mitmete sammude kaudu.

See muudab tööühikut. Arendaja töövoog näeb üha enam välja järgmine:

1. Kasutaja- või äriprobleemi mõistmine.
2. Soovitud käitumise määratlemine.
3. Töö jagamine väiksemateks ülesanneteks.
4. Sobiva ülesande määramine agendile.
5. Agendi plaani kontrollimine.
6. Agendi lubamine juurutada kontrollitud keskkonnas.
7. Testide ja turvakontrollide käivitamine.
8. Tulemuse ülevaatamine.
9. Muudatuste taotlemine või disaini revideerimine.
10. Tarkvara kinnitamine, ühendamine ja jälgimine.

Isik, kes jätab planeerimise ja ülevaatamise etapid vahele, võib siiski koodi toota, kuid ei suuda usaldusväärset toodet usaldusväärselt luua.

Toore koodiväljundi piirid

Toorkoodi tootmine on muutumas nõrgemaks võimete mõõdupuuks, sest agent suudab kiiresti genereerida suure hulga usutavat koodi. Samal ajal on agentidel endiselt raskusi pikaajalise tarkvaraarenduse, mitme faili muudatuste, ebaselgete nõuete ja käitumise säilitamisega korduvate modifikatsioonide korral. Üks 2025. aasta võrdlusuuring leidis olulise erinevuse agentide soorituses isoleeritud probleemide lahendamisel ja keerulisemate, pikaajaliste tarkvaraarenduse ülesannete puhul. (arxiv.org)

See loob olulise haridusliku erisuse:

• Õpilane, kes suudab koodi genereerida, ei pruugi seda mõista.
• Õpilane, kes suudab koodi selgitada, testida, vaidlustada ja parandada, demonstreerib sügavamat pädevust.

Hariduslikuks eesmärgiks peaks seega saama valideeritud tarkvaraotsustus, mitte lihtsalt edukas koodi genereerimine.

Kuidas õppekavad kohanevad

Ülikoolide õppekavad liiguvad mõistmise ja kontrolli suunas

ACM-i, Electrical and Electronics Engineers Computer Society ja Association for the Advancement of Artificial Intelligence’i Computer Science Curricula 2023 aruanne ennustas, et generatiivne tehisintellekt muudab programmeerimisõpet. Selle juhised viitavad, et õpilased peavad rohkem rõhku panema koodi lugemisele, mõistmisele, kontrollimisele, redigeerimisele, muutimisele, kohandamisele ja testimisele. Samuti identifitseeritakse probleemide dekomponeerimine valdkonnana, mis tõenäoliselt muutub olulisemaks. (csed.acm.org)

Samad juhised rõhutavad olulist punkti: isegi kui agent programmi kirjutab, vastutab inimene endiselt selle eest, et programm oleks õige. See tähendab, et programmeerimisõpet ei saa taandada käskude kirjutamisele. Õpilased vajavad piisavalt tehnilist arusaamist väljundi hindamiseks.

Aruanne prognoosib ka muutusi tarkvaratehnika hariduses, sealhulgas tehisintellekti suuremat kasutamist koodi genereerimiseks, silumiseks, staatiliseks analüüsiks ja koodi ülevaatamiseks. Nende tööriistade tõhus kasutamine nõuab tugevamaid disaini- ja koodimõistmise oskusi, mitte nõrgemaid. (csed.acm.org)

Akrediteerimine hakkab premeerima laiemaid inseneritöö tulemusi

Akrediteerimisnõukogu Engineering and Technology (ABET) praegused arvutusteaduste akrediteerimiskriteeriumid rõhutavad juba:

• Keeruliste arvutusprobleemide analüüs
• Arvutuslahenduste disain ja hindamine
• Professionaalne suhtlus
• Juriidiline ja eetiline vastutus
• Turvalisus ja privaatsus
• Arvutitehnoloogia sotsiaalne mõju
• Põhjalik projekt või praktiline komponent (abet.org)

Need tulemused sobivad hästi agentipõhisele arenduskeskkonnale, sest need mõõdavad otsustusvõimet ja vastutust, mitte klahvivajutusi.

Seisuga 26. juuli 2026 hõlmasid Akrediteerimisnõukogu Engineering and Technology (ABET) kavandatud muudatused 2026–2027 tsükli jaoks täiendavaid tehisintellekti programmi kriteeriume ja nõuet, et lõpetajad peavad suutma rakendada tehisintellekti teooriaid, mudeleid ja tehnikaid keeruliste probleemide lahendamisel. Kavandatud muudatused ootasid veel lõplikku vastuvõtmist ja eeldatavasti jõustuvad pärast 2026. aasta sügise koosolekut, esimene rakendamine toimub 2027–2028 ülevaatustsükli jooksul. (abet.org)

Tõenäoline suund on selge: programmid peavad näitama, et õpilased suudavad süsteeme ehitada ja hinnata, mitte ainult täita isoleeritud programmeerimisharjutusi.

Uued kursused õpetavad agentide kasutamist inseneridistsipliinina

Mitmed hiljutised ülikoolikursused illustreerivad esilekerkivat mustrit.

Marylandi ülikooli 2025. aasta kursus tehisintellekti kodeerimisassistentide ja -agentide tõhusa kasutamise kohta hõlmas tööriistu, mis suudavad käivitada ehitussüsteeme, käivitada teste ja parandada vigu. Samuti käsitleti hooldatavust, arhitektuuri, rakendusliideste disaini, tõhusust, skaleeritavust, turvalisust, pidevat integreerimist, koodi ülevaatamist, asünkroonseid agente ja automatiseeritud koodi ülevaatamist. (cs.umd.edu)

Pennsylvania ülikool on välja pakkunud teise aasta informaatika kursuse, mis keskendub tehisintellektipõhisele tarkvaraarendusele. Selle pakutavad teemad hõlmavad kodeerimisülesannete delegeerimist, modulaarset disaini, skaleeritavat testimist, riskijuhtimist, reprodutseeritavust, koostööd ja eetikat. (seas.upenn.edu)

Michigani ülikooli 2026. aasta sügisene kursus, Applied Agentic Software Engineering (Rakenduslik Agentne Tarkvaratehnika), on veelgi selgesõnalisem. See on jagatud kolmeks etapiks:

1. Kodeerimisagentide tõhus kasutamine
2. Agendi loomine suure keelemudeli rakendusliidese abil
3. Agendi orkestraatori disainimine, hindamine ja juurutamine

Kursus kasutab projektide, laboratoorsete tööde, demonstratsioonide ja kontrollpunktide süsteemi traditsiooniliste eksamite asemel. See ütleb, et hindamine premeerib mõistmist rohkem kui väljundit ja palub õpilastel selgitada, miks agent ebaõnnestus ja kuidas ümbritsevat süsteemi parandada. (eecs498-aase.github.io)

See on oluline disainimuudatus. Kursus ei õpeta õpilasi koodi kiiremini tootma. See õpetab neid saama koodi tootvate süsteemide tehnilisteks juhendajateks.

Kuidas intensiivkursused muutuvad

Intensiivkursused kohanevad kiiremini kui paljud traditsioonilised programmid, sest nende õppekavad on tihedalt seotud tööhõivenõuetega. Kohanemise kvaliteet varieerub aga.

Spetsiaalne tehisintellekti intensiivkursuse mudel

Le Wagooni praegune tehisintellekti tarkvaraarenduse intensiivkursus ühendab täislahenduse arenduse tehisintellekti integreerimisega. Selle avaldatud õppekava sisaldab tehisintellekti abil kodeerimist, suure keelemudeli integreerimist, tootmisse juurutamist, otsingupõhist genereerimist ja autonoomseid tehisintellekti agente. (lewagon.com)

See mudel käsitleb tehisintellekti kui programmi läbivat lõime, mitte kui üht valikulist tundi. Õpilastel eeldatakse õppimist mõlemat:

• Kuidas töötavad tavalised tarkvarasüsteemid
• Kuidas kasutada tehisintellekti tööriistu nende süsteemide ehitamiseks ja käitamiseks

See kombinatsioon on oluline. Õppija, kes oskab ainult agenti käitada, ei pruugi olla võimeline ära tundma vigast arhitektuuri. Õppija, kes teab ainult tavapärast programmeerimist, ei pruugi olla valmis kaasaegseteks arendustöövoogudeks.

Mudel „lisa tehisintellekti üksus”

Springboardi tarkvaratehnika intensiivkursus säilitab tavapärase aluse veebiarenduses, rakendusliidestes, esiotsa arenduses, tagapoolses arenduses ja täislahendusega projektides, lisades samal ajal tehisintellekti üksuse, mis keskendub käsuinseneriteadusele ja koostööle generatiivsete tööriistadega. (springboard.com)

See mudel on kasulik õppijatele, kes vajavad esmalt tugevaid programmeerimise aluseid. See peegeldab ka praktilist reaalsust: paljud õpilased ei peaks alustama autonoomsete agentide ehitamisest. Nad peaksid esmalt õppima, kuidas tarkvara töötab, kuidas kasutada versioonihaldust, kuidas lugeda veateateid ja kuidas programmi testida.

Nõrkus seisneb selles, et lühike käsuinseneri moodul võib jääda liiga pealiskaudseks. Tõsine agentide ajastu õppekava peaks õpetama rohkem kui ainult seda, kuidas koodi küsida. See peaks õpetama:

• Kuidas luua repositooriumi kontekstifaili
• Kuidas kirjutada tehniline spetsifikatsioon
• Kuidas määratleda ülesande piire
• Kuidas piirata agendi õigusi
• Kuidas kontrollida agendi plaane
• Kuidas hinnata genereeritud teste
• Kuidas tuvastada turvaprobleeme
• Kuidas võrrelda alternatiivseid disaine
• Kuidas dokumenteerida agendi osalust

Mida intensiivkursuste õpilased otsima peaksid

Tulevased õpilased peaksid küsima, kas programm hindab järgmist:

• Kas õpilased suudavad selgitada koodi, mida nad ise ei tippitud?
• Kas õpilased vaatavad üle ja parandavad vigase agendi väljundi?
• Kas testid, turvalisus ja hooldatavus on hinnatud?
• Kas toimub reaalajas demonstratsioon või tehniline kaitsmine?
• Kas õpilased hoiavad versioonitud projekti ajalugu?
• Kas õpilastele õpetatakse vajaduse korral ilma agendita töötamist?
• Kas programm õpetab toote avastamist ja nõuete analüüsi?
• Kas tööriistaspetsiifilised oskused on tasakaalus vastupidavate inseneripõhimõtetega?

Programm, mis reklaamib “ehita rakendus ühe nädalaga tehisintellektiga”, võib olla suurepärane kiireks prototüüpimiseks, kuid see ei ole sama, mis valmistab kedagi ette professionaalseks tarkvaratehnikaks.

Kuidas sertifikaadid kohanevad

Sertifitseerimispakkujad arendavad kolme laia tüüpi mandaate.

Tööriistaspetsiifilised teadmiste sertifikaadid

Microsofti GitHub Copiloti sertifikaat hindab vastutustundlikku kasutamist, Copiloti funktsioone, andmearhitektuuri, konteksti ja käskude loomist, arendaja tootlikkust, privaatsust, sisu välistusi ja kaitsemeetmeid. Eksam on jälgitud, kestab sada minutit ja võib sisaldada interaktiivseid komponente. (learn.microsoft.com)

See tunnistus tunnistab kasulikke töökoha teadmisi. See võib näidata, et inimene mõistab, kuidas vastutustundlikult kasutada konkreetset arendusplatvormi.

Selle piirang on see, et see on tugevalt seotud ühe tootega. Professionaal, kes oskab kasutada GitHub Copilotit, ei pruugi siiski omada võimet jaotada keerulist tootenõuet, vaidlustada arhitektuurilist valikut või vaadata üle turvatundlikku muudatus.

Platvormipõhised tehisintellekti arendussertifikaadid

AWS Certified Generative AI Developer – Professional sertifikaat on laiem. Selle eksamijuhend sisaldab alusmudeli integreerimist, andmehaldust, vastavust, juurutamist, agentseid tehisintellekti lahendusi, turvalisust, haldust, testimist, veaotsingut, jälgimist ja optimeerimist. (docs.aws.amazon.com)

Eksam on aga peamiselt valikvastustega ja mitme vastusega. See on oluline teadmiste test, kuid see ei demonstreeri täielikult, kas kandidaat suudab töötavat süsteemi ehitada, üle vaadata või kaitsta. (aws.amazon.com)

See illustreerib laiema probleemi: teadmiste eksameid on lihtsam skaleerida kui soorituspõhiseid eksameid. Sertifitseerimisorganisatsioonid saavad terminoloogiat ja disainipõhimõtteid tõhusalt testida, kuid praktiline pädevus nõuab keskkonda, kus kandidaadid peavad tegema otsuseid ja tegelema ebaõnnestumistega.

Laboratoorsed ja projektipõhised mandaadid

Microsoft Applied Skills mandaadid pakuvad paljutõotavamat mudelit. Need nõuavad õppijatelt reaalsete ülesannetega kooskõlas olevate interaktiivsete ülesannete täitmist laboripõhises hindamises. Microsoft positsioneerib need mandaadid tõendina, et kandidaat suudab lahendada tõelisi pilve- ja tehisintellekti väljakutseid, mitte lihtsalt teavet meenutada. (learn.microsoft.com)

Carnegie Melloni ülikooli täiendõppe agentne tehisintellekti programm ühendab otseõppe, juhendatud laboratooriumid, ülesanded, mitmeagendilised töövooged, hindamise, kaitsepiirded, logimise, jälgitavuse ja lõpuprojekti. (execonline.cs.cmu.edu)

Need programmid ei ole identsed sõltumatu professionaalse sertifitseerimisega, kuid need näitavad suunda, milles mandaadid tõenäoliselt liiguvad:

• Lühemad praktilised hindamised
• Liivakasti arenduskeskkonnad
• Realistlikud repositooriumid
• Hindamis- ja jälgimisülesanded
• Lõpusüsteemid
• Suulised või salvestatud tehnilised selgitused
• Tõendid vastutustundliku tööriistakasutuse kohta

Hindamistehnikad, mis mõõdavad mõistmist

Parim hindamisstrateegia ei keela agente igal ülesandel. See kasutab agente seal, kus need peegeldavad professionaalset praktikat, ja reserveerib mõned tegevused iseseisva mõistmise mõõtmiseks.

1. Spetsifikatsiooni ja dekomponeerimise dokumendid

Enne koodi kirjutamist nõudke õpilastelt esitamist:

• Kasutajaprobleem
• Funktsionaalsed nõuded
• Mittefunktsionaalsed nõuded
• Eeldused
• Piirangud
• Andmestruktuurid
• Liidesed
• Vastuvõtukriteeriumid
• Ülesande jaotus
• Teadaolevad riskid

Dokument peaks selgitama, miks probleem on jagatud konkreetseteks ülesanneteks.

See mõõdab, kas õpilane mõistab probleemi enne, kui palub agendil seda juurutada.

2. Agendi planeerimise kontrollpunktid

Nõudke õpilastelt agendi kavandatud plaani näitamist enne juurutamise algust. Õpilane peab tuvastama:

• Millised plaani osad on vastuvõetavad
• Millised osad on puudulikud
• Millised eeldused on ebaturvalised
• Millised ülesanded vajavad inimese heakskiitu
• Millised testid tuleks lisada

Lõpphinne peaks premeerima õpilase otsustusvõime kvaliteeti, mitte agendi plaani pikkust.

3. Koodi ülevaatamise hindamised

Andke õpilastele agendi genereeritud repositoorium, mis sisaldab tahtlikke vigu. Defektid võivad hõlmata:

• Ebaõige piirjuhtude käsitlus
• Ebaturvaline autentimine
• Halb veakäsitlus
• Varjatud jõudlusprobleemid
• Dubleeritud loogika
• Ebaselged liidesed
• Ebapiisavad testid
• Privaatsusrikkumised
• Sõltuvusriskid

Paluge õpilastel koostada ülevaade koos tõsiduse tasemete, tõendite, pakutud paranduste ja regressioonitestidega.

See on professionaalsele tarkvaratööle lähemal kui õpilaste palumine luua nullist veel üks väike rakendus.

4. Tagasiside ja suuline kaitse

Õpilane peaks suutma selgitada:

• Mida süsteem teeb
• Miks valiti just see arhitektuur
• Millised osad genereeriti
• Milliseid eeldusi agent tegi
• Kuidas testid demonstreerivad õigsust
• Mis võiks veel ebaõnnestuda
• Millised kompromissid aktsepteeriti

Lühikese suulise kaitsmise saab läbi viia individuaalselt või väikestes rühmades. See ei pea olema hirmutav. Viis kuni kümme keskendunud küsimust on sageli piisav, et paljastada, kas õpilane esitatud tööst aru saab.

5. Ülekandeülesanded

Pärast seda, kui õpilane on agendi abil projekti lõpetanud, esitage uus nõue, mida ei saa lahendada lihtsalt algse käsu kordamisega.

Näiteks:

• Lisage uus andmeallikas
• Muutke jõudluseesmärki
• Toetage ootamatut sisendvormingut
• Eemaldage sõltuvus
• Lisage juurdepääsukontrollid
• Selgitage ebaõnnestunud testi
• Refaktoriseerige moodulit selle käitumist muutmata

Õpilane võib kasutada agenti, kuid peab selgitama plaani, kontrollima muudatusi ja kaitsma tulemust.

Ülekandeülesanded mõõdavad, kas õpilane õppis üldist meetodit, mitte ei meelde jätnud edukat interaktsiooni.

6. Testide disain ja vastase testimine

Õpilasi tuleks hinnata nende testide kvaliteedi, mitte ainult selle järgi, kas genereeritud kood läbib etteantud testid.

Kasulikud nõuded hõlmavad:

• Kirjutada piirväärtuse testid
• Luua negatiivsed testid
• Testida vigaseid sisendeid
• Testida tõrke taastamist
• Kontrollida jõudluse eeldusi
• Kasutada omaduspõhiseid teste, kui see on asjakohane
• Testida turvatundlikku käitumist
• Selgitada, mis jääb testimata

Peamine küsimus ei ole „Kas kood läbis testi?“, vaid „Kas õpilane teadis, mida oli vaja testida?“

7. Versioonide ajalugu ja protsessiportfooliod

Projektide portfoolio võib sisaldada:

• Algne spetsifikatsioon
• Ülesande dekomponeerimine
• Agendi plaanid
• Olulised käsklused või juhised
• Tehtud kohustused (commits)
• Testi tulemused
• Ülevaate kommentaarid
• Ebaõnnestunud lähenemised
• Disainimuudatused
• Lõpparutelu

Protsessiportfoolio ei tohaks muutuda nõudeks esitada iga privaatse vestluse rida. Esinduslik ülevaade on sageli kasulikum kui tohutu transkriptsioon.

Princetoni 2025. aasta programmeerimiskursus lubas näiteks generatiivseid tehisintellekti tööriistu, kuid nõudis õpilastelt nende kasutamise kirjeldamist readme-failis esindusliku kokkuvõtte kaudu, mitte ammendava transkriptsioonina. (cs.princeton.edu)

8. Struktureeritud kaaslaste ülevaade

Kaaslaste ülevaade muudab õpilased kooditootjatest koodikriitikuteks. Varajased uuringud näitavad, et rubriigipõhine kaaslaste hindamine suudab õppejõu hindamist mõõduka täpsusega ligikaudselt jäljendada, arendades samal ajal hindavat mõtlemist ja kaasamist. (arxiv.org)

Õpilased peavad oma kommentaare tõenditega põhjendama. „See kood on halb“ ei ole ülevaade. „See funktsioon teeb andmebaasipäringu tsükli sees, luues tõenäolise jõudlusprobleemi, kui kollektsioon kasvab“ on ülevaade.

9. Käsu- ja spetsifikatsiooniprobleemid

Käsuprobleemid on programmeerimisharjutused, milles õpilased kirjutavad loomulikus keeles juhiseid, mis panevad tehisintellekti süsteemi genereerima spetsifikatsioonile vastavat koodi. Lähenemine õpetab õpilastele selgesõnaliselt arvutuslike nõuete edastamist koodi genereerivatele süsteemidele. (arxiv.org)

See võib olla kasulik, kuid see ei tohiks olla ainus hindamismeetod. 2026. aasta uuring, milles osales üle üheksasaja õpilase, leidis, et levinud vead hõlmasid oluliste detailide väljajätmist käskudest. Kui genereeritud kood ebaõnnestus, keskendusid õpilased sageli oma kavatsuse selgitamisele, selle asemel et koodi jälgida või testjuhtumeid uurida. (arxiv.org)

Käsude andmine võib seega paljastada dekomponeerimis- ja suhtlusoskused, kuid seda tuleb kombineerida koodi lugemise, testimise, silumise ja ülevaatamisega.

Näidis hindamisstruktuur

Praktiline projekt võiks kasutada järgmist kaalutlust:

See struktuur premeerib endiselt töötavat toodet, kuid see takistab õpilasel saamast kõrget hinnet lihtsalt seetõttu, et agent tootis suure koodibaasi.

Akadeemiline ausus agentide abil täidetud kursusetöödes

Üldised keelud ja piiramatu kasutamine on mõlemad ebapiisavad

Üldine keeld võib olla asjakohane konkreetse alusõppe hindamisel, eriti kui õppe-eesmärgiks on iseseisev programmeerimispraktika. Kuid universaalset keeldu on üha raskem jõustada ja see võib takistada õpilastel õppimast tööriistu, millega nad professionaalses töös kokku puutuvad.

Piiramatu kasutamine on samuti ebapiisav. Kui õpilased saavad esitada agendi koostatud töid ilma selgituseta, võib hindamine mõõta pigem tööriistale juurdepääsu kui õppimist.

Kõige tugevam lähenemine on selgesõnaline, ülesandepõhine poliitika.

Kolm kasulikku poliitikarežiimi

Režiim üks: Agent keelatud

Kasutage seda järgmiste puhul:

• Eksamid
• Algprogrammeerimise harjutused
• Individuaalsed silumise demonstratsioonid
• Tuumaalgoritmi harjutused
• Hindamised, mis on loodud abita meenutamise või rakendamise mõõtmiseks

Carnegie Melloni Imperatiivse Arvutuse Põhimõtete kursus keelab tehisintellekti tööriistad igasuguse hinnatava töö osa jaoks, sealhulgas lahenduste genereerimine, lahenduste selgitamine, koodi vormindamine ja testjuhtumite genereerimine. (cs.cmu.edu)

Režiim kaks: Agent piiratud

Kasutage seda, kui õpilased võivad küsida:

• Kontseptsioonide selgitused
• Dokumentatsiooniabi
• Veateadete tõlgendamine
• Teegi või rakendusliidese selgitamine
• Ajurünnak
• Õpilase loodud disaini kriitika
• Väike refaktoriseerimine

Carnegie Melloni süsteemikursused lubavad tehisintellekti tööriistu rakendusliideste, teekide, raamistike, pakutava koodi ja veateadete mõistmiseks, keelates samal ajal osaliste või täielike ülesandelahenduste taotlemise. (cs.cmu.edu)

Režiim kolm: Agent lubatud avalikustamise korral

Kasutage seda realistlike tarkvaratehnika projektide puhul. Nõudke õpilastelt avalikustamist:

• Milliseid tööriistu kasutati
• Millised ülesanded delegeeriti
• Kas genereeritud kood kopeeriti, muudeti või kirjutati ümber
• Kuidas väljundit testiti
• Mida õpilane õppis
• Millised disaini osad jäävad õpilase vastutusele

Princetoni teadusliku aususe juhised sätestavad, et lubatud tehisintellekti kasutamine tuleb siiski avalikustada ja et genereeritud väljundi esitamine oma tööna või selle kasutamise avaldamata jätmine võib kujutada endast aususe rikkumist. (scholarlyintegrity.princeton.edu)

Harvardi haridusteaduste kraadiõppe kool lubab samuti selliseid kasutusviise nagu selgitamine, ajurünnak ja uurimine, keelates samal ajal õpilastel esitada tehisintellekti genereeritud kursusetööd oma tööna. Samuti nõutakse lubatud kasutamise dokumenteerimist ja hoiatatakse, et õpilased vastutavad endiselt täpsuse, privaatsuse, autoriõiguse ja eelarvamuste eest. (registrar.gse.harvard.edu)

Praktiline avalikustamise avaldus

Kursus võib pakkuda lihtsa malli:

Kasutasin [tööriista nimi] [planeerimiseks, silumiseks, koodi genereerimiseks, testimiseks, dokumenteerimiseks või ülevaatamiseks]. Delegeerisin [konkreetsed ülesanded]. Vaatasin üle ja muutsin väljundit, testisin saadud süsteemi ja vastutan esitatud töö täpsuse, turvalisuse ja originaalsuse eest.

Õpilastelt ei tohiks nõuda tavaliste õigekirjaparanduste avalikustamist samamoodi nagu delegeeritud juurutamist. Eeskirjad peaksid eristama väikest abi ja olulist kognitiivset või tehnilist panust.

Privaatsus ja võrdne juurdepääs

Asutused peaksid pakkuma heakskiidetud tööriistu või alternatiive. Õpilastelt ei tohiks nõuda konfidentsiaalsete kursusetööde, isikuandmete, avaldamata uurimistöö või varalise koodi üleslaadimist avalikesse süsteemidesse.

UNESCO juhised kutsuvad üles inimkesksele lähenemisele, mis käsitleb privaatsust, turvalisust, võrdsust, kaasamist ja institutsionaalset valmisolekut. (unesco.org)

Kursused peaksid arvestama ka õpilastega, kes ei saa endale mitut tasulist tööriista lubada. Õiglane kursus saab:

• Pakkuda jagatud institutsionaalset tööriista
• Pakkuda kohalikku või avatud lähtekoodiga alternatiivi
• Kujundada ülesandeid, mis ei sõltu ühest tarnijast
• Hinnata arutluskäiku, mitte juurdepääsu kõige võimsamale mudelile
• Lubada igale olulisele õpitulemusele mitte-agendipõhiseid lahendusi

Praktilised meetodid agentide produktiivseks kaasamiseks

Kasutage kontrollitud repositooriumi

Andke õpilastele repositoorium, mis sisaldab:

• Selge readme-fail
• Väike, kuid realistlik koodibaas
• Automatiseeritud testid
• Pidev integreerimise töövoog
• Teadaolevate probleemide loend
• Stiilijuhend
• Turvalisuse kontrollnimekiri
• Muudatuste logi

See muudab agentide kasutamise jälgitavaks ja annab õpilastele midagi realistlikumat kui tühi kodeerimisharjutus.

Nõudke plaani enne juurutamist

Õpilased ei tohiks alustada, paludes agendil „ehitada kogu rakendus“. Nõudke järjekorda:

1. Paluge agendil repositooriumi kontrollida.
2. Paluge arhitektuuri kokkuvõtet.
3. Paluge riske ja puuduvat teavet.
4. Kirjutage õpilase oma ülesandeplaan.
5. Kinnitage üks väike juurutusülesanne.
6. Vaadake üle saadud muudatused.
7. Käivitage testid enne jätkamist.

See õpetab kontrollitud delegeerimist, mitte pimedat delegeerimist.

Kasutage agendimeeskonda selgete rollidega

Lihtne orkestreerimismuster võib hõlmata:

• Planeerija: pakub välja ülesannete jaotuse
• Juurutaja: muudab koodi
• Testija: loob ja käivitab teste
• Ülevaataja: otsib vigu ja riske
• Inimhindaja: kinnitab või lükkab muudatused tagasi

Õpilased peaksid õppima, et rohkemate agentide lisamine ei paranda automaatselt kvaliteeti. Rohkem agente võib luua vastuolulisi juhiseid, dubleeritud pingutusi, suurenenud kulusid ja ebaselget vastutust.

Hariduslik eesmärk ei ole ehitada suurimat mitmeagendilist süsteemi. See on valida lihtsaim töövoog, mis annab usaldusväärseid tulemusi.

Ehitage sisse inimeste heakskiidu väravad

Nõudke selget heakskiitu enne, kui agent saab:

• Muuta autentimist
• Muuta andmeskeeme
• Lisada sõltuvusi
• Juurdepääs tootmissüsteemidele
• Muuta juurutamise konfiguratsiooni
• Kustutada faile
• Ühendada tõmbepäringu (pull request)

See õpetab õpilastele, et autonoomia peab olema piiratud lubade ja ülevaatusega.

Hinda ebaõnnestumisi tahtlikult

Agendid on kõige harivamad, kui nad ebaõnnestuvad informatiivselt. Juhendajad peaksid lisama:

• Mitmetähenduslikud nõuded
• Vastuolulised piirangud
• Mittetäielikud testid
• Turvatundlikud toimingud
• Eksitav dokumentatsioon
• Ebaühtlased testid
• Jõudluspiirangud
• Muudatus, mis tundub õige, kuid rikub teist funktsiooni

Õpilase ülesanne on diagnoosida rike ja parandada protsessi.

Pädevusraamistik aastateks 2026–2031

Järgmine raamistik on loodud nii, et see jääks kasulikuks ka siis, kui konkreetsed tööriistad muutuvad.

Valdkond üks: Tehnilised alused ja koodikirjaoskus

Pädev arendaja suudab:

• Lugeda tundmatut koodi
• Selgitada kontrollvoogu ja andmevoogu
• Mõista liideseid ja sõltuvusi
• Analüüsida algoritmilist keerukust
• Kasutada versioonihaldust
• Siluda, ilma et toetuks täielikult agendile

Tõendid: koodi selgitus, käsitsi silumise ülesanne, disainikriitika ja individuaalne ülekandeharjutus.

Valdkond kaks: Probleemi raamistamine ja dekomponeerimine

Pädev arendaja suudab:

• Selgitada kasutaja eesmärke
• Tuvastada piiranguid ja eeldusi
• Eristada olulisi valikulistest nõuetest
• Jaotada töö iseseisvalt testitavateks ülesanneteks
• Määratleda vastuvõtukriteeriumid
• Tuvastada, millal ülesanne on usaldusväärseks delegeerimiseks liiga lai

Tõendid: spetsifikatsioon, ülesannete graafik, riskiregister ja dekomponeerimisvalikute selgitus.

Valdkond kolm: Agendi suunamine ja kontekstipõhine inseneriteadus

Pädev arendaja suudab:

• Pakkuda asjakohast repositooriumi konteksti
• Anda täpseid juhiseid
• Määratleda piirid ja õigused
• Valida, millal agenti kasutada ja millal mitte
• Võrrelda alternatiivseid plaane
• Taastuda, kui agent järgib valet tõlgendust

Tõendid: planeerimiskontrollpunktid, esinduslikud interaktsioonikirjed ja reaalajas muutmise ülesanne.

Valdkond neli: Kontroll ja ülevaade

Pädev arendaja suudab:

• Kontrollida genereeritud koodi
• Kujundada sisukaid teste
• Tuvastada varjatud eeldusi
• Vaadata üle turvalisuse ja privaatsuse riskid
• Hinnata hooldatavust
• Selgitada, mida testid ei tõesta

Tõendid: koodi ülevaade, vastaspoole testid, vigade leidmise harjutus ja suuline kaitse.

Valdkond viis: Orkestreerimine ja toimingud

Pädev arendaja suudab:

• Koordineerida planeerimise, juurutamise, testimise ja ülevaatamise tööriistu
• Kasutada kontrollpunkte ja inimeste heakskiidu väravaid
• Jälgida kulusid, aega ja tööriista käitumist
• Säilitada reprodutseeritavaid töövooge
• Jälgida rikkeid ja parandada süsteemi
• Otsustada, kas mitu agenti lisavad väärtust

Tõendid: töötav orkestratsiooni töövoog, logid, hindamisraport ning kulu- või jõudlusanalüüs.

Valdkond kuus: Toote- ja süsteemidisain

Pädev arendaja suudab:

• Valida sobiva automatiseerimise taseme
• Kujundada modulaarseid süsteeme
• Tasakaalustada kiirust, kvaliteeti, kulu ja riski
• Siduda tehnilised otsused kasutaja tulemustega
• Tuvastada, millal lihtne mitte-agendi lahendus on parem

Tõendid: toote kokkuvõte, arhitektuuri otsuse dokument, prototüüp ja kasutajakeskne demonstratsioon.

Valdkond seitse: Vastutustundlik erialane praktika

Pädev arendaja suudab:

• Avaldada tehisintellekti abi
• Kaitsta privaatset ja varalist teavet
• Austada autoriõigusi ja litsentsikohustusi
• Tuvastada kallutatuse ja usaldusväärsuse riske
• Suhelda ebakindlalt
• Aktsepteerida vastutust lõpptoodangu eest

Tõendid: avalikustamise avaldus, riskihindamine, privaatsuse ülevaade ja professionaalne esitlus.

Soovitatavad pädevuse tasemed

Aastaks 2031 peaks professionaalne tunnistus näitama liikumist läbi nende tasemete, mitte lihtsalt kinnitama teatud tarkvaratööriista tundmist.

Soovitused erinevatele sidusrühmadele

Ülikoolid

• Lisada olemasolevatesse kursustesse agentidest teadlikke tarkvaratehnika mooduleid.
• Säilitada alusprogrammimine ja algoritmid.
• Asendada mõned koodi genereerimise ülesanded ülevaatamis- ja ülekandeülesannetega.
• Nõuda õpilastelt olulise töö selgitamist ja kaitsmist.
• Koolitada õppejõude agentide tööriistade, hindamiskujunduse, privaatsuse ja aususe poliitika osas.
• Ehitada jagatud repositooriumid ja liivakasti keskkonnad.

Intensiivkursused

• Õpetada koos tavapärast arendust ja agendi abiga arendust.
• Muuta testimine, arhitektuur ja turvalisus õppekava keskseteks osadeks.
• Nõuda protsessikirjetega portfoolioprojekte.
• Lisada reaalajas tehnilisi demonstratsioone.
• Õpetada toote avastamist ja nõuete kirjutamist.
• Vältida lubamast, et ainult käsuandmine loob töövalmis insenere.

Sertifitseerimispakkujad

• Suurendada laboratoorsete hindamiste kasutamist.
• Lisada koodi ülevaade, testimine, silumine ja ohu analüüs.
• Kasutada realistlikke repositooriume isoleeritud valikvastustega küsimuste asemel.
• Testida tööriistast sõltumatut otsustusvõimet.
• Lisada lühikesi suulisi selgitusi või salvestatud demonstratsioone.
• Värskendada sisu sageli, ilma et mandaat sõltuks ühe müüja liidesest.

Juhendajad

• Täpsustada täpselt, mis on igal hindamisel lubatud.
• Kujundada ülesanded vastavalt kavandatud õpitulemusele.
• Anda õpilastele heakskiidetud tööriistad või samaväärsed alternatiivid.
• Hinnata protsessi, arutluskäiku ja kontrolli.
• Kasutada logisid tõendina, mitte ainsa tõendusmaterjalina.
• Vältida tehisintellekti tuvastustarkvarale kui peamisele aususe mehhanismile lootmist.

Õppijad ja toodete loojad

• Õppige piisavalt tavapärast programmeerimist, et lugeda ja vaidlustada genereeritud koodi.
• Alustage väikese tootega, mitte ebamäärase, suure rakendusega.
• Kirjutage spetsifikatsioon enne agendi avamist.
• Delegeerige üks probleem korraga.
• Vaadake üle kõik muudatused ja testige kõiki eeldusi.
• Hoidke oluliste otsuste kohta arvestust.
• Käsitlege agenti kui kiiret nooremkoostöötajat, mitte kui vaidlustamatut eksperti.

Esimene järgmine samm

Kellegi jaoks, kes alustab toote loomise teekonda, on kõige kasulikum esimene samm:

Valige üks väike kasutajaprobleem ja kirjutage ühe lehekülje pikkune spetsifikatsioon, enne kui palute agendil koodi kirjutada.

Lisage:

• Kes on kasutaja
• Mis probleem neil on
• Mida peab tegema esimene versioon
• Mida see ei tohi teha
• Kolm vastuvõtutesti
• Üks oluline turvalisuse või privaatsuse mure
• Kolm väikest juurutusülesannet

Seejärel paluge agendil spetsifikatsioon üle vaadata ja tuvastada puuduvad nõuded, mitte ehitada kogu toodet.

Pärast spetsifikatsiooni parandamist delegeerige ainult esimene ülesanne. Vaadake üle pakutud plaan, kontrollige muudatusi, käivitage testid ja kirjutage üles, mida agent valesti tegi.

See üks harjutus õpetab agentide ajastu kõige olulisema õppetunni: tulemuse kvaliteet sõltub vähem sellest, kui palju koodi agent suudab toota, kui sellest, kui selgelt inimene tööd defineerib, juhendab ja hindab.

Kokkuvõte

Arendajate haridus liigub uue tasakaalu poole.

Õpilased peavad endiselt koodi kirjutama, eriti aluskontseptsioone õppides. Kuid professionaalset pädevust demonstreeritakse üha enam probleemide dekomponeerimise, spetsifikatsiooni, koodi mõistmise, ülevaatamise, testimise, orkestreerimise, toote hindamise ja autonoomsete süsteemide vastutustundliku kasutamise kaudu.

Kõige tugevamad õppekavad ei käsitle kodeerimisagente ei petturmasinatena ega maagiliste juhendajatena. Nad käsitlevad neid kui võimsaid, kuid ekslikke inseneritööriistu. Õpilased õpivad, millal neid kasutada, kuidas neid piirata, kuidas nende väljundit hinnata ja kuidas võtta vastutus lõpptoodangu eest.

Järgmise viie aasta kõige püsivam arendaja ei ole inimene, kes suudab käsitsi kõige rohkem koodi toota või kõige pikema käsu genereerida. See on inimene, kes suudab muuta ebaselge eesmärgi usaldusväärseks protsessiks, suunata mitut tööriista selle eesmärgi poole, tuvastada rikke varakult ja selgitada, miks saadud tarkvara väärib usaldust.