Izstrādātāju izglītība un novērtēšana aģentu ērā

Izstrādātāju izglītība un novērtēšana aģentu ērā

Šī analīze atspoguļo izglītības un sertifikācijas ainavu 2026. gada 26. jūlijā.

Ievads

Autonomi kodēšanas aģenti maina programmatūras izstrādi no uzdevuma, kas vērsts uz koda rakstīšanu, uz tādu, kas vērsts uz darba specifikāciju, uzdevumu deleģēšanu, izpildes uzraudzību un rezultātu pārskatīšanu.

Mūsdienu kodēšanas aģenti var pārbaudīt repozitoriju, izstrādāt ieviešanas plānu, modificēt vairākus failus, palaist testus, reaģēt uz kļūdām un atvērt pieprasījumu (pull request) cilvēka pārskatīšanai. GitHub pašreizējā dokumentācija apraksta darbplūsmas, kurās izstrādātāji piešķir aģentiem uzdevumus, uzrauga to darbu, pieprasa koda pārskatīšanu, sniedz atsauksmes un apstiprina vai noraida rezultātu. (docs.github.com)

Tas rada sarežģītu jautājumu izglītībai:

Ja students var lūgt aģentam izveidot strādājošu programmu, kas studentam ir jāsaprot?

Atbilde nav atmest programmēšanas pamatus. Tā ir mainīt to, kam šie pamati tiek izmantoti.

Studentiem joprojām ir jāsaprot datu struktūras, algoritmi, programmēšanas valodas, sistēmu projektēšana, drošība, testēšana un atkļūdošana. Tomēr viņiem arvien vairāk ir jāpielieto šīs zināšanas, lai:

• Sadala neskaidras problēmas pārvaldāmos uzdevumos
• Raksta precīzas specifikācijas un akceptēšanas kritērijus
• Nodrošina noderīgu kontekstu kodēšanas aģentiem
• Izvērtē, vai ģenerētais kods ir pareizs un uzturams
• Izstrādā testus, kas atklāj slēptas kļūmes
• Pārskata drošības, privātuma, veiktspējas un arhitektūras riskus
• Koordinē vairākus aģentus vai rīkus, nezaudējot kontroli
• Izskaidro un aizstāv tehniskos lēmumus

Nākamās paaudzes izstrādātāju izglītībā tiks mazāk novērtēta studenta spēja radīt lielu daudzumu koda un vairāk tiks novērtēta studenta spēja izprast, vadīt, verificēt un uzlabot programmatūras sistēmas.

Centrālā maiņa: no koda ražošanas līdz inženierijas spriedumam

Kodēšanas aģenti nav vienkārši ātrāka automātiskā pabeigšana

Tradicionālie kodēšanas asistenti iesaka rindu, funkciju vai nelielu koda bloku. Autonomi kodēšanas aģenti darbojas lielākā mērogā. Tie var strādāt ar vairākiem failiem, izsaukt izstrādes rīkus, izpildīt testus, pārbaudīt dokumentāciju un turpināt darbu vairākos posmos.

Tas maina darba vienību. Izstrādātāja darbplūsma arvien vairāk izskatās šādi:

1. Izprast lietotāja vai biznesa problēmu.
2. Definēt vēlamo uzvedību.
3. Sadalīt darbu mazākos uzdevumos.
4. Piešķirt atbilstošu uzdevumu aģentam.
5. Pārbaudīt aģenta plānu.
6. Ļaut aģentam veikt ieviešanu kontrolētā vidē.
7. Palaist testus un drošības pārbaudes.
8. Pārskatīt rezultātu.
9. Pieprasīt izmaiņas vai pārskatīt dizainu.
10. Apstiprināt, apvienot un uzraudzīt programmatūru.

Persona, kas izlaiž plānošanas un pārskatīšanas posmus, joprojām var radīt kodu, taču nevar uzticami izveidot uzticamu produktu.

Neapstrādātas koda izvades ierobežojumi

Neapstrādāta koda ražošana kļūst par vājāku spēju mēru, jo aģents var ātri ģenerēt lielu daudzumu ticama koda. Tajā pašā laikā aģentiem joprojām ir grūti tikt galā ar ilgtermiņa programmatūras attīstību, vairāku failu izmaiņām, neskaidrām prasībām un uzvedības uzturēšanu atkārtotu modifikāciju laikā. Kāds 2025. gada etalonpētījums atklāja būtisku plaisu starp aģentu veiktspēju izolētu problēmu risināšanā un sarežģītākiem, ilgtermiņa programmatūras attīstības uzdevumiem. (arxiv.org)

Tas rada svarīgu izglītības atšķirību:

• Students, kurš var ģenerēt kodu, var to nesaprast.
• Students, kurš var izskaidrot, testēt, apstrīdēt un labot kodu, demonstrē dziļāku kompetenci.

Tādējādi izglītības mērķim jākļūst par validētu programmatūras spriedumu, nevis vienkārši veiksmīgu koda ģenerēšanu.

Kā mācību programmas pielāgojas

Universitāšu mācību programmas virzās uz izpratni un verifikāciju

ACM, Elektroinženieru un elektronikas inženieru institūta Datoru biedrības un Mākslīgā intelekta attīstības asociācijas (Association for the Advancement of Artificial Intelligence) 2023. gada datorzinātņu mācību programmu ziņojumā tika paredzēts, ka ģeneratīvais mākslīgais intelekts mainīs programmēšanas izglītību. Tās norādījumi liecina, ka studentiem būs jāpievērš lielāka uzmanība koda lasīšanai, izpratnei, verificēšanai, rediģēšanai, modificēšanai, pielāgošanai un testēšanai. Tas arī identificē problēmu sadalīšanu kā jomu, kas, visticamāk, kļūs svarīgāka. (csed.acm.org)

Tie paši norādījumi izvirza būtisku punktu: pat tad, ja aģents raksta programmu, cilvēks joprojām ir atbildīgs par to, lai noteiktu, vai programma ir pareiza. Tas nozīmē, ka programmēšanas izglītību nevar reducēt tikai uz uzvedņu rakstīšanu. Studentiem ir nepieciešama pietiekama tehniskā izpratne, lai novērtētu izvadi.

Ziņojumā paredzētas arī izmaiņas programmatūras inženierijas izglītībā, tostarp plašāka mākslīgā intelekta izmantošana koda ģenerēšanai, atkļūdošanai, statiskajai analīzei un koda pārskatīšanai. Šo rīku efektīva izmantošana prasa spēcīgākas, nevis vājākas, dizaina un koda izpratnes prasmes. (csed.acm.org)

Akreditācija sāk atalgot plašākus inženierijas rezultātus

Pašreizējie Akreditācijas padomes inženierzinātņu un tehnoloģiju (Accreditation Board for Engineering and Technology) datorzinātņu akreditācijas kritēriji jau uzsver:

• Kompleksu skaitļošanas problēmu analīze
• Skaitļošanas risinājumu projektēšana un novērtēšana
• Profesionālā komunikācija
• Juridiskā un ētiskā atbildība
• Drošība un privātums
• Skaitļošanas sociālā ietekme
• Visaptverošs projekts vai pieredzes komponents (abet.org)

Šie rezultāti ir labi piemēroti uz aģentiem balstītai izstrādes videi, jo tie mēra spriedumu un atbildību, nevis taustiņsitienus.

Sākot ar 2026. gada 26. jūliju, Akreditācijas padomes inženierzinātņu un tehnoloģiju (Accreditation Board for Engineering and Technology) ierosinātās izmaiņas 2026.–2027. gada ciklam ietver papildu mākslīgā intelekta programmas kritērijus un prasību, ka absolventiem jāspēj pielietot mākslīgā intelekta teorijas, modeļus un metodes sarežģītu problēmu risināšanā. Ierosinātās izmaiņas vēl gaidīja galīgo apstiprināšanu, un bija paredzēts, ka tās stāsies spēkā pēc 2026. gada rudens sanāksmes, ar pirmo piemērošanu 2027.–2028. gada pārskatīšanas ciklā. (abet.org)

Iespējamais virziens ir skaidrs: programmām būs jāpierāda, ka studenti var veidot un novērtēt sistēmas, nevis tikai pabeigt izolētus programmēšanas uzdevumus.

Jauni kursi māca aģentu izmantošanu kā inženierijas disciplīnu

Vairāki jaunākie universitātes kursi ilustrē jaunāko tendenci.

Mērilendas Universitātes 2025. gada kurss par efektīvu mākslīgā intelekta kodēšanas asistentu un aģentu izmantošanu aptvēra rīkus, kas var izsaukt būvniecības sistēmas, palaist testus un labot kļūdas. Tas arī aptvēra uzturamību, arhitektūru, lietojumprogrammu programmēšanas saskarnes (API) dizainu, efektivitāti, mērogojamību, drošību, nepārtrauktu integrāciju, koda pārskatīšanu, asinhronus aģentus un automatizētu koda pārskatīšanu. (cs.umd.edu)

Pensilvānijas Universitāte ir ierosinājusi datorzinātņu kursu otrā kursa studentiem, kas vērsts uz mākslīgā intelekta virzītu programmatūras izstrādi. Tās ierosinātās tēmas ietver kodēšanas uzdevumu deleģēšanu, modulāro dizainu, mērogojamu testēšanu, riska pārvaldību, reproducējamību, sadarbību un ētiku. (seas.upenn.edu)

Mičiganas Universitātes 2026. gada rudens kurss "Lietišķā aģentiskā programmatūras inženierija" (Applied Agentic Software Engineering) ir vēl konkrētāks. Tas ir organizēts trīs fāzēs:

1. Efektīvi izmantot kodēšanas aģentus
2. Izveidot aģentu, izmantojot liela valodu modeļa lietojumprogrammu programmēšanas saskarni (API)
3. Projektēt, novērtēt un ieviest aģentu orķestratoru

Kurss izmanto projektus, laboratorijas darbus, demonstrācijas un atzīmju pārbaudes, nevis tradicionālos eksāmenus. Tas norāda, ka vērtēšana atalgotīs izpratni, nevis izvadi, un aicina studentus izskaidrot, kāpēc aģents kļūdījās un kā salabot apkārtējo sistēmu. (eecs498-aase.github.io)

Šī ir būtiska dizaina izmaiņa. Kurss nemāca studentiem ātrāk ražot kodu. Tas māca viņiem kļūt par sistēmu tehniskiem vadītājiem, kas rada kodu.

Kā mainās intensīvās mācību programmas (bootcamps)

Intensīvās mācību programmas (bootcamps) pielāgojas ātrāk nekā daudzas tradicionālās programmas, jo to mācību programmas ir cieši saistītas ar nodarbinātības prasībām. Tomēr pielāgošanās kvalitāte atšķiras.

Mākslīgā intelekta intensīvo mācību programmu modelis

Le Wagon pašreizējā mākslīgā intelekta programmatūras izstrādes intensīvā mācību programma apvieno pilna diapazona izstrādi ar mākslīgā intelekta integrāciju. Tās publicētā mācību programma ietver ar mākslīgā intelekta palīdzību veiktu kodēšanu, liela valodu modeļa integrāciju, ražošanas ieviešanu, izguves papildinātu ģenerēšanu un autonomus mākslīgā intelekta aģentus. (lewagon.com)

Šis modelis uztver mākslīgo intelektu kā diegu, kas caurvij programmu, nevis kā vienu izvēles nodarbību. Paredzams, ka studenti iemācīsies gan:

• Kā darbojas parastās programmatūras sistēmas
• Kā izmantot mākslīgā intelekta rīkus šo sistēmu veidošanai un darbībai

Šī kombinācija ir svarīga. Students, kurš prot tikai darbināt aģentu, var nespēt atpazīt kļūdainu arhitektūru. Students, kurš prot tikai parasto programmēšanu, var nebūt sagatavots mūsdienu izstrādes darbplūsmām.

Modelis “pievienojiet mākslīgā intelekta moduli”

Springboard programmatūras inženierijas intensīvā mācību programma saglabā parasto pamatu tīmekļa izstrādē, lietojumprogrammu programmēšanas saskarnēs (API), priekšgala izstrādē, aizmugures izstrādē un pilna diapazona projektos, vienlaikus pievienojot mākslīgā intelekta moduli, kas vērsts uz uzvedņu inženieriju un sadarbību ar ģeneratīvajiem rīkiem. (springboard.com)

Šis modelis ir noderīgs studentiem, kuriem vispirms nepieciešami spēcīgi programmēšanas pamati. Tas atspoguļo arī praktisko realitāti: daudziem studentiem nevajadzētu sākt ar autonomu aģentu veidošanu. Viņiem vispirms jāmācās, kā darbojas programmatūra, kā izmantot versiju kontroli, kā lasīt kļūdu ziņojumus un kā testēt programmu.

Trūkums ir tas, ka īss uzvedņu inženierijas modulis var kļūt pārāk virspusējs. Nopietnai aģentu ēras mācību programmai jāmāca vairāk nekā tikai tas, kā lūgt kodu. Tai jāmāca:

• Kā izveidot repozitorija konteksta failu
• Kā uzrakstīt tehnisko specifikāciju
• Kā definēt uzdevumu robežas
• Kā ierobežot aģenta atļaujas
• Kā pārbaudīt aģentu plānus
• Kā novērtēt ģenerētos testus
• Kā atklāt drošības problēmas
• Kā salīdzināt alternatīvus dizainus
• Kā dokumentēt aģenta iesaisti

Ko studentiem vajadzētu meklēt intensīvajās mācību programmās

Potenciālajiem studentiem vajadzētu jautāt, vai programma novērtē šādus aspektus:

• Vai studenti var izskaidrot kodu, ko viņi nav personīgi rakstījuši?
• Vai studenti pārskata un labo kļūdainu aģenta izvadi?
• Vai tiek vērtēti testi, drošība un uzturamība?
• Vai ir tiešraides demonstrācija vai tehniskā aizstāvība?
• Vai studenti uztur versiju kontrolētu projekta vēsturi?
• Vai studentiem māca, kā strādāt bez aģenta, ja nepieciešams?
• Vai programma māca produktu atklāšanu un prasību analīzi?
• Vai rīkam specifiskās prasmes ir līdzsvarotas ar ilgtspējīgiem inženierijas principiem?

Programma, kas reklamē “izveidot lietojumprogrammu vienas nedēļas laikā ar mākslīgo intelektu”, var būt lieliska ātrai prototipēšanai, taču tas nav tas pats, kas sagatavot kādu profesionālai programmatūras inženierijai.

Kā pielāgojas sertifikācijas

Sertifikācijas pakalpojumu sniedzēji izstrādā trīs plaša veida akreditācijas.

Rīkiem specifisku zināšanu sertifikāti

Microsoft GitHub Copilot sertifikācija novērtē atbildīgu izmantošanu, Copilot funkcijas, datu arhitektūru, konteksta un uzvedņu veidošanu, izstrādātāju produktivitāti, privātumu, satura izslēgšanu un aizsardzību. Eksāmens tiek uzraudzīts, ilgst simts minūtes un var saturēt interaktīvas komponentes. (learn.microsoft.com)

Šis akreditācijas dokuments atzīst noderīgas zināšanas darba vietā. Tas var parādīt, ka persona saprot, kā atbildīgi izmantot konkrētu izstrādes platformu.

Tā ierobežojums ir tas, ka tas ir cieši saistīts ar vienu produktu. Profesionālim, kurš prot darbināt GitHub Copilot, joprojām var trūkt spējas sadalīt kompleksu produkta prasību, apstrīdēt arhitektūras izvēli vai pārskatīt drošības jutīgu izmaiņu.

Uz platformām balstītas mākslīgā intelekta izstrādes sertifikācijas

AWS Certified Generative AI Developer – Professional sertifikācija ir plašāka. Tās eksāmena ceļvedis ietver pamata modeļa integrāciju, datu pārvaldību, atbilstību, ieviešanu, aģentu mākslīgā intelekta risinājumus, drošību, pārvaldību, testēšanu, problēmu novēršanu, uzraudzību un optimizāciju. (docs.aws.amazon.com)

Tomēr eksāmens galvenokārt ir ar atbilžu variantiem un vairākām atbildēm. Tas ir būtisks zināšanu tests, taču tas pilnībā neparāda, vai kandidāts var izveidot, pārskatīt vai aizstāvēt strādājošu sistēmu. (aws.amazon.com)

Tas ilustrē plašāku problēmu: zināšanu eksāmenus ir vieglāk mērogot nekā veiktspējas eksāmenus. Sertifikācijas organizācijas var efektīvi pārbaudīt terminoloģiju un dizaina principus, taču praktiskai kompetencei ir nepieciešama vide, kurā kandidātiem jāpieņem lēmumi un jātiek galā ar kļūmēm.

Uz laboratorijām un projektiem balstītas akreditācijas

Microsoft Applied Skills akreditācijas nodrošina daudzsološāku modeli. Tās prasa studentiem pabeigt interaktīvus uzdevumus, kas atbilst reālam darbam laboratorijas novērtējumā. Microsoft pozicionē šīs akreditācijas kā pierādījumu tam, ka kandidāts var risināt reālas mākoņdatošanas un mākslīgā intelekta problēmas, nevis vienkārši atcerēties informāciju. (learn.microsoft.com)

Kārnegija Melona universitātes izpildes izglītības Aģentiskā mākslīgā intelekta programma apvieno tiešraides mācības, vadītas laboratorijas, uzdevumus, daudzaģentu darbplūsmas, novērtēšanu, drošības ierobežojumus, žurnālu ierakstus, novērojamību un noslēguma projektu. (execonline.cs.cmu.edu)

Šīs programmas nav identiskas neatkarīgai profesionālajai sertifikācijai, taču tās parāda, kādā virzienā akreditācijas, visticamāk, attīstīsies:

• Īsāki praktiskie novērtējumi
• Smilškastes izstrādes vides
• Reālistiski repozitoriji
• Novērtēšanas un novērojamības uzdevumi
• Noslēguma sistēmas
• Mutiski vai ierakstīti tehniski skaidrojumi
• Atbildīgas rīku izmantošanas pierādījumi

Novērtēšanas tehnikas, kas mēra izpratni

Labākā novērtēšanas stratēģija neaizliedz aģentus no katra uzdevuma. Tā izmanto aģentus tur, kur tie atspoguļo profesionālo praksi, un dažas aktivitātes rezervē neatkarīgas izpratnes mērīšanai.

1. Specifikācijas un sadalīšanas dokumenti

Pirms koda rakstīšanas pieprasiet studentiem iesniegt:

• Lietotāja problēmu
• Funkcionālās prasības
• Nefunkcionālās prasības
• Pieņēmumus
• Ierobežojumus
• Datu struktūras
• Saskarnes
• Akceptēšanas kritērijus
• Uzdevumu sadalījumu
• Zināmos riskus

Dokumentā jāpaskaidro, kāpēc problēma ir sadalīta konkrētos uzdevumos.

Tas mēra, vai students saprot problēmu, pirms lūgt aģentam to ieviest.

2. Aģenta plānošanas kontrolpunkti

Pieprasiet studentiem parādīt aģenta ierosināto plānu pirms ieviešanas sākuma. Studentam jāidentificē:

• Kurš plāna daļa ir pieņemama
• Kurš daļa ir nepilnīga
• Kuri pieņēmumi nav droši
• Kuriem uzdevumiem nepieciešams cilvēka apstiprinājums
• Kuri testi jāpievieno

Galīgajai atzīmei jāatalgo studenta sprieduma kvalitāte, nevis aģenta plāna garums.

3. Koda pārskatīšanas novērtējumi

Dodiet studentiem aģenta ģenerētu repozitoriju, kas satur apzinātus defektus. Defekti var ietvert:

• Nepareiza robežgadījumu apstrāde
• Nedroša autentifikācija
• Slikta kļūdu apstrāde
• Slēptas veiktspējas problēmas
• Dublēta loģika
• Neskaidras saskarnes
• Nepietiekami testi
• Privātuma pārkāpumi
• Atkarības riski

Palūdziet studentiem sagatavot pārskatu ar smaguma līmeņiem, pierādījumiem, ierosinātajiem labojumiem un regresijas testiem.

Tas ir tuvāk profesionālam programmatūras darbam nekā lūgt studentiem izveidot vēl vienu mazu lietojumprogrammu no nulles.

4. Izskaidrojums un mutiskā aizstāvība

Studentam jāspēj izskaidrot:

• Ko sistēma dara
• Kāpēc tika izvēlēta arhitektūra
• Kurš daļas tika ģenerētas
• Kādus pieņēmumus aģents veica
• Kā testi demonstrē pareizību
• Kas vēl varētu kļūdīties
• Kādus kompromisus pieņēma

Īsu mutisku aizstāvību var veikt individuāli vai mazās grupās. Tai nav jābūt biedējošai. Pieci līdz desmit mērķtiecīgi jautājumi bieži vien ir pietiekami, lai atklātu, vai students saprot iesniegto darbu.

5. Pārneses uzdevumi

Pēc tam, kad students pabeidz ar aģentu palīdzību veiktu projektu, sniedziet jaunu prasību, ko nevar atrisināt, vienkārši atkārtojot sākotnējo uzvedni.

Piemēram:

• Pievienot jaunu datu avotu
• Mainīt veiktspējas mērķi
• Atbalstīt negaidītu ievades formātu
• Noņemt atkarību
• Pievienot piekļuves kontroli
• Izskaidrot kļūdainu testu
• Refaktorēt moduli, nemainot tā uzvedību

Students var izmantot aģentu, taču viņam jāizskaidro plāns, jāpārbauda izmaiņas un jāaizstāv rezultāts.

Pārneses uzdevumi mēra, vai students iemācījies vispārēju metodi, nevis iegaumējis veiksmīgu mijiedarbību.

6. Testu izstrāde un pretinieku testēšana

Studenti jāvērtē pēc viņu testu kvalitātes, nevis tikai pēc tā, vai ģenerētais kods iztur norādītos testus.

Noderīgas prasības ietver:

• Rakstīt robežtestus
• Izveidot negatīvus testus
• Testēt nederīgu ievadi
• Testēt kļūmes atkopšanu
• Pārbaudīt veiktspējas pieņēmumus
• Izmantot uz īpašībām balstītus testus, ja tas ir piemēroti
• Testēt drošības jutīgu uzvedību
• Izskaidrot, kas paliek netestēts

Galvenais jautājums nav “Vai kods izturēja?”, bet gan “Vai students zināja, kas jātestē?”

7. Versiju vēsture un procesu portfeļi

Projekta portfelis var ietvert:

• Sākotnējo specifikāciju
• Uzdevumu sadalījumu
• Aģenta plānus
• Galvenās uzvednes vai instrukcijas
• Veiktās izmaiņas (commits)
• Testu rezultātus
• Pārskatīšanas komentārus
• Neizdevušās pieejas
• Dizaina izmaiņas
• Galīgo pārdomu

Procesu portfelim nevajadzētu kļūt par prasību iesniegt katru privātās sarunas rindu. Reprezentatīvs ieraksts bieži vien ir noderīgāks nekā milzīgs stenogramma.

Prinstonas 2025. gada programmēšanas kurss, piemēram, atļāva ģeneratīvā mākslīgā intelekta rīkus, bet pieprasīja studentiem aprakstīt to izmantošanu readme failā ar reprezentatīvu kopsavilkumu, nevis izsmeļošu stenogrammu. (cs.princeton.edu)

8. Strukturēta savstarpējā pārskatīšana

Savstarpējā pārskatīšana pārvērš studentus no koda radītājiem par koda kritiķiem. Sākotnējie pētījumi liecina, ka uz rubrikām balstīta savstarpējā vērtēšana var aptuveni atdarināt instruktora vērtējumu ar mērenu precizitāti, vienlaikus attīstot novērtēšanas domāšanu un iesaistīšanos. (arxiv.org)

Studentiem jāpieprasa pamatot savus komentārus ar pierādījumiem. “Šis kods ir slikts” nav pārskats. “Šī funkcija veic datubāzes vaicājumu ciklā, radot iespējamu veiktspējas problēmu, kad kolekcija palielinās” ir pārskats.

9. Uzvedņu un specifikāciju problēmas

Uzvedņu problēmas ir programmēšanas uzdevumi, kuros studenti raksta dabiskās valodas instrukcijas, kas liek mākslīgā intelekta sistēmai ģenerēt kodu, kas atbilst specifikācijai. Šī pieeja tieši māca studentiem, kā komunicēt skaitļošanas prasības koda ģenerēšanas sistēmām. (arxiv.org)

Tas var būt noderīgi, taču tai nevajadzētu būt vienīgajai novērtēšanas metodei. 2026. gada pētījumā, kurā piedalījās vairāk nekā deviņi simti studentu, atklājās, ka biežas kļūdas ietvēra svarīgu detaļu izlaišanu no uzvednēm. Kad ģenerētais kods kļūdījās, studenti bieži koncentrējās uz savu nodomu precizēšanu, nevis koda izsekošanu vai testu gadījumu pārbaudi. (arxiv.org)

Tādējādi uzvedņu veidošana var atklāt sadalīšanas un komunikācijas prasmes, taču tā jāapvieno ar koda lasīšanu, testēšanu, atkļūdošanu un pārskatīšanu.

Parauga novērtēšanas struktūra

Praktisks projekts varētu izmantot šādu svērumu:

Šī struktūra joprojām atalgo strādājošu produktu, taču tā neļauj studentam saņemt augstu atzīmi tikai tāpēc, ka aģents ir radījis lielu koda bāzi.

Akadēmiskā integritāte mācību darbā ar aģentu palīdzību

Vispārēji aizliegumi un neierobežota izmantošana ir nepietiekami

Vispārējs aizliegums var būt piemērots konkrētam fundamentālam novērtējumam, īpaši, ja mācību mērķis ir neatkarīga programmēšanas prakse. Tomēr universālu aizliegumu ir arvien grūtāk ieviest un tas var liegt studentiem apgūt rīkus, ar kuriem viņi saskarsies profesionālajā darbā.

Neierobežota izmantošana arī ir nepietiekama. Ja studenti var iesniegt aģenta radītu darbu bez paskaidrojuma, novērtējums var mērīt piekļuvi rīkam, nevis mācīšanos.

Spēcīgākā pieeja ir skaidra, uzdevumam atbilstoša politika.

Trīs noderīgi politikas režīmi

Pirmais režīms: Aģents aizliegts

Izmantojiet to šādiem mērķiem:

• Eksāmeni
• Fundamentālas programmēšanas drilles
• Individuālas atkļūdošanas demonstrācijas
• Pamata algoritmu uzdevumi
• Novērtējumi, kas paredzēti neatkarīgas atmiņas vai ieviešanas mērīšanai

Kārnegija Melona kursā “Imperatīvās skaitļošanas principi” (Principles of Imperative Computation) mākslīgā intelekta rīki ir aizliegti jebkurai vērtējamā darba daļai, tostarp risinājumu ģenerēšanai, risinājumu skaidrošanai, koda formatēšanai un testu gadījumu ģenerēšanai. (cs.cmu.edu)

Otrais režīms: Aģents ierobežots

Izmantojiet to, ja studenti var jautāt par:

• Koncepciju skaidrojumiem
• Dokumentācijas palīdzību
• Kļūdu ziņojumu interpretāciju
• Bibliotēku vai lietojumprogrammu programmēšanas saskarņu (API) precizēšanu
• Ideju vākšanu (brainstorming)
• Studenta radīta dizaina kritiku
• Nelielu refaktorēšanu

Kārnegija Melona sistēmu kursi atļauj mākslīgā intelekta rīkus API, bibliotēku, ietvaru, nodrošinātā koda un kļūdu ziņojumu izpratnei, vienlaikus aizliedzot pieprasīt daļējus vai pilnīgus uzdevumu risinājumus. (cs.cmu.edu)

Trešais režīms: Aģents atļauts ar atklāšanu

Izmantojiet to reālistiskiem programmatūras inženierijas projektiem. Pieprasiet studentiem atklāt:

• Kuri rīki tika izmantoti
• Kuri uzdevumi tika deleģēti
• Vai ģenerētais kods tika kopēts, modificēts vai pārrakstīts
• Kā izvade tika testēta
• Ko students iemācījās
• Kurš dizaina daļas paliek studenta atbildībā

Prinstonas zinātniskās integritātes norādījumos teikts, ka atļautā mākslīgā intelekta izmantošana joprojām ir jāatklāj un ka ģenerētas izvades pasniegšana kā savējās vai izmantošanas neatklāšana var būt integritātes pārkāpums. (scholarlyintegrity.princeton.edu)

Hārvardas Absolventu izglītības skola līdzīgi atļauj izmantot, piemēram, precizēšanai, ideju vākšanai un izpētei, vienlaikus aizliedzot studentiem iesniegt ar mākslīgā intelekta ģenerētu kursa darbu kā savu. Tā arī prasa dokumentēt atļauto izmantošanu un brīdina, ka studenti joprojām ir atbildīgi par precizitāti, privātumu, autortiesībām un neobjektivitāti. (registrar.gse.harvard.edu)

Praktisks atklāšanas paziņojums

Kurss var nodrošināt vienkāršu veidni:

Es izmantoju [rīka nosaukums], lai veiktu [plānošanu, atkļūdošanu, koda ģenerēšanu, testēšanu, dokumentāciju vai pārskatīšanu]. Es deleģēju [konkrētus uzdevumus]. Es pārskatīju un modificēju izvadi, testēju iegūto sistēmu un palieku atbildīgs par iesniegtā darba precizitāti, drošību un oriģinalitāti.

Studentiem nevajadzētu pieprasīt atklāt parastu pareizrakstības labošanu tādā pašā veidā kā deleģētu ieviešanu. Politikām jānošķir neliela palīdzība un būtiska kognitīvā vai tehniskā ieguldījums.

Privātums un vienlīdzīga piekļuve

Institūcijām jānodrošina apstiprināti rīki vai alternatīvas. Studentiem nevajadzētu pieprasīt augšupielādēt konfidenciālus kursa darbus, personisko informāciju, nepublicētus pētījumus vai patentētu kodu publiskās sistēmās.

UNESCO norādījumos aicināts izmantot uz cilvēku vērstu pieeju, kas risina privātuma, drošības, taisnīguma, iekļaušanas un institucionālās sagatavotības jautājumus. (unesco.org)

Kursiem jāņem vērā arī studenti, kuri nevar atļauties vairākus maksas rīkus. Godīgs kurss var:

• Nodrošināt kopīgu institucionālo rīku
• Piedāvāt lokālu vai atvērtā koda alternatīvu
• Izstrādāt uzdevumus, kas nav atkarīgi no viena piegādātāja
• Vērtēt spriešanas spējas, nevis piekļuvi jaudīgākajam modelim
• Atļaut ne-aģentu ceļus katram būtiskam mācību rezultātam

Praktiskās metodes aģentu produktīvai iekļaušanai

Izmantojiet kontrolētu repozitoriju

Dodiet studentiem repozitoriju, kas satur:

• Skaidru readme failu
• Mazu, bet reālistisku koda bāzi
• Automatizētus testus
• Nepārtrauktas integrācijas darbplūsmu
• Zināmo problēmu sarakstu
• Stila vadlīnijas
• Drošības kontrolsarakstu
• Izmaiņu žurnālu

Tas padara aģentu izmantošanu novērojamu un dod studentiem kaut ko reālistiskāku par tukšu kodēšanas uzdevumu.

Pieprasiet plānu pirms ieviešanas

Studentiem nevajadzētu sākt, lūdzot aģentam “izveidot visu lietojumprogrammu”. Pieprasiet secību:

1. Palūdziet aģentam pārbaudīt repozitoriju.
2. Palūdziet arhitektūras kopsavilkumu.
3. Palūdziet informāciju par riskiem un trūkumiem.
4. Uzrakstiet studenta paša uzdevumu plānu.
5. Apstipriniet vienu mazu ieviešanas uzdevumu.
6. Pārskatiet iegūtās izmaiņas.
7. Pirms turpināšanas palaidiet testus.

Tas māca kontrolētu deleģēšanu, nevis aklo deleģēšanu.

Izmantojiet aģentu komandu ar skaidrām lomām

Vienkāršs orķestrēšanas modelis var ietvert:

• Plānotājs: ierosina uzdevumu sadalījumu
• Ieviesējs: modificē kodu
• Testētājs: izveido un palaiž testus
• Pārskatītājs: meklē defektus un riskus
• Cilvēka vērtētājs: apstiprina vai noraida izmaiņas

Studentiem jāmācās, ka vairāku aģentu pievienošana automātiski neuzlabo kvalitāti. Vairāki aģenti var radīt pretrunīgas instrukcijas, dubultu darbu, palielinātas izmaksas un neskaidru atbildību.

Izglītības mērķis nav izveidot lielāko daudzaģentu sistēmu. Tas ir izvēlēties vienkāršāko darbplūsmu, kas nodrošina uzticamus rezultātus.

Izveidot cilvēka apstiprinājuma vārtus

Pieprasiet skaidru apstiprinājumu, pirms aģents var:

• Mainīt autentifikāciju
• Modificēt datu shēmas
• Pievienot atkarības
• Piekļūt ražošanas sistēmām
• Mainīt ieviešanas konfigurāciju
• Dzēst failus
• Apvienot pieprasījumu (pull request)

Tas māca studentiem, ka autonomija jāierobežo ar atļaujām un pārskatīšanu.

Apzināti vērtēt kļūmes

Aģenti ir visizglītojošākie, ja tie kļūdās informatīvi. Instruktoriem jāiekļauj:

• Neskaidras prasības
• Pretrunīgi ierobežojumi
• Nepilnīgi testi
• Drošības jutīgas darbības
• Maldinoša dokumentācija
• Nestabili testi
• Veiktspējas ierobežojumi
• Izmaiņas, kas šķiet pareizas, bet sabojā citu funkciju

Studenta uzdevums ir diagnosticēt kļūmi un uzlabot procesu.

Kompetenču ietvars 2026. līdz 2031. gadam

Šis ietvars ir paredzēts, lai saglabātu noderīgumu pat tad, ja konkrēti rīki mainās.

Pirmā joma: Tehniskie pamati un koda pratība

Kompetents izstrādātājs var:

• Lasīt nepazīstamu kodu
• Izskaidrot vadības plūsmu un datu plūsmu
• Izprast saskarnes un atkarības
• Analizēt algoritmisko sarežģītību
• Izmantot versiju kontroli
• Atkļūdot, pilnībā nepaļaujoties uz aģentu

Pierādījumi: koda skaidrojums, manuāls atkļūdošanas uzdevums, dizaina kritika un individuāls pārneses vingrinājums.

Otrā joma: Problēmas formulēšana un sadalīšana

Kompetents izstrādātājs var:

• Precizēt lietotāju mērķus
• Identificēt ierobežojumus un pieņēmumus
• Atdalīt būtiskās no izvēles prasībām
• Sadalīt darbu neatkarīgi testējamos uzdevumos
• Definēt akceptēšanas kritērijus
• Atpazīt, kad uzdevums ir pārāk plašs uzticamai deleģēšanai

Pierādījumi: specifikācija, uzdevumu grafiks, riska reģistrs un sadalīšanas izvēles skaidrojums.

Trešā joma: Aģenta vadība un konteksta inženierija

Kompetents izstrādātājs var:

• Nodrošināt atbilstošu repozitorija kontekstu
• Sniegt precīzas instrukcijas
• Definēt robežas un atļaujas
• Izvēlēties, kad izmantot aģentu un kad neizmantot
• Salīdzināt alternatīvus plānus
• Atjaunoties, ja aģents seko nepareizai interpretācijai

Pierādījumi: plānošanas kontrolpunkti, reprezentatīvi mijiedarbības ieraksti un tiešsaistes pārskatīšanas uzdevums.

Ceturtā joma: Verifikācija un pārskatīšana

Kompetents izstrādātājs var:

• Pārbaudīt ģenerēto kodu
• Izstrādāt jēgpilnus testus
• Identificēt slēptos pieņēmumus
• Pārskatīt drošības un privātuma riskus
• Novērtēt uzturamību
• Izskaidrot, ko testi neapliecina

Pierādījumi: koda pārskatīšana, pretinieku testi, defektu meklēšanas vingrinājums un mutiskā aizstāvība.

Piektā joma: Orķestrēšana un operācijas

Kompetents izstrādātājs var:

• Koordinēt plānošanas, ieviešanas, testēšanas un pārskatīšanas rīkus
• Izmantot kontrolpunktus un cilvēka apstiprinājuma vārtus
• Izsekot izmaksas, laiku un rīku uzvedību
• Uzturēt reproducējamas darbplūsmas
• Novērot kļūmes un uzlabot sistēmu
• Izlemt, vai vairāki aģenti rada pievienoto vērtību

Pierādījumi: strādājoša orķestrēšanas darbplūsma, žurnāli, novērtējuma ziņojums un izmaksu vai veiktspējas analīze.

Sestā joma: Produkta un sistēmu dizains

Kompetents izstrādātājs var:

• Izvēlēties atbilstošu automatizācijas līmeni
• Projektēt modulāras sistēmas
• Līdzsvarot ātrumu, kvalitāti, izmaksas un risku
• Savienot tehniskos lēmumus ar lietotāju rezultātiem
• Atpazīt, kad vienkāršs ne-aģenta risinājums ir labāks

Pierādījumi: produkta kopsavilkums, arhitektūras lēmuma ieraksts, prototips un uz lietotāju vērsta demonstrācija.

Septītā joma: Atbildīga profesionālā prakse

Kompetents izstrādātājs var:

• Atklāt mākslīgā intelekta palīdzību
• Aizsargāt privātu un patentētu informāciju
• Ievērot autortiesību un licencēšanas saistības
• Identificēt neobjektivitāti un uzticamības riskus
• Komunicēt neskaidrības
• Uzņemties atbildību par galīgo sistēmu

Pierādījumi: atklāšanas paziņojums, riska novērtējums, privātuma pārskats un profesionāla prezentācija.

Ieteiktie meistarības līmeņi

Līdz 2031. gadam profesionālai akreditācijai vajadzētu demonstrēt virzību caur šiem līmeņiem, nevis vienkārši apstiprināt zināšanas par konkrētu programmatūras rīku.

Ieteikumi dažādām ieinteresētajām personām

Universitātes

• Pievienot esošajiem kursiem ar aģentiem apzinātas programmatūras inženierijas moduļus.
• Saglabāt fundamentālo programmēšanu un algoritmus.
• Aizstāt dažus koda ģenerēšanas uzdevumus ar pārskatīšanas un pārneses uzdevumiem.
• Pieprasīt studentiem izskaidrot un aizstāvēt svarīgu darbu.
• Apmācīt docētājus aģentu rīkos, novērtēšanas dizainā, privātumā un integritātes politikā.
• Izveidot kopīgus repozitorijus un smilškastes vides.

Intensīvās mācību programmas (bootcamps)

• Mācīt parasto izstrādi un ar aģentu palīdzību veikto izstrādi kopā.
• Padarīt testēšanu, arhitektūru un drošību par centrālajām mācību programmas daļām.
• Pieprasīt portfeļa projektus ar procesu ierakstiem.
• Pievienot tiešraides tehniskās demonstrācijas.
• Mācīt produktu atklāšanu un prasību rakstīšanu.
• Izvairīties no solījumiem, ka tikai uzvedņu veidošana rada darbam gatavus inženierus.

Sertifikācijas pakalpojumu sniedzēji

• Palielināt uz laboratorijām balstītu novērtējumu izmantošanu.
• Iekļaut koda pārskatīšanu, testēšanu, atkļūdošanu un draudu analīzi.
• Izmantot reālistiskus repozitorijus, nevis izolētus jautājumus ar atbilžu variantiem.
• Testēt no rīkiem neatkarīgu spriedumu.
• Pievienot īsus mutiskus skaidrojumus vai ierakstītas demonstrācijas.
• Bieži atjaunināt saturu, nepadarot akreditāciju atkarīgu no viena pārdevēja saskarnes.

Instruktori

• Precīzi norādīt, kas ir atļauts katrā novērtējumā.
• Izstrādāt uzdevumus atbilstoši paredzētajam mācību rezultātam.
• Nodrošināt studentiem apstiprinātus rīkus vai līdzvērtīgas alternatīvas.
• Novērtēt procesu, spriešanas spējas un verifikāciju.
• Izmantot žurnālus kā pierādījumus, nevis kā vienīgo pierādījumu.
• Izvairīties paļauties uz mākslīgā intelekta noteikšanas programmatūru kā primāro integritātes mehānismu.

Studenti un produktu radītāji

• Iemācīties pietiekami daudz parastās programmēšanas, lai lasītu un apstrīdētu ģenerēto kodu.
• Sākt ar mazu produktu, nevis ar neskaidru, lielu lietojumprogrammu.
• Uzrakstīt specifikāciju pirms aģenta atvēršanas.
• Deleģēt vienu uzdevumu vienlaicīgi.
• Pārskatīt katru izmaiņu un testēt katru pieņēmumu.
• Saglabāt svarīgo lēmumu ierakstu.
• Uztvert aģentu kā ātru jaunāko kolēģi, nevis kā neapstrīdamu ekspertu.

Pirmais nākamais solis

Kādam, kurš sāk produkta radīšanas ceļojumu, visnoderīgākais pirmais solis ir:

Izvēlieties vienu mazu lietotāja problēmu un uzrakstiet vienas lapas specifikāciju, pirms lūgt aģentam rakstīt kodu.

Iekļaujiet:

• Kas ir lietotājs
• Kāda problēma viņam ir
• Kas jādara pirmajai versijai
• Kas tai nedrīkst darīt
• Trīs akceptēšanas testus
• Vienu svarīgu drošības vai privātuma apsvērumu
• Trīs mazus ieviešanas uzdevumus

Pēc tam lūdziet aģentam pārskatīt specifikāciju un identificēt trūkstošās prasības, nevis izveidot visu produktu.

Pēc specifikācijas labošanas deleģējiet tikai pirmo uzdevumu. Pārskatiet ierosināto plānu, pārbaudiet izmaiņas, palaidiet testus un pierakstiet, ko aģents izdarījis nepareizi.

Šis viens vingrinājums māca vissvarīgāko aģentu ēras mācību: rezultāta kvalitāte ir mazāk atkarīga no tā, cik daudz koda aģents var radīt, un vairāk no tā, cik skaidri cilvēks definē, uzrauga un novērtē darbu.

Secinājums

Izstrādātāju izglītība virzās uz jaunu līdzsvaru.

Studentiem joprojām būs jāraksta kods, īpaši apgūstot pamata jēdzienus. Bet profesionālā kompetence arvien vairāk tiks demonstrēta caur problēmu sadalīšanu, specifikāciju, koda izpratni, pārskatīšanu, testēšanu, orķestrēšanu, produkta spriedumu un autonomo sistēmu atbildīgu izmantošanu.

Spēcīgākās mācību programmas neuztvers kodēšanas aģentus ne kā krāpšanās mašīnas, ne kā maģiskus pasniedzējus. Tās tos uztvers kā jaudīgus, bet kļūdīties spējīgus inženierijas rīkus. Studenti mācīsies, kad tos izmantot, kā tos ierobežot, kā novērtēt to izvadi un kā uzņemties atbildību par galīgo sistēmu.

Nākamajos piecos gados visnoturīgākais izstrādātājs nebūs tas, kurš ar rokām var radīt visvairāk koda vai ģenerēt garāko uzvedni. Tas būs tas, kurš neskaidru mērķi var pārvērst par uzticamu procesu, vadīt vairākus rīkus šī mērķa virzienā, agri atklāt kļūmes un izskaidrot, kāpēc iegūtā programmatūra ir pelnījusi uzticību.