demo.godig.no · bak kulissene

Denne demoen ble planlagt og bygget på under 3 timer.

Av AI-agenter — med menneskelig regi og kvalitetskontroll. Alt på denne siden er ekte kvitteringer fra byggingen, logget mens det skjedde. Ingenting er rekonstruert i etterkant. Og ser det enkelt ut, er det fordi grunnarbeidet ble gjort først — den delen er faget.

10 commits · 1 dag · første 2026-08-31 kl. 11:51 · målt fra bestillingen kl. 10:45 til fase 4 var verifisert — se making-of/LOGG.md i repoet

1Bestillingen

«Ikke en nettside OM det vi gjør — men et stykke SIMULERT PROGRAMVARE besøkende kan klikke seg gjennom.»

utdrag av den faktiske prompten →

Vi skal lage en klikkbar demo-løsning på et underdomene. Ikke en
nettside OM det vi gjør — men et stykke SIMULERT PROGRAMVARE
besøkende kan klikke seg gjennom [...]

Din jobb NÅ er å planlegge. Ingen kode i denne fasen.

STEG 1 — KONSEPTVALG (stopp og vent på meg): foreslå 2–3
scenariokandidater. Krav: smerten må være umiddelbart gjenkjennbar
for en norsk SMB-leder og IKKE noe standardsystemene alt løser.
Det må finnes 2–3 tydelige "agentøyeblikk" der besøkende SER
agenten gjøre noe et menneske ellers ville brukt timer på. [...]

STEG 2 — FULL PLAN (etter mitt valg): fiktiv virksomhet og
merkevare · regi og brukerreise med fullt manus som tidslinje ·
troverdig demodata · teknisk plan · byggefaser med sjekkpunkt i
nettleser etter hver · VIKTIG: råstoffet til "Slik ble denne laget"
samles FORTLØPENDE — historien kan ikke rekonstrueres troverdig i
etterkant. [...]

Kvalitetslinje: hver gang du står mellom "imponerende" og
"forståelig", velg forståelig.

2Arbeidsmåten

AI-agenter — Claude Code, én av flere vi bruker sammen med GitHub Copilot m.fl. — fikk bestillingen, utforsket nettsiden vår med underagenter, la frem tre scenariokandidater og skrev en full plan. Så ble appen bygget i fire faser, med sjekkpunkt i nettleser etter hver.

Grunnarbeidet — bygget før én linje app-kode

En plan på 451 linjer — godkjent før første kodelinje

Fullt manus i tre akter med gates («demoen venter alltid på besøkende»), fiktiv virksomhet med egen merkevare, hendelsesarkitektur der én logg driver UI, toasts og teknisk panel, mobilstrategi og fire faser med definerte sjekkpunkter.

Arbeidsregler agentene ikke kan fravike (CLAUDE.md)

Kvalitetslinjen, regi-reglene, hydrerings- og tilgjengelighetskrav — og dokumentasjonsdisiplinen: hver økt logges FØR den starter. Ingen commit uten grønn typesjekk.

Deterministisk demodata med fasit

16 håndskrevne saker der tallene går opp mot manuset: 14 åpne, 6,8 mill. samlet, nøyaktig 3 som utløper denne uken og 4 som har vært stille i over 10 dager — med datoer som alltid er ferske relativt til i dag.

En verifiseringsrigg som spiller demoen selv

Playwright kjører HELE det guidede løpet i ekte nettleser etter hver fase — gates, redigering, godkjenning, analytics-trakten, mobil på 375px — og tar opp video som kvittering.

Hvorfor er promptene så korte?

Fordi regien var bygget først. Når planen definerer fasen, kvalitetslinjen og sjekkpunktet, trenger neste ordre bare være én linje. Det er ikke promptene som er håndverket — det er grunnlaget som gjør dem mulige:

«Kjør fase 2» — pluss to beslutninger: opptaksform, og at Claude Code omtales som én av flere agenter (GitHub Copilot m.fl.).

Utløste: Gjennomspillingen: motoren kopiert fra godig.no med tre planlagte avkoblinger, hendelsesloggen som sannhet, manuset med 6 steg og 4 gate-typer, tidshopp, Teams-kortet, fokusstyring og aria-live — og full nettleserverifisering med videoopptak.

«Gjennomfør fase 3» — hele prompten. Fasen var definert i planen med sjekkpunkt.

Utløste: «Bak panelet» (samme hendelseslogg rendret rått — kan ikke komme i utakt), utgangsskjermen med tall telt fra loggen, arkitekturdiagram, og denne siden — med stats generert fra git.

«Fase 4 go» — og agenten visste hva polish betydde, fordi planen sa det.

Utløste: Regi-finpuss på tidsstempler (nattens kjøring 06:00), mobil verifisert på 375px, fokusfeller, Lighthouse kjørt mot prod-bygget — kontrastfunn fikset og re-målt til 100.

Mennesket sto for retning og kvalitet — agentene for volumet:

Mennesket

Skrev bestillingen som kravspek: scenariokrav, agentøyeblikk, dokumentasjonsdisiplin og kvalitetslinje
Valgte scenario blant tre kandidater — og godkjente planen før én linje kode
Definerte fasene med sjekkpunkter i nettleser — derfor kunne neste ordre være én linje
Kvalitetssjekket underveis og meldte funn (bl.a. en kontrastfeil agenten fikset på minutter)
Styrte fortellingen: opptaksform, verktøyomtale, ærlighetsnivå

Agentene

Utforsket godig.no-repoet med underagenter (stack, simulator-motor, merkevare)
Skrev PLAN.md: fiktiv virksomhet, manus i tre akter, teknisk arkitektur
Bygde appen i faser — og committet med beskrivende meldinger
Verifiserte selv hele gjennomspillingen i nettleser (Playwright) med videoopptak
Fant og fikset en ekte feil verifiseringen avdekket — dokumentert uredigert

Agenten verifiserte selv — opptaket

Etter fase 2 spilte agenten HELE det guidede løpet i en ekte nettleser (Playwright) og tok opp kjøringen. Dette er opptaket — uklippet:

OK anslag
OK akt1 brief + gate
OK akt2 utkast klart
OK e-post redigert og sendt
OK akt2 sendt + tidslinje oppdatert
OK akt3 kalkyle + gate
OK Teams-godkjenning besvart
OK akt3 vunnet
OK fri utforsking
OK reset → anslaget igjen
ALT GRØNT

Én ekte feil, uredigert

Verifiseringen avdekket en feil agenten selv hadde laget — og fikset. Ærlighet er hele poenget:

locator.waitFor: Timeout 45000ms exceeded.
  waiting for getByRole('button', { name: 'Fortsett →' })
→ Årsak: effekten som skulle gå videre etter godkjenningen satte
  status og timeout i SAMME effekt — re-kjøringen ryddet bort sin
  egen timeout.
→ Fiks: delt i to effekter (Scenario.tsx). Re-kjørt: ALT GRØNT.

I dette demo-prosjektet var ingen MCP-servere koblet til — verktøykallene under er de faktiske kallene fra byggeøkten. Når vi bygger ekte løsninger, kobler samme arbeidsform seg til Dataverse og Power Platform via MCP.

3Resultatet

Demoen du nettopp klikket deg gjennom. Commit-loggen er tidslinjen — generert fra git, ikke skrevet for hånd:

2026-08-31 11:51Plan og dokumentasjonsdisiplin: PLAN.md, CLAUDE.md, making-of/
2026-08-31 11:51Fase 1: prosjektskall og konfig (Next 15 + Tailwind v4, Azure SWA)
2026-08-31 11:51Fase 1: Radar-designsystem, demodata og fagsystem-UI
2026-08-31 12:17Fase 2: hendelsesarkitektur, manus og simulator-motor
2026-08-31 12:17Fase 2: gjennomspillingen — anslag, GuideRail, gates og Teams-kort
2026-08-31 12:17Making-of: fase 2-sjekkpunkt (video, skjermbilder, øktutdrag, logg)
2026-08-31 12:37Fase 3: Bak panelet og utgangsskjermen
2026-08-31 12:37Fase 3: «Slik ble denne laget» med ekte kvitteringer
2026-08-31 12:37Making-of: fase 3-sjekkpunkt (skjermbilder, logg, ferske git-stats)
2026-08-31 12:54Fase 4: regi-tidsstempler, mobilpolish, a11y og ytelse

Agentene du nettopp så i appen, og måten appen ble bygget på, er samme filosofi: AI gjør grovarbeidet — mennesker står for retning og kvalitet.

For IT-lederen: verktøykjeden

Claude Code — én av flere AI-agenter vi bruker (GitHub Copilot m.fl.)
Underagenter for utforsking og teknisk planlegging
Next.js 15 + Tailwind v4 + TypeScript (statisk eksport til Azure Static Web Apps)
Playwright-verifisering i nettleser, med video som kvittering
git som tidslinje — hver fase er commits du kan ettergå
I ekte leveranser: samme arbeidsform koblet til MCP-servere (bl.a. Dataverse MCP) og pac code push

Dette er måten vi ville bygget for dere — book en prat →← Tilbake til demoen