Og hvad det har med rigtig god udvikling at gøre
Sekvens • Marts 2026
Når vi fortæller samarbejdspartnere, at vi bruger Claude som vores primære AI-værktøj til Business Central-udvikling, får vi ofte det samme spørgsmål: “Hvorfor ikke bare bruge Copilot eller ChatGPT?”
Det er et fair spørgsmål. Både GitHub Copilot og ChatGPT er fremragende værktøjer. Vi bruger dem også, men bare kun til de ting, de er bedst til. Når det handler om at bygge og vedligeholde AL-kode til Business Central, har vi valgt Anthropics Claude som vores foretrukne samarbejdspartner og tool.
Grunden handler ikke om tekniske benchmarks eller marketingmateriale fra den strøm af AI-posts som kommer ind i disse tider. Den handler om noget, vi kender fra vores eget fag: Forskellen på en dygtig udvikler og en topklasseudvikler.
Topklasseudvikleren stiller spørgsmål
Jeg har i årenes løb arbejdet med mange udviklere og haft fornøjelsen af at både lære en masse af andre samt at uddanne en masse dygtigere udviklere. Fællesnævneren for dygtige udviklere er i grove træk, at de kan løse de fleste opgaver – når bare de får en klar specifikation. Udviklere læser opgaveformuleringen grundigt, kender syntaksen, forstår mønstrene og leverer fungerende kode.
Men topklasseudviklere gør noget andet, før de begynder at kode. De stiller spørgsmål.
“Hvad sker der, når en bruger ændrer lokationskoden midt i en ordre?”
“Skal denne validering også køre ved import via API?”
“Hvordan håndterer vi, at kunden har tre varianter af den samme vare med forskellige BOM’er?”
De gode spørgsmål afslører lige præcis de edge cases og forretningsregler, som afgør, om en løsning holder i produktion eller bryder sammen to uger efter go-live. Det er ikke et spørgsmål om evner. Det er et spørgsmål om tilgang.
Og det er præcis dér, forskellen på AI-værktøjer viser sig.
Copilot: Den hurtige kollega
GitHub Copilot er god til én ting: At skrive kode hurtigt. Når du sidder i Visual Studio Code og skriver en AL-funktion, kan Copilot foreslå de næste linjer, inden du selv når at tænke dem. Det er som at have en hurtig kollega, der kigger over skulderen og siger: “Du vil nok skrive det her næste gang.”
Men Copilot spørger aldrig: “Er du sikker på, at det er den rigtige tilgang du har valgt?”
Copilot arbejder linje-for-linje. Det ser konteksten i den fil, du har åben, og så foreslår den den mest sandsynlige fortsættelse. Det er imponerende. Og til boilerplate-kode, mønstre som gentager sig og standard-AL-strukturer er det en stor tidsbesparelse.
Problemet opstår, når opgaven kræver forståelse for helheden. Copilot ved ikke, at din kunde har en speciel lageropsætning. Den ved ikke, at den tabel, du skriver til, har en trigger, der kalder en codeunit, som opdaterer en tredje tabel. Så det, der sker, er at den foreslår kode, der ser rigtig ud – men som ikke tager højde for den verden, koden skal leve i.
ChatGPT: Den vidende rådgiver
ChatGPT er en enorm videnbase. Du kan stille den et spørgsmål om næsten hvad som helst og få et velformuleret svar. Til research, forklaring af koncepter og hurtige svar på “hvordan virker X i BC?” er det et stærkt værktøj. Men ChatGPT har en tendens, der minder om den dygtige-men-ikke-topklasse udvikler: Den svarer med det samme. Du stiller et spørgsmål, og nærmest inden du er færdig, får du et svar. Hurtigt, selvsikkert, velartikuleret. (Nogle gange så velartikuleret at du kan blive overbevist om at den har ret, selvom den ikke har)
Og det kan jo lyde som en fordel. Men i virkeligheden er det ofte det modsatte. Når nogen spørger “Hvordan laver jeg en funktion, der opdaterer vareprisen?”, er det rigtige svar sjældent bare koden. Det rigtige svar starter med: “Hvilken pris? Kostpris, salgspris, eller enhedspris? Og skal det trigge en revaluering af lageret?”
Hvis du springer dette trin over. Så giver det dig en funktion, der virker for et scenarie, den selv har antaget.
Claude: Den der stopper op og spørger
Og så er der Claude.
Når vi giver Claude en AL-udviklingsopgave, oplever vi noget, der minder om at arbejde med en erfaren BC-udvikler. Før der bliver skrevet en eneste linje kode, kommer spørgsmålene:
“Du nævner, at prisen skal opdateres – er det Unit Cost, Unit Price eller Last Direct Cost, du refererer til?”
“Skal denne logik køre som en subscriber på OnAfterValidate, eller er det en batch-proces der kører scheduleret?”
“Jeg kan se, at du arbejder med en tabel, der har relations til både Production BOM og Routing. Skal ændringen propagere til eksisterende produktionsordrer, eller kun påvirke fremtidige?”
Det er præcis de spørgsmål, en god udvikler ville stille. Ikke fordi Claude er programmeret til at stille spørgsmål for spørgsmålenes skyld. Men fordi Claudes arkitektur prioriterer at forstå opgaven, før den løser den.
I praksis betyder det, at vi sjældent ender med den klassiske kode, som virker i teorien, men ikke i virkeligheden. Vi ender oftere med kode, der er skrevet til den faktiske kontekst for kunden. Bevares. Vi laver også fejl, men vi kan mindske antallet af fejl og vi kan være mere sikre på, at kunden får det, han eller hun ønsker.
Hvad det betyder i praksis
Lad os tage et konkret eksempel.
En kunde beder os om at bygge en automatisk prisberegning på salgslinjer baseret på kundens aftalepriser, med rabatstrukturer der afhænger af ordrestørrelse.
Med Copilot får vi hurtig kodegenerering af de individuelle funktioner. Men vi skal selv holde styr på, hvordan de hænger sammen med kundens eksisterende prisopsætning, kampagnepriser og valutahåndtering.
Med ChatGPT får vi et velstruktureret svar med kodeeksempler. Men det antager typisk en standard-opsætning og vil ofte overse, at kunden måske bruger en TRIMIT extension med egne prisberegningsflows.
Med Claude bliver vi først spurgt: Bruger kunden standardprisgrupper eller en brancheløsning? Er der valutaer involveret? Skal beregningen respektere eksisterende kampagnepriser, eller overskrive dem? Og først når de spørgsmål er besvaret, kommer koden som tilpasset præcis den virkelighed, den skal fungere i.
Det handler om færre fejl, ikke hurtigere kode
Vi hører ofte, at AI handler om at skrive kode hurtigere. Og ja, hastighed er rart. Men i ERP-verdenen er hastighed sjældent flaskehalsen.
Flaskehalsen i vores branche er misforståelser eller edge-cases som ikke er dækket ind af koden. Det er ofte den funktion eller procedure, der virkede perfekt i udviklerens test, men som brød ned, fordi ingen spurgte, om kunden også bruger intercompany-transaktioner. Det er den rapport, der mangler et filter, fordi ingen tænkte på, at kunden har tre juridiske enheder i samme database.
Hver misforståelse koster tid. Ikke bare udviklertid, men lige så meget konsulenternes tid til at finde fejlen, kundens tid til at indrapportere den, og projektlederens tid til at planlægge tid til at lave fejlen osv.
Claude reducerer de misforståelser. Det bliver aldrig til nul fejl, men det bliver altså markant bedre. Vi mener at den største årsag er, at Claude, ligesom en topklasses udvikler, stopper op og siger: “Vent. Lad mig lige forstå det her ordentligt, før vi går i gang.”
Et AI-værktøj, der passer til ERP-verdenen
Business Central er ikke et greenfield-projekt hvor Claude Code ellers er voldsomt dygtig og voldsomt hurtig til at spytte mange linjer kode ud. BC er et kæmpe økosystem af tabeller, relationer, events, triggers og forretningslogik, der er vokset over 40 år. At skrive god AL-kode kræver ikke bare at kende syntaksen i koden. Det kræver at forstå konteksten og nogle gange endda også at forstå kundens forretning.
Copilot er en hurtig skriver. ChatGPT er en vidende encyklopædi. Claude er den kollega, der sætter sig ned med dig, stiller de ubehageligt præcise spørgsmål og først derefter hjælper dig med at bygge løsningen.
Needless to say: Vi har valgt Claudes tilgang. Fordi vi ved, fra årtiers erfaring med BC-projekter, at de bedste løsninger aldrig starter med kode. De starter med et hold der står ved en tavle og stiller de rigtige spørgsmål.
Hos Sekvens bruger vi AI til at levere bedre Business Central-løsninger. Ikke bare hurtigere udvikling.
