Hvornår ansætter jeg den første udvikler?

Hvornår ansætter jeg den første udvikler i Attera? Forhåbentlig aldrig.

Det lyder arrogant, når man siger det højt, og der findes også en kedeligere forklaring, nemlig at jeg ikke rigtig har råd endnu. Men det er faktisk målet. Jeg vil gerne se, hvor langt én person kan drive en hel softwarevirksomhed i 2026.

Reglen

Hver gang en opgave begynder at gentage sig, stiller jeg det samme spørgsmål: hvordan ville et system kunne overtage det her?

Det er en lille ændring i en refleks. Den refleks, jeg havde med fra bureautiden, var at finde en person til opgaven, når den fyldte nok. Sådan gør man, og der er ikke noget galt med det. Jeg har bare skiftet spørgsmålet ud, og så bliver opgaven til et stykke automatisering, og der bliver aldrig skrevet et stillingsopslag.

Bivirkningen har vist sig at være større, end jeg regnede med. Jeg bruger ingen tid på møder og koordinering, så der er fuldt fokus på at eksekvere fra morgen til aften. Det er en behagelig måde at arbejde på, når det går godt. Den er til gengæld ret ensom, når det ikke gør.

Bettet i gruppechatten

Sam Altman fra OpenAI fortalte i et interview med Alexis Ohanian i februar 2024, som blandt andre Fortune og TechCrunch dækkede, at han har et bet kørende i sin gruppechat med andre tech-CEO'er: hvilket år kommer den første virksomhed med én person, der når en milliard dollars?

Utænkeligt for få år siden. Nu er det et spørgsmål om hvornår.

Jeg siger ikke, at det bliver Attera. Jeg siger heller ikke, at det ikke gør.

Det interessante ved bettet er for mig, at det overhovedet er blevet et spørgsmål om et årstal. Man kan sagtens være uenig i, hvornår det sker, og stadig være enig i, at grænsen flytter sig. Og flytter grænsen sig, så er min regel bare en måde at aflæse den på, mens det står på.

Hvorfor reglen giver et andet svar nu

Her er den del, jeg tror er ny.

En opgave kan gentage sig på to måder. Den kan gentage sig helt identisk, og den slags har man kunnet skrive et script til i årtier. Eller den kan gentage sig næsten: samme form, samme formål, andre detaljer hver gang. En mail, der skal besvares. Et dokument, der skal læses og lægges det rigtige sted. En fejl, der ligner de sidste tyve fejl uden at være magen til nogen af dem.

Den anden slags har altid krævet et menneske, fordi den kræver en vurdering undervejs. Det er den vurdering, en model i dag kan lave godt nok, og derfor kan en stor del af næsten-gentagelserne klares af noget, der genkender formen og selv finder detaljerne frem.

Så reglen giver et andet svar i dag, end den gav for et par år siden, og det skyldes ikke, at jeg er blevet klogere. En hel kategori af opgaver er skiftet fra nej til ja.

Hvad det koster

Der er en grænse. Det er jeg helt sikker på.

Jeg kan bare ikke se den endnu, og jeg har en mistanke om, hvor den begynder. Hver gang jeg lader et system overtage en opgave, har jeg fået en ny ting, jeg skal vedligeholde. Reglen er gratis at sige og ret dyr at følge, og følger man den længe nok, ender man som den eneste, der ved, hvordan det hele hænger sammen. En ansat kan forklare sit arbejde til den næste. En automatisering forklarer ingenting, medmindre jeg selv har sørget for det.

Så jeg skriver mere ned, end jeg har lyst til. Det er prisen for at slippe for stillingsopslaget, og indtil videre betaler jeg den gerne.

Hvor jeg er mindre sikker

Overskriften spørger om en udvikler, og det er også dér, jeg er mest sikker på svaret. Kode er den slags arbejde, hvor jeg kan se hele vejen til bunden af, hvad et system kan overtage.

Jeg er mindre sikker, når jeg tænker på salg. At sidde over for et menneske, der overvejer at købe noget af mig, ligner ikke en opgave, jeg kan sende videre til en model, og den slags møder gentager sig faktisk ret meget. Måske er det dér, grænsen ligger.

Men grænsen flytter sig hele tiden med nye modeller, så jeg vil helst finde ud af, hvor den ligger, før jeg går ud fra, at jeg allerede er nået til den.