Jeg er tilbage i udviklerrollen, som konsulent, og blev sat til at bygge en integration mellem en e-commerce platform og en af Europas førende TMS-løsninger. Kunden er en hurtigt voksende dansk webshop, og opgaven skulle løses hurtigt for at fange en konkret forretningsmulighed.
Til opgaven valgte jeg Ruby on Rails. mit go-to framework gennem 20 år. Enkelt at sætte op, hurtigt at komme i gang, og stadig overraskende effektivt til forretningsunderstøttende applikationer.
Men i modsætning til tidligere brugte jeg denne gang en sprogmodel aktivt i udviklingen, ikke som eksperiment, men som værktøj. Tidligere erfaringer med LLM’er har ærligt talt været lunkne. Men siden sidst er der sket en markant forbedring i både output og samarbejdsevne.
Jeg brugte modellen til at:
- generere boilerplate (model/controller/test scaffolding, API-interfaces, UI-komponenter)
- skrive konverteringslogik mellem datamodeller
- refaktorere klasser og funktionalitet
- generere bash-scripts til lokal opsætning og deployments
Resultatet: Jeg løste ikke bare kundens opgave hurtigere end forventet – jeg fik også lavet tre sideprojekter samtidig. Herunder et simpelt ikke-cookiebaseret analytics-værktøj, en intern B2B-webshop til IoT-enheder og denne blog. Alt sammen kunne måles i dage istedet for måneder.
Modellen er stærk på det, vi allerede har gjort mange gange før. Den kender konventioner, patterns og strukturer bedre end mange udviklere. Men den har stadig svært ved at holde kontekst over længere sessions, og den kræver, at man selv forstår retningen. Du skal være arkitekt og lead-arkitekt.
Jeg ville ikke outsource kompleks forretningslogik eller tillidstunge sikkerhedskritiske komponenter til en sprogmodel endnu. Men alt det trivielle, det konventionelle og det, der bare skal virke
? Det er dumt ikke at automatisere det.