Fejlesztői Oktatás és Értékelés az Ügynökök Korszakában

Fejlesztői Oktatás és Értékelés az Ügynökök Korszakában

Ez az elemzés a 2026. július 26-i oktatási és tanúsítási helyzetet tükrözi.

Bevezetés

Az autonóm kódoló ügynökök a szoftverfejlesztést a kódírásra összpontosító feladatból olyanná változtatják, amely a munkameghatározásra, feladatok delegálására, végrehajtás felügyeletére és az eredmények felülvizsgálatára összpontosít.

A modern kódoló ügynökök képesek egy tárolót megvizsgálni, megvalósítási tervet kidolgozni, több fájlt módosítani, teszteket futtatni, hibákra reagálni, és emberi felülvizsgálatra egy pull requestet nyitni. A GitHub jelenlegi dokumentációja olyan munkafolyamatokat ír le, amelyekben a fejlesztők feladatokat adnak az ügynököknek, figyelemmel kísérik munkájukat, kódellenőrzést kérnek, visszajelzést adnak, és jóváhagyják vagy elutasítják az eredményt. (docs.github.com)

Ez nehéz kérdést vet fel az oktatás számára:

Ha egy diák megkérhet egy ügynököt, hogy készítsen egy működő programot, akkor mit kellene megértenie a diáknak?

A válasz nem az, hogy felhagyunk a programozási alapokkal. Hanem az, hogy megváltoztatjuk, mire használjuk ezeket az alapokat.

A diákoknak továbbra is érteniük kell az adatstruktúrákat, algoritmusokat, programozási nyelveket, rendszertervezést, biztonságot, tesztelést és hibakeresést. Azonban egyre inkább ezt a tudást kell alkalmazniuk a következőkre:

• Homályos problémák kezelhető feladatokra bontása
• Precíz specifikációk és elfogadási kritériumok írása
• Hasznos kontextus biztosítása a kódoló ügynökök számára
• Megítélni, hogy a generált kód helyes és karbantartható-e
• Tesztelés tervezése a rejtett hibák feltárására
• Biztonsági, adatvédelmi, teljesítmény- és architekturális kockázatok felülvizsgálata
• Több ügynök vagy eszköz koordinálása a kontroll elvesztése nélkül
• Technikai döntések magyarázata és védelme

A fejlesztői oktatás következő generációja tehát kevésbé a diák nagy mennyiségű kód előállítására való képességét értékeli majd, és inkább a diák azon képességét, hogy szoftverrendszereket megértsen, irányítson, ellenőrizzen és fejlesszen.

A központi változás: A kódtermeléstől a mérnöki ítélőképességig

A kódoló ügynökök nem csupán gyorsabb automatikus kiegészítések

A hagyományos kódolási asszisztensek egy sort, függvényt vagy kis kódblokkot javasolnak. Az autonóm kódoló ügynökök nagyobb léptékben működnek. Képesek fájlokon átívelően dolgozni, fejlesztői eszközöket hívni, teszteket futtatni, dokumentációt megvizsgálni, és több lépésen keresztül folytatni a munkát.

Ez megváltoztatja a munkaegységet. A fejlesztő munkafolyamata egyre inkább így néz ki:

1. A felhasználói vagy üzleti probléma megértése.
2. A kívánt viselkedés meghatározása.
3. A munka kisebb feladatokra bontása.
4. Megfelelő feladat hozzárendelése egy ügynökhöz.
5. Az ügynök tervének ellenőrzése.
6. Az ügynök megvalósítása ellenőrzött környezetben.
7. Tesztek és biztonsági ellenőrzések futtatása.
8. Az eredmény felülvizsgálata.
9. Változtatások kérése vagy a tervezés felülvizsgálata.
10. A szoftver jóváhagyása, egyesítése és felügyelete.

Az a személy, aki kihagyja a tervezési és felülvizsgálati szakaszokat, még előállíthat kódot, de nem tud megbízhatóan megbízható terméket előállítani.

A nyers kódkimenet korlátai

A nyers kódtermelés egyre gyengébb képességmérővé válik, mivel egy ügynök gyorsan nagy mennyiségű valószínűsíthető kódot generálhat. Ugyanakkor az ügynökök továbbra is nehezen birkóznak meg a hosszú távú szoftverfejlesztéssel, a több fájlt érintő változtatásokkal, a homályos követelményekkel és a viselkedés fenntartásával az ismételt módosítások során. Egy 2025-ös benchmark-tanulmány jelentős szakadékot talált az ügynökök teljesítménye között az izolált problémamegoldás és a komplexebb, hosszú távú szoftverfejlesztési feladatok között. (arxiv.org)

Ez fontos oktatási különbséget teremt:

• Egy diák, aki tud kódot generálni, még nem biztos, hogy érti is azt.
• Egy diák, aki képes elmagyarázni, tesztelni, megkérdőjelezni és javítani a kódot, mélyebb kompetenciát mutat.

Az oktatási cél ezért a validált szoftveres ítélőképesség kell, hogy legyen, nem csupán a sikeres kódgenerálás.

Hogyan alkalmazkodnak a tantervek

Az egyetemi tantervek a megértés és ellenőrzés felé mozdulnak el

Az ACM, az Institute of Electrical and Electronics Engineers Computer Society és az Association for the Advancement of Artificial Intelligence Computer Science Curricula 2023 jelentése előre jelezte, hogy a generatív mesterséges intelligencia megváltoztatja a programozási oktatást. Iránymutatása szerint a hallgatóknak nagyobb hangsúlyt kell fektetniük a kód olvasására, megértésére, ellenőrzésére, szerkesztésére, módosítására, adaptálására és tesztelésére. Emellett a problémamegbontást is kiemeli, mint valószínűleg egyre fontosabbá váló területet. (csed.acm.org)

Ugyanez az iránymutatás egy kulcsfontosságú pontot is kiemel: még ha egy ügynök is írja a programot, az ember továbbra is felelős azért, hogy meghatározza, helyes-e a program. Ez azt jelenti, hogy a programozási oktatás nem redukálható promptok írására. A diákoknak elegendő technikai tudással kell rendelkezniük a kimenet értékeléséhez.

A jelentés a szoftverfejlesztési oktatás változásait is előre vetíti, beleértve a mesterséges intelligencia nagyobb mértékű felhasználását kódgenerálásra, hibakeresésre, statikus elemzésre és kódellenőrzésre. Ezen eszközök hatékony használata erősebb tervezési és kódértési készségeket igényel, nem gyengébbeket. (csed.acm.org)

Az akkreditáció kezdi jutalmazni a szélesebb mérnöki eredményeket

A Accreditation Board for Engineering and Technology jelenlegi számítástechnikai akkreditációs kritériumai már hangsúlyozzák a következőket:

• Összetett számítástechnikai problémák elemzése
• Számítástechnikai megoldások tervezése és értékelése
• Szakmai kommunikáció
• Jogi és etikai felelősség
• Biztonság és adatvédelem
• A számítástechnika társadalmi hatásai
• Átfogó projekt vagy gyakorlati komponens (abet.org)

Ezek az eredmények jól illeszkednek egy ügynök alapú fejlesztési környezetbe, mert az ítélőképességet és a felelősséget mérik, nem pedig a billentyűleütéseket.

2026. július 26-án a Accreditation Board for Engineering and Technology javasolt változtatásai a 2026–2027-es ciklusra további mesterséges intelligencia programkritériumokat és azt a követelményt tartalmazzák, hogy a végzettek képesek legyenek a mesterséges intelligencia elméleteit, modelljeit és technikáit komplex problémákra alkalmazni. A javasolt változtatások még a végső elfogadásra vártak, és várhatóan a 2026 őszi ülés után lépnek hatályba, első alkalmazásukra a 2027–2028-as felülvizsgálati ciklusban kerül sor. (abet.org)

A valószínű irány egyértelmű: a programoknak meg kell mutatniuk, hogy a hallgatók képesek rendszereket építeni és értékelni, nem csupán elszigetelt programozási feladatokat megoldani.

Új kurzusok tanítják az ügynökhasználatot mint mérnöki diszciplínát

Több friss egyetemi kurzus is illusztrálja a kialakuló mintázatot.

A Marylandi Egyetem 2025-ös, a mesterséges intelligencia kódoló asszisztensek és ügynökök hatékony használatáról szóló kurzusa olyan eszközöket tárgyalt, amelyek képesek build rendszereket hívni, teszteket futtatni és hibákat javítani. Emellett foglalkozott a karbantarthatósággal, az architektúrával, az alkalmazásprogramozási felület (API) tervezésével, a hatékonysággal, a skálázhatósággal, a biztonsággal, a folyamatos integrációval, a kódellenőrzéssel, az aszinkron ügynökökkel és az automatizált kódellenőrzéssel. (cs.umd.edu)

A Pennsylvaniai Egyetem egy másodéves számítástechnikai kurzust javasolt, amely a mesterséges intelligencia által vezérelt szoftverfejlesztésre összpontosít. Javasolt témái közé tartozik a kódolási feladatok delegálása, a moduláris tervezés, a skálázható tesztelés, a kockázatkezelés, a reprodukálhatóság, az együttműködés és az etika. (seas.upenn.edu)

A Michigani Egyetem 2026 őszi, Alkalmazott Ügynök-alapú Szoftverfejlesztés kurzusa még explicitőbb. Három fázisra szerveződik:

1. A kódoló ügynökök hatékony használata
2. Ügynök építése nagy nyelvi modell alkalmazásprogramozási felület (API) segítségével
3. Ügynök orkesztrátor tervezése, értékelése és telepítése

A kurzus projekteket, laborgyakorlatokat, demonstrációkat és ellenőrzéseket használ a hagyományos vizsgák helyett. Kijelenti, hogy az osztályozás a megértést jutalmazza a kimenet helyett, és arra kéri a hallgatókat, hogy magyarázzák el, miért hibázott egy ügynök, és hogyan javítható a környező rendszer. (eecs498-aase.github.io)

Ez jelentős tervezési változás. A kurzus nem azt tanítja a diákoknak, hogyan írjanak gyorsabban kódot. Azt tanítja nekik, hogyan váljanak kódot előállító rendszerek technikai felügyelőivé.

Hogyan változnak a bootcampek

A bootcampek gyorsabban alkalmazkodnak, mint sok hagyományos program, mivel tanterveik szorosan kapcsolódnak a foglalkoztatási követelményekhez. Azonban az alkalmazkodás minősége változó.

Az elkötelezett mesterséges intelligencia bootcamp modell

A Le Wagon jelenlegi Mesterséges Intelligencia Szoftverfejlesztési bootcampje ötvözi a full-stack fejlesztést a mesterséges intelligencia integrációjával. Közzétett tanterve tartalmazza az MI-vel támogatott kódolást, a nagy nyelvi modell (LLM) integrációját, a produkciós telepítést, a retrieval-augmented generation (RAG) technikát és az autonóm MI ügynököket. (lewagon.com)

Ez a modell a mesterséges intelligenciát a programon végigfutó szálként kezeli, nem pedig egyetlen opcionális leckeként. A hallgatóktól elvárják, hogy megtanulják mindkettőt:

• Hogyan működnek a hagyományos szoftverrendszerek
• Hogyan használják az MI eszközöket ezen rendszerek építésére és működtetésére

Ez a kombináció fontos. Egy tanuló, aki csak egy ügynök működtetését ismeri, talán nem képes felismerni a hibás architektúrát. Egy tanuló, aki csak a hagyományos programozást ismeri, talán nem készült fel a modern fejlesztési munkafolyamatokra.

Az „MI egység hozzáadása” modell

A Springboard szoftverfejlesztő bootcampje megtartja a hagyományos alapokat a webfejlesztésben, API-kban, front-end fejlesztésben, back-end fejlesztésben és full-stack projektekben, miközben hozzáad egy MI egységet, amely a prompt mérnökségre és a generatív eszközökkel való együttműködésre fókuszál. (springboard.com)

Ez a modell hasznos azoknak a tanulóknak, akiknek először erős programozási alapokra van szükségük. Egy gyakorlati valóságot is tükröz: sok diáknak nem az autonóm ügynökök építésével kell kezdenie. Először meg kell tanulniuk, hogyan működik a szoftver, hogyan kell verziókezelést használni, hogyan kell hibaüzeneteket olvasni, és hogyan kell tesztelni egy programot.

A gyengeség az, hogy egy rövid prompt-mérnökségi modul túl sekélyessé válhat. Egy komoly ügynök-kori tantervnek többet kell tanítania, mint azt, hogyan kérjünk kódot. Meg kell tanítania:

• Hogyan hozzunk létre egy adattár kontextusfájlt
• Hogyan írjunk technikai specifikációt
• Hogyan határozzuk meg a feladatok határait
• Hogyan korlátozzuk egy ügynök engedélyeit
• Hogyan ellenőrizzük az ügynök terveit
• Hogyan értékeljük a generált teszteket
• Hogyan észleljünk biztonsági problémákat
• Hogyan hasonlítsuk össze az alternatív terveket
• Hogyan dokumentáljuk az ügynök részvételét

Mire figyeljenek a bootcamp hallgatók

A leendő hallgatóknak meg kell kérdezniük, hogy egy program a következőket értékeli-e:

• Tudják-e a hallgatók elmagyarázni azt a kódot, amit nem ők írtak?
• Felülvizsgálják és javítják-e a hallgatók a hibás ügynök kimenetet?
• Osztályozzák-e a teszteket, a biztonságot és a karbantarthatóságot?
• Van-e élő bemutató vagy technikai védés?
• Tartanak-e a hallgatók verziókezelés alatt álló projekttörténetet?
• Megtanítják-e a hallgatóknak, hogyan dolgozzanak ügynök nélkül, ha szükséges?
• Tanítja-e a program a termékfelfedezést és a követelményelemzést?
• Az eszközspecifikus készségeket egyensúlyban tartják-e a tartós mérnöki elvekkel?

Egy program, amely „alkalmazás építését egy hét alatt mesterséges intelligenciával” hirdeti, kiváló lehet gyors prototípusok készítéséhez, de ez nem ugyanaz, mint valakit felkészíteni a professzionális szoftverfejlesztésre.

Hogyan alkalmazkodnak a tanúsítványok

A tanúsítványt szolgáltatók három fő típusú képesítést fejlesztenek ki.

Eszközspecifikus tudásalapú tanúsítványok

A Microsoft GitHub Copilot tanúsítványa a felelős használatot, a Copilot funkcióit, az adatarchitektúrát, a kontextus és a prompt kialakítását, a fejlesztői produktivitást, az adatvédelmet, a tartalomkizárásokat és a védelmi intézkedéseket értékeli. A vizsga felügyelt, száz percig tart, és interaktív elemeket is tartalmazhat. (learn.microsoft.com)

Ez a képesítés hasznos munkahelyi tudást ismer el. Megmutathatja, hogy egy személy felelősségteljesen érti egy adott fejlesztői platform használatát.

Korlátja az, hogy erősen egy termékhez kötődik. Egy szakember, aki tudja, hogyan kell használni a GitHub Copilotot, még mindig hiányozhat a képesség, hogy egy komplex termékkövetelményt felbontson, egy architekturális döntést megkérdőjelezzen, vagy egy biztonsági szempontból érzékeny változtatást felülvizsgáljon.

Platformalapú mesterséges intelligencia fejlesztői tanúsítványok

Az AWS Certified Generative AI Developer – Professional tanúsítvány szélesebb körű. Vizsgakérdései tartalmazzák az alapmodellek integrációját, adatkezelést, megfelelőséget, implementációt, ügynökalapú MI megoldásokat, biztonságot, irányítást, tesztelést, hibaelhárítást, monitorozást és optimalizálást. (docs.aws.amazon.com)

A vizsga azonban elsősorban feleletválasztós és több válaszadásos. Jelentős tudáspróba, de nem mutatja be teljes mértékben, hogy a jelölt képes-e működő rendszert építeni, felülvizsgálni vagy megvédeni. (aws.amazon.com)

Ez egy szélesebb problémát illusztrál: a tudásalapú vizsgák könnyebben méretezhetők, mint a teljesítményalapú vizsgák. A tanúsító szervezetek hatékonyan tesztelhetik a terminológiát és a tervezési elveket, de a gyakorlati kompetencia olyan környezetet igényel, ahol a jelölteknek döntéseket kell hozniuk és meg kell birkózniuk a kudarcokkal.

Laboratóriumi és projektalapú képesítések

A Microsoft Applied Skills képesítések ígéretesebb modellt nyújtanak. Ezekhez a tanulóknak valós munkával összehangolt interaktív feladatokat kell elvégezniük egy laboratóriumi alapú értékelésen. A Microsoft ezeket a képesítéseket úgy pozícionálja, mint bizonyítékot arra, hogy a jelölt valódi felhő- és mesterséges intelligencia kihívásokat tud megoldani, nem csupán információkat felidézni. (learn.microsoft.com)

A Carnegie Mellon Egyetem vezetői képzésének Ügynök-alapú Mesterséges Intelligencia Programja ötvözi az élő oktatást, a vezetett laborgyakorlatokat, feladatokat, többügynökös munkafolyamatokat, értékelést, védőkorlátokat, naplózást, megfigyelhetőséget és egy záróprojektet. (execonline.cs.cmu.edu)

Ezek a programok nem azonosak a független szakmai tanúsítványokkal, de megmutatják, milyen irányt vesznek valószínűleg a képesítések:

• Rövidebb gyakorlati felmérések
• Sandboxolt fejlesztői környezetek
• Realisztikus adattárak
• Értékelési és megfigyelhetőségi feladatok
• Zárórendszerek
• Szóbeli vagy rögzített technikai magyarázatok
• A felelős eszközhasználat bizonyítéka

Értékelési technikák, amelyek a megértést mérik

A legjobb értékelési stratégia nem tiltja meg az ügynököket minden feladatnál. Akkor használja az ügynököket, amikor azok a szakmai gyakorlatot tükrözik, és bizonyos tevékenységeket fenntart a független megértés mérésére.

1. Specifikációs és felbontási dokumentumok

Kódírás előtt kérje meg a hallgatókat, hogy nyújtsák be:

• A felhasználói problémát
• Funkcionális követelményeket
• Nem funkcionális követelményeket
• Feltételezéseket
• Korlátozásokat
• Adatstruktúrákat
• Interfészeket
• Elfogadási kritériumokat
• Egy feladatbontást
• Ismert kockázatokat

A dokumentumnak magyarázatot kell adnia arra, hogy miért osztották fel a problémát adott feladatokra.

Ez azt méri, hogy a hallgató megérti-e a problémát, mielőtt megkérné egy ügynököt a megvalósításra.

2. Ügynök tervezési ellenőrzőpontok

Követelje meg a hallgatóktól, hogy a megvalósítás megkezdése előtt mutassák be az ügynök javasolt tervét. A hallgatónak azonosítania kell:

• A terv mely részei elfogadhatóak
• A mely részek hiányosak
• A mely feltételezések nem biztonságosak
• A mely feladatok igényelnek emberi jóváhagyást
• A mely teszteket kell hozzáadni

A végső osztályzatnak a hallgató ítélőképességének minőségét kell jutalmaznia, nem az ügynök tervének hosszát.

3. Kódellenőrzési értékelések

Adjon a hallgatóknak egy ügynök által generált adattárat, amely szándékos hibákat tartalmaz. A hibák magukban foglalhatják:

• Helytelen peremeset kezelés
• Nem biztonságos hitelesítés
• Gyenge hibakezelés
• Rejtett teljesítményproblémák
• Duplikált logika
• Homályos interfészek
• Elégtelen tesztek
• Adatvédelmi sértések
• Függőségi kockázatok

Kérje meg a hallgatókat, hogy készítsenek egy felülvizsgálatot súlyossági szintekkel, bizonyítékokkal, javasolt javításokkal és regressziós tesztekkel.

Ez közelebb áll a professzionális szoftveres munkához, mint az, hogy a diákoktól egy másik kis alkalmazás létrehozását kérjük a semmiből.

4. Visszamagyarázás és szóbeli védés

Egy diáknak képesnek kell lennie elmagyarázni:

• Mit csinál a rendszer
• Miért ezt az architektúrát választották
• Mely részeket generálták
• Milyen feltételezéseket tett az ügynök
• Hogyan bizonyítják a tesztek a helyességet
• Mi romolhat el még
• Milyen kompromisszumokat fogadtak el

Egy rövid szóbeli védés egyénileg vagy kis csoportokban is lebonyolítható. Nem kell ijesztőnek lennie. Öt-tíz célzott kérdés gyakran elegendő ahhoz, hogy kiderüljön, a diák megérti-e a beadott munkát.

5. Transzfer feladatok

Miután egy diák elvégzett egy ügynök-segítette projektet, adjon neki egy új követelményt, amelyet nem lehet megoldani az eredeti prompt egyszerű megismétlésével.

Például:

• Új adatforrás hozzáadása
• A teljesítménycél megváltoztatása
• Váratlan bemeneti formátum támogatása
• Függőség eltávolítása
• Hozzáférés-vezérlés hozzáadása
• Egy meghibásodó teszt magyarázata
• Egy modul refaktorálása anélkül, hogy megváltoztatnánk a viselkedését

A diák használhat ügynököt, de el kell magyaráznia a tervet, ellenőriznie kell a változásokat, és meg kell védenie az eredményt.

A transzfer feladatok azt mérik, hogy a diák általános módszert tanult-e, vagy sikeres interakciót memorizált-e.

6. Teszttervezés és ellenőrző tesztelés

A hallgatók tesztjeik minősége alapján kapjanak osztályzatot, nem csupán aszerint, hogy a generált kód átmegy-e a megadott teszteken.

Hasznos követelmények:

• Határérték-tesztek írása
• Negatív tesztek létrehozása
• Érvénytelen bemenetek tesztelése
• Hibakezelés tesztelése
• Teljesítmény-feltételezések ellenőrzése
• Tulajdonságalapú tesztek használata, ahol megfelelő
• Biztonságérzékeny viselkedés tesztelése
• Annak magyarázata, hogy mi maradt tesztelés nélkül

A kulcskérdés nem az, hogy „Átment-e a kód?”, hanem az, hogy „Tudta-e a diák, mit kellett tesztelni?”

7. Verzióelőzmények és folyamatportfóliók

Egy projektportfólió tartalmazhatja:

• Kezdeti specifikáció
• Feladatbontás
• Ügynök tervek
• Főbb promptok vagy utasítások
• Commitek
• Teszteredmények
• Felülvizsgálati megjegyzések
• Sikertelen megközelítések
• Tervezési változtatások
• Végső reflexió

Egy folyamatportfóliónak nem kell minden egyes privát beszélgetés sorát beküldési követelménnyé tennie. Egy reprezentatív feljegyzés gyakran hasznosabb, mint egy hatalmas átirat.

A Princeton 2025-ös programozási kurzusa például engedélyezte a generatív mesterséges intelligencia eszközöket, de megkövetelte a diákoktól, hogy egy readme fájlban egy reprezentatív összefoglalóval írják le azok használatát, nem pedig kimerítő átirattal. (cs.princeton.edu)

8. Strukturált társ-felülvizsgálat

A társ-felülvizsgálat a diákokat a kódkészítőkből kódkritikusokká alakítja. Korai kutatások szerint a rubrika alapú társ-értékelés mérsékelt pontossággal közelítheti az oktatói értékelést, miközben fejleszti az értékelő gondolkodást és az elkötelezettséget. (arxiv.org)

A diákoknak bizonyítékokkal kell alátámasztaniuk megjegyzéseiket. A „Ez a kód rossz” nem felülvizsgálat. A „Ez a függvény egy adatbázis-lekérdezést hajt végre egy cikluson belül, ami valószínűleg teljesítményproblémát okoz, amikor a gyűjtemény növekszik” az egy felülvizsgálat.

9. Prompt és specifikációs problémák

A prompt problémák olyan programozási feladatok, amelyekben a hallgatók természetes nyelvi utasításokat írnak, amelyek egy mesterséges intelligencia rendszert késztetnek a specifikációt kielégítő kód generálására. Ez a megközelítés explicit módon tanítja meg a hallgatóknak, hogyan kommunikálják a számítási követelményeket a kódgeneráló rendszerekkel. (arxiv.org)

Ez hasznos lehet, de nem szabad, hogy ez legyen az egyetlen értékelési módszer. Egy 2026-os, több mint kilencszáz diákot érintő tanulmány megállapította, hogy gyakori hibák közé tartozott a fontos részletek kihagyása a promptokból. Amikor a generált kód hibázott, a diákok gyakran a szándékuk tisztázására összpontosítottak, ahelyett, hogy a kódot követték vagy a teszteseteket vizsgálták volna. (arxiv.org)

A promptolás tehát feltárhatja a felbontási és kommunikációs készségeket, de kombinálni kell kódolvasással, teszteléssel, hibakereséssel és felülvizsgálattal.

Egy minta értékelési struktúra

Egy gyakorlati projekt a következő súlyozást használhatja:

Ez a struktúra továbbra is jutalmazza a működő terméket, de megakadályozza, hogy egy diák csak azért kapjon magas osztályzatot, mert egy ügynök nagy kódbázist állított elő.

Akadémiai integritás az ügynök-asszisztált kurzusokon

A teljes tiltás és a korlátlan használat is elégtelen

Egy teljes tilalom megfelelő lehet egy specifikus alapozó értékeléshez, különösen, ha a tanulási cél a független programozási gyakorlat. Azonban egy univerzális tilalom betartása egyre nehezebb, és megakadályozhatja a diákokat abban, hogy olyan eszközöket tanuljanak meg, amelyekkel a szakmai munkában találkozni fognak.

A korlátlan használat is elégtelen. Ha a diákok magyarázat nélkül adhatnak be ügynök által készített munkát, az értékelés inkább az eszközhöz való hozzáférést mérheti, mintsem a tanulást.

A legerősebb megközelítés az explicit, feladat szintű szabályzat.

Három hasznos irányelvi mód

Első mód: Ügynök tiltott

Használja ezt a következőkhöz:

• Vizsgák
• Alapozó programozási gyakorlatok
• Egyéni hibakeresési bemutatók
• Alapvető algoritmusgyakorlatok
• Önálló felidézés vagy implementáció mérésére tervezett felmérések

A Carnegie Mellon Principles of Imperative Computation kurzusa tiltja a mesterséges intelligencia eszközök használatát a osztályozott munka bármely részén, beleértve a megoldások generálását, magyarázatát, a kód formázását és a tesztesetek generálását. (cs.cmu.edu)

Második mód: Ügynök korlátozott

Használja ezt, amikor a hallgatók kérhetnek:

• Koncepció magyarázatokat
• Dokumentációs segítséget
• Hibaüzenet értelmezést
• Könyvtári vagy alkalmazásprogramozási felület (API) tisztázását
• Ötletelést
• Egy hallgató által készített terv kritikáját
• Kisebb refaktorálást

A Carnegie Mellon rendszerek kurzusai engedélyezik a mesterséges intelligencia eszközöket az API-k, könyvtárak, keretrendszerek, biztosított kódok és hibaüzenetek megértéséhez, miközben tiltják a részleges vagy teljes feladatmegoldások kérését. (cs.cmu.edu)

Harmadik mód: Ügynök engedélyezett, kötelező nyilvánosságra hozatallal

Használja ezt a realisztikus szoftverfejlesztési projektekhez. Követelje meg a hallgatóktól, hogy tegyék közzé:

• Mely eszközöket használták
• Mely feladatokat delegálták
• A generált kódot másolták-e, módosították-e vagy újraírták-e
• Hogyan tesztelték a kimenetet
• Mit tanult a hallgató
• A tervezés mely részei maradnak a hallgató felelőssége

A Princeton tudományos integritási útmutatója kimondja, hogy az engedélyezett mesterséges intelligencia használatát továbbra is nyilvánosságra kell hozni, és a generált kimenet sajátként való feltüntetése, vagy annak elmulasztása, hogy az használatát közzétegyék, integritássértésnek minősülhet. (scholarlyintegrity.princeton.edu)

A Harvard Graduate School of Education hasonlóképpen engedélyezi az olyan felhasználásokat, mint a tisztázás, ötletelés és felfedezés, miközben tiltja a hallgatóknak, hogy sajátjukként nyújtsák be az mesterséges intelligencia által generált kurzusmunkát. Azt is megköveteli az engedélyezett használat dokumentálását, és figyelmeztet, hogy a hallgatók továbbra is felelősek a pontosságért, adatvédelemért, szerzői jogokért és az elfogultságért. (registrar.gse.harvard.edu)

Egy gyakorlati nyilatkozat a nyilvánosságra hozatalról

Egy kurzus egyszerű sablont biztosíthat:

A [eszköz neve] eszközt használtam [tervezéshez, hibakereséshez, kódgeneráláshoz, teszteléshez, dokumentációhoz vagy felülvizsgálathoz]. A [specifikus feladatok] delegálására. Felülvizsgáltam és módosítottam a kimenetet, teszteltem az eredményül kapott rendszert, és továbbra is felelős vagyok a benyújtott munka pontosságáért, biztonságáért és eredetiségéért.

A hallgatóktól nem kell megkövetelni a szokásos helyesírási hibák kijavításának nyilvánosságra hozatalát ugyanúgy, mint egy delegált implementációt. Az irányelveknek különbséget kell tenniük a kisebb segítség és a jelentős kognitív vagy technikai hozzájárulás között.

Adatvédelem és egyenlő hozzáférés

Az intézményeknek jóváhagyott eszközöket vagy alternatívákat kell biztosítaniuk. A hallgatóktól nem kell megkövetelni bizalmas kurzusmunka, személyes információk, kiadatlan kutatás vagy tulajdonosi kód feltöltését nyilvános rendszerekre.

Az UNESCO útmutatója emberközpontú megközelítést szorgalmaz, amely foglalkozik az adatvédelemmel, biztonsággal, méltányossággal, inklúzióval és intézményi felkészültséggel. (unesco.org)

A kurzusoknak figyelembe kell venniük azokat a hallgatókat is, akik nem engedhetnek meg maguknak több fizetős eszközt. Egy tisztességes kurzus a következőket teheti:

• Megosztott intézményi eszközt biztosít
• Helyi vagy nyílt forráskódú alternatívát kínál
• Feladatokat úgy tervez, hogy ne függjenek egyetlen gyártótól
• Az érvelést osztályozza a legerősebb modellhez való hozzáférés helyett
• Lehetővé teszi a nem-ügynöki utakat minden alapvető tanulási eredmény eléréséhez

Gyakorlati módszerek az ügynökök produktív beépítésére

Használjon ellenőrzött adattárat

Adjon a diákoknak egy adattárat, amely tartalmazza:

• Világos readme fájlt
• Egy kicsi, de reális kódbázist
• Automatizált teszteket
• Egy folyamatos integrációs (CI) munkafolyamatot
• Ismert problémák listáját
• Stílus útmutatót
• Biztonsági ellenőrzőlistát
• Változási naplót

Ez az ügynökhasználatot megfigyelhetővé teszi, és valósághűbbé teszi a feladatot, mint egy üres kódolási gyakorlat.

Terv megkövetelése a megvalósítás előtt

A hallgatók ne azzal kezdjék, hogy megkérnek egy ügynököt, hogy „építse meg az egész alkalmazást”. Követeljen meg egy sorrendet:

1. Kérje meg az ügynököt, hogy vizsgálja meg az adattárat.
2. Kérjen összefoglalót az architektúráról.
3. Kérdezzen a kockázatokról és a hiányzó információkról.
4. Írja meg a hallgató saját feladattervét.
5. Hagyjon jóvá egy kis megvalósítási feladatot.
6. Tekintse át az eredményül kapott változásokat.
7. Futtasson teszteket, mielőtt folytatná.

Ez ellenőrzött delegálást tanít, nem vak delegálást.

Használjon ügynökcsapatot világos szerepekkel

Egy egyszerű orkesztrációs minta tartalmazhatja:

• Tervező: javasolja a feladatbontást
• Implementáló: módosítja a kódot
• Tesztelő: létrehoz és futtat teszteket
• Felülvizsgáló: hibákat és kockázatokat keres
• Emberi értékelő: jóváhagyja vagy elutasítja a változásokat

A diákoknak meg kell tanulniuk, hogy több ügynök hozzáadása nem javítja automatikusan a minőséget. Több ügynök ellentmondásos utasításokat, duplikált erőfeszítést, megnövekedett költségeket és homályos felelősséget teremthet.

Az oktatási cél nem a legnagyobb többügynökös rendszer építése. Hanem a legegyszerűbb munkafolyamat kiválasztása, amely megbízható eredményeket produkál.

Beépített emberi jóváhagyási kapuk

Követeljen meg explicit jóváhagyást, mielőtt egy ügynök:

• Hitelesítést módosíthat
• Adatsémákat módosíthat
• Függőségeket adhat hozzá
• Hozzáférhet a produkciós rendszerekhez
• Telepítési konfigurációt módosíthat
• Fájlokat törölhet
• Pull requestet egyesíthet

Ez azt tanítja a diákoknak, hogy az autonómiát engedélyek és felülvizsgálat korlátozza.

Szándékos értékelési hibák

Az ügynökök a leginkább tanulságosak, ha informatív módon hibáznak. Az oktatóknak bele kell foglalniuk:

• Homályos követelményeket
• Ellentmondásos korlátozásokat
• Hiányos teszteket
• Biztonságérzékeny műveleteket
• Félrevezető dokumentációt
• Ingadozó teszteket
• Teljesítménykorlátokat
• Olyan változtatást, amely helyesnek tűnik, de egy másik funkciót elront

A diák feladata a hiba diagnosztizálása és a folyamat javítása.

Képességkeret 2026 és 2031 között

A következő keretrendszer célja, hogy hasznos maradjon, még akkor is, ha a specifikus eszközök változnak.

Első terület: Technikai alapok és kódolvasási készség

Egy kompetens fejlesztő képes:

• Ismeretlen kódot olvasni
• Elmagyarázni az adat- és vezérlésfolyamatot
• Megérteni az interfészeket és a függőségeket
• Elemezni az algoritmusok bonyolultságát
• Verziókezelést használni
• Hibakeresést végezni anélkül, hogy teljesen egy ügynökre támaszkodna

Bizonyíték: kódmagyarázat, manuális hibakeresési feladat, tervezési kritika és egyéni transzfergyakorlat.

Második terület: Probléma megfogalmazása és felbontása

Egy kompetens fejlesztő képes:

• Tisztázni a felhasználói célokat
• Azonosítani a korlátozásokat és feltételezéseket
• Elkülöníteni a lényegeset az opcionális követelményektől
• A munkát egymástól függetlenül tesztelhető feladatokra bontani
• Elfogadási kritériumokat meghatározni
• Felismerni, ha egy feladat túl széles a megbízható delegáláshoz

Bizonyíték: specifikáció, feladatgráf, kockázatnyilvántartás és a felbontási döntések magyarázata.

Harmadik terület: Ügynök irányítása és kontextus mérnökség

Egy kompetens fejlesztő képes:

• Releváns adattár kontextust biztosítani
• Precíz utasításokat adni
• Határokat és engedélyeket meghatározni
• Kiválasztani, mikor használjon ügynököt és mikor ne
• Alternatív terveket összehasonlítani
• Helyreállni, ha az ügynök téves értelmezést követ

Bizonyíték: tervezési ellenőrzőpontok, reprezentatív interakciós feljegyzések és egy élő revíziós feladat.

Negyedik terület: Ellenőrzés és felülvizsgálat

Egy kompetens fejlesztő képes:

• Generált kódot ellenőrizni
• Értelmes teszteket tervezni
• Rejtett feltételezéseket azonosítani
• Biztonsági és adatvédelmi kockázatokat felülvizsgálni
• Értékelni a karbantarthatóságot
• Elmagyarázni, amit a tesztek nem bizonyítanak

Bizonyíték: kódellenőrzés, ellenőrző tesztek, hibakeresési gyakorlat és szóbeli védés.

Ötödik terület: Orchestráció és műveletek

Egy kompetens fejlesztő képes:

• Tervezési, implementációs, tesztelési és felülvizsgálati eszközöket koordinálni
• Ellenőrzőpontokat és emberi jóváhagyási kapukat használni
• Követni a költséget, időt és az eszköz viselkedését
• Reprodukálható munkafolyamatokat fenntartani
• Hibákat megfigyelni és a rendszert javítani
• Eldönteni, hogy több ügynök hozzáadott értéket teremt-e

Bizonyíték: működő orkesztrációs munkafolyamat, naplók, értékelési jelentés és költség- vagy teljesítményelemzés.

Hatodik terület: Termék- és rendszertervezés

Egy kompetens fejlesztő képes:

• Megfelelő szintű automatizálást választani
• Moduláris rendszereket tervezni
• Egyensúlyt teremteni a sebesség, minőség, költség és kockázat között
• Összekapcsolni a technikai döntéseket a felhasználói eredményekkel
• Felismerni, amikor egy egyszerű nem-ügynöki megoldás jobb

Bizonyíték: termékleírás, architektúra döntési jegyzőkönyv, prototípus és felhasználó-központú bemutató.

Hetedik terület: Felelős szakmai gyakorlat

Egy kompetens fejlesztő képes:

• Közzétenni a mesterséges intelligencia segítségét
• Védeni a privát és tulajdonosi információkat
• Tiszteletben tartani a szerzői jogi és licencelési kötelezettségeket
• Azonosítani az elfogultság és megbízhatósági kockázatokat
• Kommunikálni a bizonytalanságot
• Felelősséget vállalni a végső rendszerért

Bizonyíték: nyilatkozat a nyilvánosságra hozatalról, kockázatértékelés, adatvédelmi felülvizsgálat és szakmai prezentáció.

Javasolt jártassági szintek

2031-re egy szakmai képesítésnek ezen szintek közötti előrehaladást kell demonstrálnia, nem csupán egy adott szoftveres eszköz ismeretét megerősítenie.

Javaslatok különböző érdekeltek számára

Egyetemek

• Adjon hozzá ügynök-tudatos szoftverfejlesztési modulokat a meglévő kurzusokhoz.
• Őrizze meg az alapozó programozást és algoritmusokat.
• Cseréljen le néhány kódgenerálási feladatot felülvizsgálati és transzfer feladatokra.
• Követelje meg a hallgatóktól, hogy magyarázzák el és védjék meg fontos munkájukat.
• Képezze az oktatókat ügynökeszközök, értékeléstervezés, adatvédelem és integritási szabályzatok terén.
• Hozzon létre megosztott adattárakat és sandbox környezeteket.

Bootcampek

• Tanítson hagyományos fejlesztést és ügynök-asszisztált fejlesztést együtt.
• Tegye a tesztelést, az architektúrát és a biztonságot a tanterv központi részévé.
• Követeljen meg portfólió projekteket folyamatfeljegyzésekkel.
• Adjon hozzá élő technikai bemutatókat.
• Tanítson termékfelfedezést és követelményírását.
• Kerülje el annak ígéretét, hogy a promptolás önmagában munkahelyre kész mérnököket eredményez.

Tanúsítvány szolgáltatók

• Növelje a laboratóriumi alapú értékelések használatát.
• Foglalja bele a kódellenőrzést, tesztelést, hibakeresést és fenyegetéselemzést.
• Használjon realisztikus adattárakat elszigetelt feleletválasztós kérdések helyett.
• Tesztelje az eszköztől független ítélőképességet.
• Adjon hozzá rövid szóbeli magyarázatokat vagy rögzített bemutatókat.
• Gyakran frissítse a tartalmat anélkül, hogy a képesítést egyetlen gyártó felületétől tenné függővé.

Oktatók

• Pontosan határozza meg, mi engedélyezett minden értékeléshez.
• Tervezze meg a feladatokat a tervezett tanulási eredmény körül.
• Adjon a hallgatóknak jóváhagyott eszközöket vagy azzal egyenértékű alternatívákat.
• Értékelje a folyamatot, az érvelést és az ellenőrzést.
• Használja a naplókat bizonyítékként, ne az egyetlen bizonyítékként.
• Kerülje el a mesterséges intelligencia detektáló szoftverekre való támaszkodást, mint elsődleges integritási mechanizmusra.

Tanulók és termékalkotók

• Tanuljon meg elegendő hagyományos programozást a generált kód elolvasásához és megkérdőjelezéséhez.
• Kezdjen egy kis termékkel, ne egy homályos, nagy alkalmazással.
• Írja meg a specifikációt, mielőtt ügynököt nyitna.
• Delegáljon egyszerre egy problémát.
• Tekintse át minden változást és tesztelje minden feltételezést.
• Készítsen feljegyzést a fontos döntésekről.
• Kezelje az ügynököt gyors junior kollégaként, nem megkérdőjelezhetetlen szakértőként.

Az első következő lépés

Valakinek, aki termékalkotási útját kezdi, a leghasznosabb első lépés a következő:

Válasszon egy kis felhasználói problémát, és írjon egy egyoldalas specifikációt, mielőtt megkéri egy ügynököt, hogy írjon kódot.

Foglalja bele:

• Ki a felhasználó
• Milyen problémája van
• Mit kell tennie az első verziónak
• Mit nem szabad tennie
• Három elfogadási tesztet
• Egy fontos biztonsági vagy adatvédelmi aggályt
• Három kis megvalósítási feladatot

Ezután kérje meg az ügynököt, hogy tekintse át a specifikációt, és azonosítsa a hiányzó követelményeket, ne pedig az egész terméket építse meg.

A specifikáció kijavítása után csak az első feladatot delegálja. Tekintse át a javasolt tervet, ellenőrizze a változásokat, futtassa a teszteket, és jegyezze fel, miben tévedett az ügynök.

Ez az egyetlen gyakorlat tanítja meg az ügynökök korának legfontosabb leckéjét: az eredmény minősége kevésbé attól függ, hogy az ügynök mennyi kódot tud előállítani, mint attól, hogy az ember mennyire világosan határozza meg, felügyeli és értékeli a munkát.

Összefoglalás

A fejlesztői oktatás új egyensúly felé mozdul.

A diákoknak továbbra is kell kódot írniuk, különösen az alapvető koncepciók tanulása közben. De a szakmai kompetenciát egyre inkább a problémabontás, specifikáció, kódértés, felülvizsgálat, tesztelés, orchestráció, termékítélet és autonóm rendszerek felelős használata révén demonstrálják majd.

A legerősebb tantervek nem fogják a kódoló ügynököket sem csaló gépekként, sem mágikus oktatóként kezelni. Erőteljes, de tévedhetetlen mérnöki eszközöknek tekintik őket. A diákok megtanulják, mikor használják őket, hogyan korlátozzák őket, hogyan értékeljék a kimenetüket, és hogyan vállaljanak felelősséget a végső rendszerért.

A következő öt év legtartósabb fejlesztője nem az lesz, aki a legtöbb kódot tudja kézzel előállítani, vagy a leghosszabb promptot tudja generálni. Az lesz, aki egy homályos célt megbízható folyamattá tud alakítani, több eszközt tud irányítani e cél felé, korán felismeri a hibákat, és el tudja magyarázni, miért érdemes bízni az eredményül kapott szoftverben.