For jeg bruger i stigende grad Github Copilot i VS Code, som assistent. Github Copilot er ikke det samme som Microsoft’s Copilot, men en tjeneste, som kan hjælpe med at planlægge, skrive, forbedre og teste kode. Det betyder, at jeg skriver mindre og mindre kode selv og i højere grad designer systemet på et mere overordnet niveau.

Github Copilot er gratis for studerende og undervisere, og man kan vælge mellem forskellige sprogmodeller (GPT, Claude, Gemini, Grok m.m.). Der er desuden p.t. fire roller (modes), som man kan give assistenten i Copilot, nemlig Ask (Q&A), Planner, Agent og Custom. Jeg har mest erfaring med Agent-mode, som er en assistent, der både kan besvare spørgsmål, hjælpe med planlægning, ændre i min kode-base og åbne en browser. Hvis man dertil aktiverer “Bypass approvals”, kan assistenten også bruge andre værktøjer bl.a. selv køre kommandoer i terminalen. Dét er selvfølgelig på bekostning af visse sikkerhedsrisici.

Min fremgangsmåden er p.t.:

1. Afklare krav til systemet og formulere kravspecifikation (både funktionelle og ikke-funktionelle krav).
2. Afklare tekniske specifikationer. Hvilke teknologier og arkitekturer skal anvendes?
3. Tilføje overordnede ønsker til brugergrænseflade (UI).
4. Afklare projektplan -Hvad skal implementeres først? Hvornår er projektet færdigt?
5. Sæt agenten i gang med at udvikle og teste systemet ifølge kravspecifikation og projektplan.
6. Når første prototype er færdig, skal assistenten tjekke om alle krav er opfyldt (fx om koden er ren og lever op til principper for god kode) og om alle tests er godkendte. Dér bruger jeg en fast prompt i filen “tjek_projekt.md”.
7. Først her tester jeg selv systemet, og overvejer om interface og funktionaliteter er som jeg forventer. Hvis ikke skriver jeg med assistenten om evt. ændringer.
8. Jeg synkroniserer til Github og får systemet ud på en statisk webside (fx github-pages) eller deployer via host (Heroku).

Måske skal jeg have flere trin fx til at designe brugergrænseflade og funktionaliteter fx use-case diagram, user stories, bruger-rejse, skitser.

For at afklare krav til systemet burger jeg en fast prompt i filen “grillme_krav.md”, med følgende indhold:

• Opret filen documentation/kravspecifikation.md, hvis den ikke findes.
• Der skal udvikles et nyt projekt. Udspørg mig grundigt om formål, brugere, krav, platform, performance, sikkerhed, integration og andre relevante aspekter.
• Stil mig et spørgsmål ad gangen og stil uddybende spørgsmål, hvis svarene ikke er klare.
• Opdater kravspecifikation.md løbende undervejs ud fra svarene på spørgsmålene.
• Noter alle relevante oplysninger i kravspecifikation.md.
• Når vi er færdige, skal du tjekke, at alle aspekter er dækket, og at projektet er klart beskrevet.

Derefter har jeg en lignende prompt i filerne “grillme_tek.md”, grillme_ui.md” og “grillme_projektplan.md”, til at formulere teknikspecifikation, udseende og projektplan. Hvis der skal bruges kald til en sprogmodel i projektet, er det beskrevet i “LLM.md”.

Agenten kan selv oprette mapper og filer, skrive koden, initialisere afhængigheder og hente biblioteker. Den kan selv skrive tests, køre dem og fortolke resultaterne -også tests hvor assistenten åbner en browser og tester funktionalitet af knapper, tekstfelter og lignende interaktive elementer. Den kan formentligt også pushe til Github, deploye og kalde sub-agenter, men det ved jeg endnu ikke, hvordan man gør.

Alt i alt er langt det meste af min kodning ændret til systemdesign. Hvordan bliver man god til systemdesign? Gennem erfaringer med selv at implementere systemer, erfaringer med at designe systemer, kan man læse sig til det eller kan man ligefrem overtage andres (fx AI’s) tilgang?

Det er ikke uden en vis faglig sorg, at kodning lige så stille forsvinder ud af mit liv. Følelsen af at være en troldmand, der egenhændigt kan skabe (næsten) hvad som helst digitalt, forsvinder. Nu kan jeg til gengæld få en ide og se den materialiseret inden for et par timer. Jeg er stadig en troldmand, men måske den lidt ældre af slagsen, som nøjes med at lægge planer og lade andre (AI) udføre dem. Vil der stadig komme nye troldmænd i Verden, når de ældre troldmænd forsvinder?

Der er flere grunde til at træne eleverne i samarbejde. Meget professionelt arbejde foregår i grupper eller teams, både blandt studerende på uni og blandt undervisere, forskere, softwareudviklere og sikkert mange andre steder. Outsourcing af vidensarbejde til chatbots og agenter kan desuden medføre, at samarbejdskompetencer bliver endnu mere efterspurgte i en nær fremtid.

Mine erfaringer fra mine børns folkeskole er, at træning i samarbejde ofte foregår ved, at eleverne selv danner grupper og fordeler opgaverne, så få motiverede/stærke elever påtager sig det faglige arbejde, mens mange elever mere eller mindre velvilligt ikke deltager i arbejdet. Dvs. ingen reel stilladsering af eller træning i samarbejde.

Det mønster ser jeg gå igen blandt eleverne i gymnasiet. Når jeg generaliserer, ser jeg mange elever, som er usikre og tilbageholdende, og de ved ikke, hvordan de skal komme på banen i en gruppe. Mange elever er ufokuserede, og deres hovedmål er at blive hurtigt færdige/undgå arbejde. Nogle elever er mere præstations-orienterede og vil typisk overtage det meste af arbejdet i en gruppe.

Få elever er interesserede i at få gruppen til at fungere. Der opstår en kultur blandt mange elever, hvor de opfatter gruppearbejde som “læreren er væk, vi kan gøre hvad vi vil” dvs. hyggetid, hvor de kan snakke privat, gå i kantinen og surfe rundt på nettet.

Så jeg har brugt lidt tid på at undersøge, hvad træning i godt samarbejde kan indebære*, og jeg sidder med en lille ad hoc arbejdsgruppe om emnet. Her er nogle pointer:

• Elever må selvfølgelig ikke vælge deres egen gruppe, det giver både alt for homogene grupper og enkelt-elever, som står uden gruppe.
• Gruppen bør være heterogen uden at være alt for blandet. At sætte en fagligt stærk elev til at trække en gruppe af fagligt svage elever går ikke -det træner ikke samarbejde.
• Der skal være tryghed til at udtrykke sig, og der bliver talt i en ordentlig tone til hinanden.
• Alle bliver hørt og bidrager til gruppens arbejde. De sikre/ekstroverte deltagere har et ansvar for at holde sig lidt tilbage, og de usikre/introverte har et ansvar for at komme mere frem. De bedste resultater opnås ved, at alle bidrager til gruppens arbejde.
• Der er ikke nogen i gruppen, som må overtage produktet og på den måde løse opgaven selv.
• Der er fokus på opgaven og ikke alt muligt andet.
• Opgaverne bør være åbne og give mulighed for diskussion. Lukkede opgaver kan nemmere løses individuelt.
• Gruppen arbejder hen imod et sted, hvor ideer kan udfordres, og der er en kritisk og undersøgende samtale om argumenter og vurderinger.

Jeg har tidligere eksperimenteret med en “social ansvarlig” i gruppearbejde blandt 3.g’ere, men det blev tydeligt, at det havde de svært ved, og rollen blev hurtigt ignoreret. Derfor tog jeg fat i 1.g’erne og har forsøgt at stilladsere arbejdet med roller mere. Jeg er kommet frem til følgende fire roller:

Referent: Skriver for gruppen (computeren eller papir). Det er ikke din pligt at løse opgaven alene, blot at deltage og skrive referat. Tal sammen i gruppen om opgaverne -lad være med at fordele dem mellem jer. Del dokumentet med hinanden, når arbejdet er slut.

Fokus-holder: Sørger for, at gruppen bliver på opgaven og ikke mister fokus. Tal sammen i gruppen om opgaverne -lad være med at fordele dem mellem jer.

Ordstyrer: Sørger for, at alle kommer til orde i gruppen, så alle taler cirka lige meget. Tal sammen i gruppen om opgaverne -lad være med at fordele dem mellem jer.

Spørge-Jørgen: Det er din rolle at stille spørgsmål til de andre mindst tre gange. Eksempler: ”Hvorfor det?”, ”Hvad betyder det?”, ”Hvordan vil du forklare det?”, ”Hvordan kan man se det fra en anden vinkel?”. Tal sammen i gruppen om opgaverne -lad være med at fordele dem mellem jer.

Jeg er ikke helt tilfreds med ordlyden. Fx. skal “Spørge-Jørgen” på sigt ikke bare være en der spørger, men være ansvarlig for at sætte gang i den faglige og kritiske diskussion. Rollen skal nok også have et nyt navn.

Målet er i første omgang, at eleverne bliver opmærksomme på, at rollerne findes i samarbejde. Opmærksomheden får de ved at påtage sig rollerne og gennem evaluering og meta-refleksioner. Derfor skal rollerne også skifte ofte. Derefter er målet, at eleverne bliver bedre eller ligefrem gode til at udfylde hver rolle. Endemålet er, at de alle påtager sig alle rollerne i gruppearbejde.

Nogle spørgsmål, som kan vække elevernes tanker kan være:

• Hvad er et godt gruppearbejde?
• Hvad er dårligt gruppearbejde?
• Hvilken rolle er den sværeste? Hvorfor?
• Hvilken rolle er den vigtigste? Hvorfor?
• Hvad lykkedes du med i rollen?
• Hvornår fungerede rollen ikke så godt?
• Hvad kunne du overveje at gøre anderledes i næste gruppearbejde?

Er rollerne udtømmende for et godt samarbejde? Nej, men de sætter nogle hjørnesten, som der kan arbejdes videre ud fra. Derefter kan vi fx arbejde med samtale-runder (evt. på tid), differentierede grupper efter niveau, individuel forberedelse i klassen/hjemme og andre tiltag, som kan støtte den svære “ordstyrer”-rolle.

* Agergaard m.fl. “Gruppearbejde”; Duch, Henriette (red.) “Gruppearbejde på ungdoms- og videregående uddannelser”, Frydenlund 2023; “Tea for Teachers”, Podcast episode “Make Team Project Work”. https://teambuildingprocess.com/making-team-projects-work/

Det er sprogmodeller i mange chatbots (GPT5.2, Gemini3), blevet meget bedre til. Eller også er jeg blevet bedre til at prompte? Som altid, vil en mere konkret og specifik prompt give et bedre og mere brugbart resultat.

Her nedenfor et forsøg på at generere syntetiske data for biogas-produktion i et produktions-anlæg. Der er 200 forsøg (10 første er vist) med forskellig biomasse, som giver forskelligt udbytte:

Proceduren kan være som følger:

1. Angiv formålet med datasættet, samt hvilke data, der skal være i sættet.
2. Angiv sammenhænge mellem data. Hvis sammenhængene fremgår af en kilde, som sprogmodellen selv kan tilgå, kan modellen forsøge at udlede sammenhængene.
3. Få sprogmodellen til at afbilde datasættet, så du kan få et overblik over om de forventede sammenhænge er tilstede, og om de er for kraftige eller svage (se billede herunder).
4. Få sprogmodellen til at lægge datasættet i en fil fx csv-fil, og angiv krav til kolonne- og decimal-adskillelse.
5. Hvis data skal bruges til en specifik matematisk undersøgelse (fx regression eller maskinlæring), så lad sprogmodellen teste denne. Opstil evt. krav til korrelation, nøjagtighed o.l.

Nedenfor afbildning af de 200 syntetiske data fra ovenfor. Kig særligt på nederste linje af plots, hvor produktionen gerne skulle følge pH og C/N. Plottet mellem C/N og protein viser, at desto mere protein, jo lavere bliver C/N forholdet (mere N). Lavere C/N forhold giver lavere pH (pga ammonium-dannelse). Der er også plots, som giver mindre mening fx mellem kulhydrat og protein.

Det kan blive elevernes opgave at forklare nogle af sammenhængene.

Det kan tage flere minutter, at få et respons fra sprogmodellen. Det er altid lidt random, hvad der kommer som output. Nogle gange kan plots ikke vises. Andre gange vises alle 200 linjer af data osv. Det kan kræve en del iterationer, hvis man ønsker helt bestemte udtryk eller nøjagtighed. Man kan også tilføje krav til spredning og intervaller for data, men dem kender man ikke altid præcist, så her er det måske bedre at lade modellen give et bud.

Man bør deklarere, at der er tale om syntetiske data. Om ikke andet for at undgå at tiltroen til videnskaben og viden generelt ikke forsvinder helt.

Da jeg ikke har fundet informationen, har jeg selv sat en liste sammen, opstillet efter videnskabelig troværdighed (de mest troværdige øverst).

Listen er selvfølgelig generaliseret fx kan der sagtens findes videnskabelige artikler, som indeholder tvivlsomme data eller fortolkninger, særligt i nye forskningsområder. Og eleverne skal vejledes til, at videnskabelige artikler som regel ligger langt over det niveau, som de forventes at forstå.

Jeg har for øvrigt brugt vibe-coding til at formatere tabellen til et nogenlunde pænt og brugervenligt udseende. Vibe-coding er kodning med en sprogmodel-assistent, hvor udvikleren udtrykker sine krav/ønsker som almindelig tekst i en prompt, og sprogmodellen omsætter dem til kode. Det tog alligevel en halv time med tilretninger, men væsentligt hurtigere end at skulle sætte mig ind i koden selv.

1. Introduktion omkring børns og maskiners læring, og hvad er en model og målet med den? Hvilke brugs-senarier kan der være for modeller? (sundhed, robotter, sprog, anbefalinger, beslutningsstøtte m.v.)
2. Træne egen simple model med analoge midler og hovedregning: “Er det frugt?“
3. Opsamle centrale pointer.
4. Træne en billed-klassifier i Techable Machine: “Er det frugt?”
5. Opsamling på pointer.
6. Skitsere vigtige trin i konstruktion af en sprogmodel og karakteristiske træk.
7. Lade eleverne arbejde med at undersøge en sprogmodel mht. de nævnte træk.

Jeg har forsøgt at designe en aktivitet, som honorerer punkt 2, og lever op til en række krav:

1. Introducerer nogle af de tekniske begreber og metoder, som indgår i sprogmodeller.
2. Er på et niveau, hvor alle kan være med.
3. Er så hands-on som muligt.
4. Ikke tager for lang tid at afvikle.

Dét er en ret svær balance at ramme. Blandt andet er en grundlæggende struktur i sprogmodeller de neurale netværk, som er i mange lag og dimensioner og træningen kræver mange gentagelser. Det bliver hurtigt omfattende, abstrakt og tidskrævende at designe og træne et neuralt netværk -det er derfor man bruger en computer. Alle beregninger i aktiviteten skal desuden kunne løses af elever i hovedet, for det reducerer risikoen for black box.

Den væsentligste egenskab ved modellerne, at de kan forudsige. Derfor har jeg designet aktiviteten, så eleverne skal hånd-træne en meget simpel perceptron-model (uden bias), som kan forudsige om et objekt er en frugt eller ej (target). Objekterne tilgås som spillekort med tre binære egenskaber (features): Er formen rund/oval? Er farven blå? Er objektet produceret i Danmark (se billede).

De tre features er valgt fordi: en frugt er ofte rund, en frugt er sjældent blå og frugt eller ej er uafhængig af hvor den er produceret.

Kortene indeholder en blanding af objekter, som er frugter fx æble, og ikke frugter fx Lego. Eleverne arbejder i par og tager et kort frem ad gangen. Alle følges ad i starten, men eleverne arbejder efterhånden selvstændigt (faded guidance): De gennemgår et trænings-flow, herunder beregner vægtet sum, bestemmer output og opdaterer vægte, hvis der er uoverensstemmelse mellem kort og modellens forudsigelse (se billede).

Sammen med kortene introduceres de første begreber: trænings-data, model, vægte, træning.

Når alle kortene er brugt, skal eleverne gentage proceduren med kortene igen og igen, indtil modellen kan forudsige rigtigt fem gange i træk.

Derefter udleveres nye kort med objekter, som eleverne skal teste modellen på. Der er både frugter, som modellen kan forudsige korrekt (fx en fersken eller rød legoklods), og objekter, som den forudsiger forkert på fx en banan eller en blå blomme.

Opsamlingen kan introducere lidt flere begreber (præcision og bias), samt nogle vigtige principper:

• Modeller kan forudsige noget (frugt eller ikke-frugt).
• Modeller lærer at forudsige, ved at vægtene bliver tilpasset gennem træning.
• Præcisionen af forudsigelserne er afhængig af træningsdata (antal og variation fx hvis vi kommer med en blå frugt (blomme), forudsiger modellen nok forkert).
• Præcisionen af forudsigelserne er afhængig af modellen (bl.a. hvilke og antal af features; kombination af modeller i et neuralt netværk).
• Der kan være tendenser (bias) i træningsdata, som gør forudsigelserne unuancerede (vi har kun trænet på en slags frugter). Bias kan mindskes ved at bruge mere varierede træningsdata.
• Forudsigelsen kan ændres fra enten/eller til en andel (fx via softmax-lignende funktion).

There will be a test.. skal eleverne have opsamlende quiz?

En alternativ tilgang kunne være at forbinde eleverne i et netværk, hvor hver elev er en knude i netværket. Hver elev har sin egen vægt, og data sendes gennem netværket.

Dét kan hurtigt udvikle sig til kaos: Hvem skal opdatere vægtene? Skal alle følges ad? Hvad sker der, hvis nogen regner forkert? Elever ved kun hvad der sker hos dem selv og ikke i hele netværket fx kommer de ikke til at forholde sig til forudsigelsen.

Jeg har eksperimenteret lidt med openAI’s agenter (GPT’er). Her kan jeg fodre en chat med specifikke tekster fx sider fra wikipedia, om det emne vi arbejder med, og med retningslinjer for bottens adfærd. Men man skal være logget ind på openAI for at tilgå agenterne, og det må jeg ikke bede eleverne om af gode GDPR-grunde.

Men nu har jeg lavet min egen applikation, som ikke kræver login fra brugeren. Ideen er, at bygge videre på ChatGPT. Når man køber adgang til ChatGPT, får man samtidig adgang til at skrive programmer, der kan kommunikere med ChatGPT (via et API). Så man kan skrive sit eget program, der kan sende input til en GPT-model og få svar retur.

Første version af systemet kan prøves her.

Det er et velkendt problem med ChatGPT, at systemer mister fokus, og glemmer dele, som ligger længere tilbage i chatten. Det er bl.a. en konsekvens af, at attention-mekanismen bruger sekvens-embeddings, så ord (tokens), der står senere i prompt (og kontekst), får større betydning for næste output-token.

Selvom man prompter ChatGPT med grundige instruktioner i, at systemet skal fokusere på læring og ikke må skrive elevernes opgaver, så glemmer den det hurtigt. Når man prompter for at blive quizzet, glemmer den reglerne efter nogle få spørgsmål.

Min løsning er, at jeg laver min egen side med en brugergrænseflade (herover), hvor brugeren kan skrive en prompt til ChatGPT. Før hver prompt sendes til ChatGPT (gpt-4o-mini), klistrer jeg en system-prompt sammen med brugerens prompt, uden at brugeren ser det fx:

“Rolle: Du er en biologi-lærer i dansk gymnasium stx gennem 15 år. Kontekst: Du skal være lærings-assistent for en elev. Du er interesseret i, at eleven lærer begreber, metoder og teorier i biologi. Du vil lave quizzer med eleven. Du er opmærksom på, at du ikke vil løse opgaver for eleven. Du vil ikke skrive elevens produkter. Du vil ikke skrive eksempler på svar eller afsnit fx til rapporter eller opgave-besvarelser. Du vil hjælpe med at forklare og formidle viden i biologi. Opgave: Hjælp elever med at lære biologi-faget. Du spørger ind til elevens læring, interesser og fremskridt. Format: korte svar. Tone: Venlig og tålmodig.”

Det er afgørende, at alle beskeder til og fra botten samles (fx i et array), og det hele sendes med til ChatGPT hver gang, for ellers mister systemet sammenhængen i samtalen.

En lidt mere generel pointe er, at jeg nu har en chatbot, som jeg kan customize og aligne, som jeg vil. Jeg kan manipulere med output og særligt med input.

Fx kan jeg lave en vejlednings-bot, der som input får de vejledningsspørgsmål, som vi som regel stiller til eleverne, den videnskabelige basismodel og måske læreplanen. Og så får den en instruktion om, at den skal optræde som vejleder og stille mange og bestemte spørgsmål. Alt det får eleven ikke at se, og hvis alt går vel, kan botten ikke bruges til andet end at vejlede.

Jeg kan lave en quiz-bot, som tager begreber og svar fra en liste, som ligger i en variabel. Dertil kan der være en liste over korrekt og ikke-korrekt besvarede begreber. På den måde støtter jeg systemets hukommelse. I modsætning til mange multiple-choice systemer, kan denne bot rette fritekst og kan forklare, når noget skal uddybes.

Nu mangler jeg bare at teste, om eleverne kan få chatbotten til at snyde.

Opdatering: ultimo november 2024

Nogle elever gider ikke bruge chatbotten, fordi den er tunet til ikke at besvare opgaver.

Mange elever kan ikke forstå, hvorfor de skal skrive med en chatbot, når den alligevel ikke kan give konkrete svar om kilder m.m.

Jeg har fået lavet en SRP-vejleder-chatbot. Jeg tænker på at prøve et chatrum til flere brugere, hvoraf chatbotten kun er een af stemmerne, for at øge samarbejdet mellem eleverne.

For programmering er et kreativt håndværk, som tager tid at lære. Heldigvis er det blevet meget nemmere at være kreativ med IT. For eleverne kan nærme sig programmering uden at skrive kode.

Efter chatbots er kommet frem, først og fremmest repræsenteret af ChatGPT, kan eleverne i stedet beskrive, hvad et program skal kunne, og prompte en chatbot til at skrive et bud på programkoden.

De nye chatbots (fx ChatGPT 4o) er så gode til at skrive kode, at elever (et stykke hen ad vejen) kan prompte en interaktiv digital model frem. Claude’s Sonnet-chatbot har endda et interface, hvor prompt, kode og kørsel af koden vises i samme skærmbillede. Der er dog også chatbots på markedet, som p.t. ikke magter opgaven fx skoleGPT.

Eleverne kan opbygge en digital model gennem en række prompts. Det kræver præcise prompts at få specifikke forhold frem i modellen, hvorfor eleverne arbejder med prompt engineering.

Den kode, som chatbotten leverer, kan være skrevet i HTML, flyttes til en tekst-editor og vises i en browser. Koden kan også flyttes til et online-udviklingsmiljø som Trinket eller Replit.

En generel fremgangsmåde og nogle opmærksomheds-punkter nedenfor. Ordet “Modellen” henviser her til den model, som eleverne prøver at skabe, og ikke til den model, som ligger i chatbotten.

1. Eleverne/læreren skal vælge en del af et simpelt system fra faget, som de vil modellere. I biologi/kemi kan det være en kemiske reaktion eller en enkel biologisk proces fx rovdyr-byttedyr, molekyler, hormoner, del af et stofkredsløb o.l.
2. Lav en skitse af modellen og beskriv indholdet med tekst/pile.
3. Eleverne skal overveje, hvilke dele af systemet de vil begynde med at modellere.
4. Det er en fordel at modellere systemer, som er velegnede til agent-baserede modeller, som bygger på en objekt-orienteret tilgang. Det er svært at animere og få elementer i modellen til at ligne konkrete dele af verden fx konkrete molekyler, organer eller cellulære strukturer.
5. Begynd med en standard prompt, som beskriver hvilket kodesprog modellen skal skrives i, og hvad modellen overordnet skal simulere. Skriv at modellen skal opbygges gennem en række prompts. Rolle, kontekst, opgave, format og sprog kan strukturere prompten.
6. Brug versionering, så det er nemmere at holde styr på forskellene på de modeller, som bliver outputtet. Begynd med version 1.0.0. Hvis en outputtet model bliver forkert, kan man let gå tilbage til en bestemt version, som var mere korrekt.
7. Bed chatbot’en placere tekster i modellen. Bliv ved med at prompte indtil placeringerne og teksterne står korrekt. Beskriv den form, som hvert sted skal repræsenteres af fx kasse eller cirkel, samt deres farver.
8. Bed chatbot’en tilføje nogle af de agenter, som skal bevæge sig mellem stederne. Præciser farve, form og bevægelseshastighed for agenterne.
9. Udvid med flere egenskaber til og/eller interaktion mellem agenterne.
10. Udvid med brugerens muligheder for at interagere med modellen fx gennem knapper, slidere og evt. tekstfelter.
11. Udvid med flere agenter.

Produkter fra chatbots må aldrig stå alene, så eleverne skal reflektere grundigt over på hvilke punkter modellen afspejler virkeligheden (det faglige indhold), og på hvilke punkter den ikke gør. De bør også reflektere over de generelle muligheder og begrænsninger ved modeller.

De kan reflektere over hvilket fagligt indhold, der var let/svært, at få frem i modellen og hvorfor. En af pointerne her, vil ofte være, at en chatbot skal promptes meget specifikt og med meget kontekst, for at opnå et bestemt udtryk. De vil muligvis også komme frem til, at for mange ændringer på samme tid, ikke giver de ønskede resultater. I stedet bør variabel-kontrol udøves, så modellen forbedres trinvist.

Aktiviteten rammer flere læringsmål:

1. Modellering (dekomposition) af indhold fra faget.
2. Arbejde med prompting af chatbots, uden at målet er en tekst, hvorfor fokus på hurtige veje til et produkt og på snyd bliver mindre.

Jeg er spændt på, om eleverne:

• Magter at dekomponere det faglige indhold til en simpel model og skitsere denne. Måske kræver det et større fagligt overblik end forventet at vælge et system, som er velegnede til denne form for modellering. I så fald, må jeg støtte dem med forslag fx et simpelt kredsløb mellem hjerte, væv og lunger.
• Vil simulere systemer, som er så komplekse, at en chatbot ikke kan skrive et program, der fungerer. For eleverne kan ikke opdage eller rette fejl i koden.
• Tager magten over chatbotten eller chatbotten tager magten over eleverne. Vil de blot acceptere (delvist forkerte) forslag, som chatbotten kommer op med? Det kan kræve en del prompt-forsøg og tålmodighed at få en model til at se ud på en bestemt måde. Og det er svært at få dynamiske systemer i balance.
• Formår at jonglere med chatbot, HTML-dokument og browser til fortolkning af HTML.

Eksempel: Her er et eksempel, som er lidt mere avanceret, end jeg forventer af eleverne. Det er kønshormonerne GnRH, LH, FSH og testosteron, som udviser feedback på hinanden. Systemet er endnu ikke helt balanceret, og viser derfor nogle ret store udsving i testosteron-indhold.

Nogle af de prompts, som er brugt til at skabe eksemplet ovenfor:

1. Standard prompt (ikke vist)
2. …en række af flere prompts..
3. Flyt kassen med Testikler lidt til venstre. Udvid den hvide ramme for kredsløbet lidt til venstre og til højre. Udskil GnRH fra Hypothalamus, også når der ikke klikkes på knappen.
4. Testosteron skal sørge for, at der udskilles mindre GnRH og FSH og LH.
5. Gør den hvide ramme lidt smallere igen på højre og venstre side.
6. Udskil færre FSH og LH på grund af GnRH.
7. Begynd simuleringen uden hormoner. GnRH skal medføre færre FSH og LH frigivet.
8. Tilføj en legend hvor det kan ses hvad de hhv. røde, grønne, gule og sorte prikker repræsenterer.
9. Kasserne med hhv. hypothalamus, hypofysen og testikler skal forblive på deres x og y koordinater, men prikkerne skal passer bagved kasserne.
10. Ændr knappen “release GnRH” til “indspøjt AAS”. Når der klikkes på knappen skal der tilføres et ekstra hormon “AAS”, som er blåt. AAS skal tilføres til venstre i kredsløbet. ASS skal opføre sig ligesom Testosteron. På legend skal der tilføjes en blåt prik og teksten “AAS (kunstigt testosteron)”.
11. AAS skal have samme hæmmende virkning på frigivelsen af GnRH, LH og FSH, som Testosteron har.

Arbejde videre med hukommelses-teknikker herunder flipkort.

Køre fag i en Agile ramme, dvs. afprøve og evaluere læringsaktiviteter og gentag aktiviteter, som ser ud til at virke.

Undersøge Generativ AI i undervisningen og formidling heraf.

I informatik vil jeg prøve par-programmering mhp. eksamensgrupper. Efter at have arbejdet med escape room gennem flere år, vil jeg arbejde med museumsformidling sammen med Naturama.

Underviseren havde planlagt kursus-forløbet som en projekt-udvikling efter formen:

Kursets indhold om planlægning af et projekt (gule ovenfor) omfatter den traditionelle sekventielle vandfaldsmodel over iterative modeller som kan kaldes Agile til at berøre extreme programming (XP). Arbejdet inden for Agile rammer blev mest præsenteret via retningslinjerne i scrum.

Scrum er en ramme for team-organisering (5-10 personer) med henblik på trinvis forbedring for jævnligt at give brugerne værdifuldt software mellem hænderne. Der er forskellige roller, artefakter og ceremonier i scrum, og en arbejdsperiode på 2-3 uger kaldes et sprint.

System-arkitektur (grønne ovenfor) delen handlede om hvordan den overordnede struktur i IT-systemer kan designes og kommunikeres. Et system kan bestå af én kode (monolit) eller af mange små selvstændige moduler (micro-services). Hvert modul kan være opbygget af typisk op til tre lag, som fungerer i en klient-server arkitektur.

Kvalitet af kode og test af programmer blev også introduceret. Kode rådner dvs. kvaliteten falder med tiden, når den refaktoriseres (omskrives) og udvides. Høj kvalitet af kode kan sikre færre fejl, at koden kan genbruges og at den kan læses og forstås (og derfor forbedres eller udvides) senere. Metoderne er bl.a. lav cyclomatisk complexitet (antal veje gennem koden) og unit tests, og inden for objekt-orienteret programmering er principper som dekobling, encapsulation (don’t show your privates), single-responsibility afgørende for høj kvalitet af kode.

Eksamensspørgsmålene omfattede:

Et godt kursus, som giver en god baggrundsviden for design af IT-systemer. På trods af, at kurset indeholdt en projektaflevering over et IT-system, kunne det have været sjovt at prøve nogle af programmerings-principperne af fx. nogle design patterns eller implementering af et system i trelags-arkitektur.

Jeg synes, at jeg har succes med at uddele kladdehæfter, og i højere grad lade eleverne tegne og skrive noter i hånden. Det startede i et forløb i en biologi c klasse og er udvidet til en bioA studieretningsklasse i en måneds tid. Det har krævet, at jeg selv øver mig i, hvad jeg vil skrive på tavlen, for eleverne kopierer det ned i deres hæfte. Husk at lave tid til, at eleverne selv kan skrive delkonklusioner, som samler op på en sekvens.

I informatik har jeg lært, at størrelsen af det system, som eleverne udvikler til eksamen, også indgår i vurderingen af deres præstation.

biologi C: Forløbet om sex og kønshormoner skal skæres til, så det kan gøres kort og præcist.

Tor har besluttet at rejse til Grønland

Året der kommer:

Året forsætter med at bruge artefakter til at styrke det neurale aftryk og dermed støtte hukommelsen. Få begreber. Flere tests.

HF: “Salt i havvand” frem for “Adskille salt og sand”. Adskille sand og salt er alt for kompliceret, mens at inddampe vand og veje det tilbageværende salt, vil fungere bedre. Jeg vil nok ikke gentage forsøget med at fremstille biogas, men måske satse mere på CO2-fang.

Videoafleveringer i HF frem for skriftlige afleveringer er værd at afprøve. Det vil kræve en del teknisk support.

Informatik: Jeg ved ikke, om jeg vil gentage forløbet om escape room, da det ikke siger eleverne ret meget. Måske skal de se rummet, som noget af det første, for at give dem noget inspiration. Dertil skal forløbet om kunstig intelligens gøres mere præcist.

Biologi A: Hvordan skal jeg inddrage chatbot i undervisningen? Jeg kan ikke ignorere det, men skal være tydelig i at vise eleverne, hvorfor det er vigtigt at udarbejde egne produkter. F.eks. i en aktivitet med chatbot assisteret forsøgsdesign eller chatbot genereret repons på deres opgaver.

Det bliver spændende at se hvordan eleverne tager imod moduler uden mobiltelefoner.