GitHub Copilot workshop – task-app

Hands-on workshop om GitHub Copilot, GitHub Projects, issues, branches, pull requests, review, GitHub Actions og agent-workflows.

AI-genereret kode er først færdig, når den er forstået, testet, reviewet og koblet til et issue.

Formål

Efter workshoppen kan I gennemføre og forklare en sammenhængende udviklingsproces, hvor AI bruges til forståelse, planlægning og afgrænset implementering:

flowchart LR
    A[Krav] --> B[Issue]
    B --> C[Plan]
    C --> D[Branch]
    D --> E[Kode]
    E --> F[Test]
    F --> G[Pull request]
    G --> H[Review]
    H --> I[GitHub Actions]
    I --> J[Merge]
    J --> K[Dokumentation]

Loading

Fokus er ikke kun, om koden virker. I skal også kunne:

• spore koden tilbage til et krav
• forklare de vigtigste kodevalg uden Copilot
• dokumentere test og review
• vurdere og fravælge forslag fra AI

Case

I arbejder med en lille task-app med fire funktioner:

#	Funktion
1	Oprette en task
2	Se alle tasks
3	Markere en task som færdig
4	Se antal åbne tasks

Casen er lille, fordi fokus er arbejdsformen – ikke appens kompleksitet.

Sæt jer på tværs af fag

Tabellen er et første forslag til, hvordan workshopens emner kan fordeles mellem fagene ud fra læringsmålene. Fordelingen er ikke endelig, men skal drøftes og aftales i fællesskab.

Fagligt blik	Ser især på
Systemudvikling	Issues, user stories, acceptkriterier, board og sporbarhed
Programmering	Kode, struktur, test, debugging og forklaring
Teknologi	Git, build, GitHub Actions, runtime, sikkerhed og drift
IT- og forretning	Værdi, prioritering, scope og projektstyring

Før I starter

I skal have:

• en GitHub-konto
• Git installeret
• IntelliJ med Java 21
• GitHub Copilot aktiveret i IDE'en

.NET-sporet kan gennemføres i Rider eller Visual Studio med en installeret .NET SDK.

Workshopplan

Tid	Aktivitet
00:00–00:15	Intro, case og grupper
00:15–00:40	Del 1–2: Lokalt projekt og første commit
00:40–00:55	Del 3–4: GitHub-repo og workshoprepo
00:55–01:10	Del 5–6: Board, labels og issue #1
01:10–01:25	Del 7: Copilot Plan uden kode
01:25–02:00	Del 8–9: Branch og implementering
02:00–02:20	Del 10–11: Test, commit og pull request
02:20–02:40	Del 12–13: Review og GitHub Actions
02:40–02:55	Del 14–15: Sammenlign arbejdsformer
02:55–03:00	Del 16: Fælles opsamling

Hvis tiden er kort, gennemføres del 14–15 som demonstration eller hjemmeopgave.

Copilot-arbejdsformer

Arbejdsform	Bruges til	Menneskets ansvar
Ask	Forklare kode, fejl, Git og test	Kontrollere og kunne gengive forklaringen
Plan	Foreslå en implementeringsplan uden kode	Vurdere scope, rækkefølge og acceptkriterier
Agent	Løse en tydelig og afgrænset opgave	Gennemgå, teste og godkende alle ændringer

Important

Brug Ask til at forstå. Brug Plan før implementering. Brug først Agent, når opgaven er tydelig og afgrænset.

Faste kontrolpunkter

Efter de centrale dele skal gruppen kunne svare på:

1. Resultat: Hvad har vi lavet?
2. Sporbarhed: Hvor kan det ses i issue, branch, commit eller pull request?
3. Forklar uden Copilot: Hvad gør løsningen, og hvorfor er den lavet sådan?

Klassediagram – målet vi arbejder hen imod

Dette er ikke startkoden. Det er den Java-struktur, som bygges trin for trin.

classDiagram
    class Main {
        +main()
        +menu()
    }

    class TaskService {
        -Task[] tasks
        -int taskCount
        -int nextId
        +createTask(title) Task
        +getAllTasks() Task[]
        +markTaskAsCompleted(id) Task
        +countOpenTasks() int
    }

    class Task {
        +int id
        +String title
        +boolean completed
        +markAsCompleted() void
        +toString() String
    }

    Main "1" --> "1" TaskService : bruger
    TaskService "1" *-- "0..10" Task : gemmer

Loading

I .NET-sporet bruges navnet TaskItem i stedet for Task.

---

Hands-on del 1: Opret lokalt projekt

Formål: I opretter det samme enkle startprojekt, kan køre det lokalt og kan forklare, hvor programmet starter – før GitHub og Copilot inddrages.

Java i IntelliJ

1. Åbn IntelliJ → New Project → vælg Java og en installeret JDK 21.
2. Navngiv projektet copilot-workshop-java-taskapp.
3. Opret src/Main.java med denne startkode:

public class Main {
    public static void main(String[] args) {
        System.out.println("Task app starter");
        System.out.println("Start herfra og implementer issue #1: Opret task");
    }
}

4. Kør Main. Programmet skal skrive de to startlinjer.

.NET i Rider, Visual Studio eller terminal

mkdir copilot-workshop-dotnet-taskapp
cd copilot-workshop-dotnet-taskapp
dotnet new console -n TaskApp

Erstat indholdet i TaskApp/Program.cs med:

Console.WriteLine("Task app starter");
Console.WriteLine("Start herfra og implementer issue #1: Opret task");

Kør programmet:

dotnet run --project TaskApp/TaskApp.csproj

Copilot Ask

Forklar startkoden kort og linje for linje.

Hvor starter programmet, og hvordan kører jeg det lokalt?

Foreslå ikke ændringer, og skriv ikke ny kode.
Svar på dansk og på begynderniveau.

Tjek

• Projektet kan køres lokalt
• Programmet skriver de to startlinjer
• Gruppen kan forklare, hvor programmet starter

---

Hands-on del 2: Git og første commit

Formål: I opretter en lokal Git-historik og gemmer projektets starttilstand i det første commit.

git init
git add .
git commit -m "Initial Java task app"

Kommando	Hvad gør den?
git init	Opretter et lokalt Git-repository i projektmappen
git add .	Gør de aktuelle filer og ændringer klar til commit
git commit -m "..."	Gemmer et dokumenteret øjebliksbillede i den lokale Git-historik

Et commit sender ikke noget til GitHub. Alt er stadig kun gemt lokalt.

Samme handling i IntelliJ

1. Vælg VCS → Enable Version Control Integration → Git.
2. Åbn Commit.
3. Markér filerne, skriv Initial Java task app, og vælg Commit.

Vælg enten terminalen eller IDE'en, så den samme handling ikke udføres to gange.

Tjek

• Git er initialiseret
• Første commit er lavet
• Gruppen kan forklare forskellen på add og commit

---

Hands-on del 3: Opret GitHub-repo og push

Formål: I forbinder det lokale Git-repository med GitHub og sender historikken op, så arbejdet kan deles og kobles til issues, branches og pull requests.

1. Gå til GitHub → New repository → brug fx copilot-workshop-java-taskapp.
2. Opret repositoryet uden README, fordi projektet allerede findes lokalt.
3. Kopiér repositoryets URL, og kør:

git branch -M main
git remote add origin https://github.com/BRUGERNAVN/REPO-NAVN.git
git push -u origin main

Kommando	Hvad gør den?
git branch -M main	Omdøber den aktuelle branch til main
git remote add origin URL	Forbinder det lokale projekt med repositoryet på GitHub
git push -u origin main	Sender main til GitHub og husker forbindelsen til den eksterne branch

Samme handling i IntelliJ

Vælg Git → GitHub → Share Project on GitHub. IntelliJ kan både oprette repositoryet og pushe projektet.

Brug enten IDE-fremgangsmåden eller terminalkommandoerne.

Tjek

• Projektet er pushet til GitHub
• Repositoryet viser src/Main.java
• Gruppen kan forklare forskellen på det lokale repository og repositoryet på GitHub

---

Hands-on del 4: Find issues og workflows i workshoprepoet

Formål: I finder de fælles kravbeskrivelser og automatiseringer, som skal kopieres fra MIKCs workshoprepo til jeres eget repository.

Åbn MIKCs workshoprepo, og find:

docs/issues        ← beskrivelser af de opgaver, der oprettes som GitHub issues
.github/workflows  ← automatiske kontroller, der køres med GitHub Actions

Et issue er en sporbar arbejdsopgave på GitHub. Det kan blandt andet indeholde en user story, acceptkriterier, afgrænsning og definition of done.

Et workflow er en automatiseret proces beskrevet i en YAML-fil. Den angiver, hvornår en kontrol kører, hvilket miljø den kører i, og hvilke trin der udføres.

Filerne findes i MIKCs repository, men alle issues, branches, commits og pull requests oprettes i gruppens eget repository.

Tjek

• I kan finde docs/issues
• I kan finde .github/workflows
• I kan forklare forskellen på en issuebeskrivelse og en workflow-fil

---

Hands-on del 5: Project board og labels

Formål: I gør arbejdets status og faglige tilknytning synlig med et Project board og labels.

Opret Project board

GitHub Projects oprettes på jeres brugerprofil eller i en organisation:

1. Åbn profilen eller organisationen på GitHub → Projects → New project.
2. Vælg en Board-visning.
3. Navngiv projektet, fx Task app - gruppe 1.
4. Tilpas statusfeltet til:

Backlog  ·  Ready  ·  In progress  ·  Review  ·  Done

Boardet viser, hvor langt arbejdet er:

Status	Betydning
Backlog	Opgaven er registreret, men endnu ikke klar
Ready	Opgaven er afklaret og klar til at blive startet
In progress	Der arbejdes på opgaven
Review	Løsningen venter på faglig gennemgang
Done	Opgaven er godkendt og afsluttet

Opret labels

Labels er kategorier, der sættes på issues og pull requests. De viser, hvad arbejdet handler om, og gør det muligt at sortere og filtrere.

Boardets status viser, hvor langt arbejdet er. Labels viser, hvad arbejdet handler om.

Opret kun de labels, der bruges i workshoppen:

systemudvikling  programmering  teknologi  it-forretning
feature  test

Label	Bruges til
systemudvikling	User stories, acceptkriterier, proces og review
programmering	Kode, metoder, klasser, fejlretning og test
teknologi	Git, GitHub, branches, build og GitHub Actions
it-forretning	Værdi, prioritering, scope og brugerbehov
feature	Ny funktionalitet
test	Test eller kvalitetssikring

Tjek

• Boardet har de fem statusser
• De seks labels er oprettet
• Gruppen kan forklare forskellen på status og label

---

Hands-on del 6: Issue #1 – Opret task

Formål: I omsætter et behov til en sporbar arbejdsopgave med testbare acceptkriterier og en tydelig definition of done.

Et issue er ikke det samme som en use case:

• Et issue er en konkret arbejdsopgave, som kan følges fra krav til færdig kode.
• En use case beskriver normalt et samlet handlingsforløb mellem en aktør og et system.

I workshoppen indeholder issuet en user story, men det er ikke en fuld use case.

Issue-teksten hentes fra workshoprepoet: docs/issues/01-opret-task.md.

1. Åbn gruppens eget repository på GitHub → Issues → New issue.
2. Sæt titlen til Opret task.
3. Kopiér hele indholdet fra docs/issues/01-opret-task.md.
4. Tilføj labels: systemudvikling, programmering, feature og test.
5. Opret issuet.
6. Tilføj issuet til boardet via Projects, og sæt status til Ready.

Issuet oprettes på GitHub i denne workshop. Nogle IDE-værktøjer kan også oprette issues, men GitHub gør sammenhængen mellem issue, board, branch og pull request tydeligst.

Tjek

• Issuet har user story, acceptkriterier, afgrænsning og definition of done
• Issuet har relevante labels
• Issuet er på boardet med status Ready
• Gruppen kan forklare forskellen på et issue og en use case

---

Hands-on del 7: Copilot Plan – uden kode

Formål: I bruger Copilot Plan til at få et forslag til, hvordan issue #1 kan løses. Gruppen vurderer og retter planen, før der skrives eller ændres kode.

Important

En AI-genereret plan er et forslag – ikke en beslutning.

1. Åbn issue #1 på GitHub, og kopiér issue-teksten.
2. Åbn Copilot Chat i IDE'en, og vælg Plan.
3. Brug prompten:

Her er GitHub issue #1:

[indsæt issue-teksten]

Lav en kort implementeringsplan, men skriv ikke kode.

Planen skal:
1. foreslå de nødvendige filer eller klasser
2. beskrive relevante manuelle eller automatiske test
3. koble hvert trin til et eller flere acceptkriterier
4. pege på spørgsmål, der bør afklares før implementering

Følg issuets afgrænsning, og hold løsningen enkel.

Vurder planen

Gruppen skal undersøge:

1. Dækker planen alle acceptkriterier?
2. Foreslår den noget, der ligger uden for issuet?
3. Er rækkefølgen hensigtsmæssig?
4. Kan gruppen forklare og begrunde planen?

Ret planen, hvis det er nødvendigt. Indsæt derefter den godkendte plan som en kort kommentar i issue #1. Det gør det synligt, hvad gruppen besluttede før implementeringen.

Tryk ikke på Implement Plan, før planen er gennemgået og godkendt.

Tjek

• Planen indeholder ikke kode
• Planen dækker acceptkriterierne uden at udvide opgaven
• Den godkendte plan er dokumenteret i issuet
• Gruppen kan forklare, hvad den ændrede eller afviste

---

Hands-on del 8: Opret branch

Formål: I opretter en branch til issue #1, så ændringerne holdes adskilt fra main og senere kan spores fra issue til kode og pull request.

Flyt først issue #1 til In progress på boardet.

Anbefalet: Opret branchen fra issuet

1. Åbn issue #1 på GitHub.
2. Find Development i højre side, og vælg Create a branch.
3. Navngiv branchen feature/opret-task, og opret den fra main.
4. Hent og skift til branchen lokalt:

git fetch origin
git switch --track origin/feature/opret-task

Når branchen oprettes fra issuets Development-felt, registrerer GitHub forbindelsen mellem issue og branch.

Alternativ: Opret branchen i IDE eller terminal

git switch main
git pull
git switch -c feature/opret-task
git push -u origin feature/opret-task

Hvis branchen oprettes lokalt, sikres forbindelsen senere med Closes #1 i pull requesten.

Hvorfor er branchen vigtig?

• main bevarer den godkendte version.
• Ændringer til issue #1 samles ét sted.
• Pull requesten kan vise præcis, hvad branchen ændrer.
• Branch, commits og pull request kan spores tilbage til issuet.

Tjek

• Branch hedder feature/opret-task
• Branch findes lokalt og på GitHub
• Issue #1 står som In progress
• Gruppen kan forklare, hvordan branchen knyttes til issuet

---

Hands-on del 9: Implementer issue #1 med Agent

Formål: I bruger Agent til at implementere en tydeligt afgrænset opgave. Bagefter gennemgår, tester og forklarer I ændringerne, før de kan godkendes.

En agent er en AI-arbejdsform, der kan undersøge flere filer, ændre kode, foreslå eller køre kommandoer og arbejde videre ud fra resultaterne. Agenten kan udføre flere trin, men gruppen skal stadig kontrollere og godkende alle ændringer.

Agent i IDE og coding agent på GitHub

Agent i IDE	Coding agent på GitHub
Arbejder i det lokale projekt	Arbejder i et særskilt miljø på GitHub
Gruppen følger ændringer og kommandoer undervejs	Arbejder asynkront ud fra fx et issue
Velegnet til undervisning, dialog og kodeforklaring	Opretter normalt en branch og en pull request
Koden testes lokalt af gruppen	Resultatet vurderes i pull request og Actions

Det hedder en agent på GitHub, ikke en agent direkte i Git. I denne del bruges Agent i IDE'en, så gruppen kan følge arbejdet.

Tjek inden start

• Issue #1 står som In progress
• Den godkendte plan findes som kommentar i issuet
• Den aktive branch er feature/opret-task
• Projektet kan køre lokalt

Åbn Copilot Chat → Agent, og brug:

Implementer issue #1 i denne Java-konsolapplikation.

Her er issue #1:

[indsæt hele issue-teksten]

Følg den godkendte plan og klassediagrammets enkle struktur.
Gem højst 10 tasks i et array.
Ændr kun de nødvendige filer.
Brug ikke ArrayList, database, Spring Boot eller andre frameworks.

Efter implementeringen skal du:
1. opliste de ændrede filer
2. koble ændringerne til acceptkriterierne
3. foreslå manuelle test

.NET-prompt

Implementer issue #1 i denne C# .NET-konsolapplikation.

Her er issue #1:

[indsæt hele issue-teksten]

Følg den godkendte plan og den enkle struktur.
Brug klassenavnet TaskItem, og gem højst 10 tasks i et array.
Ændr kun de nødvendige filer.
Brug ikke List, database, ASP.NET eller andre frameworks.

Efter implementeringen skal du:
1. opliste de ændrede filer
2. koble ændringerne til acceptkriterierne
3. foreslå manuelle test

Forventede Java-filer efter implementering:

src/Main.java  ·  src/Task.java  ·  src/TaskService.java

Læs ændringerne, før de accepteres. Afvis kode, der ikke kan forklares, eller som ligger uden for issuet.

Tjek

• En task kan oprettes
• En tom titel afvises
• Alle tasks kan vises
• Agenten har kun ændret nødvendige filer
• Gruppen kan forklare, hvor data gemmes

---

Hands-on del 10: Kør og test

Formål: I dokumenterer, at løsningen er kørt, testet og forstået. AI-genereret kode godkendes ikke alene, fordi den ser rigtig ud.

Programmet kan køres enten i IDE'en eller fra terminalen. Vælg én af metoderne. De manuelle test og de forventede resultater er de samme.

Kør i IntelliJ

Åbn Main.java, og vælg Run Main. Indtast testdata i konsollen.

Kør i terminalen

javac -d out src/*.java
java -cp out Main

.NET

Kør i Rider eller Visual Studio, eller brug:

dotnet run --project TaskApp/TaskApp.csproj

Manuel test

Test	Forventet resultat
Opret task med titel	Tasken oprettes og vises
Opret task med tom titel	Programmet viser en fejlbesked
Vis alle tasks	Alle oprettede tasks vises
Opret flere tasks	Alle tasks får forskellige id'er
Opret over maksimalt antal	Programmet håndterer det uden crash

Copilot Ask

Sammenlign koden med acceptkriterierne fra issue #1.

Svar kort:
1. Hvilke acceptkriterier er opfyldt?
2. Hvad bør testes manuelt?
3. Hvilke dele af koden skal udvikleren kunne forklare?

Foreslå ikke ny funktionalitet.

Forklar uden Copilot

Gruppen skal kunne forklare:

• hvor tasks gemmes
• hvordan et id tildeles
• hvor en tom titel afvises
• hvad der sker, når arrayet er fyldt

Tjek

• Programmet er kørt
• Både gyldigt og ugyldigt input er testet
• Testresultaterne er noteret
• Gruppen kan forklare mindst én begrænsning i koden

---

Hands-on del 11: Commit, push og pull request

Formål: En pull request samler kodeændringer, issue-reference og testresultater ét sted. Den er gruppens dokumenterede forslag om at flette branchens ændringer ind i main og danner grundlaget for review.

Begreb	Betydning
Commit	Gemmer et dokumenteret øjebliksbillede i Git
Push	Sender commits til GitHub
Pull request	Foreslår at flette branchens ændringer ind i main
Review	Gennemgår og vurderer ændringerne før merge
Merge	Fletter de godkendte ændringer ind i main

Kontrollér, at den aktive branch er feature/opret-task, og at koden virker lokalt:

git add .
git commit -m "Add task creation feature"
git push

Opret pull request på GitHub

1. Vælg Pull requests → New pull request.
2. Vælg base: main ← compare: feature/opret-task.
3. Brug denne beskrivelse:

## Hvad er lavet?

Implementerer oprettelse af tasks i konsolappen.

## Acceptkriterier

- [ ] Brugeren kan indtaste en titel
- [ ] Brugeren kan gemme tasken
- [ ] Tasken vises på listen
- [ ] Tasken er som standard ikke færdig
- [ ] Tom titel afvises

## Test

Beskriv de udførte test og resultaterne.

## Brug af Copilot

- Copilot hjalp med:
- Vi ændrede eller afviste:
- Vi kontrollerede løsningen ved:

Closes #1

Closes #1 forbinder pull requesten med issue #1 og lukker issuet automatisk, når pull requesten merges.

Flyt issue #1 til Review på boardet.

Tjek

• Pull requesten går fra feature/opret-task til main
• Beskrivelsen indeholder acceptkriterier og testresultater
• Brugen af Copilot er dokumenteret
• Closes #1 står i beskrivelsen

---

Hands-on del 12: Review pull request

Formål: Review er den faglige kontrol før merge. En anden gennemgår ændringerne, sammenholder dem med issuets acceptkriterier og vurderer kode, test og forståelighed.

Lad en kollega eller en anden gruppe gennemføre reviewet:

1. Åbn pull requesten, og vælg Files changed.
2. Kontrollér, at ændringerne løser issue #1 og ikke indeholder uvedkommende kode.
3. Sammenlign ændringerne med hvert acceptkriterium.
4. Kontrollér de beskrevne test og resultater.
5. Bed gruppen forklare en central del af koden uden Copilot.
6. Skriv mindst én faglig review-kommentar.
7. Vælg Approve, eller vælg Request changes, hvis der skal rettes noget.
8. Vent med at merge, til GitHub Actions er gennemført i del 13.

Copilot som støtte til review

Review ændringerne som underviser i programmering.

Fokusér på:
1. om koden opfylder acceptkriterierne
2. om koden er forståelig for begyndere
3. om der mangler test
4. om der er unødvendig kompleksitet
5. hvilke dele udvikleren selv bør kunne forklare

Skriv forslag, men godkend ikke pull requesten.

Copilot kan pege på mulige problemer, men revieweren skal selv kontrollere og begrunde sin vurdering.

Tjek

• Files changed er gennemgået
• Acceptkriterier og test er vurderet
• Der er skrevet en review-kommentar
• Gruppen har forklaret en central del uden Copilot
• Pull requesten er ikke merget endnu

---

Hands-on del 13: GitHub Actions

Formål: GitHub Actions kører den samme automatiske kontrol ved push og pull request. I workshoppen kontrollerer workflowet, at projektet kan hentes, kompileres og starte i et neutralt miljø. Det erstatter ikke manuel test eller review.

En workflow-fil er en YAML-fil, der beskriver:

• hvornår kontrollen kører, fx ved push eller pull request
• hvor den kører, fx på Ubuntu
• hvad der udføres som jobs og steps, fx installation af Java, kompilering og test

Det nuværende Java-workflow er en build- og smoke-check. Det er ikke en egentlig implementeringstest af acceptkriterierne. En implementeringstest kræver fx JUnit-tests og et workflow-step, der kører dem.

Workflow-filen hentes fra MIKCs workshoprepo:

.github/workflows/java-check.yml

1. Kontrollér, at I stadig står på feature/opret-task.
2. Opret .github/workflows i eget repository.
3. Kopiér java-check.yml fra workshoprepoet.
4. Commit og push workflow-filen til den samme branch.
5. Åbn pull requesten eller fanen Actions, og se, om kontrollen er grøn eller rød.
6. Åbn loggen, hvis kontrollen fejler.

Når programmet har en interaktiv menu, skal workflowets smoke test levere et afslutningsvalg. Det sidste step skal derfor svare til:

- name: Kør smoke test
  run: printf '0\n' | java -cp out Main

.NET

Der findes endnu ikke en .NET-workflow-fil i workshoprepoet. Hvis .NET-sporet skal gennemføres hele vejen, skal .github/workflows/dotnet-check.yml tilføjes før workshoppen.

Prompt ved fejl

Denne GitHub Actions-check fejler.
Her er fejlbeskeden:

[indsæt fejlbeskeden]

Forklar:
1. hvilket step der fejler
2. den sandsynlige årsag
3. hvad vi bør kontrollere først

Skriv ikke ny kode endnu.

Afslut issue #1

Når reviewet er godkendt, og Actions er grøn:

1. Merge pull requesten til main.
2. Kontrollér, at issue #1 er lukket via Closes #1.
3. Flyt issue #1 til Done på boardet.
4. Opdatér det lokale projekt:

git switch main
git pull

Tjek

• Workflow-filen ligger i repositoryet
• Gruppen kan forklare trigger, job og steps
• Gruppen kan forklare forskellen på manuel test og workflowets kontrol
• Actions er grøn før merge
• Issue #1 er lukket og står som Done

---

Hands-on del 14: Issue #2 – Marker task som færdig

Formål: I gennemfører workflowet mere selvstændigt og implementerer denne gang uden Agent. Ask og Plan må bruges som støtte til forståelse og planlægning.

Issue-tekst: docs/issues/02-marker-task-som-faerdig.md.

issue → plan → branch → kode → test → pull request → review → Actions → merge

1. Opret issue Marker task som færdig med labels og status Ready.
2. Brug Plan uden kode, og dokumentér den godkendte plan i issuet.
3. Opret branch feature/marker-task-faerdig fra issuet.
4. Implementér selv. Brug Ask til forklaring og fejl – ikke Agent til implementering.
5. Kør og test både gyldigt id, forkert id og ugyldigt input.
6. Commit, push og opret en pull request med Closes #2.
7. Gennemfør review og kontrollér Actions før merge.

Tjek

• En task kan markeres som færdig
• Færdig status vises i listen
• Forkert id og ugyldigt input håndteres uden crash
• Pull requesten er reviewet, og Actions er grøn før merge
• Gruppen kan forklare implementeringen uden Copilot

---

Hands-on del 15: Issue #3 – Vis antal åbne tasks med Agent

Formål: I afprøver Agent på en lille og tydeligt afgrænset opgave. Bagefter vurderer I, om ændringerne følger issue #3, kun berører nødvendige filer, bevarer eksisterende funktionalitet og kan forklares, før de merges.

Issue-tekst: docs/issues/03-vis-antal-aabne-tasks.md.

1. Opret issue Vis antal åbne tasks med labels og status Ready.
2. Opret branch feature/vis-antal-aabne-tasks fra issuet.
3. Åbn Copilot Chat → Agent, og brug:

Her er issue #3:

[indsæt hele issue-teksten]

Implementer præcis den beskrevne løsning.
Brug issuet som kravgrundlag.
Ændr kun de nødvendige filer, og begrund eventuelle andre ændringer.

Efter implementeringen skal du forklare:
1. hvilke filer der er ændret
2. hvordan hvert acceptkriterium er opfyldt
3. hvordan løsningen og den eksisterende funktionalitet testes

4. Gennemgå alle ændringer.
5. Test den nye funktion og de eksisterende funktioner.
6. Opret pull request med Closes #3.
7. Gennemfør review og kontrollér Actions før merge.

Sammenlign med del 14

Diskutér:

• Hvad gik hurtigere med Agent?
• Hvilke ændringer krævede stadig menneskelig vurdering?
• Var koden lettere eller sværere at forklare?
• Hvilke kontroller var de samme med og uden Agent?

Tjek

• Antal åbne tasks vises korrekt
• Færdige tasks tælles ikke med
• 0 vises, hvis der ikke er åbne tasks
• Eksisterende funktionalitet virker stadig
• Agenten har kun ændret nødvendige filer
• Gruppen kan forklare løsningen uden Copilot

---

Hands-on del 16: Fælles opsamling

Formål: I kobler workshopens aktiviteter til faglige kompetencer og diskuterer, hvilken rolle AI bør have i en professionel udviklingsproces.

Fagligt blik	Eksempler fra workshoppen
Systemudvikling	User stories, acceptkriterier, board, plan og review af krav
Programmering	Klasser, metoder, fejlinput, test og kodeforklaring
Teknologi	Git, branches, push, Actions, build og teknisk kvalitet
IT- og forretning	Værdi, prioritering, scope og ansvar

Sporbarhedskæden

Issue # → godkendt plan → branch → commits → pull request med Closes # → review → Actions → merge

Gruppen skal kunne følge kæden begge veje: fra krav til kode og fra en kodeændring tilbage til det issue, der begrunder den.

Semesterprogression

Tabellen er et forslag til en semesterprogression fra forklaringsstøtte og kodeforståelse på 1. semester til afgrænsede agent-workflows og professionel kvalitetssikring på 3. semester. Progressionen er ikke endeligt fastlagt, men skal drøftes og tilpasses læringsmålene på tværs af fagene.

Semester	Foreslået fokus
1. semester	Ask, Plan, simple issues, acceptkriterier og kodeforståelse
2. semester	Branches, pull requests, test, review og små agentopgaver
3. semester	Agent-workflows, CI/CD, deployment, sikkerhed og professionel kvalitet

Fælles refleksion

1. Hvornår gav Copilot faglig værdi?
2. Hvornår var menneskelig kontrol vigtigst?
3. Hvilke krav til forklaring, test og dokumentation skal gælde for de studerende?

Afsluttende princip

AI er en del af udviklingsprocessen, men den faglige vurdering og ansvaret ligger stadig hos mennesket.

AI kan foreslå, forklare, planlægge og implementere. Mennesker skal forstå, teste, reviewe og tage ansvar.