Det startet med en irritasjon. Substack Notes – deres variant av kortformat, omtrent som Twitter – har ingen planlegging. Du skriver, du poster, det publiseres med en gang. Vil du være konsekvent med Notes må du sitte ved datamaskinen hver eneste gang.
Jeg kjører innholdssystemet mitt fra WordPress. Alt annet blir planlagt og tidsstyrt derfra. At Notes skulle være unntaket føltes unødvendig.
Så jeg bygde et plugin som løser det.
Hva pluginet gjør
Det er enklere enn det høres ut. En egen innholdstype i WordPress for Notes – korte tekster med dato og tid. Når klokken slår publiserer pluginet automatisk til Substack.
Det krevende var at Substack ikke har noe offentlig API. Ingen offisiell måte å automatisere Notes på overhodet. Pluginet måtte reverse-engineere de interne API-endepunktene deres, autentisere via sessions-cookies og oversette WordPress-innhold til Substacks eget dokumentformat. Alt i ren PHP, ingen eksterne avhengigheter.
Jeg la til et par ting som gjør det praktisk å faktisk bruke: kryptert lagring av innloggingsdetaljer, en dashboard-widget som viser hva som er i kø og hva som er publisert, og en selvhelbredende cron-mekanisme som sørger for at Notes faktisk går ut selv på sider med lite trafikk. Om sesjonen mot Substack utløper, pauser systemet seg selv og sender en e-post i stedet for å feile stille.
Hvordan det ble bygd – og hvorfor det er interessant
Hele pluginet ble bygd i en eneste Claude Code-økt. Ikke gjennom en prompt som spyttet ut et ferdig plugin, men gjennom en iterativ prosess. Bygge, teste på en lokal WordPress-installasjon, støte på et problem, beskrive hva som skjedde, få en fix, teste igjen.
Seks reelle feil dukket opp underveis. WordPress sine saniterings-funksjoner som stille ødela Substacks sessions-cookie. Et API-endepunkt som ikke eksisterte – Claude Code måtte gå og lese kildekoden til et npm-bibliotek på GitHub for å finne riktig kall. En hook-prioritetskonflikt som gjorde at innholdstypen aldri ble registrert. Tidssoneproblemer. WP Cron som ikke trigges uten trafikk.
Hver feil var reell, ikke hypotetisk. Og det var i feilsøkingen – ikke i kodegenereringen – at samarbeidet med AI-en faktisk ble testet.
Dette er mønsteret jeg ser mer og mer i arbeidet mitt med Claude Code: AI-en er rask på å generere struktur og refaktorere. Men de vanskelige problemene krever kontekst som bare finnes på skjermen min. Jeg må beskrive hva jeg ser. AI-en må resonnere om årsaker den ikke kan observere direkte.
Koblingen til Freymwork
Jeg skrev en fullstendig artikkel om pluginet på Freymwork – den tekniske prosessen, alle seks feilene, og hva det sier om å bygge verktøy med AI. Den teksten retter seg mot et engelskspråklig publikum som bygger lignende ting.
Dette innlegget handler mer om prosessen bak. Om å gå fra «dette irriterer meg» til et fungerende verktøy på en økt. Og om hvordan grensen mellom å bruke AI og å bygge med AI begynner å bli stadig mer utydelig.
Pluginet er ikke noe jeg legger ut på WordPress-pluginkatalogen – det bygger på Substacks interne API som kan endres uten varsel. Men som personlig verktøy gjør det akkurat det jeg trenger. Notes-ene mine blir planlagt fra samme sted som alt annet innhold.
Noen ganger er den beste måten å forstå et verktøy på å bygge noe med det som løser et virkelig problem. Ikke en demo. Ikke en tutorial. Noe du faktisk har tenkt å bruke i morgen.
