Kūrėjų švietimas ir vertinimas agentų eroje

Kūrėjų švietimas ir vertinimas agentų eroje

Ši analizė atspindi švietimo ir sertifikavimo aplinką 2026 m. liepos 26 d.

Įvadas

Autonominiai kodavimo agentai keičia programinės įrangos kūrimą iš užduoties, orientuotos į kodo rašymą, į užduotį, orientuotą į darbo specifikavimą, užduočių delegavimą, vykdymo priežiūrą ir rezultatų peržiūrą.

Šiuolaikiniai kodavimo agentai gali tikrinti saugyklą, kurti įgyvendinimo planą, modifikuoti kelis failus, vykdyti testus, reaguoti į klaidas ir atidaryti „pull“ užklausą žmogaus peržiūrai. Dabartinė „GitHub“ dokumentacija aprašo darbo eigas, kuriose kūrėjai priskiria problemas agentams, stebi jų darbą, prašo kodo peržiūros, teikia atsiliepimus ir patvirtina arba atmeta rezultatą. (docs.github.com)

Tai kelia sudėtingą klausimą švietimui:

Jei studentas gali paprašyti agento sukurti veikiančią programą, ką studentas turėtų suprasti?

Atsakymas – neatsisakyti programavimo pagrindų. Reikia pakeisti tai, kam tie pagrindai naudojami.

Studentams vis dar reikia suprasti duomenų struktūras, algoritmus, programavimo kalbas, sistemų projektavimą, saugumą, testavimą ir derinimo procesą. Tačiau jiems vis dažniau reikia pritaikyti šias žinias, kad:

• Išskaidytų neaiškias problemas į valdomas užduotis
• Parašytų tikslias specifikacijas ir priėmimo kriterijus
• Pateiktų naudingą kontekstą kodavimo agentams
• Įvertintų, ar sugeneruotas kodas yra teisingas ir palaikomas
• Sukurtų testus, atskleidžiančius paslėptus gedimus
• Peržiūrėtų saugumo, privatumo, našumo ir architektūros rizikas
• Koordinuotų kelis agentus ar įrankius neprarasdamas kontrolės
• Paaiškintų ir apgintų techninius sprendimus

Todėl kitos kartos kūrėjų švietimas mažiau vertins studentų gebėjimą kurti didelius kodo kiekius, o daugiau – studentų gebėjimą suprasti, valdyti, patikrinti ir tobulinti programinės įrangos sistemas.

Pagrindinis pokytis: nuo kodo gamybos iki inžinerinio sprendimo

Kodavimo agentai nėra tiesiog greitesnis automatinis užbaigimas

Tradiciniai kodavimo asistentai siūlo eilutę, funkciją ar nedidelį kodo bloką. Autonominiai kodavimo agentai veikia didesniu mastu. Jie gali dirbti su keliais failais, iškviesti kūrimo įrankius, vykdyti testus, tikrinti dokumentaciją ir tęsti veiksmus per kelis etapus.

Tai keičia darbo vienetą. Kūrėjo darbo eiga vis labiau atrodo taip:

1. Suprasti vartotojo ar verslo problemą.
2. Apibrėžti norimą elgseną.
3. Skaidyti darbą į mažesnes užduotis.
4. Priskirti tinkamą užduotį agentui.
5. Patikrinti agento planą.
6. Leisti agentui įgyvendinti kontroliuojamoje aplinkoje.
7. Paleisti testus ir saugumo patikrinimus.
8. Peržiūrėti rezultatą.
9. Prašyti pakeitimų arba peržiūrėti dizainą.
10. Patvirtinti, sujungti ir stebėti programinę įrangą.

Asmuo, praleidžiantis planavimo ir peržiūros etapus, vis tiek gali sukurti kodą, tačiau negali patikimai sukurti patikimo produkto.

Neapdoroto kodo išvesties apribojimai

Neapdoroto kodo gamyba tampa silpnesniu gebėjimo matu, nes agentas gali greitai sugeneruoti didelį kiekį tikėtino kodo. Tuo pat metu agentams vis dar sunku tvarkytis su ilgalaike programinės įrangos evoliucija, kelių failų pakeitimais, neaiškiais reikalavimais ir elgsenos išlaikymu atliekant pakartotinius pakeitimus. Vienas 2025 m. etaloninis tyrimas nustatė didelį skirtumą tarp agentų našumo sprendžiant izoliuotas problemas ir atliekant sudėtingesnes, ilgalaikes programinės įrangos evoliucijos užduotis. (arxiv.org)

Tai sukuria svarbų edukacinį skirtumą:

• Studentas, galintis generuoti kodą, gali jo nesuprasti.
• Studentas, galintis paaiškinti, išbandyti, užginčyti ir pataisyti kodą, demonstruoja gilesnę kompetenciją.

Todėl edukacinis tikslas turėtų būti patvirtintas programinės įrangos vertinimas, o ne tiesiog sėkmingas kodo generavimas.

Kaip prisitaiko mokymo programos

Universiteto mokymo programos juda link supratimo ir patvirtinimo

ACM, IEEE Kompiuterių draugijos ir Dirbtinio intelekto plėtros asociacijos 2023 m. kompiuterių mokslo mokymo programų ataskaitoje numatyta, kad generatyvinis dirbtinis intelektas pakeis programavimo švietimą. Jos gairėse teigiama, kad studentams reikės daugiau dėmesio skirti kodo skaitymui, supratimui, tikrinimui, redagavimui, modifikavimui, pritaikymui ir testavimui. Ji taip pat nurodo, kad problemų skaidymas yra sritis, kuri greičiausiai taps svarbesnė. (csed.acm.org)

Tos pačios gairės pabrėžia esminį dalyką: net kai agentas rašo programą, žmogus lieka atsakingas už tai, ar programa yra teisinga. Tai reiškia, kad programavimo švietimo negalima sumažinti iki instrukcijų rašymo. Studentams reikia pakankamai techninių žinių, kad galėtų įvertinti išvestį.

Ataskaita taip pat numato pokyčius programinės įrangos inžinerijos švietime, įskaitant didesnį dirbtinio intelekto naudojimą kodo generavimui, derinimui, statinei analizei ir kodo peržiūrai. Efektyvus šių įrankių naudojimas reikalauja stipresnių dizaino ir kodo supratimo įgūdžių, o ne silpnesnių. (csed.acm.org)

Akreditacija pradeda skatinti platesnius inžinerijos rezultatus

Dabartiniai inžinerijos ir technologijų akreditavimo tarybos (ABET) skaičiavimo akreditavimo kriterijai jau pabrėžia:

• Kompleksinių skaičiavimo problemų analizė
• Skaičiavimo sprendimų projektavimas ir vertinimas
• Profesionali komunikacija
• Teisinė ir etinė atsakomybė
• Saugumas ir privatumas
• Socialinis skaičiavimo poveikis
• Išsamus projektas arba patirtinis komponentas (abet.org)

Šie rezultatai puikiai tinka agentais pagrįstai kūrimo aplinkai, nes jie vertina sprendimo priėmimą ir atsakomybę, o ne klavišų paspaudimus.

2026 m. liepos 26 d. duomenimis, siūlomi Inžinerijos ir technologijų akreditavimo tarybos pakeitimai 2026–2027 m. ciklui apima papildomus dirbtinio intelekto programos kriterijus ir reikalavimą, kad absolventai gebėtų pritaikyti dirbtinio intelekto teorijas, modelius ir metodus sudėtingoms problemoms spręsti. Siūlomi pakeitimai dar laukė galutinio patvirtinimo ir tikimasi, kad jie įsigalios po 2026 m. rudens posėdžio, pirmą kartą bus taikomi 2027–2028 m. peržiūros cikle. (abet.org)

Tikėtina kryptis yra aiški: programos turės parodyti, kad studentai gali kurti ir vertinti sistemas, o ne tik atlikti izoliuotus programavimo pratimus.

Nauji kursai moko agentų naudojimo kaip inžinerijos disciplinos

Keletas naujausių universitetinių kursų iliustruoja besiformuojantį modelį.

Merilendo universiteto 2025 m. kursas apie efektyvų dirbtinio intelekto kodavimo asistentų ir agentų naudojimą apėmė įrankius, kurie gali iškviesti kūrimo sistemas, vykdyti testus ir taisyti klaidas. Jame taip pat buvo nagrinėjami palaikomumo, architektūros, programos sąsajos (API) projektavimo, efektyvumo, mastelio keitimo, saugumo, nepertraukiamos integracijos, kodo peržiūros, asinchroninių agentų ir automatinės kodo peržiūros klausimai. (cs.umd.edu)

Pensilvanijos universitetas pasiūlė antrojo kurso kompiuterių mokslo kursą, skirtą dirbtinio intelekto valdomam programinės įrangos kūrimui. Siūlomos temos apima kodavimo užduočių delegavimą, modulinį projektavimą, mastelio keitimo testavimą, rizikos valdymą, atkuriamumą, bendradarbiavimą ir etiką. (seas.upenn.edu)

Mičigano universiteto 2026 m. rudens kursas „Taikomoji agentinė programinės įrangos inžinerija“ (Applied Agentic Software Engineering) yra dar aiškesnis. Jis suskirstytas į tris etapus:

1. Efektyviai naudoti kodavimo agentus
2. Sukurti agentą naudojant didelio kalbos modelio programos sąsają (API)
3. Projektuoti, vertinti ir diegti agentų orkestratorių

Kurse naudojami projektai, laboratorijos, demonstracijos ir patikrinimai vietoj tradicinių egzaminų. Jame teigiama, kad vertinimas atlygins už supratimą, o ne už rezultatą, ir prašoma studentų paaiškinti, kodėl agentas nepavyko ir kaip pataisyti aplinkinę sistemą. (eecs498-aase.github.io)

Tai yra reikšmingas dizaino pakeitimas. Kursas nemoko studentų greičiau kurti kodo. Jis moko juos tapti techniniais sistemų, kurios generuoja kodą, prižiūrėtojais.

Kaip keičiasi praktiniai mokymai

Praktiniai mokymai prisitaiko greičiau nei daugelis tradicinių programų, nes jų mokymo programos glaudžiai susijusios su įsidarbinimo reikalavimais. Tačiau prisitaikymo kokybė skiriasi.

Specializuoto dirbtinio intelekto praktinio mokymo modelis

Dabartiniai „Le Wagon“ dirbtinio intelekto programinės įrangos kūrimo praktiniai mokymai sujungia „full-stack“ kūrimą su dirbtinio intelekto integravimu. Paskelbta mokymo programa apima dirbtinio intelekto pagalba atliekamą kodavimą, didelių kalbos modelių integravimą, gamybinį diegimą, generavimą su papildoma informacija (retrieval-augmented generation) ir autonominius dirbtinio intelekto agentus. (lewagon.com)

Šis modelis dirbtinį intelektą traktuoja kaip per visą programą besitęsiantį elementą, o ne kaip vieną pasirenkamą pamoką. Tikimasi, kad studentai išmoks ir:

• Kaip veikia įprastos programinės įrangos sistemos
• Kaip naudoti dirbtinio intelekto įrankius toms sistemoms kurti ir valdyti

Šis derinys yra svarbus. Besimokantysis, kuris moka tik valdyti agentą, gali neatpažinti ydingos architektūros. Besimokantysis, kuris moka tik įprastą programavimą, gali būti nepasirengęs šiuolaikinėms kūrimo darbo eigoms.

„Dirbtinio intelekto modulio pridėjimo“ modelis

„Springboard“ programinės įrangos inžinerijos praktiniai mokymai išlaiko įprastus pagrindus žiniatinklio kūrime, programų sąsajose (API), „front-end“ kūrime, „back-end“ kūrime ir „full-stack“ projektuose, pridėdami dirbtinio intelekto modulį, skirtą instrukcijų (prompt) inžinerijai ir bendradarbiavimui su generatyviniais įrankiais. (springboard.com)

Šis modelis yra naudingas besimokantiesiems, kuriems pirmiausia reikia tvirtų programavimo pagrindų. Jis taip pat atspindi praktinę realybę: daugelis studentų neturėtų pradėti nuo autonominių agentų kūrimo. Pirmiausia jie turėtų išmokti, kaip veikia programinė įranga, kaip naudoti versijų kontrolę, kaip skaityti klaidų pranešimus ir kaip testuoti programą.

Trūkumas yra tas, kad trumpas „prompt“ inžinerijos modulis gali tapti per daug paviršutiniškas. Rimta agentų eros mokymo programa turėtų mokyti daugiau nei tik to, kaip prašyti kodo. Ji turėtų mokyti:

• Kaip sukurti saugyklos konteksto failą
• Kaip parašyti techninę specifikaciją
• Kaip apibrėžti užduočių ribas
• Kaip apriboti agento leidimus
• Kaip tikrinti agentų planus
• Kaip vertinti sugeneruotus testus
• Kaip aptikti saugumo problemas
• Kaip palyginti alternatyvius dizainus
• Kaip dokumentuoti agentų dalyvavimą

Ko turėtų ieškoti praktinių mokymų studentai

Būsimieji studentai turėtų paklausti, ar programa vertina šiuos dalykus:

• Ar studentai gali paaiškinti kodą, kurio patys neparašė?
• Ar studentai peržiūri ir taiso ydingą agento išvestį?
• Ar vertinami testai, saugumas ir palaikomumas?
• Ar vyksta gyva demonstracija ar techninė gynybą?
• Ar studentai palaiko versijų kontrolės projektų istoriją?
• Ar studentai mokomi, kaip dirbti be agento, kai to reikia?
• Ar programa moko produkto atradimo ir reikalavimų analizės?
• Ar įrankiams būdingi įgūdžiai subalansuoti su ilgaamžiais inžinerijos principais?

Programa, kuri reklamuoja „sukurkite programą per vieną savaitę su dirbtiniu intelektu“, gali būti puiki greitam prototipų kūrimui, tačiau tai nėra tas pats, kas paruošti ką nors profesionaliai programinės įrangos inžinerijai.

Kaip prisitaiko sertifikatai

Sertifikavimo teikėjai kuria tris plačius kvalifikacijos tipus.

Įrankiams specifinių žinių sertifikatai

„Microsoft“ „GitHub Copilot“ sertifikatas vertina atsakingą naudojimą, „Copilot“ funkcijas, duomenų architektūrą, konteksto ir instrukcijų (prompt) kūrimą, kūrėjų produktyvumą, privatumą, turinio išskyrimus ir apsaugos priemones. Egzaminas vykdomas prižiūrint, trunka šimtą minučių ir gali turėti interaktyvių komponentų. (learn.microsoft.com)

Šis pažymėjimas pripažįsta naudingas žinias darbo vietoje. Jis gali parodyti, kad asmuo supranta, kaip atsakingai naudoti konkrečią kūrimo platformą.

Jo apribojimas yra tas, kad jis yra glaudžiai susijęs su vienu produktu. Profesionalui, kuris moka naudotis „GitHub Copilot“, vis dar gali trūkti gebėjimo suskaidyti sudėtingą produkto reikalavimą, užginčyti architektūrinį pasirinkimą ar peržiūrėti saugumui jautrų pakeitimą.

Platforma pagrįsti dirbtinio intelekto kūrimo sertifikatai

„AWS Certified Generative AI Developer – Professional“ sertifikatas yra platesnis. Jo egzamino gairėse aprašoma bazinių modelių integravimas, duomenų valdymas, atitiktis, įgyvendinimas, agentais pagrįsti dirbtinio intelekto sprendimai, saugumas, valdymas, testavimas, gedimų šalinimas, stebėjimas ir optimizavimas. (docs.aws.amazon.com)

Tačiau egzaminas daugiausia yra pasirinkimo ir daugelio atsakymų tipo. Tai yra svarbus žinių patikrinimas, tačiau jis ne visiškai parodo, ar kandidatas gali sukurti, peržiūrėti ar apginti veikiančią sistemą. (aws.amazon.com)

Tai iliustruoja platesnę problemą: žinių egzaminus lengviau mastyti nei veiklos egzaminus. Sertifikavimo organizacijos gali efektyviai tikrinti terminologiją ir dizaino principus, tačiau praktinei kompetencijai reikia aplinkos, kurioje kandidatai turi priimti sprendimus ir susidoroti su nesėkmėmis.

Laboratoriniais ir projektiniais darbais pagrįsti pažymėjimai

„Microsoft Applied Skills“ pažymėjimai siūlo perspektyvesnį modelį. Jie reikalauja, kad besimokantieji atliktų interaktyvias užduotis, atitinkančias realų darbą, atliekant laboratorijos pagrindu paremtą vertinimą. „Microsoft“ pozicionuoja šiuos pažymėjimus kaip įrodymą, kad kandidatas gali spręsti realias debesų ir dirbtinio intelekto problemas, o ne tiesiog prisiminti informaciją. (learn.microsoft.com)

Carnegie Mellon universiteto vykdomojo švietimo agentinė dirbtinio intelekto programa apjungia gyvą mokymą, vadovaujamas laboratorijas, užduotis, kelių agentų darbo eigas, vertinimą, apsaugos priemones, registravimą, stebimumą ir baigiamąjį projektą. (execonline.cs.cmu.edu)

Šios programos nėra identiškos nepriklausomam profesiniam sertifikavimui, tačiau jos rodo, kokia kryptimi tikėtina, kad eis kvalifikacijos apibūdinimai:

• Trumpesni praktiniai vertinimai
• Izoliuotos kūrimo aplinkos
• Realistiškos saugyklos
• Vertinimo ir stebimumo užduotys
• Baigiamosios sistemos
• Žodiniai arba įrašyti techniniai paaiškinimai
• Atsakingo įrankių naudojimo įrodymai

Vertinimo metodai, matuojantys supratimą

Geriausia vertinimo strategija neuždraudžia agentų visose užduotyse. Ji naudoja agentus ten, kur jie atspindi profesinę praktiką, ir rezervuoja kai kurias veiklas nepriklausomo supratimo matavimui.

1. Specifikacijų ir skaidymo dokumentai

Prieš rašant kodą, reikalaukite, kad studentai pateiktų:

• Vartotojo problemą
• Funkcinius reikalavimus
• Nefunkcinius reikalavimus
• Prielaidas
• Apribojimus
• Duomenų struktūras
• Sąsajas
• Priėmimo kriterijus
• Užduoties suskirstymą
• Žinomas rizikas

Dokumente turėtų būti paaiškinta, kodėl problema buvo suskirstyta į konkrečias užduotis.

Tai matuoja, ar studentas supranta problemą, prieš prašydamas agento ją įgyvendinti.

2. Agentų planavimo kontroliniai taškai

Reikalaukite, kad studentai parodytų agento siūlomą planą prieš pradedant įgyvendinimą. Studentas turi nurodyti:

• Kurios plano dalys yra priimtinos
• Kurios dalys yra neišsamios
• Kurios prielaidos yra nesaugios
• Kurios užduotys reikalauja žmogaus patvirtinimo
• Kokie testai turėtų būti pridėti

Galutinis pažymys turėtų atlyginti už studento sprendimo kokybę, o ne už agento plano ilgį.

3. Kodo peržiūros vertinimai

Duokite studentams agento sugeneruotą saugyklą, kurioje yra tyčinių defektų. Defektai gali apimti:

• Neteisingas kraštinių atvejų tvarkymas
• Nesaugus autentifikavimas
• Prastas klaidų tvarkymas
• Paslėptos našumo problemos
• Dubliuota logika
• Neaiškios sąsajos
• Nepakankami testai
• Privatumo pažeidimai
• Priklausomybės rizikos

Paprašykite studentų parengti apžvalgą, nurodant sunkumo lygius, įrodymus, siūlomus pataisymus ir regresinius testus.

Tai yra arčiau profesionalaus programinės įrangos darbo, nei prašyti studentų sukurti dar vieną mažą programą nuo nulio.

4. Paaiškinimas ir žodinė gynyba

Studentas turėtų sugebėti paaiškinti:

• Ką sistema daro
• Kodėl pasirinkta tokia architektūra
• Kurios dalys buvo sugeneruotos
• Kokias prielaidas padarė agentas
• Kaip testai demonstruoja teisingumą
• Kas vis dar gali nepavykti
• Kokie kompromisai buvo priimti

Trumpą žodinę gynybą galima atlikti individualiai arba mažose grupėse. Ji neturi būti bauginanti. Penkių–dešimties tikslinių klausimų dažnai pakanka, kad paaiškėtų, ar studentas supranta pateiktą darbą.

5. Perkėlimo užduotys

Studentui baigus agento padedamą projektą, pateikite naują reikalavimą, kurio negalima išspręsti tiesiog pakartojant pradinę instrukciją.

Pavyzdžiui:

• Pridėti naują duomenų šaltinį
• Pakeisti našumo tikslą
• Palaikyti netikėtą įvesties formatą
• Pašalinti priklausomybę
• Pridėti prieigos kontrolę
• Paaiškinti nepavykusį testą
• Refaktoruoti modulį nekeičiant jo elgsenos

Studentas gali naudoti agentą, tačiau privalo paaiškinti planą, patikrinti pakeitimus ir apginti rezultatą.

Perkėlimo užduotys matuoja, ar studentas išmoko bendrą metodą, o ne įsiminė sėkmingą sąveiką.

6. Testų kūrimas ir priešiškas testavimas

Studentai turėtų būti vertinami už testų kokybę, o ne tik už tai, ar sugeneruotas kodas praeina pateiktus testus.

Naudingi reikalavimai apima:

• Parašyti ribinius testus
• Sukurti neigiamus testus
• Testuoti neteisingą įvestį
• Testuoti gedimų atkūrimą
• Patikrinti našumo prielaidas
• Naudoti nuosavybėmis pagrįstus testus, kai tinka
• Testuoti saugumui jautrią elgseną
• Paaiškinti, kas liko nepatikrinta

Pagrindinis klausimas yra ne „Ar kodas praėjo?“, o „Ar studentas žinojo, ką reikia testuoti?“

7. Versijų istorija ir proceso aplankai

Projekto aplankas gali apimti:

• Pradinę specifikaciją
• Užduoties skaidymą
• Agentų planus
• Pagrindines instrukcijas ar nurodymus
• Įrašus (commits)
• Testų rezultatus
• Peržiūros komentarus
• Nepavykusius metodus
• Dizaino pakeitimus
• Galutinę refleksiją

Proceso aplankas neturėtų tapti reikalavimu pateikti kiekvieną privačios pokalbio eilutę. Reprezentatyvus įrašas dažnai yra naudingesnis nei didžiulė transkripcija.

Prinstono 2025 m. programavimo kursas, pavyzdžiui, leido naudoti generatyvinio dirbtinio intelekto įrankius, tačiau reikalavo, kad studentai aprašytų jų naudojimą README faile per reprezentatyvią santrauką, o ne išsamią transkripciją. (cs.princeton.edu)

8. Struktūruota kolegų peržiūra

Kolegų peržiūra paverčia studentus iš tik kodo gamintojų į kodo kritikus. Ankstyvieji tyrimai rodo, kad kolegų vertinimas, pagrįstas vertinimo kriterijais, gali vidutiniškai tiksliai atspindėti instruktoriaus vertinimą, kartu ugdant vertinamąjį mąstymą ir įsitraukimą. (arxiv.org)

Studentų turėtų būti reikalaujama pagrįsti savo komentarus įrodymais. „Šis kodas yra blogas“ nėra peržiūra. „Ši funkcija atlieka duomenų bazės užklausą cikle, sukurdama tikėtiną našumo problemą, kai kolekcija auga“ – tai yra peržiūra.

9. Instrukcijų (prompt) ir specifikacijų problemos

„Prompt Problem“ yra programavimo užduotys, kuriose studentai rašo natūralios kalbos instrukcijas, dėl kurių dirbtinio intelekto sistema sugeneruoja kodą, atitinkantį specifikaciją. Šis metodas aiškiai moko studentus bendrauti su kodo generavimo sistemomis, perduodant joms skaičiavimo reikalavimus. (arxiv.org)

Tai gali būti naudinga, tačiau neturėtų būti vienintelis vertinimo metodas. 2026 m. tyrimas, kuriame dalyvavo daugiau nei devyni šimtai studentų, parodė, kad dažnos klaidos apėmė svarbių detalių praleidimą iš instrukcijų. Kai sugeneruotas kodas nepavykdavo, studentai dažnai susitelkdavo į savo ketinimų paaiškinimą, o ne į kodo sekimą ar testavimo atvejų nagrinėjimą. (arxiv.org)

Instrukcijų pateikimas gali atskleisti skaidymo ir komunikacijos įgūdžius, tačiau jį reikia derinti su kodo skaitymu, testavimu, derinimui ir peržiūra.

Pavyzdinė vertinimo struktūra

Praktiniame projekte galėtų būti naudojamas toks svoris:

Ši struktūra vis dar apdovanoja už veikiantį produktą, tačiau neleidžia studentui gauti aukšto pažymio vien todėl, kad agentas sukūrė didelę kodo bazę.

Akademinė sąžiningumas agentų padedamuose kursiniuose darbuose

Visuotinis draudimas ir neribotas naudojimas yra nepakankami

Visuotinis draudimas gali būti tinkamas konkrečiam pagrindiniam vertinimui, ypač kai mokymosi tikslas yra savarankiška programavimo praktika. Tačiau visuotinį draudimą vis sunkiau įgyvendinti ir jis gali užkirsti kelią studentams išmokti įrankius, su kuriais jie susidurs profesionaliame darbe.

Neribotas naudojimas taip pat yra nepakankamas. Jei studentai gali pateikti agento sukurtą darbą be paaiškinimo, vertinimas gali matuoti prieigą prie įrankio, o ne mokymąsi.

Stipriausias metodas yra aiški, užduoties lygio politika.

Trys naudingi politikos režimai

Pirmas režimas: Agentas draudžiamas

Naudoti tam, kas:

• Egzaminai
• Pagrindiniai programavimo pratimai
• Individualios derinimo demonstracijos
• Pagrindinių algoritmų pratimai
• Vertinimai, skirti matuoti atmintį be pagalbos arba įgyvendinimą

Carnegie Mellon universiteto „Imperatyvinio skaičiavimo principų“ kursas draudžia dirbtinio intelekto įrankius bet kuriai vertinamo darbo daliai, įskaitant sprendimų generavimą, sprendimų paaiškinimą, kodo formatavimą ir testavimo atvejų generavimą. (cs.cmu.edu)

Antras režimas: Agentas ribojamas

Naudoti, kai studentai gali prašyti:

• Sąvokų paaiškinimų
• Pagalbos su dokumentacija
• Klaidų pranešimų interpretavimo
• Bibliotekos ar programų sąsajos (API) paaiškinimo
• Idėjų generavimo
• Studento sukurto dizaino kritikos
• Nedidelio refaktorizavimo

Carnegie Mellon sistemų kursai leidžia naudoti dirbtinio intelekto įrankius, kad būtų galima suprasti programų sąsajas (API), bibliotekas, sistemas, pateiktą kodą ir klaidų pranešimus, tuo pačiu draudžiant prašymus dėl dalinių ar visų užduočių sprendimų. (cs.cmu.edu)

Trečias režimas: Agentas leidžiamas su atskleidimu

Naudoti realistiškiems programinės įrangos inžinerijos projektams. Reikalaukite, kad studentai atskleistų:

• Kokie įrankiai buvo naudojami
• Kokios užduotys buvo deleguotos
• Ar sugeneruotas kodas buvo nukopijuotas, modifikuotas ar perrašytas
• Kaip buvo testuojama išvestis
• Ko studentas išmoko
• Kurios dizaino dalys lieka studento atsakomybė

Prinstono akademinio sąžiningumo gairėse teigiama, kad leidžiamas dirbtinio intelekto naudojimas vis dar turi būti atskleistas, o sugeneruotos išvesties pateikimas kaip savo paties ar jos naudojimo neatskleidimas gali būti laikomas sąžiningumo pažeidimu. (scholarlyintegrity.princeton.edu)

Harvardo aukštoji švietimo mokykla taip pat leidžia naudoti dirbtinį intelektą paaiškinimams, idėjų generavimui ir tyrinėjimui, tačiau draudžia studentams teikti dirbtinio intelekto sugeneruotus kursinius darbus kaip savo. Ji taip pat reikalauja dokumentuoti leidžiamą naudojimą ir perspėja, kad studentai išlieka atsakingi už tikslumą, privatumą, autorių teises ir šališkumą. (registrar.gse.harvard.edu)

Praktinis atskleidimo pareiškimas

Kursas gali pateikti paprastą šabloną:

Naudojau [įrankio pavadinimas] [planavimui, derinimo procesui, kodo generavimui, testavimui, dokumentavimui ar peržiūrai]. Delegavau [konkrečias užduotis]. Peržiūrėjau ir modifikavau išvestį, testavau gautą sistemą ir lieku atsakingas už pateikto darbo tikslumą, saugumą ir originalumą.

Studentų neturėtų būti reikalaujama atskleisti įprasto rašybos taisymo taip pat, kaip ir deleguoto įgyvendinimo. Politika turėtų skirti nedidelę pagalbą nuo esminio pažintinio ar techninio indėlio.

Privatumas ir lygi prieiga

Institucijos turėtų teikti patvirtintus įrankius ar alternatyvas. Studentams neturėtų būti reikalaujama įkelti konfidencialių kursinių darbų, asmeninės informacijos, nepublikuotų tyrimų ar nuosavybės teise saugomo kodo į viešąsias sistemas.

UNESCO gairės ragina taikyti į žmogų orientuotą požiūrį, apimantį privatumą, saugumą, lygybę, įtrauktį ir institucinį pasirengimą. (unesco.org)

Kursai taip pat turėtų atsižvelgti į studentus, kurie negali sau leisti kelių mokamų įrankių. Sąžiningas kursas gali:

• Pateikti bendrą institucinį įrankį
• Pasiūlyti vietinę arba atvirojo kodo alternatyvą
• Kurti užduotis, kurios nepriklauso nuo vieno pardavėjo
• Vertinti mąstymą, o ne prieigą prie galingiausio modelio
• Leisti ne agentų kelius kiekvienam esminiam mokymosi rezultatui pasiekti

Praktiniai metodai produktyviam agentų integravimui

Naudokite kontroliuojamą saugyklą

Pateikite studentams saugyklą, kurioje yra:

• Aiškus README failas
• Maža, bet realistiška kodo bazė
• Automatiniai testai
• Nepertraukiamos integracijos darbo eiga
• Žinomų problemų sąrašas
• Stiliaus gairės
• Saugumo kontrolinis sąrašas
• Pakeitimų žurnalas

Tai daro agentų naudojimą stebimu ir suteikia studentams kažką realistiškesnio nei tuščias kodavimo pratimas.

Reikalauti plano prieš įgyvendinimą

Studentai neturėtų pradėti prašydami agento „sukurti visą programą“. Reikalaukite sekos:

1. Paprašyti agento patikrinti saugyklą.
2. Paprašyti architektūros santraukos.
3. Paprašyti rizikų ir trūkstamos informacijos.
4. Parašyti studento paties užduoties planą.
5. Patvirtinti vieną nedidelę įgyvendinimo užduotį.
6. Peržiūrėti gautus pakeitimus.
7. Paleisti testus prieš tęsiant.

Tai moko kontroliuojamo delegavimo, o ne aklo delegavimo.

Naudoti agentų komandą su aiškiais vaidmenimis

Paprastas orkestravimo modelis gali apimti:

• Planuotojas: siūlo užduoties suskirstymą
• Vykdytojas: modifikuoja kodą
• Testuotojas: kuria ir vykdo testus
• Peržiūrėtojas: ieško defektų ir rizikų
• Žmogus vertintojas: patvirtina arba atmeta pakeitimus

Studentai turėtų išmokti, kad daugiau agentų neautomatiškai pagerina kokybę. Daugiau agentų gali sukurti prieštaringus nurodymus, dubliuotą darbą, padidintas išlaidas ir neaiškią atsakomybę.

Švietimo tikslas nėra sukurti didžiausią kelių agentų sistemą. Tai yra pasirinkti paprasčiausią darbo eigą, kuri duoda patikimus rezultatus.

Įmontuoti žmogaus patvirtinimo vartus

Reikalauti aiškaus patvirtinimo, prieš agentui leidžiant:

• Pakeisti autentifikavimą
• Modifikuoti duomenų schemas
• Pridėti priklausomybes
• Pasiekti gamybos sistemas
• Pakeisti diegimo konfigūraciją
• Ištrinti failus
• Sujungti „pull“ užklausą

Tai moko studentus, kad autonomija turi būti apribota leidimais ir peržiūra.

Sąmoningai vertinti nesėkmes

Agentai yra naudingiausi edukaciniu požiūriu, kai jie patiria informatyvių nesėkmių. Instruktoriai turėtų įtraukti:

• Dviprasmiškus reikalavimus
• Prieštaringus apribojimus
• Neišsamius testus
• Saugumui jautrias operacijas
• Klaidinančią dokumentaciją
• Nepastovius (flaky) testus
• Našumo apribojimus
• Pakeitimą, kuris atrodo teisingas, bet sugadina kitą funkciją

Studento užduotis yra diagnozuoti gedimą ir pagerinti procesą.

Kompetencijų sistema 2026–2031 metams

Ši sistema sukurta taip, kad išliktų naudinga net keičiantis konkretiems įrankiams.

Pirmoji sritis: Techniniai pagrindai ir kodo raštingumas

Kompetentingas kūrėjas gali:

• Skaityti nepažįstamą kodą
• Paaiškinti valdymo srautą ir duomenų srautą
• Suprasti sąsajas ir priklausomybes
• Analizuoti algoritmų sudėtingumą
• Naudoti versijų kontrolę
• Derinti (debug) visiškai nepasikliaujant agentu

Įrodymai: kodo paaiškinimas, rankinio derinimo užduotis, dizaino kritika ir individualus perkėlimo pratimas.

Antroji sritis: Problemos formulavimas ir skaidymas

Kompetentingas kūrėjas gali:

• Paaiškinti vartotojo tikslus
• Nustatyti apribojimus ir prielaidas
• Atskirpti esminius nuo pasirenkamų reikalavimų
• Skaidyti darbą į nepriklausomai testuojamas užduotis
• Apibrėžti priėmimo kriterijus
• Atpažinti, kada užduotis yra per plati patikimam delegavimui

Įrodymai: specifikacija, užduočių grafikas, rizikos registras ir skaidymo pasirinkimų paaiškinimas.

Trečioji sritis: Agentų valdymas ir konteksto inžinerija

Kompetentingas kūrėjas gali:

• Pateikti atitinkamą saugyklos kontekstą
• Pateikti tikslias instrukcijas
• Apibrėžti ribas ir leidimus
• Pasirinkti, kada naudoti agentą ir kada jo nenaudoti
• Palyginti alternatyvius planus
• Atsigauti, kai agentas vadovaujasi klaidinga interpretacija

Įrodymai: planavimo kontroliniai taškai, reprezentatyvūs sąveikos įrašai ir gyvojo peržiūros užduotis.

Ketvirtoji sritis: Patvirtinimas ir peržiūra

Kompetentingas kūrėjas gali:

• Tikrinti sugeneruotą kodą
• Kurti prasmingus testus
• Nustatyti paslėptas prielaidas
• Peržiūrėti saugumo ir privatumo rizikas
• Vertinti palaikomumą
• Paaiškinti, ko testai neįrodo

Įrodymai: kodo peržiūra, priešiški testai, defektų paieškos užduotis ir žodinė gynyba.

Penktoji sritis: Orkestravimas ir operacijos

Kompetentingas kūrėjas gali:

• Koordinuoti planavimo, įgyvendinimo, testavimo ir peržiūros įrankius
• Naudoti kontrolinius taškus ir žmogaus patvirtinimo vartus
• Stebėti išlaidas, laiką ir įrankio elgseną
• Palaikyti atkuriamas darbo eigas
• Stebėti gedimus ir tobulinti sistemą
• Nuspręsti, ar keli agentai suteikia vertės

Įrodymai: veikianti orkestravimo darbo eiga, žurnalai, vertinimo ataskaita ir sąnaudų ar našumo analizė.

Šeštoji sritis: Produktų ir sistemų projektavimas

Kompetentingas kūrėjas gali:

• Pasirinkti tinkamą automatizavimo lygį
• Kurti modulines sistemas
• Subalansuoti greitį, kokybę, sąnaudas ir riziką
• Susieti techninius sprendimus su vartotojo rezultatais
• Atpažinti, kada paprastas ne-agento sprendimas yra geresnis

Įrodymai: produkto aprašymas, architektūros sprendimų įrašas, prototipas ir į vartotoją orientuota demonstracija.

Septintoji sritis: Atsakinga profesinė praktika

Kompetentingas kūrėjas gali:

• Atskleisti dirbtinio intelekto pagalbą
• Apsaugoti privačią ir nuosavybės teise saugomą informaciją
• Gerbti autorių teises ir licencijavimo įsipareigojimus
• Nustatyti šališkumo ir patikimumo rizikas
• Pranešti apie neaiškumus
• Prisiimti atsakomybę už galutinę sistemą

Įrodymai: atskleidimo pareiškimas, rizikos vertinimas, privatumo peržiūra ir profesionalus pristatymas.

Siūlomi kompetencijos lygiai

Iki 2031 m. profesionalus pažymėjimas turėtų rodyti judėjimą per šiuos lygius, o ne tiesiog patvirtinti susipažinimą su konkrečiu programinės įrangos įrankiu.

Rekomendacijos skirtingoms suinteresuotosioms šalims

Universitetai

• Įtraukti į esamus kursus agentus atpažįstančius programinės įrangos inžinerijos modulius.
• Išsaugoti pagrindinį programavimą ir algoritmus.
• Pakeisti kai kurias kodo generavimo užduotis peržiūros ir perkėlimo užduotimis.
• Reikalauti, kad studentai paaiškintų ir apgintų svarbų darbą.
• Mokyti dėstytojus agentų įrankių, vertinimo projektavimo, privatumo ir sąžiningumo politikos.
• Kurti bendras saugyklas ir izoliuotas (sandbox) aplinkas.

Praktiniai mokymai

• Mokyti įprasto kūrimo ir agentų padedamo kūrimo kartu.
• Padaryti testavimą, architektūrą ir saugumą pagrindinėmis mokymo programos dalimis.
• Reikalauti portfelio projektų su proceso įrašais.
• Pridėti gyvų techninių demonstracijų.
• Mokyti produkto atradimo ir reikalavimų rašymo.
• Vengti žadėti, kad vien instrukcijų (prompt) naudojimas paruošia inžinierius darbui.

Sertifikavimo paslaugų teikėjai

• Padidinti laboratorinių vertinimų naudojimą.
• Įtraukti kodo peržiūrą, testavimą, derinimą ir grėsmių analizę.
• Naudoti realistiškas saugyklas, o ne izoliuotus pasirinkimo klausimus.
• Testuoti nuo įrankio nepriklausomą sprendimo priėmimą.
• Pridėti trumpus žodinius paaiškinimus arba įrašytas demonstracijas.
• Dažnai atnaujinti turinį, nedarant kvalifikacijos priklausomos nuo vieno tiekėjo sąsajos.

Dėstytojai

• Tiksliai nurodyti, kas leidžiama kiekvienam vertinimui.
• Kurti užduotis pagal numatytą mokymosi rezultatą.
• Pateikti studentams patvirtintus įrankius arba lygiavertes alternatyvas.
• Vertinti procesą, mąstymą ir patvirtinimą.
• Naudoti žurnalus kaip įrodymus, o ne kaip vienintelį patvirtinimą.
• Vengti pasikliauti dirbtinio intelekto aptikimo programine įranga kaip pagrindiniu sąžiningumo mechanizmu.

Besimokantieji ir produktų kūrėjai

• Išmokti pakankamai įprasto programavimo, kad galėtų skaityti ir užginčyti sugeneruotą kodą.
• Pradėti nuo mažo produkto, o ne nuo neaiškios, didelės programos.
• Parašyti specifikaciją prieš atidarant agentą.
• Deleguoti po vieną problemą.
• Peržiūrėti kiekvieną pakeitimą ir išbandyti kiekvieną prielaidą.
• Palaikyti svarbių sprendimų įrašą.
• Vertinti agentą kaip greitą jaunesnįjį bendradarbį, o ne kaip neginčijamą ekspertą.

Pirmas kitas žingsnis

Tiems, kurie pradeda produkto kūrimo kelionę, naudingiausias pirmas žingsnis yra:

Pasirinkite vieną nedidelę vartotojo problemą ir parašykite vieno puslapio specifikaciją, prieš prašydami agento parašyti kodą.

Įtraukite:

• Kas yra vartotojas
• Kokią problemą jie turi
• Ką turi daryti pirmoji versija
• Ko ji neturi daryti
• Tris priėmimo testus
• Vieną svarbią saugumo ar privatumo problemą
• Tris nedideles įgyvendinimo užduotis

Tada paprašykite agento peržiūrėti specifikaciją ir nustatyti trūkstamus reikalavimus, o ne sukurti visą produktą.

Pataisius specifikaciją, deleguokite tik pirmąją užduotį. Peržiūrėkite siūlomą planą, patikrinkite pakeitimus, paleiskite testus ir užrašykite, ką agentas padarė neteisingai.

Šis vienas pratimas moko svarbiausios agentų eros pamokos: rezultato kokybė mažiau priklauso nuo to, kiek kodo gali sukurti agentas, o labiau nuo to, kaip aiškiai žmogus apibrėžia, prižiūri ir vertina darbą.

Išvada

Kūrėjų švietimas juda link naujos pusiausvyros.

Studentams vis dar reikės rašyti kodą, ypač mokantis pagrindinių sąvokų. Tačiau profesinė kompetencija vis dažniau bus demonstruojama per problemų skaidymą, specifikavimą, kodo supratimą, peržiūrą, testavimą, orkestravimą, produkto vertinimą ir atsakingą autonominių sistemų naudojimą.

Stipriausios mokymo programos kodavimo agentų nelaikys nei apgaulės mašinomis, nei magiškais korepetitoriais. Jos traktuos juos kaip galingus, bet klystančius inžinerinius įrankius. Studentai išmoks, kada juos naudoti, kaip juos apriboti, kaip vertinti jų išvestį ir kaip prisiimti atsakomybę už galutinę sistemą.

Patvariausias kūrėjas per ateinančius penkerius metus bus ne tas, kuris gali ranka sukurti daugiausiai kodo ar sugeneruoti ilgiausią instrukciją. Tai bus asmuo, kuris neaiškų tikslą gali paversti patikimu procesu, nukreipti kelis įrankius šio tikslo link, anksti aptikti gedimus ir paaiškinti, kodėl gauta programinė įranga nusipelno pasitikėjimo.