For to ugers arbejde, færdig på under en time

Vi forbandt for nylig en kundes ordrestyringssystem med kurertjenesten DPD, så de kunne sende fragtlabels og sporingskoder direkte til printeren, uden at nogen skulle taste dem ind manuelt. For et par år siden ville den opgave have krævet et par ugers arbejde: læsning af API-dokumentation, skrivning af rutinepræget grundkode, efterfulgt af test og atter test, indtil det holdt til virkelige forhold. Denne gang havde vi en fungerende første version på under en time.

Jeg vil gerne tage dig igennem, hvordan det lader sig gøre, for det er mere interessant end selve overskriften - og det forklarer, hvad der rent faktisk ændrer sig i det arbejde, vi udfører for vores kunder.

Editoren ser det fulde billede

Størstedelen af vores arbejde foregår i en kode-editor; den software, vi bruger til at skrive og håndtere kode. I dette kvartal har teamet næsten udelukkende arbejdet i Cursor, en AI-bygget editor skabt på samme fundament som Visual Studio Code - det værktøj, som en stor del af alle udviklere i forvejen bruger hver dag. Den velkendte base betyder mere, end det umiddelbart lyder til. Ingen behøvede at lægge værktøjet fra sig og lære deres håndværk forfra.

Det, der adskiller Cursor fra mængden, er det, den kan se. En standard kodeassistent kigger på den ene fil, der er åben foran den, og ikke ret meget andet. Cursor læser hele projektet på én gang: hvordan frontenden kommunikerer med backenden, hvor dataene bor, og hvordan hver del afhænger af de andre. Det er denne bevidsthed om den fulde kontekst, der gør den oprigtigt brugbar frem for bare hurtig. Da vi byggede DPD-forbindelsen, gættede værktøjet ikke i blinde. Det forstod allerede det system, det var ved at integrere med, så det første udkast, det producerede, ramte den ret plet, i stedet for at være et generisk udgangspunkt, vi først skulle skille ad.

Hvor mennesket bliver ved roret

Her er den del, jeg er meget påpasselig med at være ærlig omkring, for det er let at oversælge. AI'en stak ikke af og byggede integrationen på egen hånd. Vores team satte konteksten, definerede problemet, gennemgik hvert eneste output, den gav os, og testede resultatet grundigt, før det kom i nærheden af kundens live-system. AI'en finder problemerne. Det er stadig os, der beslutter, hvordan de skal løses.

Den skelnen udgør næsten hele jobbet nu. Hastigheden er ægte nok, men hastighed uden dømmekraft bagved er bare en hurtigere måde at udgive en fejl på. Et værktøj, der skriver plausibel kode på få sekunder, er kun et aktiv i hænderne på folk, der kan kende forskel på god kode og kode, der blot ser rigtig ud. I praksis bliver den tid, vi sparer på det første udkast, brugt dér, hvor det tæller: på gennemgangen. Vi læser det, værktøjet producerer, kører det op mod rigtige data og forsøger at ødelægge det, før en kunde nogensinde får muligheden. Kurer-opgaven var igennem den samme mølle. Den ene time købte os stilladset. Resten af dagen gik med at sikre, at det ikke ville vælte på en travl mandag.

Hvad hastigheden rent faktisk giver kunderne

Den samme tilgang har ændret måden, vi bygger hjemmesider på. Projekter, der før tog ugevis, bliver nu leveret på under to dage. Dette er ikke en diskret måde at tage den samme pris for mindre arbejde. Tværtimod. Når selve byggefasen stopper med at æde hele tidsplanen, forsvinder den tid ikke fra fakturaen. Den bliver i stedet lagt tilbage i de dele, der afgør, om et site overhovedet er godt: hårdere tests på tværs af rigtige enheder og særtilfælde (edge cases), samt den finpudsning, der normalt bliver sparet væk, når en deadline nærmer sig. Vores kunder får et bedre resultat, hurtigere, og inden for den faste aftale (retainer), de allerede har.

Vi bygger også små interne værktøjer for at smidiggøre vores egne arbejdsgange - de gentagne trin, der plejede at forsinke et projekt i det stille. De gevinster bliver ikke kun på vores side af hegnet. De bliver til hurtigere leveringstider og kvikkere ændringer på en kundekonto fra uge til uge.

Et kort ord om pålidelighed, for det er det spørgsmål, jeg ville stille, hvis jeg var i dine sko. Hurtigere betyder ikke mere ustabilt. Hvis noget, så giver hastigheden os mulighed for at bruge en større del af tidsplanen på det ucharmerende sikkerhedsarbejde: fejlhåndtering, "hvad-sker-der-når-kurersystemet-er-nede"-scenarierne, samt de belastningstests, der afgør, om en integration er en lydløs bekvemmelighed eller et opkald uden for åbningstid. Det er præcis de dele, der førhen blev forhastede, når uret tikkede imod os, og det er her, en god portion af de genvundne timer nu lægges.

Regnestykket for, hvad der kan betale sig, har ændret sig

Vi har knap nok kradset i overfladen af, hvad dette muliggør. Værktøjerne bevæger sig hurtigt, og vi tester konstant for at finde ud af, hvor de gør gavn, og - lige så vigtigt - hvor de ikke hører hjemme. Det siger sig selv, at vi hellere vil finde grænserne selv end at opdage dem på et kundeprojekt.

For kunder med en fast aftale arbejder hastigheden og skalerbarheden allerede til deres fordel. En ændring, der engang betød et tilbud på et stort omfang og 14 dages ventetid, kan nu klares med en kort snak og en hurtig levering. En integration, som ville have været svær at forsvare rent økonomisk for et år siden, kan måske klares på en fornuftig eftermiddag i dag.

Så her er mit ene praktiske forslag: Hvis der er noget, du har parkeret - en integration, du vurderede var for besværlig, eller en ombygning, der føltes for langsom til at være forstyrrelsen værd - så tag det op med os. De årsager, der gjorde, at det blev lagt på hylden, gælder måske ikke længere. Arbejdet er ikke blevet mindre omhyggeligt. Det er bare blevet enormt meget hurtigere, og det åbner i det stille op for ting, der slet ikke var på bordet før.