Hvordan jeg bygde et AI-agentsystem for å kjøre sideprosjektene mine
10.06 2026, 13 minutters lesetid
TL; DR: Agentiske AI-systemer kan bygges for mange formål. Denne artikkelen handler om hvordan Fortytwos driftsdirektør Remi Vandemir bygde et agentsystem som administrerer alle sideprosjektene han ikke har tid til å administrere selv.
Lær hvordan du kan bygge noe som er virkelig nyttig, effektivt og får jobben gjort.
- Hvordan jeg bygde et AI-agentsystem for å kjøre sideprosjektene mine
- Utfordringen: for mange ideer og for lite tid
- Obsidian som den delte kunnskapsbasen for AI-agenter
- Hoveddelene av AI-sideprosjektsystemet
- Forbedreren: agenten som gjør oppdrag om til pull-forespørsler
- Hvorfor planlagt oppdragsrotasjon holder agentene nyttige
- Hopp over betingelser: lære agenten når han ikke skal åpne en PR
- Utdatalaget: gjennomgang av AI-generert arbeid som vanlige GitHub PR-er
- Djevelen: en fiendtlig AI-anmelder for planer, PR og forslag
- Hvorfor alle generative agenter trenger en anmelder som utfordrer dem
- Innovasjonskanalen: bruk av agenter for å foreslå nye produktideer
- Fra forslag til etterslep til pull-forespørsel
- Tidsplanen: kjøre agentsystemet med launchd
- Resultatene: 41 agentrunder, 14 PR-er og 28 produktideer på én uke
- Å velge riktig modell for hver type agentarbeid
- Det som overrasket meg med å kjøre autonome agenter på sideprosjekter
- Sideprosjektkirkegården min har fått nattskift
Utfordringen: for mange ideer og for lite tid
Noen måneder etter Helgeeksperimentet med dyp tankegangJeg møtte på et problem hjemme som kanskje føles kjent: for mange ideer, ikke nok timer og en ~/projects/-mappe full av gode intensjoner. Obsidian-hvelvet mitt var fullt av «neste steg»-lister jeg sjelden gikk tilbake til, og hvert prosjekt hadde nok momentum til å føles levende, men ikke nok struktur til å gå videre uten at jeg husket å presse det. Det var sytten mapper der inne, halvparten uten en commit den siste måneden eller mer, tre av dem med ekte brukere som ville legge merke til det hvis noe gikk i stykker.
Så, i løpet av noen sene kvelder, bygde jeg et personlig driftslag for sideprosjektene mine.
Den plukker opp arbeid, kjører oppdrag, åpner PR-er, skriver statusrapporter, foreslår nye ideer og fortsetter mens jeg sover. Dette er historien om hva som kjører, hva som overrasket meg og hva jeg ville endret.
Agentene kjører i et innesluttet lag, oppå infrastruktur som ble sikret først; et fundament som gjør systemet nyttig snarere enn hensynsløst, og jeg kommer tilbake til det i et eget innlegg, fordi det fortjener mer plass enn en ansvarsfraskrivelse.
Dette innlegget handler om selve byggingen min.
Obsidian som den delte kunnskapsbasen for AI-agenter
Alt starter med Obsidian-hvelvet mitt, som inneholder samme type materiale som ellers ville ligget i Notion: prosjektnotater, beslutninger, daglige logger, implementeringsdetaljer, lærdommer, grove planer og små biter av operativ visdom. Forskjellen fra Notion er at alt eksisterer som ren nedskrivning på disk, en detalj som betyr mer enn jeg visste da jeg først startet.
Markdown på disk betyr at alle agenter på maskinen min kan lese og skrive til den samme kunnskapsbasen uten autentiseringsflyter, skjemaer, tilpassede API-er eller skjøre integrasjoner. For agenter som ikke har direkte filsystemtilgang, plasserer jeg en MCP-server med verktøy som vault_search, vault_project_notes og vault_add_log foran Obsidian-hvelvet, slik at de kan få tilgang til det. Jeg la også til strømbar HTTP over Tailscale, slik at den bærbare datamaskinen, telefonen og hjemmeserveren min kan snakke med den samme hjernen.
Obsidian-hvelvet vedlikeholder seg selv gjennom kroker. Når jeg skriver noe Claude Code tolker som «Jeg lærte nettopp X», slipper en UserPromptSubmit-krok et flagg for senere opptak. Når en redigering oppretter en wiki-lenke til et notat som ikke finnes, advarer en PostToolUse-krok meg. En ukentlig miner skanner transkripsjoner og avdekker «visdomskandidater» som misforståelser, tommelfingerregler og lærdommer jeg kan fremme i den permanente kunnskapsbasen. Poenget er at hvelvet alltid er der, alltid skrivbart og kontinuerlig delt av alle deler av systemet.
Min kommandoplattform: det lokale dashbordet for agentflåten
På toppen av hvelvet bygde jeg en cockpit kalt My Command Deck. Selve appen heter Brain-portal. Det er en Next.js 16-app festet til http://brutus/brain på Tailnet-et mitt, og den er kun LAN-basert fordi jeg ikke vil ha den på det åpne internettet. Stakken er bevisst ordinær: App Router, Tailwind 4, the Fortytwo Babel designsystem og JetBrains Mono for kode.
Huben: en liveoversikt over PR-er, feil og aktive agentkjøringer
Huben er systemets hjemmeside og gir meg en rask oversikt over statusen til alt. Den varsler meg om hvilke feil som trenger oppmerksomhet, hvor mange PR-er som er åpne og hvilke deler av flåten som er inaktive. Under alt dette er det en aktivitetsfeed. En høyre skinne viser hva agentene gjør akkurat nå, en live-ticker teller oppover mens en kjøring pågår, og Cmd-K søker gjennom hele hvelvet i millisekunder.
Hoveddelene av AI-sideprosjektsystemet
Før vi går inn på detaljene, er det nyttig å dele systemet inn i hoveddelene.
Forbedreren er agenten som gjør implementeringsarbeidet. Den tar et prosjekt og et oppdrag, undersøker hva som må gjøres, lager planer, redigerer koden, kjører kontroller og åpner en PR.
Oppdragene definere hva slags arbeid forbedreren skal se etter. De hindrer systemet i å utføre samme type vedlikeholdsarbeid hver gang.
The Devil er den kontradiktoriske granskeren. Den skriver ikke kode, men gjennomgår planer, PR-er og forslag for svake antagelser, risikoer og sannsynlige feiltilstander.
Innovasjonskanalen er idégeneratoren. Den leser prosjektkontekst og nylig aktivitet, og foreslår deretter nye ting et prosjekt kan gjøre.
Timeplanen holder systemet i gang uten å være avhengig av at jeg husker det. Den kontrollerer når oppdrag kjøres, hvor ofte de kjøres og hvordan feil dukker opp.
Utdatalaget er bevisst vanlig. Arbeidet kommer tilbake som GitHub-PR-er, forslag, statusoppdateringer og morgenrapporter, slik at jeg kan gjennomgå det på samme måte som jeg gjennomgår menneskelig arbeid.
Forbedreren: agenten som gjør oppdrag om til pull-forespørsler
Forbedreren er agenten som utfører implementeringsarbeid på tvers av de aktive prosjektene. Den tar et prosjekt og et oppdrag, og kjører deretter gjennom hele løkken: oppdagelse, planlegging, testing, kritikk, utførelse og til slutt en pull-forespørsel. Oppdraget gir kjøringen sin form, slik at agenten ikke bare ser etter en mulig endring for endringens skyld, men snarere etter en bestemt type nyttig og målrettet endring.
Oppdragstypene: vedlikehold, sikkerhet, brukeropplevelse, refaktorering, funksjoner, Sentry-rettelser og avhengighetsrevisjoner
De nåværende oppdragene dekker det tilbakevendende arbeidet jeg ønsker å gjøre på tvers av prosjektene:
Hvorfor planlagt oppdragsrotasjon holder agentene nyttige
Hvert prosjekt har en ukentlig oppdragsplan der hver dag har sitt eget oppdrag:
– Vedlikehold på hverdagskvelder
– Lørdager kjører vakthold
– Søndager veksler mellom ux-polering og deps-revisjon
Rotasjonen er viktig, ettersom systemet ellers har en tendens til å drive mot den typen arbeid som er lettest å finne. Hvis hver kjøring er "vedlikehold", blir mange PR-er til slutt små testtillegg eller avhengighetsdytt. Disse kan være nyttige, men de er ikke hele bildet. Oppdragsplanen tvinger agenten til å inspisere forskjellige deler av hvert prosjekt og hindrer arbeidet i å gruppere seg rundt den samme kjente oppgaven.
Hopp over betingelser: lære agenten når han ikke skal åpne en PR
Forbedringsprogrammet har også eksplisitte hoppbetingelser for hvert oppdrag. Hvis sikkerheten kjører flere ganger på fortwo-babel og hopper hver gang, er det fortsatt nyttig informasjon, som betyr at det ikke finnes noen åpenbare sikkerhetsproblemer for det oppdraget. Jeg vil at systemet skal føle seg komfortabelt med å returnere uten en forskjell når det ikke er noen endring verdt å gjøre.
Utdatalaget: gjennomgang av AI-generert arbeid som vanlige GitHub PR-er
Resultatet fra Improver er en vanlig GitHub PR, og jeg vurderer den som alle andre PR. Omtrent 60 % av det den leverer blir slått sammen. De andre 40 % trenger enten menneskelig vurdering som agenten ikke har, eller løser et problem som ikke var verdt å løse.
Jeg leser fortsatt alle PR-er, men det tar vanligvis minutter å gjennomgå en ferdig differanse, mens det ofte tar timer å skrive den selv. Det gjør handelen nyttig selv når en betydelig andel av arbeidet blir avvist. De avviste PR-ene er en viktig del av systemet, fordi de viser hvor agentens vurdering slutter, og min begynner.
Djevelen: en fiendtlig AI-anmelder for planer, PR og forslag
Djevelen er en motstridende anmelder i flåten som jobber med å presse tilbake planer, forslag og endringer før jeg forplikter meg til dem. Den stresstester antagelser, peker på risikoer og lister opp feilmoduser jeg kanskje ikke har vurdert, og resultatet er innvendinger i stedet for kode.
Jeg bruker den på Improver-PR-er som berører noe risikabelt før jeg slår dem sammen, og også på innovasjonsforslag jeg er fristet til å godkjenne før de går inn i byggekøen, for ikke å snakke om mine egne planer når jeg skal bruke mer enn tretti minutter på noe jeg ikke har trykktestet.
Hvorfor alle generative agenter trenger en anmelder som utfordrer dem
Djevelen oppdager ofte problemer jeg ellers ville ha oppdaget senere, etter å ha brukt tid på å gå i feil retning. Noen ganger er innvendingene feil, men de er fortsatt nyttige fordi de tvinger frem bedre beslutninger. Når én aktør genererer noe, bør en annen aktør få lov til å utfordre det.
Innovasjonskanalen: bruk av agenter for å foreslå nye produktideer
Innovasjonskanalen er ansvarlig for å foreslå nytt arbeid i stedet for å fikse eksisterende problemer. Hver tolvte time kjører et «bygg noe nytt»-oppdrag på et utvalg av prosjekter. Den leser prosjektets hvelvnotat, ser på nylig aktivitet fra hjernen og skriver ett forslag som beskriver noe prosjektet kan gjøre som det ikke gjør i dag.
På dette stadiet skriver den ikke kode, den foreslår bare.
Jeg forventet at mange av forslagene skulle være åpenbare, som å skrive en README-fil, legge til en innstillingsside eller opprette en eksportknapp. Noen var enkle, men flere var mer nyttige enn jeg forventet. Et prosjekts hvelvnotat ga et forslag til et eksportformat jeg ikke hadde vurdert. Et annet foreslo et panel jeg bygde neste helg. Noen har vært sterke nok til at jeg ville ha dem i produktet med en gang.
Dette har blitt en av de mer verdifulle delene av systemet fordi det gir meg ideer fra en annen vinkel. Målet er ikke å levere funksjoner uten gjennomgang. Målet er å avdekke ideer jeg kanskje ikke genererer selv når jeg er sliten, for nær prosjektet eller fokusert på feil problem.
Fra forslag til etterslep til pull-forespørsel
Forslag lander i Brain/Innovation-forslag og vises i portalen under /innovation. Jeg leser dem med morgenkaffen og godkjenner de som er verdt å bygge på. Godkjente forslag havner i en Kanban-etterslep, og på sitt neste funksjonsoppdrag kan Forbedreren trekke det øverste elementet fra tavlen og sende det som en PR. Det gir systemet en ren vei fra idé, til etterslep, til forgrening, til gjennomgang.
Tidsplanen: kjøre agentsystemet med launchd
Alt kjører på launchd, macOS sin innebygde planlegger. Det gir meg skikkelig logging, omstart ved krasj og KeepAlive, slik at en jobb som dør midt i kjøringen kan komme tilbake uten tilpassede wrapper-skript. Kadensen er enkel: nattlig sortering, The Improver kjører med noen få timers mellomrom per aktivt prosjekt, The Innovator kjører to ganger om dagen på et valgt delsett, og digests og transkripsjonsutvinning kjøres ukentlig.
Hvordan portalen viser jobbstatus, feil og kommende kjøringer
Hver jobb er en .plist i ~/Library/LaunchAgents/, og portalen analyserer disse plistene direkte inn på Plan-siden. Derfra kan jeg se når hver jobb sist kjørte, når den vil kjøre neste gang, og hvilken som mislyktes sist. Hvis jeg kobler fra i en uke, fortsetter systemet å kjøre, og når jeg kommer tilbake, gir morgenbriefen meg en sorteringsliste i stedet for å la meg rekonstruere hva som skjedde.
Selve portalen kjører også som en launchd-jobb, og starter på nytt hvis den krasjer, med en filovervåker som oppdaterer brukergrensesnittet hver gang noe i hvelvet endres. Det holder siden aktiv uten manuelle omlastinger og gjør at systemet føles mer som en betjeningsflate enn et statisk dashbord.
Resultatene: 41 agentrunder, 14 PR-er og 28 produktideer på én uke
Forrige uke kjørte Forbedringsprogrammet 41 ganger på tvers av ni aktive prosjekter. Det åpnet 14 PR-er. Ni ble slått sammen, og fem ble stengt uten sammenslåing: fire fordi endringen ikke var verdt det, og én fordi agenten gjorde feil.
Skillet mellom sytten prosjekter og ni aktive prosjekter er bevisst. Sytten er innboksen. Ni er arbeidsmengden. Jeg peker flåten mot prosjektene der den tjener til livets opphold og lar resten være i fred med vilje.
Innovasjonskanalen foreslo 28 ideer. Jeg leste alle og merket fire som verdt å bygge på. To står i køen for forbedrere, én bygger jeg selv, og én tenker jeg fortsatt på.
Å velge riktig modell for hver type agentarbeid
Modellene er tilpasset jobben. Claude Opus håndterer vanskelig resonnement, som planlegging, tvetydige rettelser og sikkerhetsrevisjoner, Sonnet håndterer rutinemessige koderedigeringer, og Haiku håndterer raske løkker som sjekker ting med noen minutters mellomrom. Det finnes også en hard stopp som avslutter hver jobb hvis en kjøring går i spiral. Det har ikke skjedd ennå, men jeg vil heller ha den kontrollen tilgjengelig før jeg trenger den.
Det som overrasket meg med å kjøre autonome agenter på sideprosjekter
Forbedringsverktøyet fungerer omtrent slik jeg designet det til å fungere, men Innovasjonskanalen overrasket meg mest, fordi jeg forventet åpenbare forslag, men i stedet fikk ideer som ofte er bedre enn mine egne, fordi agenten ikke er forankret i det jeg tilfeldigvis tenker på.
Jeg handler bare på en håndfull av ideene den kommer opp med, men det tok meg en stund å forstå at «ingen kandidat verdt å selge» er et gyldig resultat.
Flaskehalsen for skapelse har blitt dømmekraft, tid og smak, og dette er den største lærdommen å lære når man jobber med agentsystemer. Ideer er ikke lenger en knapp ressurs, og ikke alle ideer har rett til å leve. En time med Opus som produserer ingenting er bedre enn en uke med gjennomgang av PR-er som aldri burde ha blitt åpnet. Modellen må tilpasses arbeidet, oppdraget må være snevert nok til å kunne evalueres, og agenten må få lov til å stoppe.
En agent vil gjerne generere bevegelse for alltid, og systemet fungerer bare når bevegelse ikke behandles som fremgang som standard.
Sideprosjektkirkegården min har fått nattskift
Ingen av delene i sideprosjektet mitt er bemerkelsesverdige i seg selv: det finnes et hvelv, en planlegger, en agent som velger arbeid, en kontradiktorisk vurderingsanmelder, en forslagskø og en portal for å se alt.
Det som er bemerkelsesverdig er at det kjører sideprosjektene mine uten meg, og at arbeidet kommer tilbake i en form jeg forstår: notater, forslag, PR, feil og statusrapporter.
Sideprosjekter pleide å være en gravplass for ting jeg nesten var ferdig med. Nå er de en gravplass med nattskift.