Utviklerutdanning og vurdering i agentæraen

Utviklerutdanning og vurdering i agentæraen

Denne analysen reflekterer utdannings- og sertifiseringslandskapet per 26. juli 2026.

Introduksjon

Autonome kodeagenter endrer programvareutvikling fra en oppgave sentrert rundt kodeskriving til en sentrert rundt spesifisering av arbeid, delegering av oppgaver, overvåking av utførelse og gjennomgang av resultater.

Moderne kodeagenter kan inspisere et repositorium, utvikle en implementeringsplan, endre flere filer, kjøre tester, respondere på feil og åpne en pull request for menneskelig gjennomgang. GitHubs nåværende dokumentasjon beskriver arbeidsflyter der utviklere tildeler saker til agenter, overvåker arbeidet deres, ber om kodegjennomgang, gir tilbakemelding og godkjenner eller avviser resultatet. (docs.github.com)

Dette skaper et vanskelig spørsmål for utdanning:

Hvis en student kan be en agent om å produsere et fungerende program, hva bør studenten da være pålagt å forstå?

Svaret er ikke å forlate programmeringsgrunnlaget. Det er å endre hva dette grunnlaget brukes til.

Studenter må fortsatt forstå datastrukturer, algoritmer, programmeringsspråk, systemdesign, sikkerhet, testing og feilsøking. Imidlertid må de i økende grad anvende denne kunnskapen til:

• Dele opp tvetydige problemer i håndterbare oppgaver
• Skrive presise spesifikasjoner og akseptkriterier
• Gi nyttig kontekst til kodeagenter
• Vurdere om generert kode er korrekt og vedlikeholdbar
• Designe tester som avdekker skjulte feil
• Gjennomgå sikkerhets-, personvern-, ytelses- og arkitekturrisikoer
• Koordinere flere agenter eller verktøy uten å miste kontrollen
• Forklare og forsvare tekniske beslutninger

Den neste generasjonen av utviklerutdanning vil derfor vurdere mindre av studentens evne til å produsere store mengder kode, og mer av studentens evne til å forstå, styre, verifisere og forbedre programvaresystemer.

Det sentrale skiftet: Fra kodeproduksjon til ingeniørvurdering

Kodeagenter er ikke bare raskere autofullføring

Tradisjonelle kodeassistenter foreslår en linje, funksjon eller en liten kodeblokk. Autonome kodeagenter opererer i større skala. De kan jobbe på tvers av filer, påkalle utviklingsverktøy, utføre tester, inspisere dokumentasjon og fortsette gjennom flere trinn.

Dette endrer arbeidsenheten. Utviklerens arbeidsflyt ser i økende grad slik ut:

1. Forstå bruker- eller forretningsproblemet.
2. Definere ønsket oppførsel.
3. Bryte ned arbeidet i mindre oppgaver.
4. Tilordne en passende oppgave til en agent.
5. Inspisere agentens plan.
6. La agenten implementere innenfor et kontrollert miljø.
7. Kjøre tester og sikkerhetskontroller.
8. Gjennomgå resultatet.
9. Be om endringer eller revidere designet.
10. Godkjenne, flette og overvåke programvaren.

Den som hopper over planleggings- og gjennomgangsstadiene, kan fortsatt produsere kode, men kan ikke pålitelig produsere et pålitelig produkt.

Grensene for rå kodeutgang

Rå kodeproduksjon blir en svakere målestokk for evne fordi en agent raskt kan generere store mengder plausibel kode. Samtidig fortsetter agenter å slite med langvarig programvareutvikling, endringer i flere filer, uklare krav og opprettholdelse av atferd over gjentatte modifikasjoner. En referansestudie fra 2025 fant et betydelig gap mellom agentytelse på isolert problemhåndtering og mer komplekse, langsiktige programvareutviklingsoppgaver. (arxiv.org)

Dette skaper en viktig pedagogisk distinksjon:

• En student som kan generere kode, forstår den kanskje ikke.
• En student som kan forklare, teste, utfordre og reparere kode, demonstrerer dypere kompetanse.

Det pedagogiske målet bør derfor bli validert programvarevurdering, ikke bare vellykket kodegenerering.

Hvordan læreplaner tilpasses

Universitetslæreplaner beveger seg mot forståelse og verifisering

Rapporten Computer Science Curricula 2023 fra ACM, Institute of Electrical and Electronics Engineers Computer Society og Association for the Advancement of Artificial Intelligence forutså at generativ kunstig intelligens ville endre programmeringsutdanningen. Veiledningen deres antyder at studenter vil trenge mer vekt på å lese, forstå, verifisere, redigere, modifisere, tilpasse og teste kode. Den identifiserer også problemoppdeling som et område som sannsynligvis vil bli viktigere. (csed.acm.org)

Samme veiledning peker på et avgjørende poeng: selv når en agent skriver programmet, forblir mennesket ansvarlig for å avgjøre om programmet er korrekt. Dette betyr at programmeringsutdanning ikke kan reduseres til å skrive prompter. Studenter trenger tilstrekkelig teknisk forståelse for å evaluere resultatet.

Rapporten forutser også endringer i programvareingeniørutdanningen, inkludert større bruk av kunstig intelligens for kodegenerering, feilsøking, statisk analyse og kodegjennomgang. Effektiv bruk av disse verktøyene krever sterkere design- og kodeforståelsesferdigheter, ikke svakere. (csed.acm.org)

Akkreditering begynner å belønne bredere ingeniørresultater

De nåværende akkrediteringskriteriene for databehandling fra Accreditation Board for Engineering and Technology vektlegger allerede:

• Analyse av komplekse databehandlingsproblemer
• Design og evaluering av databehandlingsløsninger
• Profesjonell kommunikasjon
• Juridisk og etisk ansvar
• Sikkerhet og personvern
• Sosiale konsekvenser av databehandling
• En omfattende prosjekt- eller erfaringskomponent (abet.org)

Disse resultatene passer godt i et agentbasert utviklingsmiljø fordi de måler vurdering og ansvar snarere enn tastetrykk.

Per 26. juli 2026 inkluderer foreslåtte endringer fra Accreditation Board for Engineering and Technology for syklusen 2026–2027 ytterligere programkriterier for kunstig intelligens og et krav om at kandidater skal kunne anvende teorier, modeller og teknikker innen kunstig intelligens på komplekse problemer. De foreslåtte endringene ventet fortsatt på endelig vedtak og forventes å tre i kraft etter høstmøtet 2026, med første anvendelse i gjennomgangssyklusen 2027–2028. (abet.org)

Den sannsynlige retningen er klar: programmer må vise at studenter kan bygge og evaluere systemer, ikke bare fullføre isolerte programmeringsoppgaver.

Nye kurs underviser i agentbruk som en ingeniørdisiplin

Flere nylige universitetskurs illustrerer det fremvoksende mønsteret.

University of Marylands kurs fra 2025 om effektiv bruk av AI-kodeassistenter og agenter dekket verktøy som kan påkalle byggesystemer, kjøre tester og rette feil. Det adresserte også vedlikeholdbarhet, arkitektur, design av applikasjonsprogrammeringsgrensesnitt (API), effektivitet, skalerbarhet, sikkerhet, kontinuerlig integrasjon, kodegjennomgang, asynkrone agenter og automatisert kodegjennomgang. (cs.umd.edu)

University of Pennsylvania har foreslått et datavitenskapskurs på andreårsnivå med fokus på AI-drevet programvareutvikling. De foreslåtte emnene inkluderer delegering av kodingsoppgaver, modulær design, skalerbar testing, risikostyring, reproduserbarhet, samarbeid og etikk. (seas.upenn.edu)

University of Michigans høstkurs 2026, Applied Agentic Software Engineering, er enda mer eksplisitt. Det er organisert i tre faser:

1. Bruke kodeagenter effektivt
2. Bygge en agent ved hjelp av et API for store språkmodeller
3. Designe, evaluere og distribuere en agentorkestrator

Kurset bruker prosjekter, laboratorieøvelser, demonstrasjoner og avkryssinger i stedet for tradisjonelle eksamener. Det slår fast at karaktersettingen vil belønne forståelse fremfor resultat, og ber studentene forklare hvorfor en agent feilet og hvordan man fikser det omkringliggende systemet. (eecs498-aase.github.io)

Dette er en betydelig designendring. Kurset lærer ikke studentene å produsere kode raskere. Det lærer dem å bli tekniske veiledere for systemer som produserer kode.

Hvordan Bootcamps endrer seg

Bootcamps tilpasser seg raskere enn mange tradisjonelle programmer fordi læreplanene deres er nært knyttet til ansettelseskrav. Kvaliteten på tilpasningen varierer imidlertid.

Den dedikerte AI-bootcamp-modellen

Le Wagons nåværende bootcamp for AI-programvareutvikling kombinerer full-stack-utvikling med AI-integrasjon. Den publiserte læreplanen inkluderer AI-assistert koding, integrasjon av store språkmodeller, produksjonsdistribusjon, retrieval-augmented generation og autonome AI-agenter. (lewagon.com)

Denne modellen behandler kunstig intelligens som en rød tråd gjennom programmet snarere enn som en enkelt valgfri leksjon. Studenter forventes å lære begge deler:

• Hvordan konvensjonelle programvaresystemer fungerer
• Hvordan bruke AI-verktøy for å bygge og drifte disse systemene

Denne kombinasjonen er viktig. En lærende som bare vet hvordan man opererer en agent, er kanskje ikke i stand til å gjenkjenne en feilaktig arkitektur. En lærende som bare kan konvensjonell programmering, er kanskje ikke forberedt på moderne utviklingsarbeidsflyter.

Modellen «legg til en AI-enhet»

Springboards programvareingeniør-bootcamp beholder et konvensjonelt grunnlag innen webutvikling, applikasjonsprogrammeringsgrensesnitt (APIer), front-end-utvikling, back-end-utvikling og full-stack-prosjekter, samtidig som den legger til en AI-enhet fokusert på prompt-engineering og samarbeid med generative verktøy. (springboard.com)

Denne modellen er nyttig for studenter som først trenger sterke programmeringsfundamenter. Den reflekterer også en praktisk realitet: mange studenter bør ikke starte med å bygge autonome agenter. De bør først lære hvordan programvare fungerer, hvordan man bruker versjonskontroll, hvordan man leser feilmeldinger og hvordan man tester et program.

Svakheten er at en kort prompt-engineering-modul kan bli for overfladisk. En seriøs læreplan for agentæraen bør undervise i mer enn hvordan man ber om kode. Den bør undervise i:

• Hvordan opprette en repositoriekontekstfil
• Hvordan skrive en teknisk spesifikasjon
• Hvordan definere oppgavegrenser
• Hvordan begrense en agents tillatelser
• Hvordan inspisere agentplaner
• Hvordan evaluere genererte tester
• Hvordan oppdage sikkerhetsproblemer
• Hvordan sammenligne alternative design
• Hvordan dokumentere agentens involvering

Hva bootcamp-studenter bør se etter

Potensielle studenter bør spørre om et program vurderer følgende:

• Kan studenter forklare kode de ikke selv har skrevet?
• Gjennomgår og reparerer studenter feilaktig agentutdata?
• Er tester, sikkerhet og vedlikeholdbarhet karakterbelagt?
• Er det en live demonstrasjon eller teknisk forsvar?
• Opprettholder studenter en versjonskontrollert prosjekthistorikk?
• Blir studenter lært hvordan de skal jobbe uten en agent når det er nødvendig?
• Underviser programmet i produktoppdagelse og kravsanalyse?
• Er verktøyspesifikke ferdigheter balansert med varige ingeniørprinsipper?

Et program som annonserer «bygg en applikasjon på én uke med kunstig intelligens» kan være utmerket for rask prototyping, men det er ikke det samme som å forberede noen for profesjonell programvareutvikling.

Hvordan sertifiseringer tilpasses

Sertifiseringsleverandører utvikler tre brede typer sertifikater.

Verktøyspesifikke kunnskapssertifiseringer

GitHub Copilot-sertifiseringen fra Microsoft vurderer ansvarlig bruk, Copilot-funksjoner, dataarkitektur, kontekst- og prompt-utforming, utviklerproduktivitet, personvern, innholdsutestengelser og sikkerhetstiltak. Eksamen er overvåket, varer i hundre minutter og kan inneholde interaktive komponenter. (learn.microsoft.com)

Dette sertifikatet anerkjenner nyttig arbeidsplasskunnskap. Det kan vise at en person forstår hvordan man bruker en spesifikk utviklingsplattform ansvarlig.

Begrensningen er at det er sterkt knyttet til ett produkt. En profesjonell som vet hvordan man opererer GitHub Copilot, kan fortsatt mangle evnen til å dekomponere et komplekst produktkrav, utfordre et arkitektonisk valg eller gjennomgå en sikkerhetsfølsom endring.

Plattformbaserte AI-utviklingssertifiseringer

AWS Certified Generative AI Developer – Professional-sertifiseringen er bredere. Dens eksamensguide inkluderer integrasjon av grunnleggende modeller, datahåndtering, overholdelse, implementering, agentbaserte AI-løsninger, sikkerhet, styring, testing, feilsøking, overvåking og optimalisering. (docs.aws.amazon.com)

Eksamen består imidlertid primært av flervalgsspørsmål og spørsmål med flere svar. Det er en omfattende kunnskapstest, men den demonstrerer ikke fullt ut om en kandidat kan bygge, gjennomgå eller forsvare et fungerende system. (aws.amazon.com)

Dette illustrerer et bredere problem: kunnskapstester er lettere å skalere enn ytelsestester. Sertifiseringsorganisasjoner kan teste terminologi og designprinsipper effektivt, men praktisk kompetanse krever et miljø der kandidater må ta beslutninger og håndtere feil.

Lab-baserte og prosjektbaserte sertifikater

Microsoft Applied Skills-sertifikater tilbyr en mer lovende modell. De krever at studentene fullfører interaktive oppgaver tilpasset reelt arbeid i en lab-basert vurdering. Microsoft posisjonerer disse sertifikatene som bevis på at en kandidat kan løse virkelige sky- og AI-utfordringer i stedet for bare å huske informasjon. (learn.microsoft.com)

Carnegie Mellon Universitys etterutdanningsprogram for ledere, Agentic Artificial Intelligence Program, kombinerer live undervisning, veiledede laboratorieøvelser, oppgaver, multiagent-arbeidsflyter, evaluering, sikkerhetsmekanismer, logging, observerbarhet og et sluttprosjekt. (execonline.cs.cmu.edu)

Disse programmene er ikke identiske med uavhengig profesjonell sertifisering, men de viser retningen sertifikatene sannsynligvis vil ta:

• Kortere praktiske vurderinger
• Sandkasset utviklingsmiljø
• Realistiske repositorier
• Evaluerings- og observerbarhetsoppgaver
• Avsluttende systemer
• Muntlige eller innspilte tekniske forklaringer
• Bevis på ansvarlig verktøybruk

Vurderingsteknikker som måler forståelse

Den beste vurderingsstrategien forbyr ikke agenter fra hver eneste oppgave. Den bruker agenter der de reflekterer profesjonell praksis og forbeholder noen aktiviteter for å måle uavhengig forståelse.

1. Spesifikasjons- og dekomponeringsdokumenter

Før kodeskriving kreves det at studenter leverer:

• Brukerproblemet
• Funksjonelle krav
• Ikke-funksjonelle krav
• Antagelser
• Begrensninger
• Datastrukturer
• Grensesnitt
• Akseptkriterier
• En oppgavedeling
• Kjente risikoer

Dokumentet bør forklare hvorfor problemet er delt inn i spesifikke oppgaver.

Dette måler om studenten forstår problemet før han ber en agent om å implementere det.

2. Sjekkpunkter for agentplanlegging

Krev at studentene viser agentens foreslåtte plan før implementering starter. Studenten må identifisere:

• Hvilke deler av planen som er akseptable
• Hvilke deler som er ufullstendige
• Hvilke antagelser som er usikre
• Hvilke oppgaver som krever menneskelig godkjenning
• Hvilke tester som bør legges til

Den endelige karakteren bør belønne kvaliteten på studentens vurdering, ikke lengden på agentens plan.

3. Kodegjennomgangsvurderinger

Gi studentene et agentgenerert repositorium som inneholder bevisste feil. Feilene kan inkludere:

• Feil håndtering av grensetilfeller
• Usikker autentisering
• Dårlig feilhåndtering
• Skjulte ytelsesproblemer
• Duplisert logikk
• Uklare grensesnitt
• Utilstrekkelige tester
• Personvernbrudd
• Avhengighetsrisikoer

Be studentene om å produsere en gjennomgang med alvorlighetsgrader, bevis, foreslåtte rettelser og regresjonstester.

Dette er nærmere profesjonelt programvarearbeid enn å be studentene om å lage en annen liten applikasjon fra bunnen av.

4. Forklaring og muntlig forsvar

En student bør kunne forklare:

• Hva systemet gjør
• Hvorfor arkitekturen ble valgt
• Hvilke deler som ble generert
• Hvilke antagelser agenten gjorde
• Hvordan testene demonstrerer korrekthet
• Hva som fortsatt kan feile
• Hvilke avveininger som ble akseptert

Et kort muntlig forsvar kan gjennomføres individuelt eller i små grupper. Det trenger ikke å være skremmende. Fem til ti fokuserte spørsmål er ofte nok til å avsløre om en student forstår innleveringen.

5. Overføringsoppgaver

Etter at en student har fullført et agentassistert prosjekt, gi et nytt krav som ikke kan løses ved å bare gjenta den opprinnelige prompten.

For eksempel:

• Legge til en ny datakilde
• Endre ytelsesmålet
• Støtte et uventet inndataformat
• Fjerne en avhengighet
• Legge til tilgangskontroller
• Forklare en feilende test
• Refaktorere en modul uten å endre dens oppførsel

Studenten kan bruke en agent, men må forklare planen, verifisere endringene og forsvare resultatet.

Overføringsoppgaver måler om studenten lærte en generell metode snarere enn å huske en vellykket interaksjon.

6. Testdesign og adversariell testing

Studenter bør vurderes basert på kvaliteten på testene deres, ikke bare om den genererte koden passerer gitte tester.

Nyttige krav inkluderer:

• Skrive grensetester
• Opprette negative tester
• Teste ugyldig inndata
• Teste feilgjenoppretting
• Sjekke ytelsesantagelser
• Bruke egenskapsbaserte tester der det er hensiktsmessig
• Teste sikkerhetsfølsom atferd
• Forklare hva som forblir uutprøvd

Nøkkelspørsmålet er ikke «Bestod koden?» men «Visste studenten hva som måtte testes?»

7. Versjonshistorikk og prosessporteføljer

En prosjektportefølje kan inkludere:

• Innledende spesifikasjon
• Oppgavedekomponering
• Agentplaner
• Viktige prompter eller instruksjoner
• Commits
• Testresultater
• Gjennomgangskommentarer
• Mislykkede tilnærminger
• Designendringer
• Avsluttende refleksjon

En prosessportefølje bør ikke bli et krav om å levere hver linje med privat samtale. En representativ oversikt er ofte mer nyttig enn en enorm transkripsjon.

Prinsjeprogrammeringskurset fra 2025, for eksempel, tillot generative AI-verktøy, men krevde at studentene beskrev bruken i en readme-fil gjennom en representativ oppsummering snarere enn en uttømmende transkripsjon. (cs.princeton.edu)

8. Strukturert fagfellevurdering

Fagfellevurdering forvandler studenter fra å bare være kodeprodusenter til kodekritikere. Tidlig forskning tyder på at rubrikkbasert fagfellevurdering kan tilnærme instruktørevaluering med moderat nøyaktighet samtidig som den utvikler evaluerende tenkning og engasjement. (arxiv.org)

Studenter bør pålegges å begrunne kommentarene sine med bevis. «Denne koden er dårlig» er ikke en vurdering. «Denne funksjonen utfører en databaseforespørsel inne i en løkke, noe som skaper et sannsynlig ytelsesproblem når samlingen vokser» er en vurdering.

9. Prompt- og spesifikasjonsproblemer

Prompt-problemer er programmeringsøvelser der studenter skriver naturlig språk-instruksjoner som får et AI-system til å generere kode som tilfredsstiller en spesifikasjon. Tilnærmingen lærer eksplisitt studentene å kommunisere beregningskrav til kodegenererende systemer. (arxiv.org)

Dette kan være nyttig, men det bør ikke være den eneste vurderingsmetoden. En studie fra 2026 som involverte over ni hundre studenter, fant at vanlige feil inkluderte å utelate viktige detaljer fra prompter. Når generert kode feilet, fokuserte studentene ofte på å klargjøre sin intensjon snarere enn å spore koden eller undersøke testtilfeller. (arxiv.org)

Prompter kan derfor avsløre dekomponerings- og kommunikasjonsferdigheter, men må kombineres med koding, testing, feilsøking og gjennomgang.

En eksempelvurderingsstruktur

Et praktisk prosjekt kan bruke følgende vektlegging:

Denne strukturen belønner fortsatt et fungerende produkt, men den forhindrer at en student får en høy karakter bare fordi en agent produserte en stor kodebase.

Akademisk integritet i agentassisterte kurs

Både generelle forbud og ubegrenset bruk er utilstrekkelige

Et generelt forbud kan være passende for en spesifikk grunnleggende vurdering, spesielt når læringsmålet er uavhengig programmeringspraksis. Imidlertid blir et universelt forbud stadig vanskeligere å håndheve og kan hindre studenter i å lære verktøy de vil møte i profesjonelt arbeid.

Ubegrenset bruk er også utilstrekkelig. Hvis studenter kan levere agentprodusert arbeid uten forklaring, kan vurderingen måle tilgang til et verktøy snarere enn læring.

Den sterkeste tilnærmingen er eksplisitt, oppgavenivåpolicy.

Tre nyttige policy-moduser

Modus én: Agent forbudt

Bruk dette for:

• Eksamener
• Grunnleggende programmeringsøvelser
• Individuelle feilsøkingsdemonstrasjoner
• Kjernealgoritmeøvelser
• Vurderinger designet for å måle uassistert gjenkalling eller implementering

Carnegie Mellons kurs i Principles of Imperative Computation forbyr AI-verktøy for enhver del av gradert arbeid, inkludert generering av løsninger, forklaring av løsninger, formatering av kode og generering av testtilfeller. (cs.cmu.edu)

Modus to: Agent begrenset

Bruk dette når studenter kan spørre om:

• Konseptforklaringer
• Dokumentasjonshjelp
• Tolkning av feilmeldinger
• Avklaring av bibliotek eller applikasjonsprogrammeringsgrensesnitt (API)
• Idémyldring
• Kritikk av et student-opprettet design
• Mindre refaktorering

Carnegie Mellon-systemkurs tillater AI-verktøy for å forstå applikasjonsprogrammeringsgrensesnitt (APIer), biblioteker, rammeverk, gitt kode og feilmeldinger, samtidig som de forbyr forespørsler om delvise eller komplette oppgaveløsninger. (cs.cmu.edu)

Modus tre: Agent tillatt med offentliggjøring

Bruk dette for realistiske programvareingeniørprosjekter. Krev at studentene offentliggjør:

• Hvilke verktøy som ble brukt
• Hvilke oppgaver som ble delegert
• Om generert kode ble kopiert, modifisert eller omskrevet
• Hvordan resultatet ble testet
• Hva studenten lærte
• Hvilke deler av designet som forblir studentens ansvar

Princetons veiledning om akademisk integritet slår fast at tillatt AI-bruk fortsatt må offentliggjøres, og at å fremstille generert resultat som sitt eget eller unnlate å offentliggjøre bruken kan utgjøre et brudd på integriteten. (scholarlyintegrity.princeton.edu)

Harvard Graduate School of Education tillater tilsvarende bruksområder som avklaring, idémyldring og utforskning, samtidig som studenter forbys å levere AI-generert kursarbeid som sitt eget. Det krever også dokumentasjon av tillatt bruk og advarer om at studenter forblir ansvarlige for nøyaktighet, personvern, opphavsrett og skjevhet. (registrar.gse.harvard.edu)

En praktisk offentliggjøringserklæring

Et kurs kan tilby en enkel mal:

Jeg brukte [verktøynavn] for [planlegging, feilsøking, kodegenerering, testing, dokumentasjon eller gjennomgang]. Jeg delegerte [spesifikke oppgaver]. Jeg gjennomgikk og modifiserte resultatet, testet det resulterende systemet, og forblir ansvarlig for nøyaktigheten, sikkerheten og originaliteten i innleveringen.

Studenter bør ikke pålegges å offentliggjøre vanlig stavekontroll på samme måte som delegert implementering. Retningslinjer bør skille mellom mindre assistanse og betydelig kognitiv eller teknisk bidrag.

Personvern og lik tilgang

Institusjoner bør tilby godkjente verktøy eller alternativer. Studenter bør ikke pålegges å laste opp konfidensielt kursarbeid, personlig informasjon, upublisert forskning eller proprietær kode til offentlige systemer.

UNESCOs veiledning etterlyser en menneskesentrert tilnærming som adresserer personvern, sikkerhet, likhet, inkludering og institusjonell beredskap. (unesco.org)

Kurs bør også vurdere studenter som ikke har råd til flere betalte verktøy. Et rettferdig kurs kan:

• Tilby et felles institusjonelt verktøy
• Tilby et lokalt eller åpen kildekode-alternativ
• Designe oppgaver som ikke avhenger av én leverandør
• Karaktersette resonnement snarere enn tilgang til den kraftigste modellen
• Tillate ikke-agent-veier for hvert essensielle læringsutbytte

Praktiske metoder for å innlemme agenter produktivt

Bruk et kontrollert repositorium

Gi studentene et repositorium som inneholder:

• En tydelig readme-fil
• En liten, men realistisk kodebase
• Automatiserte tester
• En arbeidsflyt for kontinuerlig integrasjon
• En liste over kjente problemer
• En stilguide
• En sikkerhetssjekkliste
• En endringslogg

Dette gjør agentbruk observerbart og gir studentene noe mer realistisk enn en tom kodeøvelse.

Krev en plan før implementering

Studenter bør ikke starte med å be en agent om å «bygge hele applikasjonen». Krev en sekvens:

1. Be agenten om å inspisere repositoriet.
2. Be om en oppsummering av arkitekturen.
3. Be om risikoer og manglende informasjon.
4. Skriv studentens egen oppgaveplan.
5. Godkjenn en liten implementeringsoppgave.
6. Gjennomgå de resulterende endringene.
7. Kjør tester før du fortsetter.

Dette lærer kontrollert delegering snarere enn blind delegering.

Bruk et agentteam med klare roller

Et enkelt orkestreringsmønster kan inkludere:

• Planlegger: foreslår oppgavedelingen
• Implementator: endrer koden
• Tester: lager og kjører tester
• Gransker: søker etter feil og risikoer
• Menneskelig evaluator: godkjenner eller avviser endringer

Studenter bør lære at det å legge til flere agenter ikke automatisk forbedrer kvaliteten. Flere agenter kan skape motstridende instruksjoner, duplisert innsats, økte kostnader og uklart ansvar.

Det pedagogiske målet er ikke å bygge det største multiagentsystemet. Det er å velge den enkleste arbeidsflyten som produserer pålitelige resultater.

Bygg inn menneskelige godkjenningsporter

Krev eksplisitt godkjenning før en agent kan:

• Endre autentisering
• Modifisere dataskjemaer
• Legge til avhengigheter
• Få tilgang til produksjonssystemer
• Endre distribusjonskonfigurasjon
• Slette filer
• Flette en pull request

Dette lærer studentene at autonomi må begrenses av tillatelser og gjennomgang.

Karaktersett feil bevisst

Agenter er mest lærerike når de feiler på informative måter. Instruktører bør inkludere:

• Tvetydige krav
• Motstridende begrensninger
• Ufullstendige tester
• Sikkerhetsfølsomme operasjoner
• Villedende dokumentasjon
• Ustabile tester
• Ytelsesgrenser
• En endring som ser korrekt ut, men bryter en annen funksjon

Studentens oppgave er å diagnostisere feilen og forbedre prosessen.

Et kompetanserammeverk for 2026 til 2031

Følgende rammeverk er designet for å forbli nyttig selv når spesifikke verktøy endres.

Domene én: Tekniske grunnlag og kodekunnskap

En kompetent utvikler kan:

• Lese ukjent kode
• Forklare kontrollflyt og dataflyt
• Forstå grensesnitt og avhengigheter
• Analysere algoritmisk kompleksitet
• Bruke versjonskontroll
• Feilsøke uten å stole utelukkende på en agent

Bevis: kodeforklaring, manuell feilsøkingsoppgave, designkritikk og individuell overføringsøvelse.

Domene to: Problemformulering og dekomponering

En kompetent utvikler kan:

• Klargjøre brukerens mål
• Identifisere begrensninger og antagelser
• Separere essensielle fra valgfrie krav
• Bryte ned arbeid i uavhengig testbare oppgaver
• Definere akseptkriterier
• Gjenkjenne når en oppgave er for bred for pålitelig delegering

Bevis: spesifikasjon, oppgavegraf, risikoregister og forklaring av dekomponeringsvalg.

Domene tre: Agentstyring og kontekstingeniørkunst

En kompetent utvikler kan:

• Gi relevant repositoriumkontekst
• Gi presise instruksjoner
• Definere grenser og tillatelser
• Velge når man skal bruke en agent og når man ikke skal
• Sammenligne alternative planer
• Komme seg når agenten følger feil tolkning

Bevis: planleggingssjekkpunkter, representative interaksjonsposter og en live revisjonsoppgave.

Domene fire: Verifisering og gjennomgang

En kompetent utvikler kan:

• Inspisere generert kode
• Designe meningsfulle tester
• Identifisere skjulte antagelser
• Gjennomgå sikkerhets- og personvernrisikoer
• Evaluere vedlikeholdbarhet
• Forklare hva testene ikke beviser

Bevis: kodegjennomgang, adversarielle tester, feilsøkingsoppgave og muntlig forsvar.

Domene fem: Orkestrering og operasjoner

En kompetent utvikler kan:

• Koordinere planleggings-, implementerings-, test- og gjennomgangsverktøy
• Bruke sjekkpunkter og menneskelige godkjenningsporter
• Spore kostnad, tid og verktøyatferd
• Opprettholde reproduserbare arbeidsflyter
• Observere feil og forbedre systemet
• Bestemme om flere agenter tilfører verdi

Bevis: fungerende orkestreringsarbeidsflyt, logger, evalueringsrapport og kostnads- eller ytelsesanalyse.

Domene seks: Produkt- og systemdesign

En kompetent utvikler kan:

• Velge et passende automatiseringsnivå
• Designe modulære systemer
• Balansere hastighet, kvalitet, kostnad og risiko
• Koble tekniske beslutninger til brukerresultater
• Gjenkjenne når en enkel ikke-agentløsning er bedre

Bevis: produktbeskrivelse, arkitekturavgjørelseslogg, prototype og brukersentrert demonstrasjon.

Domene syv: Ansvarlig profesjonell praksis

En kompetent utvikler kan:

• Offentliggjøre AI-assistanse
• Beskytte privat og proprietær informasjon
• Respektere opphavsrett og lisensforpliktelser
• Identifisere skjevheter og pålitelighetsrisikoer
• Kommunisere usikkerhet
• Akseptere ansvar for det endelige systemet

Bevis: offentliggjøringserklæring, risikovurdering, personverngjennomgang og profesjonell presentasjon.

Foreslåtte ferdighetsnivåer

Innen 2031 bør et profesjonelt sertifikat demonstrere bevegelse gjennom disse nivåene snarere enn å bare bekrefte kjennskap til et spesifikt programvareverktøy.

Anbefalinger for ulike interessenter

Universiteter

• Legg til agentbevisste programvareingeniørmoduler i eksisterende kurs.
• Bevare grunnleggende programmering og algoritmer.
• Erstatte noen kodegenereringsoppgaver med gjennomgangs- og overføringsoppgaver.
• Krev at studenter forklarer og forsvarer viktig arbeid.
• Trene fakultetet i agentverktøy, evalueringsdesign, personvern og integritetspolicy.
• Bygge delte repositorier og sandkasse-miljøer.

Bootcamps

• Undervise i konvensjonell utvikling og agentassistert utvikling sammen.
• Gjøre testing, arkitektur og sikkerhet til sentrale deler av læreplanen.
• Krev porteføljeprosjekter med prosesshistorikk.
• Legge til live tekniske demonstrasjoner.
• Undervise i produktoppdagelse og kravsskriving.
• Unngå å love at prompting alene skaper jobbklar ingeniører.

Sertifiseringsleverandører

• Øke bruken av lab-baserte vurderinger.
• Inkludere kodegjennomgang, testing, feilsøking og trusselanalyse.
• Bruke realistiske repositorier snarere enn isolerte flervalgsspørsmål.
• Teste verktøyuavhengig vurdering.
• Legge til korte muntlige forklaringer eller innspilte demonstrasjoner.
• Oppdatere innhold ofte uten å gjøre sertifikatet avhengig av én leverandørs grensesnitt.

Instruktører

• Angi nøyaktig hva som er tillatt for hver vurdering.
• Designe oppgaver rundt det tiltenkte læringsutbyttet.
• Gi studenter godkjente verktøy eller tilsvarende alternativer.
• Vurdere prosess, resonnement og verifisering.
• Bruke logger som bevis, ikke som det eneste beviset.
• Unngå å stole på AI-deteksjonsprogramvare som den primære integritetsmekanismen.

Lærende og produktutviklere

• Lære nok konvensjonell programmering til å lese og utfordre generert kode.
• Starte med et lite produkt snarere enn en vag, stor applikasjon.
• Skrive spesifikasjonen før du åpner en agent.
• Deleger én sak om gangen.
• Gjennomgå hver endring og test hver antagelse.
• Holde en oversikt over viktige beslutninger.
• Behandle agenten som en rask junior-samarbeidspartner, ikke som en udiskutabel ekspert.

Det første neste skrittet

For noen som starter en produktutviklingsreise, er det mest nyttige første skrittet:

Velg ett lite brukerproblem og skriv en én-sides spesifikasjon før du ber en agent om å skrive kode.

Inkluder:

• Hvem brukeren er
• Hvilket problem de har
• Hva den første versjonen må gjøre
• Hva den ikke må gjøre
• Tre aksepttester
• Én viktig sikkerhets- eller personvernhensyn
• Tre små implementeringsoppgaver

Be deretter agenten om å gjennomgå spesifikasjonen og identifisere manglende krav, ikke å bygge hele produktet.

Etter å ha korrigert spesifikasjonen, deleger kun den første oppgaven. Gjennomgå den foreslåtte planen, inspiser endringene, kjør testene, og skriv ned hva agenten gjorde feil.

Den ene øvelsen lærer den viktigste leksjonen fra agentæraen: kvaliteten på resultatet avhenger mindre av hvor mye kode agenten kan produsere, enn av hvor tydelig mennesket definerer, overvåker og evaluerer arbeidet.

Konklusjon

Utviklerutdanningen beveger seg mot en ny balanse.

Studenter vil fortsatt måtte skrive kode, spesielt mens de lærer grunnleggende konsepter. Men profesjonell kompetanse vil i økende grad demonstreres gjennom problemoppdeling, spesifikasjon, kodeforståelse, gjennomgang, testing, orkestrering, produktvurdering og ansvarlig bruk av autonome systemer.

De sterkeste læreplanene vil ikke behandle kodeagenter som juksemaskiner eller magiske veiledere. De vil behandle dem som kraftige, men feilbarlige ingeniørverktøy. Studenter vil lære når de skal bruke dem, hvordan de skal begrense dem, hvordan de skal evaluere resultatene deres, og hvordan de skal ta ansvar for det endelige systemet.

Den mest varige utvikleren de neste fem årene vil ikke være personen som kan produsere mest kode for hånd eller generere den lengste prompten. Det vil være personen som kan forvandle et uklart mål til en pålitelig prosess, veilede flere verktøy mot dette målet, oppdage feil tidlig, og forklare hvorfor den resulterende programvaren fortjener å bli stolt på.