Nøkkelinnsikt

• Block kuttet fra 10 000+ til under 6000 ansatte til tross for voksende inntekter, et signal om at store utviklingsteam kan bli en ulempe snarere enn en fordel
• Å skrive kode gikk fra å være det dyreste til det billigste steget i å levere programvare, og fjernet flaskehalsen som begrunnet store team
• Den nye flaskehalsen er kodegjennomgang, testing og kvalitetssikring, ferdigheter de fleste utviklere tradisjonelt har undervurdert

---

Kort fortalt

Block, selskapet bak Square og Cash App, har nettopp sagt opp over 4000 ansatte til tross for at de er lønnsomme og voksende. Theo Browne mener dette ikke handler om å spare penger, men om at hele strukturen i programvareselskaper er i ferd med å endre seg. AI-verktøy har gjort det nesten gratis å skrive kode. Flaskehalsen har flyttet seg nedover til kodegjennomgang, testing og utsending, og selskaper med store utviklingsteam oppdager at flere folk nå betyr tregere leveranser, ikke raskere.

---

Block: lønnsom, voksende, og kutter halvparten

Jack Dorsey, Blocks toppsjef og mannen som grunnla Twitter, kunngjorde at Block reduserer fra over 10 000 til under 6000 ansatte (12:54). Det betyr at over 4000 mennesker mister jobben.

Det uvanlige: Block har det bra økonomisk. Bruttoresultatet fortsetter å vokse, kundemassen øker, og lønnsomheten blir bedre (16:04). Dorseys forklaring er at AI-verktøy, kombinert med mindre og flatere team, forandrer hva det betyr å bygge og drive et selskap.

Dorsey beskrev to valg: kutte gradvis over måneder eller år, eller handle nå. Han valgte det siste. Argumentet hans er at gjentatte små runder med oppsigelser ødelegger moralen uten å faktisk tvinge frem organisasjonsendringene som trengs (16:29). Å gå fra 10 til 8 personer endrer ikke prosessen. Å gå fra 10 til 2 tvinger deg til å tenke helt nytt (33:06).

Browne påpeker at sluttpakken er raus: 20 ukers lønn pluss én ekstra uke per år ansettelse, aksjeopsjoner som modnes frem til slutten av mai, seks måneders helseforsikring, jobbens PC/Mac, og 5000 dollar til omstilling (13:06).

---

Beviset: gjenoppbygging av et produkt til 14 milliarder på to uker

For å vise hvor mye som har endret seg, forteller Browne om Lawn. Lawn er et alternativ til Frame.io, en plattform for videogjennomgang som Adobe kjøpte i 2021 for 1,3 milliarder dollar (rundt 14 milliarder kroner) (6:47).

Browne sier han bygde et fungerende alternativ på to uker, på deltid, mens han drev selskapet sitt og YouTube-kanalen. Han hevder å ikke ha skrevet en eneste kodelinje for hånd (5:27). Han strukturerte API-ene (Application Programming Interface, reglene for hvordan ulike deler av programvaren snakker med hverandre) og applikasjonslogikken ved å beskrive for en AI-agent hvordan ting burde fungere, sjekket forslagene, og lot den skrive koden. Etterpå gjorde han alt åpen kildekode (open source).

Browne innrømmer at ingeniørbakgrunnen hans hjalp. Han forstod begrensningene og kravene i videoprodukter. Men han hevder at selv uten den bakgrunnen ville AI-modellen gitt minst halvparten av de viktigste beslutningene (8:40).

Poenget er bredere: hvis én person kan gjenoppbygge et produkt til 14 milliarder på deltid på to uker, har kostnadsfordelen ved å ha et stort utviklingsteam kollapset.

---

Koden er ikke flaskehalsen lenger

Browne bryter ned prosessen med å levere programvare i steg (22:19):

1. Bruker rapporterer et problem
2. Beskriv problemet tydelig
3. Finn en løsning
4. Planlegg og fordel arbeidet
5. Skriv koden
6. Se over koden (kodegjennomgang)
7. Test koden
8. Planlegg og gjennomfør lansering

Historisk sett var steg 5 det dyre steget. Det krevde høyt kvalifiserte, godt betalte utviklere. Alt over dette steget handlet om å filtrere ideer slik at bare de beste nådde utviklingsteamet. Prosessen så ut som en trakt: 500 brukerproblemer ble 100 beskrevne saker, 50 fikk løsningsforslag, 15 ble planlagt, og kanskje 5 ble faktisk kodet (22:48).

Nå, hevder Browne, har trakten blitt flat ved kodingssteget. En utvikler kan lime inn et skjermbilde av en brukerklage i en AI-agent og hoppe rett fra «brukerproblem» til «kode skrevet» (23:31). Steget som pleide å begrunne ansettelse av flere utviklere er ikke lenger begrensningen.

---

Hvorfor flere utviklere nå betyr tregere leveranser

Her mener Browne det virkelig blir farlig for store selskaper. Når AI genererer kode raskt, flytter flaskehalsen seg til kodegjennomgang, testing og godkjenning av lanseringer.

Flere utviklere betyr flere PR-er (pull requests, foreslåtte kodeendringer som må gjennomgås før de slås sammen med hovedkoden). Flere PR-er betyr mer koordinering, flere godkjenninger, og flere muligheter for at team blokkerer hverandre. Browne forteller at hans eget team endte opp med hundrevis av PR-er som bare ble liggende fordi gjennomgangen ikke holdt tritt (28:37).

Han sammenligner store team med hangarskip: de kan frakte mye, men hvis de må endre kurs, tar det dager å snu. Små team snur på sekundet (29:18).

Et konkret eksempel: Browne prøvde å få en ny AI-modell lagt til i GitHubs Copilot CLI (kommandolinjeverktøy, et tekstbasert verktøy du bruker i terminalen). Til tross for hjelp fra folk høyt oppe i Microsoft, var svaret at det «ikke var enkelt» på grunn av interne prosesser (34:01). Browne hevder dette er én eneste kodelinje som blokkeres av organisatorisk kompleksitet, ikke teknisk vanskelighetsgrad.

Hans eget team illustrerer poenget: tre utviklere konkurrerer med OpenAIs Codex-team, som han anslår til 20+ personer (20:24).

---

Hva er verdifullt nå?

Hvis kode er nesten gratis å skrive, hvilke ferdigheter betyr noe? Browne lister opp flere (30:43):

• Oversette brukerproblemer til tydelige planer. Evnen til å ta en vag klage og gjøre den om til en spesifikk, handlingsbar beskrivelse.
• Gjøre kode klar for lansering. Kodegjennomgang, kvalitetssikring (QA, prosessen med å verifisere at programvare fungerer riktig), og manuell testing.
• Bygge tilbakerullingssystemer. Pålitelige måter å angre endringer på når noe går galt i produksjon.
• Skrive grundige tester. Automatiserte sjekker som verifiserer at koden oppfører seg som forventet.
• Kjenne brukerne dine. Browne hevder at mange utviklere ikke kan nevne én eneste kunde av produktet de jobber med. Hvis en AI-agent vet mer om kundene dine enn du gjør, er posisjonen din sårbar (39:10).

Browne peker også på en utfordring for motivasjonen: å skrive kode var en av de morsomste delene av jobben. Nå bruker utviklere mer tid på gjennomgang og testing, noe de fleste misliker (31:06).

Rådet hans til utviklere: snakk mer med brukerne, bli mer involvert i lanseringsprosessen, lær systemene rundt utsending, og prøv å automatisere ditt eget arbeid. Gjennom den automatiseringen oppdager du alt rundt koden som faktisk betyr noe (38:18).

---

Hvor seriøst bør vi ta disse påstandene?

Browne er innholdsskaper og gründer med et tydelig perspektiv og et publikum å engasjere. Argumentene hans er overbevisende, men fortjener kritisk blikk.

Eksemplene passer best på nye prosjekter

Lawn og T3 Code er nye prosjekter bygd fra grunnen av (greenfield), i teknologi Browne kan godt. Å bygge noe nytt i et domene du forstår er veldig forskjellig fra å vedlikeholde et gammelt system du har arvet. Sammenligningen med Frame.io til 14 milliarder inkluderer også årevis med partnerskap, integrasjoner og kunderelasjoner som kode alene ikke kan erstatte. Browne erkjenner dette for Blocks produkter (11:52), men bruker likevel sammenligningen.

«Kode er gratis» gjelder ikke overalt

AI-kodeverktøy fungerer best på vanlige mønstre: CRUD-applikasjoner (apper som oppretter, leser, oppdaterer og sletter data), standard webgrensesnitt og godt dokumenterte rammeverk. Systemer med uvanlige begrensninger, strenge regulatoriske krav, eller kompleks distribuert infrastruktur er vanskeligere å gjenskape. Påstanden er sterkest for den typen programvare de fleste selskaper lager, og svakest for den typen som er vanskeligst å erstatte.

Problemet med store team er ikke nytt

Argumentet om at flere utviklere bremser ting er eldre enn AI. Fred Brooks beskrev det i 1975 i boken «The Mythical Man-Month». AI-verktøy har forsterket denne dynamikken, men selskaper som allerede håndterte koordinering godt, opplever kanskje mindre omveltning enn Browne antyder. Det dypere spørsmålet handler ikke bare om kodeproduksjon, men om hvor godt en organisasjon tar beslutninger.

Overlevelseseffekten i småteam-fortellingen

Brownes team på tre personer leverer raskt, men mange små team feiler. Fortellingen fremhever vinnerne. Et mer komplett bilde ville inkludere hvor mange AI-akselererte prosjekter stopper opp fordi utvikleren traff en situasjon modellen ikke klarte, mistet oversikten, eller sendte ut feil som et større testteam ville fanget opp.

---

Ordliste

---

Kilder og ressurser