AI
Fra Copilots kodeforslag til AI i hele udviklingsarbejdet
Min vej fra Copilots inline-forslag til en arbejdsform med AI, tydelige krav, projektviden, tilsluttede værktøjer og kontrol af det færdige resultat.
Min brug af AI til udvikling begyndte med Copilots inline suggestions: kodeforslag, der dukkede op i editoren, mens jeg skrev. Jeg havde hænderne i koden og tog stilling til det næste forslag. Kunne jeg bruge det? Skulle det tilpasses? Eller skulle jeg bare skrive videre?
I dag fylder AI flere dele af mit udviklingsarbejde. Jeg bruger det til at beskrive opgaver, undersøge muligheder, holde styr på beslutninger og følge arbejdet frem til et resultat, der kan afprøves. Det stiller større krav til, hvordan jeg formulerer opgaven, og hvordan jeg vurderer det, der kommer tilbage.
Fra næste linje til en hel opgave
Med inline-forslag var udgangspunktet den kode, jeg var i gang med at skrive. Jeg bestemte retningen og vurderede hjælpen undervejs. Den arbejdsform har stadig et formål, når opgaven ligger lige foran mig i editoren.
En større opgave kræver mere sammenhæng. En agent kan eksempelvis undersøge et repository, finde relevante filer, ændre kode, køre tests og arbejde videre ud fra resultatet. De muligheder afhænger af de værktøjer og rettigheder, den har adgang til. GitHub beskriver den arbejdsform i sin dokumentation om Copilot-agenter.
Det flytter nogle af mine spørgsmål frem i processen. Hvad skal løsningen kunne? Hvilke begrænsninger gælder? Hvad må ændres? Og hvad skal være kontrolleret, før opgaven kan kaldes færdig?
Projektets viden skal kunne findes igen
Jeg vil kunne vende tilbage til et projekt og fortsætte på et ordentligt grundlag. Derfor skal krav, beslutninger og status gemmes sammen med projektet. En vigtig rettelse skal kunne findes, også når den oprindelige samtale er blevet lang.
På tranborg.eu ligger projektgrundlaget i repositoryet, og projektet har sit eget plugin. Det samler indgangen til krav, indhold, design og status. Jeg bruger også genbrugelige instruktioner, eller skills, til arbejdsgange, der går igen på tværs af opgaver.
For mig er værdien, at næste opgave kan begynde med de beslutninger, der allerede er taget. Når jeg har valgt en enkel løsning, skal senere forslag vurderes ud fra det valg. Når jeg retter en oplysning om mig selv, skal rettelsen følge med videre.
Værktøjer gør arbejdet konkret
En del af udviklingen er forbindelsen til de systemer, hvor arbejdet faktisk foregår. AI kan med de rette værktøjer læse projektfiler, undersøge en ændring i GitHub og kontrollere resultatet af en kørsel.
MCP, Model Context Protocol, er en standard, der kan forbinde AI-applikationer med eksterne værktøjer og datakilder. Det er én måde at give adgang til relevant information og handlinger på. Adgangen og de tilgængelige funktioner afhænger af den konkrete opsætning.
Det betyder, at jeg kan stille mere præcise krav til tilbagemeldingen: Hvilken ændring er gemt? Hvilke kontroller er kørt? Hvad viste de? Er den nye version faktisk udgivet?
Jeg skal samtidig tage stilling til, hvilke handlinger jeg har givet lov til. At undersøge noget, ændre kode og publicere et resultat er forskellige opgaver med forskellige konsekvenser.
En bestået kontrol er kun en del af resultatet
Arbejdet med denne hjemmeside er et konkret eksempel. Jeg bad om en personlig præsentation med SEO tænkt ind fra begyndelsen. Løsningen skulle være enkel at drive, og mit eksisterende DNS-setup skulle blive, hvor det var.
Jeg gav i dette projekt tilladelse til, at Codex kunne skrive koden. Derefter kunne jeg se siden, bruge den og give konkrete rettelser. På min skærm med en opløsning på 3440 × 1440 fyldte layoutet for meget. Min tilbagemelding var: smallere og centreret.
Senere havde undersiderne fået mere indhold, men fordelingen i kolonner og de store mellemrum fungerede dårligt for mig. Det krævede en ny vurdering af, hvordan teksten faktisk blev læst på skærmen.
Den slags feedback kan en bestået buildkontrol ikke levere alene. Koden kan være gyldig, links kan virke, og siden kan stadig være utilfredsstillende at bruge. Jeg skal se resultatet i den sammenhæng, det er lavet til.
Min opgave bliver også at prioritere
Den arbejdsform har en tydelig forbindelse til ledelse og koordinering: at beskrive målet, fordele opgaver, sætte grænser og følge op. Jeg skal kunne forklare, hvad der er vigtigst, og afgøre, hvornår en løsning er god nok til den konkrete opgave.
Jeg holder derfor fast i KISS. Flere værktøjer og mere automatisering skal have et formål. Min personlige hjemmeside behøver eksempelvis ikke en database for at præsentere tekst og links.
Min udvikling fra Copilot-forslag i editoren til den måde, jeg arbejder på nu, handler om at få flere dele af processen til at hænge sammen. AI kan bidrage undervejs, mens jeg fortsat skal forstå opgaven, vurdere resultatet og tage ansvar for de valg, der bliver truffet.
Det er den praksis, jeg vil bruge bloggen til at undersøge: konkrete opgaver, valg og opdagelser undervejs. Også de gange, hvor et lovende resultat kræver en omgang mere.
Videre læsning
Officiel dokumentation til de tekniske begreber, kontrolleret 10. november 2026: