De siste årene har det blitt mulig å bygge nettsider ved hjelp av KI-verktøy. Ikke bare tekst og designforslag, men faktisk fungerende kode. Vi har gjort det selv, da vi migrerte techlab.no fra Squarespace til en fullt custom løsning.
Her er hvordan prosessen foregikk, hva som fungerte, og hva du bør vite før du starter.
Hvorfor vi forlot Squarespace
Squarespace er enkelt. Du er oppe og kjører noen timer, men det er også en lukket plattform, og etter flere år med justeringer og workarounds ble begrensningene tydelige.
Vi trengte en kunnskapsdatabase med egne artikkeltyper. Vi trengte kursstruktur. Vi ville ha full kontroll på ytelse, design og teknisk SEO, ned til schema markup, sidestruktur og lastehastighet.
Ingenting av det lot seg løse godt nok innenfor Squarespace sine rammer.
Så vi bestemte oss for å bygge fra bunnen.
Spesifikasjon først. KI etterpå.
Det er fristende å starte med å skrive en prompt. Det er feil.
Før vi åpnet et eneste KI-verktøy, laget vi et designdokument.
Hvilke sider trenger vi? Hvilke innholdstyper? Hvordan skal navigasjonen fungere? Hvilke moduler skal gjenbrukes?
Denne spesifikasjonen ble grunnmuren. Uten den hadde KI-verktøyene produsert masse retningsløs kode, teknisk funksjonell, men strukturelt kaotisk.
Lærdommen er enkel: KI er god til å generere, men du må vite hva den skal generere.
Verktøyene vi brukte
Vi testet og kombinerte flere verktøy underveis. Fordi ulike verktøy løser ulike problemer.
Codex CLI ble hovedverktøyet for dette prosjektet. Vi ville teste OpenAIs Codex 5.3-modell i praksis, og arbeidsflyten viste seg å være svært lik den vi kjenner fra Claude Code - terminalen som base, localhost spunnet opp, endringer gjort iterativt og committet i brancher etterhvert som siden tok form. Codex CLI leverte godt på avgrensede oppgaver: generere enkeltkomponenter, skrive funksjoner og foreslå løsninger på spesifikke problemer.
Claude Code dukket opp på noen få commits underveis - stort sett i situasjoner der Codex-modellen ikke traff på det vi var ute etter. Det var unntaket, ikke regelen, men det er greit å ha et verktøy i bakhånd som du vet forstår prosjektet når du trenger det.
Anti Gravity brukte vi for rask prototyping av layout og visuelle konsepter, der vi trengte å se noe visuelt raskt før vi skrev kode. Det var også her elevene fant seg mest til rette. IT-elevene fra VG2 på Polarsirkelen videregående skole omfavnet Antigravity med stort hell og var i gang allerede etter kort tid med IDE-en.
Lovable.dev testet vi som designverktøy. Det ga nyttige utgangspunkt, men ble ikke en del av sluttløsningen.
ChatGPT for Teams løste et helt annet problem. Elevene trengte også tilgang til KI-verktøy, og med ChatGPT for Teams kunne Techlab spandere et månedsabonnement på dem uten noe mer enn deres personlige e-poster. Ingen bedriftskonto, ingen komplisert oppsett. Per februar 2026 er dette den enkleste måten vi har funnet å dele et abonnement og gi alle i et team kontekstuell tilgang til den samme basiskunnskapen.
Ingen av verktøyene fungerte som en magisk knapp. De fungerte som en svært rask juniorutvikler - en som produserer forslag i høy hastighet, men som trenger deg til å vurdere, rette og ta beslutninger.
Arbeidsflyten: lokal utvikling, GitHub og Vercel
Selve utviklingen foregikk lokalt. Kode ble skrevet og testet på egen maskin. Når noe fungerte slik vi ønsket, ble det committet til et privat GitHub-repository.
Derfra tok Vercel over. Hver gang vi pusher endringer til GitHub, bygger Vercel nettsiden automatisk og publiserer den. Det eneste oppsettet som kreves er at domenet peker til Vercel via DNS.
Vercel er på gratis hobby-abonnement, ergo var det kun mine commits til GitHub som trigget bygging og publisering. En liten begrensing, men verdt å spare de kronene der.
I praksis betyr det at publisering skjer gjennom versjonskontroll. Du committer en endring, pusher til GitHub, og sekunder senere er den live. Ingen FTP. Ingen manuell opplasting. Ingen nedetid.
For de som er vant til tradisjonell webhosting, er dette et paradigmeskifte. For de som allerede jobber med moderne utvikling, er det standard.
Illustrasjonsbilde over flere plattformer, kredit Midjourney.com
Kan man gjøre dette uten å kunne kode?
Det ærlige svaret: nja.
KI gjør det mulig å “skrive” kode uten å skrive selv. Du kan beskrive en komponent eller funksjon i naturlig språk og få fungerende kode tilbake. Det senker terskelen dramatisk. Det er spesielt gunstig for folk som meg, som vet hva man vil ha, men ikke hvordan man gjør det.
Men du må forstå hva du ser på. Du må kunne lese HTML-struktur, gjenkjenne når CSS gir uventede resultater, og vite når en løsning er skjør. Du må kunne tenke akriktetur.
Du trenger ikke skrive all koden, men du må kunne vurdere den.
Forskjellen fra før er at veien fra idé til fungerende prordukt er mye kortere. Med riktig spesifikasjon og vilje til å lære underveis, kan du komme langt uten formell utviklerbakgrunn.
Men «uten å kunne kode» og «uten å forstå kode» er to forskjellige ting.
Læring i praksis: brancher og parallelt arbeid
En del av prosessen som ga uventet verdi, var at vi involverte elever på utplassering.
Vi jobbet i samme GitHub-repository, men på separate brancher. Det betyr at flere personer kunne teste løsninger parallelt uten å påvirke hverandres arbeid. Når en branch var klar, ble den merget inn i hovedprosjektet.
For elevene var dette en inngang til hvordan reell utvikling fungerer, versjonskontroll, code review, iterasjon. Ikke teori, men praksis på et levende prosjekt.
For oss var det en måte å teste ideer raskere og få perspektiv fra folk som ser løsninger med friske øyne.
Så, kan du bygge en nettside med KI?
Ja. Men ikke ved å skrive «lag en nettside» og vente.
Det krever en tydelig spesifikasjon. Det krever forståelse for struktur. Det krever en arbeidsflyt som inkluderer versjonskontroll og automatisert publisering. Og det krever at du tar ansvar for kvaliteten på det som genereres.
KI erstatter ikke tenkning eller kreativt artbeid, det akselererer den.
Brukt riktig kan det redusere utviklingstiden fra måneder til uker, og gi deg full kontroll over design, funksjonalitet og ytelse, uten å være avhengig av en lukket plattform.