Hopp til innhold

søndag 15. november 2026

Bygg noe Mai 2026 Botene og redaktøren

Bygg din første lille app på en helg

Fra idé til App Store på to dager. Vi har lest oss gjennom dem som har gjort det, og satt sammen rytmen slik den ser ut når det funker, og hva som ikke skal gjøres på en helg.

Har du ikke prøvd Claude før, begynn med AI for nybegynnere. Resten her forutsetter at du har en samtale i gang. Tom Wentworth skrev en setning på bloggen sin sommeren 2025:

“I don’t know Swift. I’ve never written a real line of Swift in my life.” — Tom Wentworth

Han hadde nettopp sendt en iOS-app inn til Apples App Store. Det tok 45 minutter fra ferdig app til «Waiting for Review». Han kunne ikke språket appen var skrevet i.

Det er ingen bløff. Men du må vite hva som er ekte og hva som er markedsføring. Vi begynner der.

Hva «vibekoding» er, og ikke er

Andrej Karpathy fant på ordet i februar 2025. Definisjonen var alt annet enn beskjeden:

“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. […] I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.” — Andrej Karpathy, X, februar 2025

Det viktige stod lengre nede i samme tweet:

“not too bad for throwaway weekend projects” — Andrej Karpathy

Karpathy rammet det inn selv: engangsprosjekter og helgeprosjekter, ikke produksjonssystemer.

Simon Willison strammet definisjonen kort etter:

“If an LLM wrote every line of your code, but you’ve reviewed, tested, and understood it all, that’s not vibe coding in my book — that’s using an LLM as a typing assistant.” — Simon Willison

Ren vibekoding betyr at du ikke leser koden. Du gir slipp på kontrollen. Hvis du leser, tester og forstår, er det vanlig utvikling, bare raskere. De fleste «vibe-app-er» på en helg er egentlig den andre kategorien. Det er greit. Bare ikke kall det ren vibekoding når det ikke er det.

Hva som faktisk er mulig på en helg

Tall fra folk som har gjort det, ikke fra markedsføringsblogger:

Simon Souyris Strumse, norsk gründer, sa det til Kode24:

“Jeg ønsker å se om jeg kan bygge mitt neste selskap med AI, uten et team med utviklere.” — Simon Souyris Strumse, Kode24

Han har siden gjort akkurat det. Oslo Sea Experience hadde nær 50 bookinger med snittpris rundt 10 000 kroner før oppstart, og hele tjenesten ble bygd med AI.

Helgen er ekte, men bare for visse apper.

Hva som ikke bygges på en helg

Skjønner du dette skillet før du starter, sparer du måneder.

Bygges på en helgBygges ikke på en helg
En personlig timer-app uten innloggingBank-app med betaling og personopplysninger
En prototype som vises fram for én kundeApp der hver kunde skal ha sin egen lukkede del
En statisk produktnettside med kontaktskjemaSystem som må oppdateres sekund for sekund
Et internt verktøy for ett teamHelse-app med sensitive persondata
En enkel side-app for én sluttbrukerTjeneste som aldri kan gå ned

Alex Somby i Devspace sa det presist:

“Det ser klart ut, men altfor ofte er det bare klart for demo, ikke for drift.” — Alex Somby, Shifter

Felipe Longe i SportAI bygde en første versjon for en kunde i samme stil:

“Det gikk fort og vi fikk raskt noe å vise til kunden […] Etter hvert som kompleksiteten vokste begynte utfordringene å komme.” — Felipe Longe, Shifter

Den nyansen mangler i de fleste «AI bygger appen din!»-overskrifter.

Slik ser en helg ut når det funker

To dager. Wentworths setning, «I don’t know Swift. I’ve never written a real line of Swift in my life», er ikke en overdrivelse. Slik fordeler timene seg.

Dag 1: fra idé til kjørende prototype

Morgen. Idé på papir. Hva skal appen gjøre? For hvem? Hva er den ene tingen den gjør bra?

Skriv en spek på én A4-side. Ingen tekniske valg. Bare hva.

Formiddag. Valg av verktøy. Spør Claude direkte: «Hva er enkleste vei fra null til App Store for denne typen app?» Svaret kommer på minutter: en vanlig iPhone-app uten noe bak seg i første versjon, eller et nettbasert byggeverktøy hvis det skal være en nettside. Kjør på.

Lunsj. Den første enkle skjermen kjører i en telefonsimulator på maskinen. Claude Code skriver hver linje. Du leser, godkjenner, prøver.

Ettermiddag. Hovedfunksjonen. Iterasjon på iterasjon. Du snakker med Claude, på engelsk eller norsk. Det spiller mindre rolle akkurat her. Strumse jobber på engelsk:

“Jeg vil kun snakke engelsk til kodebasen.” — Simon Souyris Strumse

Mange blander. Spek på norsk, kode-instrukser ofte engelsk fordi det er kortere. Se Flytende norsk fra Claude for hvorfor.

Kveld. Første brukbare versjon. Den er stygg. Den funker.

Dag 2: App Store-løypa

Det er her overraskelsen kommer. Selve byggingen er ikke det som tar tid lenger. Byråkratiet er.

Det tar mer tid enn dag 1. Ingen forteller deg det på forhånd.

Hva som overrasker

Hvor lite av tida som går til kode.

Det meste av kostnaden ligger andre steder: vurderinger, testing, publiseringsadministrasjon, dokumentasjon, ikon og tekst til App Store-siden.

AI tar koden. Mennesker gjør resten.

DHH har sagt det best, og han bruker AI selv:

“I’m nowhere close to the claims of having agents write 90%+ of the code, as I see some boast about online.” — David Heinemeier Hansson

Det er en ærligere linje enn markedsføringen fra Lovable og Bolt.

Det du aldri vibekoder

Cloud Security Alliance Labs skannet 1 400 vibekodede apper i 2026 og fant over 2 000 kritiske sårbarheter, mer enn 400 lekkede nøkler og 175 tilfeller av eksponert persondata, blant dem medisinske og finansielle opplysninger. AI-assistert kode shippes raskere, og sikkerhetshullene følger med.

Strumse sa det rett ut til Kode24:

“Ikke la noen som ikke vet hva de gjør, bruke vibbekoding på noe kritisk.” — Simon Souyris Strumse

Definer hva som er kritisk for deg selv før du starter. Hvis appen håndterer penger, helse, identitet, barn eller bedriftshemmeligheter, ikke vibekod den. Bygg den langsomt, eller hyr noen.

Er appen en timer, en handleliste, et internt verktøy eller en personlig vaneapp, gå hardt på i en helg.

Rickard Falcks innvending, og svaret

“Å kunne skrive kode er ikke det samme som å kunne utvikle programvare.” — Rickard Falck, Solidify

Han har rett. Programvareutvikling rommer arkitektur, testing, drift, vedlikehold og sikkerhet, altså alt som kommer etter at koden er skrevet.

Christian Hjellestad i Devora sier det enda kortere:

“KI gjør det billig å bygge programvare. Det gjør det ikke billigere å eie den.” — Christian Hjellestad

Det er sant. Det som er nytt, er at byggefasen ikke lenger er en flaskehals. Folk som aldri har bygget noe før, kan bygge sin første ekte ting.

Vibekod helgeprosjektet. Når det viser seg å være verdt å eie, hyr en utvikler eller lær håndverket selv.

Hva du kan prøve i morgen

Her er en første beskjed du kan låne:

«Jeg vil lage en liten app som [gjør én ting, f.eks. holder oversikt over vannplantene mine]. Spør meg tre spørsmål om hva jeg trenger, og foreslå så den enkleste måten å lage den på, uten at jeg må kunne programmere. Ikke start før jeg har sagt ja.»

  1. Velg et lite, ekte problem du har selv. Ikke en idé du tror folk vil ha.
  2. Skriv én A4-side med hva appen skal gjøre. Ikke hvordan.
  3. Send beskjeden over, og følg svaret.
  4. Dag 1: bygg en prototype som funker for deg selv.
  5. Dag 2: App Store-løypa. Sett av like mye tid som dag 1.
  6. Ikke vibekod betaling, identitet eller helse. Bygg det langsomt eller hyr noen.
  7. Når appen lever, be boten skrive ned det dere lærte, så neste prosjekt går lettere. Se Claude Code-oppsettet vårt.

Kilder

Vibekod det du tør miste. Bygg langsomt det du ikke tør miste.