Vzdělávání a hodnocení vývojářů v éře agentů

Vzdělávání a hodnocení vývojářů v éře agentů

Tato analýza reflektuje stav vzdělávání a certifikací k 26. červenci 2026.

Úvod

Autonomní kódovací agenti mění vývoj softwaru z úkolu zaměřeného na psaní kódu na úkol zaměřený na specifikaci práce, delegování úkolů, dohled nad prováděním a kontrolu výsledků.

Moderní kódovací agenti dokáží prozkoumat repozitář, vyvinout implementační plán, upravit více souborů, spustit testy, reagovat na chyby a otevřít pull request pro lidskou kontrolu. Současná dokumentace GitHubu popisuje pracovní postupy, ve kterých vývojáři přidělují úkoly agentům, monitorují jejich práci, požadují kontrolu kódu, poskytují zpětnou vazbu a schvalují nebo odmítají výsledek. (docs.github.com)

To vytváří obtížnou otázku pro vzdělávání:

Pokud student může požádat agenta o vytvoření funkčního programu, co by měl student být povinen chápat?

Odpovědí není opustit základy programování. Je to změna toho, k čemu se tyto základy používají.

Studenti stále potřebují rozumět datovým strukturám, algoritmům, programovacím jazykům, návrhu systémů, bezpečnosti, testování a ladění. Stále více však potřebují tyto znalosti aplikovat na:

• Rozkládat nejednoznačné problémy na zvládnutelné úkoly
• Psát přesné specifikace a akceptační kritéria
• Poskytovat užitečný kontext kódovacím agentům
• Posoudit, zda je generovaný kód správný a udržovatelný
• Navrhovat testy, které odhalují skryté chyby
• Kontrolovat bezpečnostní, soukromí, výkonnostní a architektonická rizika
• Koordinovat několik agentů nebo nástrojů, aniž by ztratil kontrolu
• Vysvětlit a obhájit technická rozhodnutí

Příští generace vzdělávání vývojářů bude proto méně hodnotit schopnost studenta produkovat velké množství kódu a více schopnost studenta rozumět, řídit, ověřovat a zlepšovat softwarové systémy.

Klíčový posun: Od produkce kódu k inženýrskému úsudku

Kódovací agenti nejsou jen rychlejší automatické dokončování

Tradiční kódovací asistenti navrhují řádek, funkci nebo malý blok kódu. Autonomní kódovací agenti operují ve větším měřítku. Mohou pracovat napříč soubory, vyvolávat vývojové nástroje, provádět testy, kontrolovat dokumentaci a pokračovat v mnoha krocích.

To mění pracovní jednotku. Pracovní postup vývojáře stále více vypadá takto:

1. Pochopit uživatelský nebo obchodní problém.
2. Definovat požadované chování.
3. Rozdělit práci na menší úkoly.
4. Přidělit vhodný úkol agentovi.
5. Zkontrolovat plán agenta.
6. Nechat agenta implementovat v kontrolovaném prostředí.
7. Spustit testy a bezpečnostní kontroly.
8. Zkontrolovat výsledek.
9. Požádat o změny nebo revidovat návrh.
10. Schválit, sloučit a monitorovat software.

Osoba, která přeskočí fáze plánování a kontroly, může stále produkovat kód, ale nemůže spolehlivě produkovat důvěryhodný produkt.

Limity syrového výstupu kódu

Produkce syrového kódu se stává slabším měřítkem schopností, protože agent dokáže rychle generovat velké množství věrohodného kódu. Zároveň se agenti stále potýkají s dlouhodobou evolucí softwaru, změnami ve více souborech, nejasnými požadavky a udržováním chování napříč opakovanými modifikacemi. Jedna benchmarková studie z roku 2025 zjistila podstatnou mezeru mezi výkonem agentů při řešení izolovaných problémů a složitějšími, dlouhodobými úkoly evoluce softwaru. (arxiv.org)

To vytváří důležitý vzdělávací rozdíl:

• Student, který dokáže generovat kód, mu nemusí rozumět.
• Student, který dokáže kód vysvětlit, otestovat, zpochybnit a opravit, prokazuje hlubší kompetenci.

Vzdělávacím cílem by se proto měl stát ověřený softwarový úsudek, nikoli pouze úspěšné generování kódu.

Jak se přizpůsobují osnovy

Univerzitní osnovy se posouvají směrem k porozumění a ověřování

Zpráva Computer Science Curricula 2023 od ACM, Institute of Electrical and Electronics Engineers Computer Society a Association for the Advancement of Artificial Intelligence předpokládala, že generativní umělá inteligence změní výuku programování. Její doporučení naznačuje, že studenti budou potřebovat větší důraz na čtení, porozumění, ověřování, úpravu, modifikaci, adaptaci a testování kódu. Rovněž identifikuje rozklad problémů jako oblast, která se pravděpodobně stane důležitější. (csed.acm.org)

Stejné doporučení zdůrazňuje klíčový bod: i když program píše agent, člověk zůstává odpovědný za určení, zda je program správný. To znamená, že výuka programování nemůže být omezena na psaní promptů. Studenti potřebují dostatečné technické porozumění k vyhodnocení výstupu.

Zpráva rovněž předpokládá změny ve výuce softwarového inženýrství, včetně většího využití umělé inteligence pro generování kódu, ladění, statickou analýzu a revizi kódu. Efektivní používání těchto nástrojů vyžaduje silnější dovednosti v oblasti návrhu a porozumění kódu, nikoli slabší. (csed.acm.org)

Akreditace začíná oceňovat širší inženýrské výsledky

Současná akreditační kritéria pro informatiku od Akreditační rady pro inženýrství a technologie (ABET) již zdůrazňují:

• Analýzu komplexních počítačových problémů
• Návrh a hodnocení počítačových řešení
• Profesionální komunikaci
• Právní a etickou odpovědnost
• Bezpečnost a soukromí
• Sociální dopady informatiky
• Komplexní projekt nebo zážitkovou složku (abet.org)

Tyto výsledky jsou dobře uzpůsobeny pro vývojové prostředí založené na agentech, protože měří úsudek a odpovědnost spíše než stisky kláves.

K 26. červenci 2026 navrhované změny Akreditační rady pro inženýrství a technologie (ABET) pro cyklus 2026–2027 zahrnují dodatečná programová kritéria pro umělou inteligenci a požadavek, aby absolventi byli schopni aplikovat teorie, modely a techniky umělé inteligence na komplexní problémy. Navrhované změny stále čekaly na konečné schválení a očekávalo se, že vstoupí v platnost po podzimním zasedání v roce 2026, s prvním uplatněním během cyklu přezkumu 2027–2028. (abet.org)

Pravděpodobný směr je jasný: programy budou muset ukázat, že studenti umí stavět a vyhodnocovat systémy, nikoli pouze dokončovat izolovaná programovací cvičení.

Nové kurzy učí používání agentů jako inženýrskou disciplínu

Několik nedávných univerzitních kurzů ilustruje nastupující trend.

Kurz University of Maryland z roku 2025 o efektivním používání asistentů a agentů pro kódování s umělou inteligencí pokrýval nástroje, které mohou vyvolávat build systémy, spouštět testy a opravovat chyby. Zabýval se také udržovatelností, architekturou, návrhem aplikačního programovacího rozhraní, efektivitou, škálovatelností, bezpečností, nepřetržitou integrací, kontrolou kódu, asynchronními agenty a automatizovanou kontrolou kódu. (cs.umd.edu)

University of Pennsylvania navrhla kurz informatiky pro druháky zaměřený na vývoj softwaru řízený umělou inteligencí. Mezi navrhovaná témata patří delegování kódovacích úkolů, modulární design, škálovatelné testování, řízení rizik, reprodukovatelnost, spolupráce a etika. (seas.upenn.edu)

Kurz Applied Agentic Software Engineering na University of Michigan z podzimu 2026 je ještě explicitnější. Je uspořádán do tří fází:

1. Efektivně používat kódovací agenty
2. Vytvořit agenta pomocí aplikačního programovacího rozhraní velkého jazykového modelu
3. Navrhnout, vyhodnotit a nasadit orchestrátor agentů

Kurz používá projekty, laboratorní cvičení, demonstrace a kontrolní body namísto tradičních zkoušek. Uvádí, že hodnocení bude odměňovat porozumění spíše než výstup a žádá studenty, aby vysvětlili, proč agent selhal a jak opravit okolní systém. (eecs498-aase.github.io)

Jedná se o významnou změnu designu. Kurz neučí studenty rychleji produkovat kód. Učí je stát se technickými supervizory systémů, které produkují kód.

Jak se mění bootcamps

Bootcampy se přizpůsobují rychleji než mnoho tradičních programů, protože jejich osnovy jsou úzce spojeny s požadavky trhu práce. Kvalita adaptace se však liší.

Model bootcampu zaměřeného na umělou inteligenci

Současný bootcamp Le Wagon pro vývoj softwaru s umělou inteligencí kombinuje full-stack vývoj s integrací umělé inteligence. Jeho zveřejněné kurikulum zahrnuje kódování s pomocí umělé inteligence, integraci velkých jazykových modelů, nasazení do produkce, generování s rozšířeným vyhledáváním a autonomní agenty umělé inteligence. (lewagon.com)

Tento model vnímá umělou inteligenci jako vlákno procházející celým programem, nikoli jako jednu volitelnou lekci. Studenti se mají naučit obojí:

• Jak fungují konvenční softwarové systémy
• Jak používat nástroje umělé inteligence k vytváření a provozování těchto systémů

Tato kombinace je důležitá. Student, který ví pouze, jak ovládat agenta, nemusí být schopen rozpoznat chybnou architekturu. Student, který zná pouze konvenční programování, nemusí být připraven na moderní vývojové postupy.

Model „přidání jednotky umělé inteligence“

Bootcamp softwarového inženýrství Springboard si zachovává konvenční základ ve webovém vývoji, aplikačních programovacích rozhraních, front-end vývoji, back-end vývoji a full-stack projektech, přičemž přidává jednotku umělé inteligence zaměřenou na prompt engineering a spolupráci s generativními nástroji. (springboard.com)

Tento model je užitečný pro studenty, kteří nejprve potřebují silné programovací základy. Odráží také praktickou realitu: mnoho studentů by nemělo začínat budováním autonomních agentů. Měli by se nejprve naučit, jak funguje software, jak používat správu verzí, jak číst chybové zprávy a jak testovat program.

Slabinou je, že krátký modul prompt engineeringu se může stát příliš povrchním. Seriózní kurikulum éry agentů by mělo učit více než jen to, jak žádat o kód. Mělo by učit:

• Jak vytvořit kontextový soubor repozitáře
• Jak napsat technickou specifikaci
• Jak definovat hranice úkolů
• Jak omezit oprávnění agenta
• Jak kontrolovat plány agentů
• Jak vyhodnocovat generované testy
• Jak detekovat bezpečnostní problémy
• Jak porovnávat alternativní návrhy
• Jak dokumentovat zapojení agenta

Co by měli studenti bootcampů hledat

Potenciální studenti by se měli ptát, zda program hodnotí následující:

• Dokážou studenti vysvětlit kód, který osobně nenapsali?
• Kontrolují a opravují studenti chybný výstup agenta?
• Jsou hodnoceny testy, bezpečnost a udržovatelnost?
• Existuje živá ukázka nebo technická obhajoba?
• Udržují studenti historii projektu spravovanou verzovacím systémem?
• Učí se studenti, jak pracovat bez agenta, když je to potřeba?
• Učí program objevování produktu a analýzu požadavků?
• Jsou dovednosti specifické pro nástroje vyváženy trvalými inženýrskými principy?

Program, který inzeruje „vytvořte aplikaci za jeden týden s umělou inteligencí“, může být vynikající pro rychlé prototypování, ale to není totéž jako příprava na profesionální softwarové inženýrství.

Jak se přizpůsobují certifikace

Poskytovatelé certifikací vyvíjejí tři široké typy pověření.

Certifikace znalostí specifických pro nástroj

Certifikace GitHub Copilot od Microsoftu hodnotí zodpovědné používání, funkce Copilotu, datovou architekturu, tvorbu kontextu a promptů, produktivitu vývojářů, soukromí, vyloučení obsahu a bezpečnostní opatření. Zkouška je dohlížená, trvá sto minut a může obsahovat interaktivní komponenty. (learn.microsoft.com)

Tato pověření uznávají užitečné znalosti pro pracovní prostředí. Mohou ukázat, že osoba rozumí, jak zodpovědně používat konkrétní vývojovou platformu.

Jeho omezením je, že je silně vázáno na jeden produkt. Profesionál, který ví, jak ovládat GitHub Copilot, může stále postrádat schopnost rozložit komplexní požadavek na produkt, zpochybnit architektonickou volbu nebo zkontrolovat změnu citlivou na bezpečnost.

Platformně založené certifikace pro vývoj umělé inteligence

Certifikace AWS Certified Generative AI Developer – Professional je širší. Její průvodce zkouškou zahrnuje integraci základních modelů, správu dat, dodržování předpisů, implementaci, agentní řešení umělé inteligence, bezpečnost, správu, testování, řešení problémů, monitorování a optimalizaci. (docs.aws.amazon.com)

Zkouška je však primárně s výběrem z více možností a s více správnými odpověďmi. Je to podstatný znalostní test, ale plně neprokazuje, zda je kandidát schopen vybudovat, zkontrolovat nebo obhájit funkční systém. (aws.amazon.com)

To ilustruje širší problém: znalostní zkoušky jsou snáze škálovatelné než výkonnostní zkoušky. Certifikační organizace mohou efektivně testovat terminologii a principy návrhu, ale praktická kompetence vyžaduje prostředí, ve kterém musí kandidáti činit rozhodnutí a vyrovnat se se selháním.

Osvědčení založená na laboratoři a projektech

Osvědčení Microsoft Applied Skills poskytují slibnější model. Vyžadují, aby studenti dokončili interaktivní úkoly sladěné se skutečnou prací v laboratorním hodnocení. Microsoft tyto osvědčení prezentuje jako důkaz, že kandidát dokáže řešit skutečné cloudové a umělointeligenční výzvy, spíše než jen vybavovat si informace. (learn.microsoft.com)

Program Agentic Artificial Intelligence pro manažery na Carnegie Mellon University kombinuje živou výuku, řízené laboratoře, úkoly, víceagentní pracovní postupy, hodnocení, zábrany, protokolování, pozorovatelnost a závěrečný projekt. (execonline.cs.cmu.edu)

Tyto programy nejsou identické s nezávislou profesní certifikací, ale ukazují směr, kterým se pověření pravděpodobně budou ubírat:

• Kratší praktická hodnocení
• Izolovaná vývojová prostředí
• Realistické repozitáře
• Úkoly hodnocení a pozorovatelnosti
• Závěrečné systémy
• Ústní nebo nahrané technické vysvětlení
• Důkaz zodpovědného používání nástrojů

Hodnotící techniky, které měří porozumění

Nejlepší hodnotící strategie nezakazuje agenty z každého úkolu. Používá agenty tam, kde odrážejí profesionální praxi, a některé aktivity si vyhrazuje pro měření nezávislého porozumění.

1. Specifikační a dekompoziční dokumenty

Před psaním kódu vyžadujte od studentů, aby předložili:

• Uživatelský problém
• Funkční požadavky
• Nefunkční požadavky
• Předpoklady
• Omezení
• Datové struktury
• Rozhraní
• Akceptační kritéria
• Rozdělení úkolů
• Známá rizika

Dokument by měl vysvětlit, proč byl problém rozdělen do konkrétních úkolů.

To měří, zda student rozumí problému, než požádá agenta o jeho implementaci.

2. Kontrolní body plánování agenta

Vyžadujte od studentů, aby ukázali navržený plán agenta před zahájením implementace. Student musí identifikovat:

• Které části plánu jsou přijatelné
• Které části jsou neúplné
• Které předpoklady jsou nebezpečné
• Které úkoly vyžadují lidské schválení
• Které testy by měly být přidány

Konečná známka by měla odměňovat kvalitu úsudku studenta, nikoli délku plánu agenta.

3. Hodnocení recenze kódu

Dejte studentům repozitář generovaný agentem, který obsahuje záměrné vady. Vady mohou zahrnovat:

• Nesprávné zpracování okrajových případů
• Nezabezpečené ověřování
• Špatné zpracování chyb
• Skryté problémy s výkonem
• Duplikovaná logika
• Nejasná rozhraní
• Nedostatečné testy
• Porušení soukromí
• Rizika závislostí

Požádejte studenty, aby vytvořili recenzi s úrovněmi závažnosti, důkazy, navrhovanými opravami a regresními testy.

To je blíže profesionální softwarové práci než požadovat po studentech, aby vytvořili další malou aplikaci od nuly.

4. Vysvětlení zpět a ústní obhajoba

Student by měl být schopen vysvětlit:

• Co systém dělá
• Proč byla zvolena tato architektura
• Které části byly generovány
• Jaké předpoklady agent učinil
• Jak testy prokazují správnost
• Co by ještě mohlo selhat
• Jaké kompromisy byly akceptovány

Krátká ústní obhajoba může být provedena individuálně nebo v malých skupinách. Nemusí být zastrašující. Pět až deset zaměřených otázek často stačí k odhalení, zda student rozumí podané práci.

5. Transferní úkoly

Poté, co student dokončí projekt s asistencí agenta, poskytněte nový požadavek, který nelze vyřešit jednoduchým opakováním původního promptu.

Například:

• Přidat nový datový zdroj
• Změnit cílový výkon
• Podporovat neočekávaný vstupní formát
• Odebrat závislost
• Přidat řízení přístupu
• Vysvětlit selhávající test
• Refaktorovat modul, aniž by se změnilo jeho chování

Student může použít agenta, ale musí vysvětlit plán, ověřit změny a obhájit výsledek.

Transferní úkoly měří, zda se student naučil obecnou metodu, spíše než si zapamatoval úspěšnou interakci.

6. Návrh testů a nepřátelské testování

Studenti by měli být hodnoceni za kvalitu svých testů, nikoli pouze za to, zda generovaný kód projde poskytnutými testy.

Užitečné požadavky zahrnují:

• Psát testy hranic
• Vytvářet negativní testy
• Testovat neplatný vstup
• Testovat zotavení po selhání
• Kontrolovat předpoklady výkonu
• Používat testy založené na vlastnostech, kde je to vhodné
• Testovat chování citlivé na bezpečnost
• Vysvětlit, co zůstalo netestováno

Klíčovou otázkou není „Prošel kód?“, ale „Věděl student, co je třeba otestovat?“

7. Historie verzí a procesní portfolia

Projektové portfolio může zahrnovat:

• Počáteční specifikace
• Rozklad úkolů
• Plány agentů
• Hlavní prompty nebo instrukce
• Commity
• Výsledky testů
• Komentáře k recenzi
• Neúspěšné přístupy
• Změny designu
• Závěrečná reflexe

Procesní portfolio by se nemělo stát požadavkem na předložení každého řádku soukromé konverzace. Reprezentativní záznam je často užitečnější než obrovský přepis.

Například programovací kurz Princetonu z roku 2025 povoloval generativní nástroje umělé inteligence, ale vyžadoval, aby studenti popsali jejich použití v souboru readme prostřednictvím reprezentativního shrnutí, nikoli vyčerpávajícího přepisu. (cs.princeton.edu)

8. Strukturovaná peer review

Peer review (vzájemné hodnocení studentů) mění studenty z pouhých producentů kódu na kritiky kódu. Počáteční výzkum naznačuje, že vzájemné hodnocení založené na rubrikách může s mírnou přesností aproximovat hodnocení instruktora a zároveň rozvíjet hodnotící myšlení a angažovanost. (arxiv.org)

Studenti by měli být povinni své komentáře zdůvodnit důkazy. „Tento kód je špatný“ není recenze. „Tato funkce provádí dotaz na databázi uvnitř smyčky, což vytváří pravděpodobný problém s výkonem, když se kolekce zvětší“ je recenze.

9. Problémy s prompty a specifikacemi

Prompt Problems jsou programovací cvičení, ve kterých studenti píší instrukce v přirozeném jazyce, které způsobí, že systém umělé inteligence vygeneruje kód splňující specifikaci. Tento přístup explicitně učí studenty komunikovat výpočetní požadavky se systémy generujícími kód. (arxiv.org)

To může být užitečné, ale nemělo by to být jedinou metodou hodnocení. Studie z roku 2026, zahrnující více než devět set studentů, zjistila, že běžné chyby zahrnovaly opomenutí důležitých detailů v promtpech. Když generovaný kód selhal, studenti se často zaměřovali na objasnění svého záměru spíše než na sledování kódu nebo zkoumání testovacích případů. (arxiv.org)

Promptování proto může odhalit dekompoziční a komunikační dovednosti, ale musí být kombinováno s čtením kódu, testováním, laděním a revizí.

Ukázková struktura hodnocení

Praktický projekt by mohl použít následující váhy:

Tato struktura stále odměňuje funkční produkt, ale zabraňuje studentovi získat vysokou známku pouze proto, že agent vytvořil velký kódový základ.

Akademická integrita v kurzech s asistencí agentů

Plošné zákazy i neomezené použití jsou nedostatečné

Plošný zákaz může být vhodný pro specifické základní hodnocení, zejména když je cílem učení nezávislá programovací praxe. Univerzální zákaz je však stále obtížnější vynutit a může studentům bránit v učení nástrojů, se kterými se setkají v profesionální práci.

Neomezené použití je také nedostatečné. Pokud studenti mohou odevzdat práci vytvořenou agentem bez vysvětlení, hodnocení může měřit přístup k nástroji spíše než učení.

Nejsilnější přístup je explicitní politika na úrovni zadání.

Tři užitečné režimy politiky

Režim jedna: Agent zakázán

Použijte to pro:

• Zkoušky
• Základní programovací cvičení
• Individuální demonstrace ladění
• Cvičení základních algoritmů
• Hodnocení navržená k měření samostatné paměti nebo implementace

Kurz Principles of Imperative Computation na Carnegie Mellon zakazuje nástroje umělé inteligence pro jakoukoli část hodnocené práce, včetně generování řešení, vysvětlování řešení, formátování kódu a generování testovacích případů. (cs.cmu.edu)

Režim dva: Agent omezen

Použijte to, když studenti mohou požádat o:

• Vysvětlení konceptů
• Pomoc s dokumentací
• Interpretaci chybových zpráv
• Vyjasnění knihovny nebo aplikačního programovacího rozhraní
• Brainstorming
• Kritiku studentem vytvořeného návrhu
• Drobné refaktorování

Systémové kurzy Carnegie Mellon povolují nástroje umělé inteligence pro porozumění aplikačním programovacím rozhraním, knihovnám, frameworkům, poskytnutému kódu a chybovým zprávám, přičemž zakazují požadavky na částečná nebo úplná řešení úkolů. (cs.cmu.edu)

Režim tři: Agent povolen s oznámením

Použijte to pro realistické projekty softwarového inženýrství. Vyžadujte od studentů, aby zveřejnili:

• Které nástroje byly použity
• Jaké úkoly byly delegovány
• Zda byl generovaný kód zkopírován, upraven nebo přepsán
• Jak byl výstup testován
• Co se student naučil
• Které části návrhu zůstávají odpovědností studenta

Doporučení Princetonu pro akademickou integritu uvádí, že povolené použití umělé inteligence musí být stále zveřejněno a že prezentování generovaného výstupu jako vlastního nebo nezveřejnění jeho použití může představovat porušení integrity. (scholarlyintegrity.princeton.edu)

Harvard Graduate School of Education podobně povoluje použití, jako je objasnění, brainstorming a průzkum, zatímco zakazuje studentům odevzdávat práci generovanou umělou inteligencí jako svou vlastní. Rovněž vyžaduje dokumentaci povoleného použití a varuje, že studenti zůstávají odpovědní za přesnost, soukromí, autorská práva a zaujatost. (registrar.gse.harvard.edu)

Praktické prohlášení o zveřejnění

Kurz může poskytnout jednoduchou šablonu:

Použil/a jsem [název nástroje] pro [plánování, ladění, generování kódu, testování, dokumentaci nebo revizi]. Delegoval/a jsem [specifické úkoly]. Zkontroloval/a a upravil/a jsem výstup, otestoval/a výsledný systém a zůstávám odpovědný/á za přesnost, bezpečnost a originalitu odevzdané práce.

Studenti by neměli být povinni zveřejňovat běžné opravy pravopisu stejným způsobem jako delegovanou implementaci. Politiky by měly rozlišovat mezi drobnou pomocí a podstatným kognitivním nebo technickým přínosem.

Soukromí a rovný přístup

Instituce by měly poskytovat schválené nástroje nebo alternativy. Studenti by neměli být povinni nahrávat důvěrné studijní práce, osobní údaje, nepublikovaný výzkum nebo proprietární kód do veřejných systémů.

Doporučení UNESCO vyzývá k přístupu zaměřenému na člověka, který se zabývá soukromím, bezpečností, rovností, inkluzí a institucionální připraveností. (unesco.org)

Kurzy by měly zohlednit i studenty, kteří si nemohou dovolit několik placených nástrojů. Spravedlivý kurz může:

• Poskytnout sdílený institucionální nástroj
• Nabídnout lokální nebo open-source alternativu
• Navrhovat úkoly, které nezávisí na jednom dodavateli
• Hodnotit uvažování spíše než přístup k nejvýkonnějšímu modelu
• Povolit neagentní cesty pro každý základní vzdělávací výsledek

Praktické metody pro produktivní začlenění agentů

Použijte kontrolovaný repozitář

Dejte studentům repozitář obsahující:

• Jasný soubor readme
• Malý, ale realistický kódový základ
• Automatizované testy
• Pracovní postup nepřetržité integrace
• Seznam známých problémů
• Stylový průvodce
• Bezpečnostní kontrolní seznam
• Záznam změn

To činí použití agentů pozorovatelným a dává studentům něco realističtějšího než prázdné programovací cvičení.

Vyžadujte plán před implementací

Studenti by neměli začínat tím, že požádají agenta, aby „postavil celou aplikaci“. Vyžadujte posloupnost:

1. Požádejte agenta, aby prozkoumal repozitář.
2. Požádejte o shrnutí architektury.
3. Požádejte o rizika a chybějící informace.
4. Napište vlastní plán úkolů studenta.
5. Schvalte jeden malý implementační úkol.
6. Zkontrolujte výsledné změny.
7. Spusťte testy před pokračováním.

To učí řízenou delegaci spíše než slepou delegaci.

Použijte tým agentů s jasnými rolemi

Jednoduchý orchestrace vzor může zahrnovat:

• Plánovač: navrhuje rozdělení úkolů
• Implementátor: modifikuje kód
• Tester: vytváří a spouští testy
• Recenzent: hledá vady a rizika
• Lidský hodnotitel: schvaluje nebo odmítá změny

Studenti by se měli naučit, že přidávání dalších agentů automaticky nezlepšuje kvalitu. Více agentů může vytvářet protichůdné instrukce, duplikované úsilí, zvýšené náklady a nejasnou odpovědnost.

Vzdělávacím cílem není vybudovat největší multiagentní systém. Je to výběr nejjednoduššího pracovního postupu, který produkuje důvěryhodné výsledky.

Vytvořte brány pro lidské schválení

Vyžadujte explicitní schválení, než agent může:

• Změnit ověřování
• Upravit datová schémata
• Přidat závislosti
• Přistupovat k produkčním systémům
• Změnit konfiguraci nasazení
• Smazat soubory
• Sloučit pull request

To učí studenty, že autonomie musí být omezena oprávněními a kontrolou.

Hodnotit selhání záměrně

Agenti jsou nejvíce vzdělávací, když selhávají informativními způsoby. Instruktoři by měli zahrnout:

• Nejednoznačné požadavky
• Konfliktní omezení
• Neúplné testy
• Bezpečnostně citlivé operace
• Zkreslující dokumentaci
• Nestabilní testy
• Limity výkonu
• Změnu, která se zdá správná, ale rozbije jinou funkci

Úkolem studenta je diagnostikovat selhání a zlepšit proces.

Kompetenční rámec pro roky 2026 až 2031

Následující rámec je navržen tak, aby zůstal užitečný i při změnách konkrétních nástrojů.

Doména jedna: Technické základy a kódová gramotnost

Kompetentní vývojář umí:

• Číst neznámý kód
• Vysvětlit tok řízení a tok dat
• Rozumět rozhraním a závislostem
• Analyzovat algoritmickou složitost
• Používat správu verzí
• Ladit bez spoléhání se výhradně na agenta

Důkaz: vysvětlení kódu, úkol ručního ladění, kritika návrhu a individuální transferní cvičení.

Doména dvě: Formulace problému a dekompozice

Kompetentní vývojář umí:

• Vyjasnit uživatelské cíle
• Identifikovat omezení a předpoklady
• Oddělit podstatné od volitelných požadavků
• Rozdělit práci na nezávisle testovatelné úkoly
• Definovat akceptační kritéria
• Rozpoznat, kdy je úkol příliš široký pro spolehlivou delegaci

Důkaz: specifikace, graf úkolů, registr rizik a vysvětlení voleb dekompozice.

Doména tři: Směřování agenta a kontextové inženýrství

Kompetentní vývojář umí:

• Poskytnout relevantní kontext repozitáře
• Dávat přesné instrukce
• Definovat hranice a oprávnění
• Vybrat, kdy použít agenta a kdy ne
• Porovnat alternativní plány
• Zotavit se, když agent sleduje špatnou interpretaci

Důkaz: kontrolní body plánování, reprezentativní záznamy interakcí a úloha živé revize.

Doména čtyři: Ověřování a revize

Kompetentní vývojář umí:

• Kontrolovat generovaný kód
• Navrhovat smysluplné testy
• Identifikovat skryté předpoklady
• Kontrolovat bezpečnostní rizika a rizika soukromí
• Hodnotit udržovatelnost
• Vysvětlit, co testy neprokazují

Důkaz: revize kódu, nepřátelské testy, cvičení hledání defektů a ústní obhajoba.

Doména pět: Orchestrace a operace

Kompetentní vývojář umí:

• Koordinovat nástroje pro plánování, implementaci, testování a revizi
• Používat kontrolní body a brány pro lidské schválení
• Sledovat náklady, čas a chování nástrojů
• Udržovat reprodukovatelné pracovní postupy
• Pozorovat selhání a zlepšovat systém
• Rozhodnout, zda více agentů přidává hodnotu

Důkaz: funkční orchestrace pracovního postupu, logy, hodnotící zpráva a analýza nákladů nebo výkonu.

Doména šest: Návrh produktů a systémů

Kompetentní vývojář umí:

• Vybrat vhodnou úroveň automatizace
• Navrhovat modulární systémy
• Vyvažovat rychlost, kvalitu, náklady a riziko
• Propojovat technická rozhodnutí s uživatelskými výsledky
• Rozpoznat, kdy je lepší jednoduché řešení bez agenta

Důkaz: popis produktu, záznam o architektonickém rozhodnutí, prototyp a uživatelsky orientovaná demonstrace.

Doména sedm: Zodpovědná profesionální praxe

Kompetentní vývojář umí:

• Zveřejnit asistenci umělé inteligence
• Chránit soukromé a proprietární informace
• Respektovat autorská práva a licenční závazky
• Identifikovat zaujatost a rizika spolehlivosti
• Komunikovat nejistotu
• Přijmout odpovědnost za finální systém

Důkaz: prohlášení o zveřejnění, posouzení rizik, revize soukromí a profesionální prezentace.

Navrhované úrovně odbornosti

Do roku 2031 by profesionální osvědčení mělo prokazovat posun těmito úrovněmi, spíše než pouze potvrzovat znalost konkrétního softwarového nástroje.

Doporučení pro různé zúčastněné strany

Univerzity

• Přidat do stávajících kurzů moduly softwarového inženýrství s ohledem na agenty.
• Zachovat základní programování a algoritmy.
• Nahradit některé úkoly generování kódu revizními a transferními úkoly.
• Vyžadovat od studentů, aby vysvětlili a obhájili důležitou práci.
• Školit fakultu v nástrojích agentů, návrhu hodnocení, soukromí a zásadách integrity.
• Vybudovat sdílené repozitáře a sandboxová prostředí.

Bootcampy

• Učit konvenční vývoj a vývoj s asistencí agentů dohromady.
• Učinit testování, architekturu a bezpečnost ústředními částmi kurikula.
• Vyžadovat portfoliové projekty se záznamy procesů.
• Přidat živé technické demonstrace.
• Učit objevování produktu a psaní požadavků.
• Vyhnout se slibům, že samotné promptování vytváří inženýry připravené k práci.

Poskytovatelé certifikací

• Zvýšit používání laboratorních hodnocení.
• Zahrnout revizi kódu, testování, ladění a analýzu hrozeb.
• Používat realistické repozitáře namísto izolovaných otázek s výběrem z více možností.
• Testovat úsudek nezávislý na nástroji.
• Přidat krátká ústní vysvětlení nebo nahrané demonstrace.
• Často aktualizovat obsah, aniž by se certifikát stal závislým na rozhraní jednoho dodavatele.

Instruktoři

• Přesně uvést, co je povoleno pro každé hodnocení.
• Navrhovat úkoly podle zamýšleného výsledku učení.
• Poskytnout studentům schválené nástroje nebo ekvivalentní alternativy.
• Hodnotit proces, uvažování a ověřování.
• Používat logy jako důkaz, nikoli jako jediný důkaz.
• Vyhnout se spoléhání na software pro detekci umělé inteligence jako primární mechanismus integrity.

Studenti a tvůrci produktů

• Naučit se dostatek konvenčního programování k čtení a zpochybnění generovaného kódu.
• Začít s malým produktem spíše než s vágní, velkou aplikací.
• Napsat specifikaci před spuštěním agenta.
• Delegovat jeden problém najednou.
• Zkontrolovat každou změnu a otestovat každý předpoklad.
• Vést záznam důležitých rozhodnutí.
• Považovat agenta za rychlého juniorního spolupracovníka, nikoli za nezpochybnitelného experta.

První další krok

Pro někoho, kdo se pouští do tvorby produktu, je nejužitečnější první krok:

Vyberte jeden malý uživatelský problém a napište specifikaci na jednu stránku, než požádáte agenta o napsání kódu.

Zahrnout:

• Kdo je uživatel
• Jaký problém mají
• Co musí udělat první verze
• Co nesmí udělat
• Tři akceptační testy
• Jeden důležitý bezpečnostní problém nebo problém se soukromím
• Tři malé implementační úkoly

Poté požádejte agenta, aby zkontroloval specifikaci a identifikoval chybějící požadavky, nikoli aby postavil celý produkt.

Po opravení specifikace delegujte pouze první úkol. Zkontrolujte navrhovaný plán, prozkoumejte změny, spusťte testy a zapište si, co agent udělal špatně.

Toto jediné cvičení učí nejdůležitější lekci éry agentů: kvalita výsledku závisí méně na tom, kolik kódu agent dokáže vyprodukovat, než na tom, jak jasně člověk definuje, dohlíží a hodnotí práci.

Závěr

Vzdělávání vývojářů se posouvá k nové rovnováze.

Studenti budou stále potřebovat psát kód, zejména při učení základních konceptů. Profesionální kompetence se však bude stále více prokazovat prostřednictvím dekompozice problémů, specifikace, porozumění kódu, revize, testování, orchestrace, úsudku o produktu a zodpovědného používání autonomních systémů.

Nejsilnější osnovy nebudou s kódovacími agenty zacházet ani jako s podvádějícími stroji, ani jako s magickými lektory. Budou s nimi zacházet jako s výkonnými, ale omylnými inženýrskými nástroji. Studenti se naučí, kdy je používat, jak je omezit, jak hodnotit jejich výstup a jak převzít odpovědnost za konečný systém.

Nejtrvanlivější vývojář příštích pěti let nebude ten, kdo dokáže ručně vyprodukovat nejvíce kódu nebo vygenerovat nejdelší prompt. Bude to ten, kdo dokáže přeměnit nejasný cíl na spolehlivý proces, vést k tomuto cíli několik nástrojů, včas odhalit selhání a vysvětlit, proč si výsledný software zaslouží důvěru.