Udvikleruddannelse og vurdering i agentæraen

Udvikleruddannelse og vurdering i agentæraen

Denne analyse afspejler landskabet for uddannelse og certificering pr. 26. juli 2026.

Introduktion

Autonome kodeagenter ændrer softwareudvikling fra en opgave centreret om at skrive kode til en, der er centreret om at specificere arbejde, delegere opgaver, overvåge udførelse og gennemgå resultater.

Moderne kodeagenter kan inspicere et lager, udvikle en implementeringsplan, ændre flere filer, køre tests, reagere på fejl og åbne en pull-anmodning til menneskelig gennemgang. GitHubs nuværende dokumentation beskriver arbejdsgange, hvor udviklere tildeler opgaver til agenter, overvåger deres arbejde, anmoder om kodegennemgang, giver feedback og godkender eller afviser resultatet. (docs.github.com)

Dette skaber et vanskeligt spørgsmål for uddannelse:

Hvis en studerende kan bede en agent om at producere et fungerende program, hvad skal den studerende så forventes at forstå?

Svaret er ikke at opgive programmeringens grundprincipper. Det er at ændre, hvad disse grundprincipper bruges til.

Studerende skal stadig forstå datastrukturer, algoritmer, programmeringssprog, systemdesign, sikkerhed, test og fejlfinding. Men de skal i stigende grad anvende denne viden til at:

• Nedbryde tvetydige problemer til håndterbare opgaver
• Skrive præcise specifikationer og acceptkriterier
• Give nyttig kontekst til kodeagenter
• Vurdere, om genereret kode er korrekt og vedligeholdelsesvenlig
• Designe tests, der afslører skjulte fejl
• Gennemgå sikkerheds-, privatlivs-, ydeevne- og arkitekturmæssige risici
• Koordinere flere agenter eller værktøjer uden at miste kontrol
• Forklare og forsvare tekniske beslutninger

Den næste generation af udvikleruddannelse vil derfor i mindre grad vurdere den studerendes evne til at producere store mængder kode og i højere grad den studerendes evne til at forstå, styre, verificere og forbedre softwaresystemer.

Det centrale skift: Fra kode-produktion til ingeniørfaglig dømmekraft

Kodeagenter er ikke blot hurtigere autofuldførelse

Traditionelle kodeassistenter foreslår en linje, funktion eller en lille kodeblok. Autonome kodeagenter opererer i større skala. De kan arbejde på tværs af filer, kalde udviklingsværktøjer, udføre tests, inspicere dokumentation og fortsætte gennem flere trin.

Det ændrer arbejdsenheden. Udviklerens arbejdsgang ligner i stigende grad dette:

1. Forstå bruger- eller forretningsproblemet.
2. Definere den ønskede adfærd.
3. Opdele arbejdet i mindre opgaver.
4. Tildel en passende opgave til en agent.
5. Inspicer agentens plan.
6. Lad agenten implementere inden for et kontrolleret miljø.
7. Kør tests og sikkerhedstjek.
8. Gennemgå resultatet.
9. Anmod om ændringer eller revider designet.
10. Godkend, flet og overvåg softwaren.

Den person, der springer planlægnings- og gennemgangstrinnene over, kan stadig producere kode, men kan ikke pålideligt producere et troværdigt produkt.

Grænserne for rå kodeoutput

Rå kode-produktion bliver et svagere mål for evne, fordi en agent hurtigt kan generere en stor mængde plausibel kode. Samtidig kæmper agenter fortsat med langsigtet softwareudvikling, ændringer i flere filer, uklare krav og opretholdelse af adfærd på tværs af gentagne ændringer. En benchmarkundersøgelse fra 2025 fandt et betydeligt gab mellem agentpræstationen ved isoleret problemopløsning og mere komplekse, langsigtede softwareudviklingsopgaver. (arxiv.org)

Dette skaber en vigtig uddannelsesmæssig forskel:

• En studerende, der kan generere kode, forstår den måske ikke.
• En studerende, der kan forklare, teste, udfordre og reparere kode, demonstrerer dybere kompetence.

Det uddannelsesmæssige mål bør derfor blive valideret softwarebedømmelse, ikke blot vellykket kodegenerering.

Hvordan pensum tilpasses

Universitetspensum bevæger sig mod forståelse og verifikation

ACM, Institute of Electrical and Electronics Engineers Computer Society og Association for the Advancement of Artificial Intelligence's Computer Science Curricula 2023-rapport forventede, at generativ kunstig intelligens ville ændre programmeringsuddannelsen. Deres vejledning antyder, at studerende får mere vægt på at læse, forstå, verificere, redigere, ændre, tilpasse og teste kode. Den identificerer også problemnedbrydning som et område, der sandsynligvis vil blive vigtigere. (csed.acm.org)

Den samme vejledning fremhæver et afgørende punkt: selv når en agent skriver programmet, forbliver mennesket ansvarligt for at bestemme, om programmet er korrekt. Dette betyder, at programmeringsuddannelse ikke kan reduceres til at skrive prompts. Studerende har brug for tilstrækkelig teknisk forståelse til at evaluere outputtet.

Rapporten forudser også ændringer i softwareingeniøruddannelsen, herunder større brug af kunstig intelligens til kodegenerering, fejlfinding, statisk analyse og kodegennemgang. Effektiv brug af disse værktøjer kræver stærkere design- og kodeforståelsesfærdigheder, ikke svagere. (csed.acm.org)

Akkreditering begynder at belønne bredere ingeniørfaglige resultater

De nuværende akkrediteringskriterier for computing fra Accreditation Board for Engineering and Technology fremhæver allerede:

• Analyse af komplekse computerproblemer
• Design og evaluering af computerløsninger
• Professionel kommunikation
• Juridisk og etisk ansvar
• Sikkerhed og privatliv
• Sociale konsekvenser af computing
• Et omfattende projekt eller erfaringsbaseret komponent (abet.org)

Disse resultater er velegnede til et agentbaseret udviklingsmiljø, fordi de måler dømmekraft og ansvar snarere end tastetryk.

Pr. 26. juli 2026 inkluderer foreslåede ændringer fra Accreditation Board for Engineering and Technology for cyklussen 2026–2027 yderligere programkriterier for kunstig intelligens og et krav om, at kandidater skal kunne anvende teorier, modeller og teknikker inden for kunstig intelligens til komplekse problemer. De foreslåede ændringer afventede stadig endelig vedtagelse og forventedes at træde i kraft efter efterårsmødet i 2026, med første anvendelse under gennemgangscyklussen 2027–2028. (abet.org)

Den sandsynlige retning er klar: programmer skal vise, at studerende kan bygge og evaluere systemer, ikke blot gennemføre isolerede programmeringsøvelser.

Nye kurser underviser i agentbrug som en ingeniørfaglig disciplin

Flere nylige universitetskurser illustrerer det nye mønster.

University of Marylands kursus fra 2025 om effektiv brug af AI-kodeassistenter og -agenter dækkede værktøjer, der kan kalde byggesystemer, køre tests og rette fejl. Det behandlede også vedligeholdbarhed, arkitektur, design af applikationsprogrammeringsgrænseflader (API), effektivitet, skalerbarhed, sikkerhed, kontinuerlig integration, kodegennemgang, asynkrone agenter og automatiseret kodegennemgang. (cs.umd.edu)

University of Pennsylvania har foreslået et datalogikursus på andet års niveau fokuseret på AI-drevet softwareudvikling. De foreslåede emner omfatter delegering af kodningsopgaver, modulært design, skalerbar test, risikostyring, reproducerbarhed, samarbejde og etik. (seas.upenn.edu)

University of Michigans efterårskursus 2026, Applied Agentic Software Engineering, er endnu mere eksplicit. Det er organiseret i tre faser:

1. Brug kodeagenter effektivt
2. Byg en agent ved hjælp af et stort sprogmodels API (Application Programming Interface)
3. Design, evaluer og implementer en agentorkestrator

Kurset anvender projekter, laboratorier, demonstrationer og godkendelser i stedet for traditionelle eksaminer. Det anfører, at bedømmelsen vil belønne forståelse frem for output og beder studerende om at forklare, hvorfor en agent fejlede, og hvordan man retter det omkringliggende system. (eecs498-aase.github.io)

Dette er en betydelig designændring. Kurset lærer ikke studerende at producere kode hurtigere. Det lærer dem at blive tekniske supervisorer af systemer, der producerer kode.

Hvordan bootcamps ændrer sig

Bootcamps tilpasser sig hurtigere end mange traditionelle programmer, fordi deres pensum er tæt knyttet til ansættelseskrav. Kvaliteten af tilpasningen varierer dog.

Den dedikerede AI bootcamp-model

Le Wagons nuværende Artificial Intelligence Software Development bootcamp kombinerer full-stack udvikling med integration af kunstig intelligens. Deres offentliggjorte pensum inkluderer AI-assisteret kodning, integration af store sprogmodeller, produktionsimplementering, retrieval-augmented generation og autonome AI-agenter. (lewagon.com)

Denne model behandler kunstig intelligens som en rød tråd gennem programmet snarere end som en enkelt valgfri lektion. Studerende forventes at lære begge dele:

• Hvordan konventionelle softwaresystemer fungerer
• Hvordan man bruger AI-værktøjer til at bygge og drive disse systemer

Den kombination er vigtig. En lærende, der kun ved, hvordan man betjener en agent, er måske ude af stand til at genkende en fejlbehæftet arkitektur. En lærende, der kun kender konventionel programmering, er måske ikke forberedt på moderne udviklingsarbejdsgange.

Modellen med at "tilføje en AI-enhed"

Springboards softwareingeniør-bootcamp bevarer et konventionelt fundament inden for webudvikling, applikationsprogrammeringsgrænseflader (API'er), front-end udvikling, back-end udvikling og full-stack projekter, samtidig med at den tilføjer en AI-enhed fokuseret på prompt engineering og samarbejde med generative værktøjer. (springboard.com)

Denne model er nyttig for studerende, der først har brug for stærke programmeringsgrundlæggende. Den afspejler også en praktisk virkelighed: mange studerende bør ikke begynde med at bygge autonome agenter. De bør først lære, hvordan software fungerer, hvordan man bruger versionskontrol, hvordan man læser fejlmeddelelser, og hvordan man tester et program.

Svagheden er, at et kort prompt-engineering modul kan blive for overfladisk. Et seriøst pensum i agentæraen bør undervise i mere end hvordan man beder om kode. Det bør undervise i:

• Hvordan man opretter en repository kontekstfil
• Hvordan man skriver en teknisk specifikation
• Hvordan man definerer opgavegrænser
• Hvordan man begrænser en agents tilladelser
• Hvordan man inspicerer agentplaner
• Hvordan man evaluerer genererede tests
• Hvordan man opdager sikkerhedsproblemer
• Hvordan man sammenligner alternative designs
• Hvordan man dokumenterer agentens involvering

Hvad bootcamp-studerende bør kigge efter

Potentielle studerende bør spørge, om et program vurderer følgende:

• Kan studerende forklare kode, de ikke selv har skrevet?
• Gennemgår og reparerer studerende fejlbehæftet agent-output?
• Bliver tests, sikkerhed og vedligeholdbarhed bedømt?
• Er der en live demonstration eller et teknisk forsvar?
• Opretholder studerende en versionskontrolleret projekthistorik?
• Bliver studerende undervist i, hvordan man arbejder uden en agent, når det er nødvendigt?
• Underviser programmet i produktdiskovering og kravanalyse?
• Er værktøjsspecifikke færdigheder afbalanceret med holdbare ingeniørprincipper?

Et program, der annoncerer “byg en applikation på en uge med kunstig intelligens”, kan være fremragende til hurtig prototyping, men det er ikke det samme som at forberede nogen på professionel softwareingeniørarbejde.

Hvordan certificeringer tilpasses

Certificeringsudbydere udvikler tre brede typer af legitimationsoplysninger.

Værktøjsspecifikke videnscertificeringer

GitHub Copilot-certificeringen fra Microsoft vurderer ansvarlig brug, Copilot-funktioner, dataarkitektur, kontekst- og prompt-udformning, udviklerproduktivitet, privatliv, indholdseksklusioner og sikkerhedsforanstaltninger. Eksamen er overvåget, varer hundrede minutter og kan indeholde interaktive komponenter. (learn.microsoft.com)

Denne certificering anerkender nyttig arbejdspladsviden. Den kan vise, at en person forstår, hvordan man bruger en bestemt udviklingsplatform ansvarligt.

Dens begrænsning er, at den er stærkt knyttet til ét produkt. En professionel, der ved, hvordan man betjener GitHub Copilot, mangler måske stadig evnen til at nedbryde et komplekst produktkrav, udfordre et arkitektonisk valg eller gennemgå en sikkerhedsfølsom ændring.

Platformbaserede AI-udviklingscertificeringer

AWS Certified Generative AI Developer – Professional-certificeringen er bredere. Dens eksamensguide inkluderer integration af grundmodeller, datastyring, overholdelse, implementering, agentiske AI-løsninger, sikkerhed, governance, test, fejlfinding, overvågning og optimering. (docs.aws.amazon.com)

Eksamen er dog primært multiple choice og multiple response. Det er en omfattende videnstest, men den demonstrerer ikke fuldt ud, om en kandidat kan bygge, gennemgå eller forsvare et fungerende system. (aws.amazon.com)

Dette illustrerer et bredere problem: vidensprøver er lettere at skalere end præstationsprøver. Certificeringsorganisationer kan teste terminologi og designprincipper effektivt, men praktisk kompetence kræver et miljø, hvor kandidater skal træffe beslutninger og håndtere fejl.

Laboratoriebaserede og projektbaserede certificeringer

Microsoft Applied Skills-certificeringer tilbyder en mere lovende model. De kræver, at eleverne udfører interaktive opgaver, der stemmer overens med virkeligt arbejde i en laboratoriebaseret vurdering. Microsoft positionerer disse certificeringer som bevis på, at en kandidat kan løse virkelige cloud- og AI-udfordringer i stedet for blot at huske information. (learn.microsoft.com)

Carnegie Mellon Universitys executive education Agentic Artificial Intelligence Program kombinerer live undervisning, guidede laboratorier, opgaver, multi-agent-arbejdsgange, evaluering, sikkerhedsforanstaltninger (guardrails), logning, observerbarhed og et afsluttende projekt. (execonline.cs.cmu.edu)

Disse programmer er ikke identiske med uafhængig professionel certificering, men de viser den retning, legitimationsoplysninger sandsynligvis vil tage:

• Kortere praktiske vurderinger
• Sandboxed udviklingsmiljøer
• Realistiske repositories
• Evaluerings- og observerbarhedsopgaver
• Capstone systemer
• Mundtlige eller optagede tekniske forklaringer
• Bevis for ansvarlig brug af værktøjer

Vurderingsteknikker, der måler forståelse

Den bedste vurderingsstrategi forbyder ikke agenter fra enhver opgave. Den bruger agenter, hvor de afspejler professionel praksis og reserverer nogle aktiviteter til at måle uafhængig forståelse.

1. Specifikations- og nedbrydningsdokumenter

Før de skriver kode, skal studerende indsende:

• Brugerproblemet
• Funktionelle krav
• Ikke-funktionelle krav
• Antagelser
• Begrænsninger
• Datastrukturer
• Grænseflader
• Acceptkriterier
• En opgaveopdeling
• Kendte risici

Dokumentet skal forklare, hvorfor problemet er opdelt i specifikke opgaver.

Dette måler, om den studerende forstår problemet, før han/hun beder en agent om at implementere det.

2. Checkpoints for agentplanlægning

Kræv, at studerende viser agentens foreslåede plan, før implementeringen begynder. Den studerende skal identificere:

• Hvilke dele af planen der er acceptable
• Hvilke dele der er ufuldstændige
• Hvilke antagelser der er usikre
• Hvilke opgaver der kræver menneskelig godkendelse
• Hvilke tests der skal tilføjes

Den endelige karakter bør belønne kvaliteten af den studerendes dømmekraft, ikke længden af agentens plan.

3. Kodegennemgangsvurderinger

Giv studerende et agentgenereret repository, der indeholder bevidste fejl. Fejlene kan omfatte:

• Forkert håndtering af kanttilfælde
• Usikker godkendelse
• Dårlig fejlhåndtering
• Skjulte ydelsesproblemer
• Duplikeret logik
• Uklare grænseflader
• Utilstrækkelige tests
• Privatlivskrænkelser
• Afhængighedsrisici

Bed studerende om at udarbejde en gennemgang med alvorsgrader, beviser, foreslåede rettelser og regressionstests.

Dette er tættere på professionelt softwarearbejde end at bede studerende om at skabe en anden lille applikation fra bunden.

4. Forklaring og mundtligt forsvar

En studerende bør kunne forklare:

• Hvad systemet gør
• Hvorfor arkitekturen blev valgt
• Hvilke dele der blev genereret
• Hvilke antagelser agenten gjorde
• Hvordan testene demonstrerer korrekthed
• Hvad der stadig kunne fejle
• Hvilke kompromiser der blev accepteret

Et kort mundtligt forsvar kan udføres individuelt eller i små grupper. Det behøver ikke at være skræmmende. Fem til ti fokuserede spørgsmål er ofte nok til at afsløre, om en studerende forstår indsendelsen.

5. Overførselsopgaver

Efter en studerende har gennemført et agentassisteret projekt, skal der gives et nyt krav, der ikke kan løses ved blot at gentage den oprindelige prompt.

For eksempel:

• Tilføj en ny datakilde
• Ændr ydelsesmålet
• Understøt et uventet inputformat
• Fjern en afhængighed
• Tilføj adgangskontroller
• Forklar en fejlet test
• Refaktorér et modul uden at ændre dets adfærd

Den studerende må bruge en agent, men skal forklare planen, verificere ændringerne og forsvare resultatet.

Overførselsopgaver måler, om den studerende har lært en generel metode snarere end at have husket en vellykket interaktion.

6. Testdesign og adversariel test

Studerende bør bedømmes på kvaliteten af deres tests, ikke kun om den genererede kode består de givne tests.

Nyttige krav omfatter:

• Skriv grænsetests
• Opret negative tests
• Test ugyldigt input
• Test fejlgenopretning
• Kontroller ydelsesantagelser
• Brug egenskabsbaserede tests, hvor det er relevant
• Test sikkerhedsfølsom adfærd
• Forklar, hvad der forbliver utestet

Nøgle spørgsmålet er ikke “Bestod koden?” men “Vidste den studerende, hvad der skulle testes?”

7. Versionshistorik og procesporteføljer

En projektportefølje kan inkludere:

• Indledende specifikation
• Opgavenedbrydning
• Agentplaner
• Vigtige prompts eller instruktioner
• Commits
• Testresultater
• Gennemgangskommentarer
• Mislykkede tilgange
• Designændringer
• Afsluttende refleksion

En procesportefølje bør ikke blive et krav om at indsende hver linje af privat samtale. En repræsentativ registrering er ofte mere nyttig end en enorm transskription.

Princetons programmeringskursus fra 2025 tillod for eksempel generative AI-værktøjer, men krævede, at studerende beskrev deres brug i en readme-fil gennem et repræsentativt resumé snarere end en udtømmende udskrift. (cs.princeton.edu)

8. Struktureret peer review

Peer review forvandler studerende fra kun at være kode-producenter til kode-kritikere. Tidlig forskning tyder på, at rubric-baseret peer-vurdering kan tilnærme instruktørevaluering med moderat nøjagtighed, samtidig med at det udvikler evaluerende tænkning og engagement. (arxiv.org)

Studerende skal pålægges at begrunde deres kommentarer med beviser. “Denne kode er dårlig” er ikke en gennemgang. “Denne funktion udfører en databaseforespørgsel inde i en løkke, hvilket skaber et sandsynligt ydelsesproblem, når samlingen vokser” er en gennemgang.

9. Prompt- og specifikationsproblemer

Prompt-problemer er programmeringsøvelser, hvor studerende skriver instruktioner i naturligt sprog, der får et kunstigt intelligenssystem til at generere kode, der opfylder en specifikation. Tilgangen lærer eksplicit studerende at kommunikere beregningsmæssige krav til kodegenererende systemer. (arxiv.org)

Dette kan være nyttigt, men det bør ikke være den eneste vurderingsmetode. En undersøgelse fra 2026, der involverede mere end ni hundrede studerende, fandt, at almindelige fejl omfattede udeladelse af vigtige detaljer fra prompts. Når genereret kode fejlede, fokuserede studerende ofte på at afklare deres hensigt snarere end at spore koden eller undersøge testcases. (arxiv.org)

Prompting kan derfor afsløre dekomponerings- og kommunikationsfærdigheder, men det skal kombineres med kodelæsning, test, fejlfinding og gennemgang.

En eksempelvurderingsstruktur

Et praktisk projekt kunne bruge følgende vægtning:

Denne struktur belønner stadig et fungerende produkt, men den forhindrer en studerende i at modtage en høj karakter blot fordi en agent producerede en stor kodebase.

Akademisk integritet i agentassisteret kursusarbejde

Generelle forbud og ubegrænset brug er begge utilstrækkelige

Et generelt forbud kan være passende for en specifik grundlæggende vurdering, især når læringsmålet er uafhængig programmeringspraksis. Et universelt forbud er dog i stigende grad vanskeligt at håndhæve og kan forhindre studerende i at lære værktøjer, de vil møde i professionelt arbejde.

Ubegrænset brug er også utilstrækkelig. Hvis studerende kan indsende agentproduceret arbejde uden forklaring, kan vurderingen måle adgang til et værktøj snarere end læring.

Den stærkeste tilgang er eksplicit, opgavespecifik politik.

Tre nyttige politikformer

Tilstand et: Agent forbudt

Brug dette til:

• Eksamener
• Grundlæggende programmeringsøvelser
• Individuelle fejlfindingsdemonstrationer
• Kernealgoritmeøvelser
• Vurderinger designet til at måle uassisteret genkaldelse eller implementering

Carnegie Mellons kursus Principles of Imperative Computation forbyder AI-værktøjer til enhver del af bedømt arbejde, herunder generering af løsninger, forklaring af løsninger, formatering af kode og generering af testcases. (cs.cmu.edu)

Tilstand to: Agent begrænset

Brug dette, når studerende må spørge om:

• Begrebsforklaringer
• Dokumentationshjælp
• Fejlmeddelelsesfortolkning
• Afklaring af bibliotek eller API (Application Programming Interface)
• Brainstorming
• Kritik af et studenterskabt design
• Mindre refactoring

Carnegie Mellon systemkurser tillader AI-værktøjer til at forstå API'er (Application Programming Interfaces), biblioteker, frameworks, leveret kode og fejlmeddelelser, mens anmodninger om delvise eller komplette opgaveløsninger er forbudt. (cs.cmu.edu)

Tilstand tre: Agent tilladt med oplysning

Brug dette til realistiske softwareingeniørprojekter. Kræv, at studerende oplyser:

• Hvilke værktøjer der blev brugt
• Hvilke opgaver der blev delegeret
• Om genereret kode blev kopieret, ændret eller omskrevet
• Hvordan outputtet blev testet
• Hvad den studerende lærte
• Hvilke dele af designet der forbliver den studerendes ansvar

Princetons vejledning om akademisk integritet fastslår, at tilladt AI-brug stadig skal oplyses, og at fremstilling af genereret output som ens eget eller undladelse af at oplyse om dets brug kan udgøre en integritetskrænkelse. (scholarlyintegrity.princeton.edu)

Harvard Graduate School of Education tillader på samme måde anvendelser som afklaring, brainstorming og udforskning, mens studerende forbydes at indsende AI-genereret kursusarbejde som deres eget. Det kræver også dokumentation af tilladt brug og advarer om, at studerende forbliver ansvarlige for nøjagtighed, privatliv, ophavsret og bias. (registrar.gse.harvard.edu)

En praktisk oplysningserklæring

Et kursus kan give en simpel skabelon:

Jeg brugte [værktøjsnavn] til [planlægning, fejlfinding, kodegenerering, test, dokumentation eller gennemgang]. Jeg delegerede [specifikke opgaver]. Jeg gennemgik og modificerede outputtet, testede det resulterende system, og er fortsat ansvarlig for indsendelsens nøjagtighed, sikkerhed og originalitet.

Studerende bør ikke pålægges at oplyse om almindelig stavekorrektur på samme måde som delegeret implementering. Politikker bør skelne mellem mindre assistance og væsentlig kognitiv eller teknisk bidrag.

Privatliv og lige adgang

Institutioner bør levere godkendte værktøjer eller alternativer. Studerende bør ikke pålægges at uploade fortroligt kursusarbejde, personlige oplysninger, upubliceret forskning eller proprietær kode til offentlige systemer.

UNESCOs vejledning opfordrer til en menneskecentreret tilgang, der adresserer privatliv, sikkerhed, lighed, inklusion og institutionel parathed. (unesco.org)

Kurser bør også tage hensyn til studerende, der ikke har råd til flere betalte værktøjer. Et retfærdigt kursus kan:

• Udbyde et fælles institutionelt værktøj
• Tilbyde et lokalt eller open source-alternativ
• Designe opgaver, der ikke afhænger af én leverandør
• Bedømme ræsonnement snarere end adgang til den mest kraftfulde model
• Tillade ikke-agent-veje for hvert væsentligt læringsudbytte

Praktiske metoder til produktiv inkorporering af agenter

Brug et kontrolleret repository

Giv studerende et repository, der indeholder:

• En klar readme-fil
• En lille, men realistisk kodebase
• Automatiserede tests
• En kontinuerlig integrationsarbejdsgang
• En liste over kendte problemer
• En stilguide
• En sikkerhedscheckliste
• En ændringslog

Dette gør agentbrug observerbart og giver studerende noget mere realistisk end en tom kodningsøvelse.

Kræv en plan før implementering

Studerende bør ikke begynde med at bede en agent om at “bygge hele applikationen”. Kræv en sekvens:

1. Bed agenten om at inspicere repository'et.
2. Bed om et resumé af arkitekturen.
3. Bed om risici og manglende information.
4. Skriv den studerendes egen opgaveplan.
5. Godkend en lille implementeringsopgave.
6. Gennemgå de resulterende ændringer.
7. Kør tests før du fortsætter.

Dette lærer kontrolleret delegering frem for blind delegering.

Brug et agentteam med klare roller

Et simpelt orkestreringsmønster kan inkludere:

• Planlægger: foreslår opgaveopdelingen
• Implementator: ændrer koden
• Tester: opretter og kører tests
• Reviewer: søger efter fejl og risici
• Menneskelig evaluator: godkender eller afviser ændringer

Studerende bør lære, at tilføjelse af flere agenter ikke automatisk forbedrer kvaliteten. Flere agenter kan skabe modstridende instruktioner, duplikeret arbejde, øgede omkostninger og uklar ansvarlighed.

Målet med uddannelsen er ikke at bygge det største multi-agentsystem. Det er at vælge den simpleste arbejdsgang, der producerer troværdige resultater.

Indbyg menneskelige godkendelsesporte

Kræv udtrykkelig godkendelse, før en agent kan:

• Ændre godkendelse
• Ændre dataskemaer
• Tilføje afhængigheder
• Få adgang til produktionssystemer
• Ændre udrulningskonfiguration
• Slette filer
• Flette en pull-anmodning

Dette lærer studerende, at autonomi skal være begrænset af tilladelser og gennemgang.

Bedøm fejl bevidst

Agenter er mest lærerige, når de fejler på informative måder. Instruktører bør inkludere:

• Tvetydige krav
• Modstridende begrænsninger
• Ufuldstændige tests
• Sikkerhedsfølsomme operationer
• Vildledende dokumentation
• Flaky tests (ustabile tests)
• Ydelsesbegrænsninger
• En ændring, der ser korrekt ud, men ødelægger en anden funktion

Den studerendes opgave er at diagnosticere fejlen og forbedre processen.

En kompetenceramme for 2026 til 2031

Den følgende ramme er designet til at forblive nyttig, selv når specifikke værktøjer ændres.

Domæne et: Tekniske grundlag og kodefærdigheder

En kompetent udvikler kan:

• Læse ukendt kode
• Forklare kontrolflow og dataflow
• Forstå grænseflader og afhængigheder
• Analysere algoritmisk kompleksitet
• Bruge versionskontrol
• Fejlfinde uden udelukkende at stole på en agent

Bevis: kodeforklaring, manuel fejlfindingsopgave, designkritik og individuel overførselsøvelse.

Domæne to: Problemformulering og nedbrydning

En kompetent udvikler kan:

• Afklare brugerens mål
• Identificere begrænsninger og antagelser
• Adskille essentielle fra valgfri krav
• Opdele arbejde i uafhængigt testbare opgaver
• Definere acceptkriterier
• Erkende, når en opgave er for bred til pålidelig delegering

Bevis: specifikation, opgavegraf, risikoregister og forklaring af nedbrydningsvalg.

Domæne tre: Agentstyring og kontekst-engineering

En kompetent udvikler kan:

• Give relevant repository-kontekst
• Give præcise instruktioner
• Definere grænser og tilladelser
• Vælge, hvornår man skal bruge en agent, og hvornår man ikke skal bruge en
• Sammenligne alternative planer
• Komme sig, når agenten følger den forkerte fortolkning

Bevis: planlægningscheckpoints, repræsentative interaktionslogfiler og en live revisionsopgave.

Domæne fire: Verifikation og gennemgang

En kompetent udvikler kan:

• Inspicere genereret kode
• Designe meningsfulde tests
• Identificere skjulte antagelser
• Gennemgå sikkerheds- og privatlivsrisici
• Evaluere vedligeholdbarhed
• Forklare, hvad testene ikke beviser

Bevis: kodegennemgang, adversarial tests, fejlfinding øvelse og mundtligt forsvar.

Domæne fem: Orkestrering og drift

En kompetent udvikler kan:

• Koordinere planlægnings-, implementerings-, test- og gennemgangsværktøjer
• Bruge checkpoints og menneskelige godkendelsesporte
• Spore omkostninger, tid og værktøjsadfærd
• Opretholde reproducerbare arbejdsgange
• Observere fejl og forbedre systemet
• Afgøre, om flere agenter tilføjer værdi

Bevis: fungerende orkestreringsarbejdsgang, logs, evalueringsrapport og omkostnings- eller ydelsesanalyse.

Domæne seks: Produkt- og systemdesign

En kompetent udvikler kan:

• Vælge et passende niveau af automatisering
• Designe modulære systemer
• Afbalancere hastighed, kvalitet, omkostninger og risiko
• Forbinde tekniske beslutninger med brugerresultater
• Erkende, når en simpel ikke-agent-løsning er bedre

Bevis: produktbrief, arkitekturbeslutningslog, prototype og brugercentreret demonstration.

Domæne syv: Ansvarlig professionel praksis

En kompetent udvikler kan:

• Oplyse om AI-assistance
• Beskytte private og proprietære oplysninger
• Respektere ophavsrets- og licensforpligtelser
• Identificere bias- og pålidelighedsrisici
• Kommunikere usikkerhed
• Acceptere ansvar for det endelige system

Bevis: oplysningserklæring, risikovurdering, privatlivsgennemgang og professionel præsentation.

Foreslåede færdighedsniveauer

Inden 2031 bør en professionel certificering demonstrere bevægelse gennem disse niveauer snarere end blot at bekræfte kendskab til et bestemt softwareværktøj.

Anbefalinger til forskellige interessenter

Universiteter

• Tilføj agent-bevidste softwareingeniørmoduler til eksisterende kurser.
• Bevar grundlæggende programmering og algoritmer.
• Erstat nogle kodegenereringsopgaver med gennemgangs- og overførselsopgaver.
• Kræv, at studerende forklarer og forsvarer vigtigt arbejde.
• Træn fakultetet i agentværktøjer, evalueringsdesign, privatliv og integritetspolitik.
• Byg delte repositories og sandkasse-miljøer.

Bootcamps

• Undervis i konventionel udvikling og agentassisteret udvikling sammen.
• Gør test, arkitektur og sikkerhed til centrale dele af pensum.
• Kræv porteføljeprojekter med proceslogfiler.
• Tilføj live tekniske demonstrationer.
• Undervis i produktdiskovering og kravskrivning.
• Undgå at love, at prompting alene skaber jobparate ingeniører.

Certificeringsudbydere

• Øg brugen af laboratoriebaserede vurderinger.
• Inkluder kodegennemgang, test, fejlfinding og trusselsanalyse.
• Brug realistiske repositories snarere end isolerede multiple-choice spørgsmål.
• Test værktøjsuafhængig dømmekraft.
• Tilføj korte mundtlige forklaringer eller optagede demonstrationer.
• Opdater indhold ofte uden at gøre certificeringen afhængig af én leverandørs grænseflade.

Undervisere

• Angiv præcist, hvad der er tilladt for hver vurdering.
• Design opgaver omkring det tilsigtede læringsudbytte.
• Giv studerende godkendte værktøjer eller tilsvarende alternativer.
• Vurder proces, ræsonnement og verifikation.
• Brug logs som bevis, ikke som det eneste bevis.
• Undgå at stole på AI-detektionssoftware som den primære integritetsmekanisme.

Lærende og produktudviklere

• Lær nok konventionel programmering til at læse og udfordre genereret kode.
• Start med et lille produkt snarere end en vag, stor applikation.
• Skriv specifikationen, før du åbner en agent.
• Deleger én opgave ad gangen.
• Gennemgå hver ændring og test hver antagelse.
• Opbevar en registrering af vigtige beslutninger.
• Behandl agenten som en hurtig junior-samarbejdspartner, ikke som en ubestridelig ekspert.

Det første næste skridt

For en, der påbegynder en produktudviklingsrejse, er det mest nyttige første skridt:

Vælg et lille brugerproblem og skriv en en-sides specifikation, før du beder en agent om at skrive kode.

Inkluder:

• Hvem brugeren er
• Hvilket problem de har
• Hvad den første version skal gøre
• Hvad den ikke må gøre
• Tre accepttests
• En vigtig sikkerheds- eller privatlivsbekymring
• Tre små implementeringsopgaver

Bed derefter agenten om at gennemgå specifikationen og identificere manglende krav, ikke om at bygge hele produktet.

Efter at have rettet specifikationen, deleger kun den første opgave. Gennemgå den foreslåede plan, inspicer ændringerne, kør testene, og skriv ned, hvad agenten gjorde forkert.

Den ene øvelse lærer den vigtigste lektie i agentæraen: kvaliteten af resultatet afhænger mindre af, hvor meget kode agenten kan producere, end af, hvor tydeligt mennesket definerer, overvåger og evaluerer arbejdet.

Konklusion

Udvikleruddannelsen bevæger sig mod en ny balance.

Studerende vil stadig skulle skrive kode, især mens de lærer grundlæggende koncepter. Men professionel kompetence vil i stigende grad blive demonstreret gennem problemnedbrydning, specifikation, kodeforståelse, gennemgang, test, orkestrering, produktbedømmelse og ansvarlig brug af autonome systemer.

De stærkeste læseplaner vil ikke behandle kodeagenter som snydemaskiner eller magiske vejledere. De vil behandle dem som kraftfulde, men fejlbarlige ingeniørværktøjer. Studerende vil lære, hvornår de skal bruge dem, hvordan de begrænses, hvordan deres output evalueres, og hvordan de tager ansvar for det endelige system.

Den mest holdbare udvikler i de næste fem år vil ikke være den person, der kan producere mest kode manuelt eller generere den længste prompt. Det vil være den person, der kan omdanne et uklart mål til en pålidelig proces, guide flere værktøjer mod dette mål, opdage fejl tidligt og forklare, hvorfor den resulterende software fortjener tillid.