Fra "Dyrt Svineri" til "Game Changer": Vores Uventede Rejse med AI-Programmering

Lad os være ærlige: De fleste udviklere har et anstrengt forhold til AI-kodningsassistenter. Vi har set demoerne, læst succeshistorierne, og måske prøvet det selv – bare for at ende med ugers oprydningsarbejde i genereret kode, der så pæn ud, men faldt fra hinanden under pres.

Vi har været der. For et par år siden hoppede vi på tidlige AI-værktøjer og endte med flere måneders restaureringsarbejde. Koden så ren ud, bestod de første tests, og missede fuldstændig nuancerne i det, vi faktisk havde brug for. Det var en dyr læring i, hvorfor blind tillid til AI-output er en opskrift på katastrofe.

Så da vi vendte tilbage til AI-programmeringsværktøjer i år, gjorde vi det med behørig forsigtighed. Det, vi opdagede, overraskede os: Værktøjerne var modnet dramatisk, men vigtigere – hvordan du bruger dem, betyder lige så meget som hvilke værktøjer du vælger.

Det Egentlige Gennembrud: Start Småt, Tænk Stort

Vendepunktet kom fra en uventet kant. En ikke-ingeniør på holdet – vores marketingchef – satte en fungerende database-klient sammen på blot et par timer ved hjælp af en AI-assistent. Det virkede. Ikke perfekt, men godt nok til at være brugbart.

Det fangede vores opmærksomhed. Hvis AI kunne hjælpe en person uden for kerneudvikling med at levere fungerende kode hurtigt, hvad kunne det så gøre for den egentlige funktionsudvikling?

Vi begyndte at eksperimentere med at udvide eksisterende systemer. Vores REST API havde brug for nye muligheder til at håndtere batch-operationer. Den oprindelige implementering havde krævet betydelig ingeniørindsats. Den AI-assisterede udvidelse? To dage.

Dette var den afgørende indsigt: AI er exceptionel til at udvide og bygge videre på eksisterende kodebaser. Den forstår kontekst, navngivningskonventioner og arkitektoniske mønstre, når de allerede er etableret. Hvad den kæmper med, er at skabe komplekse systemer fra bunden uden det fundament.

Det Store Sats: En Decenniegammel Udfordring

Opmuntret af disse sejre besluttede vi os for at teste grænserne. Der var en funktion, vores brugere havde efterspurgt gentagne gange i årevis – en kapacitet, vi havde nedprioriteret, fordi kompleksiteten virkede uoverstigelig med traditionelle udviklingstilgange.

Vi taler om at tilføje sofistikerede forespørgselsmuligheder til en distribueret key-value store. Tænk på det som at bringe kompleks SQL-understøttelse til et system, der traditionelt er optimeret til simple, ultrasnelle operationer. Med konventionelle metoder vurderede vores estimater dette til mindst et to-års projekt.

Spørgsmålet var enkelt: Kunne AI-assisteret udvikling fundamentalt ændre den ligning?

Fem måneder senere havde vi vores svar. Vi leverede beta-understøttelse til funktioner, der havde ligget på vores TODO-liste i over et årti.

Den Udviklingsmodel, Der Faktisk Virker

Her er hvad vi lærte: AI erstatter ikke god ingeniørmæssig dømmekraft – den forstærker den. Gennem hele vores udviklingsproces opretholdt vi den disciplinerede tilgang, der altid har virket for komplekse systemer:

Start med en overordnet plan. Vide, hvor du er på vej hen, før du begynder at skrive kode – selv hvis den kode bliver skrevet af en AI.

Opdel det i detaljerede faser. Vores implementering gik gennem flere planlægningsiterationer, hver med 10-20+ distinkte faser. AI kan hjælpe dig med at eksekvere disse faser hurtigere, men kun hvis du har gjort tænkearbejdet på forhånd.

Test benhårdt. Her bliver AI-assistance virkelig transformativ. At generere omfattende testsuiter – inklusive de distribuerede systemtests, der normalt kræver enorm indsats – bliver gennemførligt. Vi kunne teste individuelle systemlag isoleret, før vi Tacklede integration, hvilket dramatisk accelererede vores vej til en fungerende implementering.

De Komplementære Styrker i Forskellige AI-Modeller

Ikke alle AI-assistenter er skabt lige, og vi lærte at udnytte deres distinkte styrker:

Model A (vi brugte Claude) var exceptionel til at opretholde kontekst over lange udviklingssessioner. Den holdt styr på, hvor vi var i den overordnede plan, hvad der resterede at gøre, og hvordan ny kode passede ind i den større arkitektur. Denne model var vores projektleder og navigator.

Model B (vi brugte Codex) viste sig bedre til at løse komplekse, fokuserede problemer. Når vi stødte på en særligt tricky bug eller havde brug for at implementere en tricky algoritme, fandt denne model ofte elegante løsninger hurtigere, end vi kunne.

Læringen? Bind dig ikke udelukkende til ét værktøj. Byg en arbejdsgang, der udnytter hver models styrker.

Async-udfordringen: Hvor AI Stadig Har Brug for Vejledning

Her er en nuancering, der overraskede os: AI-programmeringsværktøjer fungerer bemærkelsesværdigt godt med sekventiel, synchron kode – den slags mønstre, de har set mest i træningsdata.

Når du kaster asynkrone operationer ind i blandingen, bliver det interessant. Modellerne misser undertiden kontekst, der ville være indlysende for en erfaren udvikler. Men her er det smukke: Det er som regel ligetil at rette kursen gennem målrettede prompts og forklaringer.

Det omvendte gælder også. Den hastighed, hvormed AI kan generere fungerende kode – særligt for boilerplate og velkendte mønstre – overgår fuldstændigt, hvad et menneske kunne opnå manuelt. Det er som at have en utrættelig pair-programmer, der aldrig bliver træt af at skrive unit tests.

Hvad Dette Betyder for Dit Næste Projekt

Hvis du overvejer AI-assisteret udvikling, her er vores ærlige vurdering:

Det virker exceptionelt godt, når:

• Du har en eksisterende kodebase med etablerede mønstre
• Du udvider eller tilføjer til eksisterende funktionalitet
• Du kan generere omfattende testsuiter (noget vi altid har villet gøre, men aldrig haft båndbredde til)
• Du opretholder menneskeligt tilsyn og ikke er bange for at iterere på prompts

Det er mere risikabelt, når:

• Du bygger komplekse systemer fra bunden uden en referencearkitektur
• Domænet kræver dyb kontekstuel forståelse, som AI ikke har været eksponeret for
• Du forventer, at AI forstår implicitte krav uden eksplicit specifikation

Teknologien er modnet til det punkt, hvor seriøs ingeniørarbejde med AI-assistance er genuint muligt. Men det er stadig et værktøj, der kræver kyndige hænder at håndtere effektivt.

Vibe Coding-fordelen

Der er et begreb, der vinder indpas i udviklerkredse: "vibe coding." Det fanger noget virkeligt om, hvordan AI ændrer udviklingsoplevelsen. Når AI håndterer boilerplate og genererer første implementeringer, kan ingeniører bruge mere tid på de kreative, arkitektoniske beslutninger, der faktisk betyder noget.

Vores fem måneders rejse beviste, at dette ikke bare er hype. Vi leverede funktioner, der ville have taget år med traditionelle tilgange. Vigtigere endnu: Vi opretholdt kvalitet hele vejen – fordi den testinfrastruktur, vi byggede med AI-assistance, fangede problemer tidligt.

Fremtiden for kompleks systemudvikling handler ikke om at erstatte ingeniører med AI. Det handler om at give ingeniører superkræfter – og lære, hvornår man skal stole på værktøjerne, versus hvornår man skal anvende menneskelig dømmekraft.

Det er en vibe, vi kan bakke op om.