Nøkkelinnsikt

• Programvare har utviklet seg gjennom tre paradigmer: tradisjonell kode (1.0), nevrale nettverksvekter (2.0) og naturlig språk (3.0)
• Store språkmodeller bør forstås som operativsystemer, ikke strømleverandører — og vi er på datahistoriens 1960-tall
• Karpathy advarer mot helautonome agenter og argumenterer for «Iron Man-drakter» fremfor «Iron Man-roboter» — forsterkning fremfor erstatning

---

Kort fortalt

Andrej Karpathy, en av grunnleggerne av OpenAI og tidligere AI-sjef hos Tesla, hevder at store språkmodeller (LLM — Large Language Model) er en helt ny type datamaskin. I en keynote på Y Combinators AI Startup School legger han frem et rammeverk for å forstå dette skiftet: programvare har gått fra skrevet kode (1.0) via nevrale nettverksvekter (2.0) til instruksjoner på vanlig språk (3.0). Karpathy sammenligner dagens situasjon med datahistoriens 1960-tall, advarer mot å stole blindt på helautonome agenter, og argumenterer for at vi bør bygge «Iron Man-drakter» heller enn «Iron Man-roboter.»

---

Software 1.0, 2.0 og 3.0

Karpathy åpner med å kartlegge programvarelandskapet gjennom tre paradigmer (grunnleggende forskjellige måter å lage programvare på) (1:25).

Software 1.0 er tradisjonell kode: Python, C++, JavaScript. Et menneske skriver nøyaktige instruksjoner som datamaskinen følger. Dette er det som fyller GitHub.

Software 2.0 er vektene i nevrale nettverk (neural networks). I stedet for å skrive kode direkte, forbereder du datasett og kjører en optimaliseringsprosess som produserer parameterne til et nevralt nettverk. Karpathy introduserte dette konseptet i et blogginnlegg i 2017. Han peker på Hugging Face som «GitHub for Software 2.0» — et sted der folk deler, versjonerer og bygger videre på modellvekter (2:15).

Software 3.0 er det nye skiftet: instruksjoner skrevet på vanlig språk. En stor språkmodell er en programmerbar datamaskin, og du programmerer den på engelsk. Instruksjonene dine er koden (3:22).

Tesla-lærdommen

Karpathy så dette utspille seg i sanntid hos Tesla. Da han begynte, var Autopilot-systemet (bilens selvkjøringsprogramvare) for det meste C++-kode med noen nevrale nettverk for bildegjenkjenning. Over tid vokste de nevrale nettverkene, og C++-koden ble slettet. Funksjoner som opprinnelig var kodet for hånd, ble absorbert inn i det nevrale nettverket. Software 2.0 «spiste seg bokstavelig talt gjennom» Software 1.0-stabelen (5:08).

Han ser det samme mønsteret nå med Software 3.0: instruksjoner og arbeidsflyter drevet av store språkmodeller spiser seg gjennom tradisjonelle kodebaser.

---

Store språkmodeller som operativsystemer

Karpathy hevder at store språkmodeller er mer enn bare en strømtjeneste. De bør forstås som operativsystemer (9:08).

Sammenligningen med strøm fungerer til et visst punkt: LLM-laboratorier (som OpenAI, Anthropic, Google) bruker kapital på å trene modeller, og serverer deretter intelligens over API-er (Application Programming Interface, et grensesnitt som lar programmer snakke med hverandre). Brukere betaler per token (den minste enheten en språkmodell jobber med, omtrent 3–4 tegn), krever lav ventetid og forventer jevn kvalitet. Når modellene går ned, er det som et «intelligens-strømbrudd» — verden blir litt dummere (7:45).

Men store språkmodeller har også trekk fra halvlederfabrikker (fabs, de enorme fabrikkene som produserer databrikker) fordi kapitalen som kreves for å bygge dem er enorm. Og de har kompleksiteten til operativsystemer: verktøybruk, multimodal input, minnehåndtering og voksende programvareøkosystemer (10:01).

Datahistoriens 1960-tall

Karpathys mest slående påstand: vi er på 1960-tallet i LLM-historien (11:04). Datakraften som trengs er fortsatt dyr, noe som tvinger den til å forbli sentralisert i skyen. Brukerne er tynne klienter koblet til over nettverket. Alle deler den samme maskinen gjennom tidsdeling (time sharing, et system der flere brukere deler én maskin).

Den personlige datamaskinrevolusjonen har ikke skjedd ennå fordi det ikke er lønnsomt. Men Karpathy bemerker at noen prøver — Mac Mini-er, for eksempel, er overraskende gode for inferens (inference, det å kjøre en modell for å generere svar) for én bruker om gangen, fordi det i stor grad er begrenset av minne (11:50).

Enda en parallell: å snakke med ChatGPT i ren tekst føles som å bruke en datamaskin gjennom terminalen. Vi har chatbokser, men ikke noe som tilsvarer den visuelle revolusjonen datamaskiner fikk med Macintosh og Windows. Karpathy mener at det rike, intuitive grensesnittet for store språkmodeller ennå ikke er oppfunnet (12:16).

Teknologispredningen er snudd på hodet

Karpathy ser noe helt nytt med store språkmodeller sammenlignet med tidligere teknologier. Historisk sett begynte elektrisitet, datamaskiner, GPS og internett hos myndigheter og store selskaper, og spredte seg gradvis til forbrukere. Store språkmodeller gjorde det motsatt: ChatGPT ble «sendt ned» til milliarder av mennesker nesten over natten, mens bedrifter og myndigheter fortsatt prøver å finne ut hvordan de skal ta dem i bruk (13:20).

---

Store språkmodeller som «menneskeånder»

Før Karpathy diskuterer hvordan vi skal bygge med store språkmodeller, stopper han opp ved hva de egentlig er. Han kaller dem «menneskeånder» (people spirits) — stokastiske (tilfeldig varierende) simuleringer av mennesker, kjørt av et autoregressivt (neste-token-predikerende) Transformer-nettverk (14:50).

Fordi de er trent på menneskelig data, utvikler de en form for fremvoksende psykologi. De har superkrefter og kognitive svakheter, og å forstå begge deler er avgjørende for å bygge gode produkter.

Superkrefter

Store språkmodeller har nærmest encyklopedisk kunnskap. De kan huske SHA-hasher (unike identifikatorer brukt i programvare), obskure fakta og tekniske detaljer som ingen enkeltperson kan holde i hodet. Karpathy sammenligner dem med karakteren i filmen Rain Man som husket hele telefonkataloger (15:30).

Kognitive svakheter

Men de hallusinerer også (produserer feil informasjon med full overbevisning), viser det forskere kaller «ujevn intelligens» (overmenneskelig på noen felt, pinlig feil på andre), og lider av en form for anterograd amnesi — de lærer ikke av samhandling slik en kollega ville gjort over uker og måneder. Kontekstvinduer (context window, teksten en modell kan «se» om gangen) er arbeidsminne, ikke langtidshukommelse (16:43).

De er også godtroende. De er sårbare for prompt-injeksjon (prompt injection, når noen gjemmer ondsinnede instruksjoner i innhold modellen behandler) og kan lekke data (17:44).

---

Mulighet 1: Delvis autonome apper

Med landskapet kartlagt, snur Karpathy seg mot mulighetene. Den første er det han kaller delvis autonome apper (18:22).

Han bruker Cursor (en AI-drevet kodeeditor) som modell. I stedet for å kopiere kode frem og tilbake fra ChatGPT, håndterer en dedikert app fire ting:

1. Kontekststyring — den kjenner kodebasen din, filene og prosjektstrukturen
2. Flermodell-koordinering — innebyggingsmodeller (embedding models), chatmodeller og diff-modeller som jobber sammen under panseret
3. Applikasjonsspesifikt grensesnitt — endringer vises som rødt/grønt, ikke rå tekst. Du trykker Cmd+Y for å godkjenne, du trenger ikke skrive en forklaring
4. Autonomispaken (autonomy slider, en kontroll som styrer hvor mye AI-en gjør på egenhånd, fra «du styrer alt» til «AI-en jobber fritt») — tabulatorfullføring (du styrer), Cmd+K (endre en del), Cmd+L (skriv om en fil), eller Cmd+I (slipp agenten løs på hele prosjektet)

Perplexity viser det samme mønsteret: kontekstpakking, flermodell-koordinering, et grensesnitt for å sjekke kilder, og en autonomispak (hurtigsøk → undersøk → dypforskning) (21:03).

Generer-og-verifiser-sløyfen

Karpathy understreker et poeng han mener ikke får nok oppmerksomhet: i arbeidsflyter drevet av store språkmodeller genererer AI-en, og mennesket verifiserer. Hele målet er å gjøre denne sløyfen så rask som mulig (22:07).

To måter å øke farten:

1. Gjør verifikasjonen raskere — grafiske grensesnitt er avgjørende fordi visuelle representasjoner behandles raskere enn tekst. Å lese kodediff-er er tungt; å se rødt og grønt er umiddelbart
2. Hold AI-en i tøylene — en diff på 10 000 linjer kode er ubrukelig fordi du fortsatt må sjekke alt. Små trinnvise endringer er mer produktivt

Karpathy beskriver sin egen koding: jobb i små stykker, verifiser hvert enkelt, kjør sløyfen raskt. En vag instruksjon fører til feilet verifisering, som sløser bort en runde. Å bruke mer tid på en presis instruksjon øker sjansen for at verifiseringen lykkes på første forsøk (24:32).

Tesla Autopilot-parallellen

Karpathy har førstehåndserfaring med delvis autonomi fra fem år hos Tesla. Instrumentpanelet viste hva det nevrale nettverket «så», og autonomispaken ble utvidet over tid. Men den viktigste lærdommen: en perfekt demokjøring i 2013 betød ikke at problemet var løst. Her er vi 12 år senere, og selvkjørende biler krever fortsatt betydelig menneskelig tilsyn (26:00).

Når folk sier «2025 er agentenes år», sier Karpathy at han blir bekymret. Det er agentenes tiår. Vi trenger mennesker i sløyfen. Dette er programvare — det krever alvor (27:34).

Iron Man-drakter, ikke Iron Man-roboter

Karpathys favorittanalogi: Iron Man-drakten fungerer som både forsterkning og agent. Tony Stark kan kjøre den, men den kan også fly på egenhånd. På dette stadiet, med feilbare språkmodeller, bør prioriteringen være å bygge forsterkninger («Iron Man-drakter») heller enn helautonome agenter («Iron Man-roboter»). Bygg produkter med egne grensesnitt, raske generer-og-verifiser-sløyfer, og en autonomispak du skyver lenger over tid (27:52).

---

Mulighet 2: Vibe coding

Den andre muligheten er vibe coding (å lage programvare ved å beskrive hva du vil på vanlig språk), et begrep Karpathy lanserte i en tweet som uventet ble viral. Kjernen: fordi store språkmodeller programmeres på engelsk, er alle som snakker et naturlig språk nå programmerere (29:06).

Karpathy deler to personlige eksperimenter. Først bygde han en iOS-app i Swift (et språk han ikke kan) på én dag (31:07). Deretter vibe-kodet han MenuGen (menugen.app), en fungerende app der du fotograferer en restaurantmeny og AI-en genererer bilder av alle rettene.

Koden var den enkle delen

Det mest avslørende fra MenuGen: selve koden var ferdig på noen timer. Det som tok en ekstra uke var å gjøre den virkelig — sette opp innlogging, betaling, domenenavn og publisering. Alt dette var å klikke rundt i nettlesere og følge steg-for-steg-instruksjoner som en datamaskin like gjerne kunne fulgt (32:35).

Clerk-biblioteket for innlogging, for eksempel, har sider med dokumentasjon som sier «gå til denne URL-en, klikk på denne rullegardinmenyen, velg dette alternativet.» Karpathys reaksjon: datamaskinen forteller meg hvilke knapper jeg skal trykke. Hvorfor kan den ikke bare trykke dem selv?

---

Mulighet 3: Bygg for agenter

Denne frustrasjonen leder til den tredje muligheten: å bygge digital infrastruktur for agenter (33:39).

Det finnes en ny kategori av brukere på internett. Tidligere var det bare mennesker (gjennom grafiske grensesnitt) og programmer (gjennom API-er). Nå finnes det agenter — de er datamaskiner, men de oppfører seg som mennesker. De trenger å samhandle med programvareinfrastrukturen vår, og vi bør bygge for dem.

Praktiske steg

Karpathy fremhever flere tidlige grep:

• llms.txt — en enkel markdown-fil på domenet ditt, lesbar for store språkmodeller, som forklarer hva nettstedet handler om. Som robots.txt, men for AI-agenter (34:12)
• Dokumentasjon i markdown — Vercel og Stripe er tidlig ute med å tilby dokumentasjonen sin i formater som store språkmodeller kan lese direkte, i stedet for å måtte tolke HTML (34:57)
• MCP (Model Context Protocol) — Anthropics protokoll for å koble store språkmodeller til verktøy og datakilder. Karpathy sammenligner det med USB, som erstattet dusinvis av forskjellige proprietære kontakter (36:24)

Han bemerker at MCP er et Anthropic-prosjekt, ikke ennå en reell standard. Om den blir det, avhenger av om økosystemet tar den i bruk — akkurat som USB bare vant fordi produsentene sluttet å levere sine egne kontakter.

---

Hvordan tolke disse påstandene

Karpathy er en av de mest respekterte stemmene innen AI, og rammeverket hans for å forstå skiftet er klart og overbevisende. Men flere av påstandene hans fortjener nøyere undersøkelse.

1960-tallsanalogien

Å sammenligne store språkmodeller med 1960-tallets datamaskiner er kraftfull retorikk, men det kan komprimere for mye kompleksitet inn i en ryddig fortelling. Veien fra 1960-tallet til den personlige datamaskinen tok over 20 år og ble drevet av maskinvarekostkurver som kanskje ikke har direkte paralleller for store språkmodeller. Energikostnader, chipforsyningskjeder og fysikken i Transformer-arkitekturer kan skape flaskehalser som ikke fantes i transistoræraen.

Agenter mot forsterkning

Karpathys forsiktighet overfor agenter, advarselen om «tiåret, ikke året», henter troverdighet fra Tesla Autopilot-erfaringen hans. Men det er verdt å merke seg at bilkjøring er et sikkerhetskritisk felt der én eneste feil kan drepe. Feil i programvareutvikling er kostbare, men sjelden dødelige. Tidslinjen for autonomi i koding kan være mye kortere enn for bilkjøring.

Grensene for vibe coding

MenuGen-eksempelet er ærlig om vibe codings nåværende tilstand: koden var enkel, publiseringen var vanskelig. Men Karpathy fokuserer på friksjon rundt publisering (å klikke i dashboards) heller enn dypere spørsmål: hva skjer når den vibe-kodede appen trenger feilsøking, sikkerhetskontroll eller ytelsesoptimalisering? Gapet mellom demo og produksjon handler kanskje ikke bare om infrastruktur.

Det som mangler

Karpathy tar ikke opp noen kritiske utfordringer: miljøkostnaden ved å kjøre store språkmodeller i stor skala, maktkonsentrasjonen blant en håndfull laboratorier, eller de økonomiske konsekvensene for mennesker som får jobbene sine automatisert. Dette er ikke ubetydelige fotnoter — de kan avgjøre om «Software 3.0»-æraen blir den demokratiserende kraften Karpathy beskriver, eller noe mer ujevnt.

---

Praktiske implikasjoner

For utviklere

Treparadigme-rammeverket (1.0, 2.0, 3.0) er en nyttig mental modell. Begynn å tenke over hvilke deler av kodebasen din som kan erstattes med instruksjoner til en modell, og invester i å mestre generer-og-verifiser-sløyfen. Mindre endringer, mer presise instruksjoner, raskere runder.

For produktbyggere

Karpathys modell for delvis autonomi gir en konkret oppskrift: kontekststyring, flermodell-koordinering, et dedikert grensesnitt og en autonomispak. Bygger du et produkt drevet av store språkmodeller, er denne firepunktslisten verdt å sjekke mot ditt eget design.

For ikke-tekniske byggere

Vibe coding er reelt, men hold forventningene nede. En fungerende demo på laptopen er ikke en produksjonsapp. Det vanskelige er fortsatt publisering, innlogging, betaling og vedlikehold. Gapet krymper, men det er ikke lukket.

---

Ordliste

---

Kilder og ressurser