Min metode

Jeg bruker AI aktivt, men ikke som en knapp som lager ferdige nettsteder. Prosjektene utvikles gjennom en kontrollert arbeidsflyt der idé, brukerbehov, datagrunnlag, innhold, kode og kvalitet vurderes i flere omganger.

Idé og vurdering
PRD og kildearbeid
Utvikling
Uavhengig kontroll
Deploy
Måling og forbedring

Fra idé til prosjekt

En idé blir ikke automatisk et prosjekt. De fleste innfall stopper på notatstadiet, og det er meningen. Før jeg setter i gang går jeg gjennom en del spørsmål som skal avgjøre om prosjektet er verdt tiden.

Om noen faktisk har et problem eller spørsmål siden kan løse
Om prosjektet tilfører noe mer enn generisk innhold
Tilgjengelige og pålitelige datakilder
Konkurranse og realistisk mulighet til å bli synlig
Hvor mye vedlikehold prosjektet vil kreve
Sesongvariasjoner gjennom året
Mulige inntektsmodeller
Om prosjektet kan være nyttig selv før det tjener penger
Om idéen bør gjennomføres, utsettes eller forkastes

Her bruker jeg ChatGPT som en streng sparringspartner. Oppgaven er å lete etter svakheter og gode grunner til å la være — ikke å bekrefte at idéen er lur. Det er lettere å droppe et prosjekt før det er bygget enn etterpå.

PRD og prosjektteam i flere roller

Større prosjekter starter med en grundig PRD — et kravdokument som beskriver hva siden skal gjøre, for hvem, med hvilke data og hvilke krav. Jeg jobber meg gjennom dokumentet fra flere roller for å se prosjektet fra ulike vinkler:

ProduktansvarligBruker og målgruppeUX- og webdesignerUtvikler og teknisk arkitektSEO- og innholdsansvarligData- og kildeansvarligPersonvern og kvalitetssikringKommersiell og affiliate-ansvarligKritisk motstemme

Poenget er ikke å leke prosjektgruppe, men å avdekke hull mens de fortsatt er billige å tette. En SEO-innvending, et personvernspørsmål eller en manglende datakilde er mye enklere å håndtere før kodingen starter.

Interne arbeidsdokumenter

Over tid har jeg utviklet et sett med interne sjekklister, standarder og arbeidsmodeller som går igjen på tvers av prosjektene. Et utvalg:

Claude-prosjektteam og kvalitetssikring
Felles PRD-sjekkliste
Sjekkliste for nye webprosjekter
Standard for metadata, SEO og AI-søk
Testmodell for evergreen-verktøy
Prosjektportefølje og årshjul
Masterprompt for affiliate- og AI-prosjekter
Oppstarts- og prosjektguide
Idébank for webdesign

Dokumentene er interne arbeidsverktøy og ligger ikke ute for nedlasting. De blir oppdatert når et nytt prosjekt avdekker en svakhet eller en bedre måte å gjøre noe på — det er som regel der de største forbedringene kommer fra.

Prosjektene lærer av hverandre

Prosjektene utvikles ikke helt isolert. En QA-modell som viser seg å fungere ett sted blir gjerne tatt i bruk i de neste, og det samme gjelder sesonglogikk, datamodeller, metadataarbeid og måten kilder håndteres på. Det er erfaringene og arbeidsmåtene som gjenbrukes — design og innhold skal fortsatt tilpasses hvert enkelt prosjekt og målgruppen det er laget for.

Koding med Claude Code

Til selve kodingen bruker jeg Claude Code og de modellene som til enhver tid fungerer best for prosjektet. Modellene og verktøyene utvikler seg raskt, så arbeidsmåten er viktigere enn navnet på én bestemt modell.

Hver oppgave gis med:

Avgrensede oppgaver, ikke «bygg hele siden»
Eksisterende prosjektkontekst
Klare akseptansekriterier
Krav om tester og verifisering
Instruks om å bevare eksisterende funksjonalitet
Krav om rapport etter utført arbeid

Kontrollsløyfen

Dette er kjernen i arbeidsflyten. I stedet for å la ett verktøy både foreslå, utføre og godkjenne arbeidet, går hver endring gjennom en runde med uavhengig vurdering:

1Jeg utformer oppgaven sammen med ChatGPT og vurderer konsekvensene av den.
2Oppgaven gis til Claude Code inne i prosjektet.
3Claude leser kodebasen, gjennomfører arbeidet og kjører tester.
4Rapporten og resultatene kopieres tilbake til ChatGPT.
5ChatGPT brukes til kritisk vurdering, oppfølgingsspørsmål og neste kontrollerte kommando.
6Jeg vurderer visuelt og funksjonelt om resultatet faktisk er godt nok.
7Endringen deployes først når testene og den manuelle kontrollen er tilfredsstillende.

Rundgangen er bevisst. En modell som vurderer sitt eget arbeid har en tendens til å være fornøyd for tidlig, og da er det jeg som sitter igjen med feilen i produksjon.

Testing og kvalitetssikring

At «build gikk grønt» betyr bare at koden kompilerer. Det sier ingenting om siden faktisk er riktig, lesbar eller nyttig. Typiske kontroller før noe regnes som ferdig:

Lint og TypeScript
Automatiserte tester
Produksjonsbuild
Serverrendret HTML
Lenker og omdirigeringer
Canonical, metadata, sitemap og robots
Strukturert data
Mobil og desktop
Tilgjengelighet og kontrast
Lastetid og scroll-ytelse
Datakilder og faktagrunnlag
At eksisterende funksjoner ikke ble endret ved et uhell
Live-QA etter deploy

Teknisk oppsett

Verktøykassen er bevisst liten. Færre bevegelige deler gir mindre å vedlikeholde:

Domeneshop: Domener
GitHub: Versjonskontroll og kodehistorikk
Vercel: Bygging og publisering
Google Search Console: Indeksering og søkesynlighet
Bing Webmaster Tools: Supplerende søkedata
IndexNow: Varsling om nye og endrede sider
Google Analytics: Bruksmønstre og trafikk
Claude Code: Utvikling
ChatGPT: Research, planlegging, utfordring og validering

Google Search Console er hovedverktøyet mitt for å følge indeksering og synlighet i Google. Bing Webmaster Tools brukes som et supplement på prosjekter som registreres der, og gir et litt annet perspektiv på hvordan sidene oppfattes. IndexNow kan varsle støttede søkemotorer når sider opprettes, oppdateres eller fjernes, slik at endringer kan fanges opp raskere.

Raskere varsling er ikke det samme som indeksering. IndexNow garanterer verken at en side blir tatt inn eller hvordan den rangeres — det er et signal, ikke en snarvei. Verktøyene her brukes til kontroll og måling, ikke som erstatning for godt innhold og solid teknisk kvalitet.

Etter lansering

Et nettsted er ikke ferdig når det publiseres — det er da man først får vite om det virker. Arbeidet fortsetter med:

Data fra Google Search Console
Faktiske søk brukerne finner siden gjennom
Feil og døde lenker
Nye datakilder
Sesongstyrt innhold
Oppdatering av metadata og innhold
Forbedringer basert på reell bruk
Fjerning eller nedprioritering av ting som ikke virker
Kontroll av om prosjektet fortsatt gir reell nytte

Hva AI ikke bestemmer

AI kan foreslå, analysere, skrive og kode, men bestemmer ikke alene hvilke prosjekter jeg starter, hvilke kilder jeg stoler på, eller når noe er godt nok til å publiseres. Det ansvaret ligger hos meg.

Jeg velger retning og prioritering
Påstander og datakilder må kunne kontrolleres
Dårlige forslag blir forkastet
Ikke alle idéer blir bygget
Brukerverdi prioriteres foran ren publiseringsmengde

Utfordringer jeg prøver å unngå

AI-assistert utvikling har noen tydelige svakheter. De forsvinner ikke av seg selv, så dette er tingene jeg må jobbe aktivt imot:

Generisk malpreg

Moderne rammeverk, designsystemer og AI-verktøy gjør det lett å lage ryddige sider — og like lett å ende opp med nettsteder som ser nesten like ut. Tailwind er et effektivt verktøy, men kombinasjonen av standardkomponenter, store gradientoverskrifter, mange avrundede kort, blur-effekter og den samme typografiske oppskriften kan gjøre at ulike nettsteder får et generisk malpreg. Målet mitt er porteføljekonsistens uten at alle prosjektene blir like: samme kvalitetsstandard overalt, men et visuelt uttrykk som passer temaet, innholdet og brukerne. Ikke forskjeller for forskjellenes skyld, og ikke et nytt tungt designsystem for hver lille side.

Generisk AI-innhold

AI kan raskt produsere tekst som høres helt korrekt ut, men som kunne stått på nesten hvilket som helst nettsted. Problemet er ikke at teksten er AI-generert, men at den er generisk. Det som faktisk tilfører verdi er egne beregninger, lokale eller strukturerte data, praktiske verktøy, bedre svarstruktur, ordentlig kildearbeid og at reelle spørsmål dekkes komplett — pluss min egen vurdering av hva som er viktig.

Påstander som ikke er kontrollert

Språkmodeller formulerer gjerne usikre eller feilaktige svar med stor selvsikkerhet. Derfor må kilder kunne spores, og tall, regler og produktopplysninger kontrolleres. Informasjon som endrer seg trenger en oppdateringsplan, og der data mangler eller er usikre, er det bedre å si det tydelig enn å fylle hullet med noe som høres rimelig ut.

For store endringer på én gang

«Forbedre alt»-oppgaver er vanskelige å kontrollere og lette å angre på. Små, avgrensede endringer med tydelige akseptansekriterier er enklere å vurdere, og eksisterende funksjonalitet må vernes underveis. Baseline og regresjonstester reduserer risikoen — en grønn build alene betyr bare at koden kompilerer.

Kvalitet som ikke synes

En side kan se helt riktig ut og likevel ha feil i canonical, metadata, sitemap, robots, strukturert data, mobilvisning, tilgjengelighet, lenker og redirects, serverrendret HTML eller laste- og scroll-ytelse. Ingenting av dette oppdages ved å se på skjermen, så det trengs både automatiserte sjekker og manuell kontroll.

Å bygge mer enn brukeren trenger

Flere funksjoner og mer innhold gir ikke automatisk et bedre nettsted. Alt som bygges må vedlikeholdes, og hver ekstra funksjon øker kompleksiteten. Funksjoner uten dokumentert brukerbehov er lett å legge til og vanskelig å bli kvitt — kjernen bør være ordentlig på plass først.

Å holde data og innhold oppdatert

Prosjektene har svært ulike datatyper: åpningstider, lover og regler, priser, vær- og miljødata, navnedata, kalenderdata, sesonginnhold og kommersielle opplysninger som affiliate-lenker. Hvert prosjekt trenger derfor en realistisk modell for hvor data kommer fra, når de sist ble kontrollert og hvem som vedlikeholder dem.

Å vite når man skal stoppe

Ikke alle idéer bør bygges, og ikke alle eksisterende prosjekter fortjener like mye videre arbeid. Et prosjekt kan settes på pause, en funksjon kan forkastes, og noe som ikke gir nok bruker- eller læringsverdi kan prioriteres ned. Ferdigstilt og stabil drift er ofte et bedre mål enn stadig utvidelse.

Metoden utvikler seg

Dette er ikke et låst system. Verktøyene endrer seg raskt, og metoden blir derfor aldri helt ferdig. Det som består, er kravet om tydelig formål, gode kilder, kontrollerte endringer og en kritisk gjennomgang før noe publiseres.

Se prosjektene