Kan AI erstatte udviklere? Hvad ChatGPT, Lovable og Cursor kan og ikke kan

Kan AI erstatte udviklere? Til en prototype, et lille script eller et internt værktøj som kun du bruger, er svaret ofte ja. Til software der skal i drift med rigtige brugere, persondata og betalinger er svaret nej i 2026, fordi nogen stadig skal forstå koden, teste den og tage ansvar for den, når noget går galt.

Jeg er selv freelanceudvikler og bruger AI-værktøjer i mit daglige arbejde, så jeg har en interesse i svaret begge veje. Derfor får du også et ærligt bud på hvornår du ikke har brug for en som mig.

Den korte version: hvad kan AI erstatte?

Min tommelfingerregel: hvis en fejl kun koster dig selv lidt tid, kan AI alene være nok. Hvis en fejl kan ramme dine kunder, deres data eller dine penge, skal der være en med som kan læse koden.

AI er i øvrigt ikke en ny type udvikler. Det er et værktøj som alle typer bruger, fra frontend- til backendudviklere. Hvem der laver hvad, har jeg gennemgået i oversigten over typer af udviklere.

Hvad ChatGPT, Lovable og Cursor kan i praksis

De tre navne bliver ofte nævnt i samme sætning, men de er bygget til tre forskellige brugere. Det er den vigtigste forskel at forstå, før du vælger.

ChatGPT og andre chatassistenter

ChatGPT, Claude og Gemini er gode til at forklare. Du kan indsætte en fejlbesked, et stykke kode eller en kravspecifikation og få en forståelig forklaring tilbage. De kan også skrive små, afgrænsede stykker kode: en formel til et regneark, et script der flytter data mellem to filer, eller et første udkast til en e-mailskabelon.

Begrænsningen er at du selv er limen. Assistenten ser kun det du indsætter, og den ved ikke hvordan resten af dit system ser ud. Når ti svar skal samles til ét program, når svar nummer syv ikke passer med svar nummer to, og når det hele skal ligge på en server, er det dig der gør arbejdet.

Lovable og andre AI-appbyggere

Lovable, Bolt og v0 går et skridt videre. Du beskriver en app med almindelige sætninger, og værktøjet bygger en fungerende version med skærmbilleder, database og login, som du ofte kan klikke rundt i efter få minutter. Ifølge Lovables egen dokumentation kan koden synkroniseres til GitHub, så den ikke er låst inde i værktøjet.

For alle der vil teste en idé uden at kode, er det et stort skridt fremad. Problemet opstår når prototypen bliver til et produkt. Værktøjet bygger det du beder om, og du ved ikke nødvendigvis hvad du skulle have bedt om: adgangsregler i databasen, håndtering af fejl, og hvad der sker når to brugere retter det samme på én gang. Grænsen minder meget om den der gælder for no-code- og low-code-udviklere: hurtigt i starten, og dyrt hvis du bliver ved for længe.

Cursor og andre AI-kodeeditorer

Cursor, GitHub Copilot og Claude Code er bygget til udviklere. De ligger i den editor eller terminal udvikleren allerede arbejder i, kan læse hele kodebasen og foreslå eller selv lave ændringer på tværs af mange filer.

I hænderne på en der kan kode, sparer de tid på rutinearbejde: test, gentagelser, opdateringer og det første udkast til en ny funktion. I hænderne på en der ikke kan kode, er de mest en dyrere måde at bruge en chatassistent på, fordi du ikke kan vurdere de ændringer værktøjet foreslår. Cursor erstatter ikke udvikleren. Det gør en udvikler hurtigere til nogle opgaver.

Hvor grænsen går for produktionssoftware

Produktionssoftware er software som rigtige mennesker bruger, og som skal blive ved med at virke. Det er her forskellen mellem AI og en udvikler bliver tydelig. Ikke fordi AI skriver dårlig kode hver gang, men fordi koden kun er en del af opgaven.

Sikkerhed og persondata

AI-genereret kode ser ofte rigtig ud og virker, når du prøver den. Det er ikke det samme som at den er sikker. Veracode testede kode fra over 100 sprogmodeller i 2025, og 45 % af kodeeksemplerne indeholdt sårbarheder fra OWASP Top 10, den mest brugte liste over typiske sikkerhedshuller i webapps.

Det er ikke kun teori. En sikkerhedsforsker fandt i 2025 at omkring 170 apps bygget med Lovable havde databaser hvor uvedkommende kunne komme til brugernes data, fordi adgangsreglerne ikke var sat korrekt op. Appsene virkede fint for brugerne. Hullet var usynligt for den der ikke vidste hvor man skulle kigge.

Helheden over tid

Et program er ikke færdigt, når det virker første gang. Der kommer nye krav, nye versioner af de pakker koden bygger på, og fejl der først viser sig med mange brugere. AI-værktøjer arbejder i korte samtaler og husker ikke hvorfor en beslutning blev truffet for et halvt år siden. En udvikler der kender systemet, kan forklare hvorfor koden ser ud som den gør, og hvad en ændring vil ramme.

Drift og ansvar

Nogen skal holde øje med serveren, sørge for backup, lukke sikkerhedshuller og rykke ud når betalingerne holder op med at virke en fredag aften. Et AI-værktøj kan hjælpe med hvert enkelt trin, men det kan ikke indgå en aftale med dig, og det kan ikke stå til ansvar. Det kan en udvikler.

Afklaringen før koden

Den dyreste fejl er at bygge det forkerte. En erfaren udvikler spørger hvem der skal bruge det, hvad der sker hvis det fejler, og om et standardværktøj kan løse opgaven i stedet. AI bygger som regel det du beder om, og det er ikke altid det du har brug for.

Hvornår AI ikke er nok, og hvornår du ikke har brug for en udvikler

Begge dele har situationer hvor de er det forkerte valg. Det er mindst lige så nyttigt at kende.

AI alene passer ikke når

• appen skal håndtere login, persondata eller betalinger for rigtige kunder
• den skal tale sammen med andre systemer, fx et økonomisystem, et CRM eller en betalingsudbyder
• en fejl kan koste kunder, omdømme eller en sag hos Datatilsynet
• du har brug for at nogen kan svare, når den går ned
• du bruger mere tid på at prompte dig ud af fejl end på at bygge noget nyt.

En udvikler passer ikke når

Det skal jeg også være ærlig om, for jeg lever af at sælge udviklertimer.

• Du vil teste om en idé overhovedet holder. Byg en prototype med Lovable eller lignende, og vis den til fem potentielle kunder, før du bruger penge på kode.
• Du har brug for et internt værktøj til dig selv eller et lille team, uden følsomme data.
• Opgaven kan løses med et færdigt værktøj eller et regneark. Så er en udvikler ofte den dyreste vej til samme resultat.
• Budgettet rækker kun til få timer. Så får du mere ud af at bygge selv og få en udvikler til at gennemgå det bagefter.

Kan du genkende dig selv i den første liste, er det typisk tid til at hente hjælp. Det betyder ikke nødvendigvis at alt skal bygges om. Ofte kan en stor del af det AI har lavet, genbruges, når fundamentet bliver gennemgået og rettet.

Gør AI udviklere overflødige eller bare hurtigere?

AI er allerede blevet hverdag for mange udviklere. I Stack Overflows udviklerundersøgelse fra 2025 svarede 84 % at de bruger eller planlægger at bruge AI-værktøjer, og godt halvdelen af de professionelle bruger dem dagligt. Samme undersøgelse viser at 46 % ikke stoler på at svarene er korrekte. Den største frustration, som 66 % nævner, er løsninger der er næsten rigtige, men ikke helt.

Det er præcis den svaghed der gør AI risikabelt i hænderne på en der ikke kan se forskellen. Næsten rigtig kode er værre end kode der fejler med det samme, fordi fejlen først viser sig senere.

Hvor meget hurtigere udviklere bliver, er også mindre klart end man skulle tro. Forskningsorganisationen METR lod i 2025 erfarne open source-udviklere løse rigtige opgaver i deres egne projekter med og uden AI. De brugte 19 % længere tid med AI, men troede selv at de var blevet 20 % hurtigere. En opfølgning med nyere værktøjer i februar 2026 pegede i retning af at udviklerne blev hurtigere, men METR kalder selv resultatet meget svag evidens.

Min vurdering er at selve skrivningen af kode er blevet billigere, mens vurderingen af koden er blevet mere værd. Derfor udvisker AI heller ikke forskellen på en junior- og en seniorudvikler, snarere tværtimod. Hvordan professionelle udviklere bruger værktøjerne i praksis, og hvad det betyder for din pris, har jeg skrevet om i indlægget om AI i softwareudvikling.

Den bedste løsning er ofte AI og en udvikler sammen

Valget står sjældent mellem AI og en udvikler. For en mindre virksomhed ser den mest fornuftige model tit sådan ud:

1. Du tester idéen med AI. Byg en prototype i Lovable eller lignende, og vis den til rigtige brugere. Det koster typisk et abonnement og noget af din egen tid.
2. En udvikler gennemgår fundamentet. Før du lancerer, ser en udvikler på sikkerhed, datastruktur, adgangsregler og hosting og fortæller hvad der kan blive, og hvad der skal laves om.
3. Udvikleren bygger det kritiske. Betalinger, integrationer og det der skal kunne holde til vækst, bliver bygget eller rettet af en der kan stå inde for det, gerne med AI som værktøj.
4. Du fortsætter selv med det enkle. Tekster, små justeringer og nye skærmbilleder kan du ofte selv lave, så længe ændringerne bliver set igennem.

Er du i tvivl om hvilken slags udvikler trin 2 og 3 kræver, hjælper beslutningsguiden til hvilken udvikler du har brug for dig med at sortere efter projekttype.

Næste skridt: sådan vurderer du din egen situation

Har du allerede en app bygget med Lovable, Bolt eller Cursor, og skal den bruges af rigtige kunder, kan du se hvordan jeg arbejder med at gøre en AI-app klar til produktion. Er du stadig i idéfasen, så byg gerne videre selv, og kom tilbage når prototypen har fundet sine første brugere.

Ofte stillede spørgsmål

Bliver udviklere overflødige inden for få år?+

Det tror jeg ikke, men ingen ved det med sikkerhed. Efter min vurdering ændrer rollen sig: færre timer går med at skrive rutinekode, og flere går med afklaring, gennemgang af kode, sikkerhed og drift. Jeg forventer også at der bliver bygget mere software, når det bliver billigere at bygge. Nogen skal stadig forstå og stå inde for det der kører hos rigtige brugere.

Kan jeg bygge min app i Lovable og få en udvikler til at gøre den færdig?+

Ja, og det er en fornuftig måde at starte på. Synkronisér koden til GitHub tidligt, så en udvikler kan få adgang uden at gå gennem din Lovable-konto. Regn med at udvikleren først laver en gennemgang og derefter retter sikkerhed, datastruktur og fejlhåndtering. Nogle dele kan genbruges direkte, andre skal skrives om. Hvor meget afhænger af hvor langt prototypen er nået.

Må jeg indsætte kundedata i ChatGPT eller andre AI-værktøjer?+

Som udgangspunkt bør du lade være, medmindre du har styr på databehandlingen. Persondata om kunder og medarbejdere er omfattet af GDPR, og du skal vide hvor data ender, og om udbyderen bruger dem til træning. Erhvervsabonnementer har typisk andre vilkår end gratis versioner. Brug anonymiserede eksempler når du beder om hjælp, og få juridisk rådgivning hvis du er i tvivl.

Skal jeg vælge en udvikler der bruger AI?+

Ja, som regel. En udvikler der bruger AI med omtanke, kan løse rutineopgaver hurtigere, og det kan komme dig til gode i prisen. Spørg hvordan de bruger værktøjerne, hvordan de gennemgår den kode AI skriver, og om din kode eller dine data bliver sendt til eksterne AI-tjenester. Et godt svar er konkret. Et dårligt svar er at AI skriver det hele.