★ FEATUREDOtte uger til en hel sundhedsplatformByg jeres BI-dashboard fra bunden — hurtigere end at tæmme Power BISeletøjet, ikke agentenAidan — assistenten der voksede op herhelpdeskLæs →
Platform

AI'en byggede det på en eftermiddag. Tre uger senere ved ingen hvorfor.

Der er kommet et ord for det: vibe coding. Du beskriver hvad du vil have, AI'en skriver koden, og du læser den knap nok igennem. Det virker — og det virker forbløffende godt.

84 % af udviklere gør det nu. Kun 29 % stoler på resultatet.

Det tal er hele historien.

Hvorfor alle gør det

Fordi det leverer. Opgaver bliver løst 20-45 % hurtigere. Nye udviklere kommer igennem et projekt op mod 55 % hurtigere end ad den gamle vej. Fire ud af ti nye SaaS-produkter bliver i år bygget primært sådan her.

Vi gør det selv. Hver dag. Det her er ikke en artikel imod vibe coding.

Hvad der sker tre uger senere

Noget skal ændres. Ingen kan huske hvorfor det blev bygget sådan. Beslutningen lå i en samtale der er scrollet væk, og agenten der traf den, findes ikke længere.

Det er ikke en fornemmelse. Det er målt:

  • Teknisk gæld stiger 30-41 % efter et hold tager AI-værktøjer i brug — målt på 8,1 millioner kodeændringer.
  • 45 % af AI-skrevet kode indeholder en sårbarhed fra branchens egen top-10-liste. Testet på over 100 sprogmodeller.
  • Hemmelige nøgler slipper ud dobbelt så ofte som i kode skrevet i hånden.
  • 20-30 % af et holds tid går efter tre måneder til at rette fejl der stammer fra AI'en.

Og den værste detalje: gælden er usynlig. Koden består testene. Den kommer igennem review. Problemerne sidder i fejlhåndtering, i kanttilfælde og i sikkerhedsgrænser — steder der først giver lyd fra sig under rigtig belastning, med rigtige brugere.

Det er ikke AI'en. Det er fraværet af et seletøj.

En hest uden seletøj er ikke et dårligt dyr. Den er bare ikke spændt for noget.

Vibe coding fejler ikke fordi modellen er dårlig. Den fejler fordi der ikke er noget udenom: ingen plan der overlever samtalen, ingen beslutning der bliver husket, og ingen der siger nej før noget går live.

Det er dét vi har bygget.

Planen skrives før koden

Hver feature får et skrevet dokument før første linje kode: hvad den skal, hvad den udtrykkeligt ikke skal, og hvordan man kan se om den virker.

En agent der får en plan, bygger det der står i den. En agent der får en samtale, bygger sin egen fortolkning — og I opdager forskellen når den er kodet. Planen er også det eneste der stadig findes om tre måneder, når nogen spørger hvorfor.

Beslutninger bliver ikke genåbnet

Alle hold har valg der er truffet. Vi bruger ikke det framework. Betalinger rører vi ikke uden en direkte ordre. Kundedata forlader ikke EU.

At træffe dem er ikke problemet. At de bliver glemt er — og så foreslår den næste noget der allerede er sagt nej til, med en god begrundelse ingen kan huske.

Hos os ligger de ét sted og bliver leveret til hver agent når den starter. Sammen med det der forsvinder først: hvad blev valgt fra, og hvorfor. Det er dér den spildte tid ligger.

"Færdig" kræver bevis

En agent må ikke erklære sit eget arbejde færdigt.

Når en opgave meldes klar, åbner en rigtig browser siden og ser efter: står knappen der, virker den, ser skærmen rigtig ud på en telefon. Ikke "testene er grønne" — men et billede af at det virker.

Fejler den, ryger opgaven tilbage. Den nåede aldrig ud til jeres brugere.

Det er præcis dét de 45 % handler om: kode der består testene og alligevel bærer en sårbarhed. En prøve der kun spørger "svarede den?" kan ikke se det. En der kigger, kan.

Jeres agenter. Jeres maskiner.

Agenterne kører hvor I vil have dem: på jeres egne computere, eller i EU-skyen i Stockholm. Jeres kode forlader ikke jeres kontrol, og ingen tredjepart får et kig med.

For nogle er det en præference. For andre — sundhed, finans, det offentlige — afgør det om projektet overhovedet må starte.

Og I styrer det fra telefonen

I koder ikke fra mobilen. I dirigerer.

Start en agent hvor som helst, følg den mens den arbejder, send den en besked, se hvad den beslutter. Få et vib når den er færdig — eller når den har brug for et ja fra jer.

Bygget klokken to om natten. I nikker fra sengen.

Hvornår vibe coding er det rigtige — og hvornår det ikke er

Ærligt, og med tallene i hånden:

Brug det frit til en prototype, et internt værktøj, en idé der skal afprøves i denne uge. Hastigheden er ægte, og gælden når ikke at koste noget før du alligevel smider koden væk.

Brug det ikke uden seletøj til noget der skal leve: betalinger, kundedata, en platform I skal vedligeholde om to år. Her er de 30-41 % ikke en statistik — det er jeres kalender næste forår.

Bemærk også hvem der vinder mest: erfarne udviklere melder om 81 % højere produktivitet. Juniorer måler ingen forbedring overhovedet, fordi de mangler dømmekraften til at bedømme det AI'en afleverer. Et seletøj er dét der giver et helt hold den dømmekraft — ikke kun dem der havde den i forvejen.

500 timer — designet mens det blev brugt

Cardmem er ikke opstået tilfældigt. Det er designet, gennem omkring 500 timers arbejde side om side med de agenter det styrer.

Men det er designet ét bestemt sted: midt i rigtige kundeopgaver. Vi er buildere — vi bygger kommercielle, kundevendte platforme der skal holde, og vi bygger dem med præcis den motor vi sælger. Hver regel i seletøjet er tegnet mens en rigtig deadline løb, og prøvet af på arbejde nogen betalte for.

Det er forskellen på en metode og en teori. Reglen om at planen skrives før koden blev ikke fundet på ved et whiteboard — den blev tegnet, brugt, fundet utilstrækkelig, og strammet, fordi en agent havde bygget sin egen fortolkning af en samtale og vi opdagede det da det var kodet. Kravet om et rigtigt billede før noget må gå live kom af at testene var grønne mens siden var forkert. Kravet om at bevise at en kontrol overhovedet blev kørt kom af en kontrol der svarede det samme uanset hvad — og som vi troede på.

Vi tager vores egen medicin hver eneste dag. Går der noget galt hos os, bliver det til en spærre — og den spærre får I med. Det er derfor det virker i praksis og ikke kun på papiret.

Det er ikke en teori. Vi bygger selv sådan.

FD Sundhed er en hel sundhedsplatform — booking, betalinger, kundeportal, medarbejderadgang — plus native apps til både iPhone og Android.

Otte uger fra første linje kode til rigtige brugere. Ét menneske stod bag, og han skriver ikke selv kode: han dirigerer 15+ AI-agenter gennem den motor der er beskrevet ovenfor.

Skal vi vise jer det?

Vi sætter det op på jeres eget projekt, ikke på en demo. Så kan I se jeres egen kode gå gennem løkken, og selv bedømme om det er sådan I vil arbejde.

Otte uger til en hel sundhedsplatform.

Hej — jeg er Aidan