AI kan efterhånden producere mere kode på en eftermiddag, end jeg ansvarligt kan nå at gennemgå.
Det lyder umiddelbart som et luksusproblem. For mig blev det snarere et tegn på, at jeg arbejdede på den forkerte måde.
Hvis AI skriver hurtigere, mens jeg fortsat kontrollerer hver linje, retter de samme fejl og manuelt samler alle løse ender, bliver jeg ikke nødvendigvis mere effektiv. Jeg gør bare mig selv til det langsomste led i en hurtigere produktionslinje.
Den erkendelse har ændret min rolle som udvikler. Jeg er ikke holdt op med at bygge løsninger. Men en større del af arbejdet består nu i at formulere de krav, rammer og kontroller, som løsningerne skal bygges ud fra.
Det er en overgang fra kode til krav — og fra at rette den enkelte fejl til at forbedre det system, der skal forhindre den næste.
Første fase: Jeg byggede løsningen
Den første arbejdsform var velkendt.
Jeg fik en opgave, skrev koden og testede resultatet. Hvis noget ikke virkede, fandt jeg fejlen, rettede den og kørte løsningen igen.
Arbejdet var konkret og tilfredsstillende. Man kunne pege på en funktion og sige: Den har jeg bygget. Der var en tydelig forbindelse mellem indsats og resultat, og kontrollen kom af at kende detaljerne.
Dagens Aktie begyndte på samme måde. Funktioner, integrationer og arbejdsgange blev bygget én del ad gangen, og jeg var direkte involveret i næsten hvert trin.
Det fungerede, så længe opgaverne var få nok til, at én person kunne forstå og udføre dem alle. Men modellen skalerede kun ved, at jeg brugte flere timer.
Anden fase: AI skrev, og jeg ryddede op
Næste fase føltes først som et stort produktivitetsspring.
AI kunne skrive et første udkast til en funktion, foreslå en rettelse eller producere en større mængde kode, end jeg selv kunne nå på samme tid. Min rolle blev at gennemgå resultatet, rette fejlene og tilpasse løsningen til den eksisterende platform.
Jeg arbejdede hurtigere, men arbejdsformen var grundlæggende den samme. AI producerede, og jeg fungerede som den meget grundige udvikler, der sad bagefter og gjorde arbejdet færdigt.
Det skabte en ny flaskehals.
AI kunne producere mere, end jeg kunne kontrollere. Hvis den samme type fejl opstod igen og igen, og jeg hver gang rettede den direkte i koden, lærte processen ikke noget. Jeg fjernede symptomet, men efterlod årsagen intakt.
Det er bagsiden af den produktivitet, jeg tidligere har beskrevet i AI-kodning er absurd produktivt: Når produktionen bliver billig, bliver vurdering, afgrænsning og kvalitetskontrol den knappe ressource.
Tredje fase: Jeg retter kravet før koden
Nu forsøger jeg at arbejde på et andet niveau.
I stedet for straks at rette løsningen forsøger jeg først at rette kravene til løsningen. Jeg beskriver tydeligere:
- hvilket resultat der skal leveres
- hvilke data og kilder der må bruges
- hvilke grænser systemet skal respektere
- hvilke fejltilstande det skal kunne håndtere
- hvordan resultatet skal testes
- hvornår systemet skal stoppe og bede om menneskelig vurdering.
Derefter får agenterne lov til at undersøge den eksisterende løsning, finde årsagen, foretage ændringen og kontrollere resultatet.
Det betyder ikke, at jeg blindt accepterer det, der bliver afleveret. Det betyder, at kontrollen flyttes fra manuel udførelse til tydelige betingelser og verificerbare resultater.
Den afgørende forskel er, om jeg beder et system om at gøre noget, eller om jeg præcist beskriver, hvordan et korrekt resultat kan genkendes.
Fejlen ligger ofte et niveau højere
Mit første instinkt er stadig at åbne koden, når noget går galt. Det sidder dybt i mig som udvikler.
Men jeg forsøger i stigende grad at stoppe op og spørge:
- Var opgaven formuleret uklart?
- Manglede der en regel eller en vigtig begrænsning?
- Var datagrundlaget forkert eller ufuldstændigt?
- Var succeskriteriet så løst, at næsten enhver løsning kunne bestå?
- Manglede der en test, som burde have fanget fejlen før aflevering?
Når jeg retter koden, løser jeg den konkrete fejl. Når jeg retter kravet, datagrundlaget eller testen, kan systemet selv rette fejlen — og måske undgå en hel kategori af lignende fejl fremover.
Det er ikke altid kravet, der er problemet. Nogle gange er en fejl bare en fejl i koden. Men hvis den samme slags fejl vender tilbage, er det et tegn på, at problemet sandsynligvis ligger i processen omkring koden.
Et krav er ikke det samme som en lang prompt
Det er fristende at tro, at bedre krav blot betyder flere instruktioner. Det gør det ikke nødvendigvis.
En lang beskrivelse kan stadig være uklar. Den kan indeholde modstridende ønsker, skjulte antagelser og formuleringer, der ikke kan testes.
Et godt krav gør især tre ting:
- Det gør intentionen tydelig.
- Det begrænser løsningsrummet dér, hvor fejl vil være dyre.
- Det gør det muligt at afgøre, om resultatet er korrekt.
Det sidste punkt er det vigtigste. Hvis jeg ikke kan beskrive, hvordan løsningen skal kontrolleres, har jeg sandsynligvis heller ikke beskrevet opgaven godt nok.
I praksis kan en test være teknisk, men den kan også være redaktionel eller datamæssig. Findes alle nødvendige felter? Kommer tallene fra de rigtige kilder? Er datoerne aktuelle? Virker de interne links? Er konklusionen understøttet af indholdet? Stopper processen, hvis centrale data mangler?
Kravet bliver dermed ikke bare en bestilling. Det bliver en del af kontrolsystemet.
Hvad det betyder for Dagens Aktie
Dagens Aktie følger næsten den samme udvikling som mit øvrige arbejde.
Først byggede og skrev jeg det meste manuelt. Derefter lod jeg AI producere kode og indhold, som jeg selv gennemgik og rettede bagefter. Nu bruger jeg mere tid på at forbedre instruktionerne, datagrundlaget og kontrollen, så systemet i højere grad kan opdage og rette sine egne fejl.
Det er nødvendigt, når mere end tusind aktieanalyser skal holdes løbende opdaterede. Opgaven kan ikke løses ansvarligt ved blot at producere mere tekst. Systemet skal kunne skelne mellem nyt og gammelt, væsentligt og uvæsentligt samt dokumentation og antagelser.
Hvis en analyse bruger en gammel begivenhed som noget aktuelt, er den langsigtede løsning ikke kun at ændre den pågældende sætning. Løsningen er også at forbedre reglerne for aktualitet og kildebrug.
Hvis et selskabs tal ikke stemmer, er det ikke nok at indsætte det korrekte tal manuelt. Jeg skal undersøge, om kildehierarkiet, dataudtrækket eller kontrollen mellem perioder er utilstrækkelig.
Hvis en tekst bliver overbevisende uden at være tilstrækkeligt dokumenteret, skal systemet ikke blot have en ny formulering. Det skal have et tydeligere krav om belæg, usikkerhed og stopkriterier.
De faste principper for analyserne er beskrevet i metoden bag Dagens Aktie. Men metoden er ikke et færdigt dokument. Den er en del af et system, der løbende skal forbedres, når nye fejl viser svagheder i processen.
Kontrol forsvinder ikke — den skifter form
Det kan føles som et tab af kontrol ikke længere selv at skrive hver linje.
Tidligere kom kontrollen fra nærhed: Jeg havde selv bygget detaljen og vidste derfor, hvordan den fungerede. I en mere agentbaseret arbejdsform skal kontrollen i højere grad komme fra arkitektur, rettigheder, tests, sporbarhed og klare grænser.
Det stiller faktisk større krav til teknisk forståelse.
Jeg skal stadig kunne se, når noget er forkert, forstå hvorfor det er forkert og vurdere, om løsningen er forsvarlig. Jeg skal vide, hvornår en test giver falsk tryghed, hvornår en datakilde ikke kan bruges, og hvornår en hurtig løsning skaber et større problem senere.
Forskellen er, at jeg ikke behøver udføre alle rettelserne med mine egne hænder.
AI kan overtage en del af produktionen. Den kan ikke overtage ansvaret for, hvad der bliver sat i produktion eller offentliggjort.
Håndværket bliver mindre synligt
Overgangen er mærkelig, fordi arbejdet bliver sværere at pege på.
Jeg skriver færre af de linjer, der ender i den færdige løsning. Til gengæld bruger jeg mere tid på intention, rammer, datakvalitet, test og håndtering af fejl.
Jeg er gået fra primært at bygge løsningen til at bygge det system, der kan bygge, kontrollere og rette løsningen.
Det er stadig udvikling, men belønningen føles anderledes.
Før kunne man leve højt på en god leverance i længere tid. Man afsluttede en funktion, så den virke og kunne glæde sig over noget håndgribeligt. Nu er tilfredsheden ofte kort. I samme øjeblik én opgave er løst, bliver det synligt, hvad systemet bør kunne som det næste.
Det er enormt effektivt og en smule ubehageligt.
Men måske er det netop den største forandring, AI har skabt i mit arbejde: Jeg er ikke holdt op med at udvikle løsninger. Jeg er begyndt at udvikle de betingelser, som gode løsninger kan opstå, testes og forbedres under.
Og jeg er stadig ved at vænne mig til det.