Jeg trengte en ny artikkelside til Din Plattform.
Ikke bare en liste med innlegg i kronologisk rekkefølge. En skikkelig side — med en hero-seksjon for de viktigste artiklene, et rutenett for resten, kanskje en kompakt liste helt nederst. Og et skjema et sted i midten for å fange opp nyhetsbrevabonnenter.
Problemet var at jeg visste nøyaktig hvordan det pleier å ende. Samme artikkel dukker opp i tre seksjoner. Eller så må man bruke timer på å manuelt fjerne duplikater hver gang man publiserer noe nytt.
Jeg ville ha blokker som snakket med hverandre. Som visste hva de andre allerede hadde vist.
Dette er historien om hvordan jeg bygde det — på én arbeidsdag.
Forberedelsen som gjorde forskjellen
Jeg har lært at kodeprosjekter sjelden feiler på grunn av koden. De feiler fordi man ikke vet hva man bygger.
Så før vi skrev noe skikkelig kode forklarte jeg for Claude Code hva jeg ville oppnå — og at jeg først ville ha en avskaltet HTML-mockup. Ingen PHP, ingen WordPress, bare ren markup som viste strukturen.
Etter et par revisjoner hadde vi en HTML-fil som fungerte som kart. Hvordan skulle hero-seksjonen se ut? Hvilke elementer trengte den? Hvordan skulle gridet oppføre seg? Hvor skulle skjemaet plasseres? Alt var der, og vi var enige om retningen før vi begynte å bygge på ordentlig.
Så fant jeg noe som viste seg å være avgjørende: Blockstudio har en fil som heter blockstudio-llm.txt. Det er en tekstfil som beskriver nøyaktig hvordan blokker skal struktureres — hvilke attributter som finnes, hvordan block.json skal se ut, hvordan PHP-renderingen fungerer.
Filen er laget for å deles med AI-verktøy. Tanken er at du gir den til en LLM sammen med oppgaven din, og AI-en genererer kode som faktisk følger riktig mønster.
Det høres ut som en liten ting. Men det er forskjellen mellom å få ut kode som fungerer med en gang og å bruke timer på å rette strukturfeil.
Dagen: Fra mockup til ferdige blokker
Jeg brukte Claude Code som arbeidspartner.
Morgenen startet med Blog Featured — hero-blokken. Jeg ga Claude min HTML-mockup, Blockstudios LLM-fil, og en beskrivelse av hva blokken skulle gjøre. Håndplukkede artikler hvis man ville. Automatisk fylt hvis man ikke valgte noe. Tre artikler totalt, én stor og to små.
Første versjon fungerte. Nesten. Bildene skalerte ikke riktig. Kategori-etiketten havnet på feil sted. Småting som tok ti minutter å fikse.
Så kom den første skikkelige utfordringen.
WordPress rendrer blokker to ganger gjennom sitt content-filter. Det er en quirk som de fleste aldri merker. Men når du bygger blokker som holder styr på tilstand — som «hvilke artikler har allerede blitt vist» — blir det et problem.
Første rendering: Featured viser artikkel 1, 2, 3. Markerer dem som vist. Andre rendering: Grid skal ekskludere 1, 2, 3, men listen er allerede «brukt opp».
Løsningen var render-caching. Hver blokk cacher resultatet sitt første gang den rendres. Andre gang returnerer den bare cachen. Ikke rocket science, men det tok et par timer å forstå problemet og implementere løsningen.
Lunsj.
Ettermiddagen var glattere. Blog Grid fungerte på første forsøk — ekskluderingslogikken var allerede på plass. Blog Horizontal List var en variant av samme tema. Blog CTA Minikurs var mest styling.
Mellom hver blokk: review. Hva skjer hvis det ikke finnes nok artikler? Hva skjer hvis noen håndplukker en artikkel som er slettet? Hva skjer hvis man blander kategorifilter med håndplukkede artikler?
Edge cases. Det er der bugs bor.
Ved firetiden hadde jeg fire fungerende blokker og en hjelpefunksjonsfil som holdt alt sammen.
Hva jeg lærte
LLM-filen var avgjørende. Uten den hadde vi sittet fast i strukturspørsmål. Hvordan skal attributter defineres? Hvor skal renderingslogikken ligge? Med filen på plass genererte Claude kode som passet inn med en gang. Jeg slapp å oversette mellom «hvordan Claude tror Blockstudio fungerer» og «hvordan det faktisk fungerer».
Mockup-first sparer tid. Det føles som en omvei å begynne med en HTML-mockup. Men det tvinger deg til å tenke gjennom strukturen før du skriver kode. Og det gir AI-en noe konkret å ta utgangspunkt i — ikke bare en vag beskrivelse. Å la Claude Code generere mockupen først gjør at dere er enige om hva som skal bygges før dere begynner.
Review mellom hvert steg fanger problemer tidlig. Jeg kunne ha bygget alle fire blokkene og så testet. Men da hadde dobbeltrenderings-problemet dukket opp på slutten, når alt var koblet sammen og vanskeligere å debugge.
Dokumentasjon etterpå er verdt bryet. Jeg skrev en komplett dokumentasjon av hele systemet samme kveld. Hvordan hver blokk fungerer. Hvilke hjelpefunksjoner som finnes. Vanlige problemer og løsninger. Det tok en time. Men neste gang jeg ser på denne koden — om tre måneder, om et år — kommer jeg til å takke meg selv.
Hva jeg ville gjort annerledes
Hvis jeg bygde dette på nytt ville jeg startet med hjelpefunksjonene. Ekskluderingslogikken, post-trackingen, render-cachingen. Få det på plass først, så bygge blokkene oppå.
Jeg ville også testet dobbeltrendering tidligere. Det var den eneste skikkelige bremsen i løpet av dagen — og den kunne jeg ha oppdaget med en enkel test før jeg i det hele tatt begynte på den andre blokken.
Men det er lett å si i etterkant.
Dette er starten på noe større
Fire blokker er ikke revolusjonerende. Det er en løsning på et spesifikt problem.
Men prosessen — mockup først, LLM-fil som kontekst, blokk for blokk med review imellom — den er gjenbrukbar. Neste gang jeg trenger å bygge noe i WordPress vet jeg hvordan jeg tar meg fra idé til implementasjon på én dag i stedet for en uke.
Blokkene ligger nå live på Din Plattform. Du kan se resultatet på artikkelsiden.
Jeg kommer tilbake med hvordan det fungerer i praksis etter at jeg har brukt dem en stund. Det er én ting å bygge noe. En annen å leve med det.
