AI bruges i programmeringsarbejdet til alt fra små hjælpefunktioner til ændringer i eksisterende systemer. Modellen foreslår kode, men kender ikke automatisk de aftaler, som resten af løsningen bygger på. Et forslag kan derfor se rigtigt ud og alligevel passe dårligt ind. Forskellen viser sig i fejltilfældene eller i den omkringliggende kode, som stadig kalder funktionen med de gamle forventninger.

Den første opgave med AI og programmering skal være afgrænset

En funktion, der omformer et internt dataformat, er en mere overskuelig begyndelse end en omskrivning af et helt modul. Her kan du beskrive input og forventet output præcist og holde ændringen adskilt fra resten af systemet. Digitaliseringsstyrelsen anbefaler at begynde med små AI-projekter med lav risiko, eksempelvis uden personoplysninger. I programmering kan du med den tilgang afprøve modellens forslag uden samtidig at ændre centrale adgangsregler. Kodeforslag påvirker både kvaliteten og ansvarsfordelingen i et udviklingsteam, og de spørgsmål kan også indgå i et godt foredrag om AI.

Vælg en opgave, hvor du allerede kan forklare, hvordan et korrekt resultat ser ud. Det kan være en funktion, der læser en fil med opdigtede varenavne og afviser rækker med manglende felter. Så kan du kontrollere både det normale forløb og den konkrete fejlbesked. Er forretningsreglen uklar, må nogen først afklare, hvilke rækker funktionen skal acceptere.

Et hurtigt kodeudkast kan kræve lang gennemgang, hvis modellen indfører et nyt bibliotek eller ændrer programmets struktur. Den tid hører med i vurderingen af værktøjet. Notér tiden til kontrol og rettelser sammen med tiden til selve udkastet, og sammenlign med en tilsvarende opgave løst uden AI.

Sådan beskriver du programmeringsopgaven for AI

Modellen arbejder ud fra den sammenhæng, du giver den. En besked som »ret fejlen« efterlader mange åbne valg, selv når du indsætter en fejlmeddelelse. Beskriv derfor, hvad programmet skulle gøre, og hvad det faktisk gjorde, sammen med de tekniske begrænsninger for løsningen. Funktionen skal for eksempel bevare sin nuværende returtype, eller projektet må ikke få nye afhængigheder.

En præcis opgavebeskrivelse skelner mellem krav og antagelser. Hvis en tom tekst skal behandles anderledes end en manglende værdi, skal forskellen stå udtrykkeligt. Ellers udvisker modellen den med en bekvem standardværdi. Det skjuler fejl længere inde i programmet, for eksempel når en tom adresse bliver opfattet som en bevidst sletning.

Når opgaven berører flere funktioner, afslører et kort løsningsforslag før selve kodeændringen misforståelser tidligt. Bed modellen arbejde ud fra relevante kodeuddrag og de steder, hvor funktionerne bliver kaldt. Hele kodebasen giver ikke nødvendigvis brugbar sammenhæng. Uvedkommende eksempler trækker forslaget væk fra projektets eksisterende mønstre og fører til ændringer i filer, som opgaven ikke berører.

Hvordan kontrollerer du koden fra AI?

Generativ AI kan levere faktuelt forkerte eller opdigtede svar. I kode viser det sig som et kald til en funktion, der ikke findes, eller som en overbevisende forklaring bygget på en forkert antagelse. At forslaget kan kompileres, siger kun noget om en del af kvaliteten. Programmet kan stadig acceptere ugyldige værdier eller håndtere en afbrudt forbindelse forkert.

Læs ændringen som kode fra en kollega, og følg dataene gennem funktionen, især dér, hvor input skifter form, eller koden fanger en fejl. En bred fejlhåndtering kan få en test til at passere ved at returnere en tom samling, selv om den underliggende forespørgsel aldrig lykkedes. Dermed får den kode, der kalder funktionen, samme svar ved »ingen resultater« og »systemet kunne ikke svare«.

Skriv de forventede resultater for centrale testtilfælde, før du lader modellen foreslå testkode. Ellers gentager testen den samme misforståelse som implementeringen. Et tilfælde, der skal afvises, viser, om valideringen virker. Fjerner du bevidst den relevante validering, skal testen fejle. Passerer den stadig, kan fejlen også slippe igennem ved en senere ændring. Hvis du lærer at programmere med AI, kan du på en efterskole med programmering øve dig i at skrive test, der afslører fejl i modellens forslag.

Oplysninger du må give et AI-værktøj

Et fejlspor indeholder ofte langt mere end tekniske detaljer. En loglinje kan rumme en mailadresse, og et eksempel fra databasen kan afsløre oplysninger om en konkret medarbejder. Personoplysninger bør kun indtastes i et generativt AI-værktøj, når virksomheden har vurderet og godkendt værktøjet til den behandling. Adgang til værktøjet er ikke i sig selv en godkendelse til at indsætte for eksempel medarbejderoplysninger fra en database.

Erstat virkelige data med konstruerede eksempler, som bevarer den struktur, fejlen afhænger af. Handler problemet om et særligt tegn i et navnefelt, behøver modellen ikke personens rigtige navn. Resten af materialet kan dog stadig indeholde oplysninger, der afslører personen, for eksempel kombinationen af et arbejdssted og en konkret hændelse.

Fortrolig kildekode kræver også en risikovurdering, før du sender den til et værktøj. Du skal gentage vurderingen, når anvendelsen eller rammerne ændrer sig. Undersøg derfor, hvilke filer en kodeassistent faktisk kan læse, særligt når den får adgang til projektmapper. Konfigurationsfiler kan indeholde adgangsnøgler, selv om du kun har åbnet en harmløs hjælpefunktion i editoren for at rette en formateringsfejl.

Små kodeændringer giver en mere præcis gennemgang

Et AI-forslag blander let en nødvendig fejlrettelse med omfattende oprydning. Modellen omdøber måske variable og flytter funktioner, mens den ændrer betingelsen, der udløste fejlen. Resultatet ser pænt ud, men ændringsvisningen bliver vanskeligere at læse. Den relevante adfærdsændring drukner mellem linjer, som blot har fået en anden formatering eller placering.

Bed om den mindste ændring, der opfylder det aftalte krav, og hold oprydning i en separat ændring. Så kan du i gennemgangen koncentrere dig om, om koden retter den beskrevne fejl uden at ændre anden adfærd. Et nyt bibliotek kræver også en vurdering af, om den eksisterende kode allerede dækker behovet. Afhængigheden skal med i installationen og håndteres ved senere opdateringer.

Databaseændringer og kald til eksterne tjenester kræver særlig opmærksomhed. En funktion kan virke ved første forsøg, men skabe dubletter, når et afbrudt kald gentages. Beskriv, hvad der skal ske ved gentagelse, og hvordan programmet skal håndtere en delvist gennemført handling. Et kort eksempel med et vellykket kald viser ikke, hvad der sker, hvis forbindelsen afbrydes, efter at databasen har gemt ændringen. Det kræver særskilte testforløb med afbrydelser.

Bevar forståelsen efter koden er godkendt

AI ændrer ikke behovet for at kunne forklare den kode, du sætter i drift. Andre skal kunne vedligeholde ændringen uden at have deltaget i samtalen med modellen. Forklaringen skal derfor beskrive programmets faktiske adfærd. Ligger begrundelsen kun i en lang samtalehistorik, må næste udvikler lede dér efter svaret på, hvorfor en bestemt fejl skal sendes videre til brugeren.

Skriv beslutningen dér, hvor næste udvikler vil lede efter den, for eksempel i beskrivelsen af ændringen eller tæt på en overraskende betingelse. En kommentar skal forklare begrundelsen frem for at gentage koden med andre ord. Findes en kontrol, fordi et ældre system sender tomme felter, forklarer den oplysning, hvorfor kontrollen stadig står i koden.

Når du lærer et nyt område, kan du bede modellen forklare forslaget og derefter selv ændre et centralt vilkår, for eksempel ved at lade funktionen modtage flere poster ad gangen. Kan du forudsige, hvordan det påvirker resultatet og fejlhåndteringen? En uventet konsekvens peger på noget, du endnu mangler at forstå i koden. Lad en kollega gennemgå ændringen og testene med adgang til de oprindelige krav, så forventningerne til input og fejlbeskeder også indgår i gennemgangen.