Jag testade någon annans verktyg i stället för att bygga vidare på mitt eget

I min tidigare artikel skrev jag att Norns Companion löste överblicken av mina agenter, men att tröttheten satt kvar i besluten, i code review och i växlingen mellan sessioner. Det naturliga nästa steget hade varit att bygga vidare på Companion och lägga ner ännu fler timmar i jakt på en lösning.

I stället installerade jag Herdr i slutet av september och har kört det bredvid mitt eget verktyg sedan dess. Det hela slutade med att jag skapade ett eget plugin, en pull request till någon annans plugin och en del funderingar kring vad jag egentligen letar efter i ett verktyg.

Varför testa något annat när mitt eget fungerar?

Herdr är en terminal multiplexer som påstås brygga kommunikationen mellan dig och agenterna. Den har workspaces, tabbar och paneler som tmux, och en sidopanel som visar vad varje agent gör: arbetar, väntar på input, är klar eller står still. Sessionerna överlever att jag stänger terminalen eller startar om datorn.

Min vardag är väldigt ofta Drupal-webbplatser som körs i ddev, LazyVim i Ghostty och zsh, med en Mac som daily driver och en Linux-burk över Tailscale för egen utveckling och lokal AI. Innan Herdr körde jag tmux och Norns Companion, en egen app som fungerar genom att hålla koll på sessionerna och har styrning av ddev inbyggt.

Halvvägs in i testet kunde jag sätta ord på vad jag faktiskt förväntade mig. Jag vill se vilken agent som väntar på mig och vart min uppmärksamhet ska ta vägen. Det var samma behov som fick mig att bygga Companion. Ett eget verktyg är också mitt att underhålla, och jag ville se om något som fler använder kunde ta över den biten och hålla en hel dag med flera agenter och miljöer.

Herdr på ett svenskt tangentbord

Första utmaningen var tangentbordet. Herdr har ctrl+b som prefix, precis som tmux, och jag bytte det mot §. På ett svenskt tangentbord sitter § uppe till vänster och används inte till något annat, så det blir ett tryck i stället för en kombination, och Neovim får tillbaka ctrl+b för att bläddra uppåt. Idén kom från Dataluminas guide om Herdr.

Alla genvägar som bygger på Alt fick strykas. Med Option som Alt på Macen kan jag inte längre skriva @, [, ], { och } med svensk layout, och det är tecken jag skriver hela dagen. ctrl+h/j/k/l flyttar mellan både Neovim-splits och Herdr-paneler, som jag är van vid från tmux. Detta gör att ctrl+l, ctrl+k och ctrl+j inte längre når fram till Claude.

Notiserna gick först via systemet, och på macOS betyder det via AppleScript. Att klicka på en notis öppnade ett tomt dokument i Script Editor, så jag lät Ghostty leverera dem i stället. Konfigurationen ligger i mina dotfiles med en symlänk, som allt annat, och Herdrs egen inställningsvy skriver igenom symlänken utan problem.

Det som gjorde mest intryck i vardagen var återställningen. När jag uppdaterade till Golden Gate och fick starta om datorn kom inte bara panelerna tillbaka, Herdr startade också upp Claudes senaste session i varje panel. Companion återställer sessionerna, men den startar inte Claude där jag var.

Läs pluginet innan du installerar det

Herdr har en marknadsplats för plugins, och flera av dem kopplar in sig i Claude Code. Ett sådant är herdr-agent-progress, som visar hur långt varje agent har kommit direkt i sidopanelen, till exempel ~65% · Testing changes. Det är agenten själv som rapporterar, via hooks i Claude Code, och det betyder att pluginet kör kod vid varje steg agenten tar.

Så innan jag installerade det lät jag som vanligt Claude läsa hela koden innan även jag läste in mig på vad den gör. Det var ungefär 2 100 rader Rust med tio vanliga crates, ingen nätverkskod alls, tre hooks och försiktiga, atomiska skrivningar till konfigurationen. Det fanns ändå saker att veta. Pluginet vägrar läsa en konfiguration som är en symlänk, vilket är en säkerhetsfunktion som krockar med dotfiles, så jag fick ange sökvägen explicit. Varje uppgift kostar några tokens extra, och när pluginet uppgraderas tappar de sessioner som redan kör sin koppling, så varje Claude-session behöver återupptas manuellt efteråt.

Andra plugins passade inte riktigt mitt workflow. herdr-projects bygger på GitHub och git worktrees, mina repon ligger på Bitbucket och en ddev-miljö per worktree och uppgift blir för tungt för maskinen. Jag hoppar mellan upp till fem olika kunder under en dag, så det blir många ddev-miljöer som skulle rulla i worktree. vim-herdr-navigation och herdr-reviewr fick stanna, även om reviewrs flik för pull requests inte stödjer Bitbucket. herdr-radar skriver om både Herdrs och Ghosttys konfiguration och herdr-auto-title kräver Go, så dem testar jag längre fram.

Från frustration till pull request

Efter några dagars testande märkte jag att raden för agenten blev stale när Claude körde subagenter i mer än fem minuter. Huvudagenten sitter då och väntar i sitt anrop till subagenterna, gör inga egna tool calls och har ingen chans att rapportera, och pluginet slängde medvetet alla händelser från subagenterna.

Claude Code skickar subagenternas händelser med huvudagentens session och ett eget agent-id. Min fix låter de händelserna räknas som ett livstecken för huvudagenten, utan att subagenterna själva får något injicerat, och raden visar subagents i stället för stale medan de arbetar. Det blev ungefär 30 rader och två tester, utan någon migrering.

Jag forkade, skrev tester som först fallerade, körde min egen Herdr på fork-branchen och testade det live innan jag öppnade ett issue och en pull request. Det har inte kommit något svar från den som underhåller pluginet än, så jag får köra vidare med min fork under tiden.

En av sakerna som saknades: ddev

Herdr minskade inte tröttheten i sig, men det väckte behovet av att få in sådant jag redan hade i Companion, framför allt ddev och bättre notiser. Så jag byggde herdr-ddev, ett plugin som tar över ddev-delen av Companion.

Varje workspace får en markering för sitt ddev-projekt: kör, pausat, stoppat eller upptaget. Jag kan starta, stoppa och öppna sajten med ett par tangenter, och en lista över alla ddev-projekt låter mig starta, stoppa eller starta om vilket som helst.

Några beslut tog jag direkt. Repot skulle vara publikt från första dagen, första versionen skulle bara göra det Companion redan gjorde, och statusen skulle hämtas med en enkel kontroll var femte sekund i stället för något mer avancerat. Mätningar styr resten. docker ps med ddevs etiketter tar ungefär 0,04 sekunder och ddev list ungefär 1,3 sekunder, så pluginet läser direkt från Docker.

Det mesta av tankearbetet gick till att det ska vara lätt att förstå vad pluginet tänker installera och ändra. configure visar exakt vad det tänker lägga till, frågar, gör en backup av befintliga inställningar, kontrollerar resultatet med herdr config check och sparar vad det behöver lägga till, så att unconfigure bara tar bort sina egna rader.

Jag byggde det med Claude på samma sätt som jag jobbar med kundprojekt: använda brainstorm-skillen för att börja planera upp det, sedan omvandla det till en skriven spec och en plan på 17 uppgifter som genomfördes testdrivet. Därefter fick en reviewer utan context läsa hela branchen. Den hittade inga kritiska fel, åtta viktiga findings som jag rättade med ett fallerande test först, och sexton mindre saker som fick en egen korrekturrunda. Releasen hade 152 tester.

Herdrs marknadsplats listade pluginet ungefär 20 minuter efter att jag taggat v0.1.0.

Notiser och hur jag arbetar med dem

Nästa sak jag undersökte blev herdr-nudge, där en klickbar notis tar mig direkt till panelen som väntar. Även där hittade jag saker som skavde lite, eller features som jag tycker gör det hela lite "bättre".

Detta blev en färdig ändring på +1650 rader som väntar. Här skall jag testa att istället fråga plugin-skaparen om han vill ha den innan jag öppnar en PR.

Vad löser Herdr inte?

Herdr gör samma sak för mig som Companion: vägen till agenten som väntar blir kort. Besluten när jag väl är där är fortfarande mina, och det var där tröttheten satt i förra artikeln.

Jag har också tittat på tuios, en annan fönsterhanterare för agenter i terminalen. Den har en inkorg, en lista över allt som väntar där jag kan svara på godkännanden direkt. Om det löser min dagliga utmaning är inte säkert. Men jag tänker fortfarande fortsätta prova nya verktyg tills jag hittar sätt som optimerar min arbetsdag till det bättre.

Bygga själv eller använda andras?

Jag kör Herdr fortfarande, och ddev-delen av Companion lever nu som ett plugin som andra kan använda. Det känns som en bättre fördelning än att bygga ett helt eget verktyg för allt. Speciellt om jag aldrig tänker publicera det till världen.

Det jag har lärt mig så här långt handlar mer om hur jag väljer verktyg än om Herdr i sig. Jag testar det som finns innan jag bygger mer, jag läser koden innan ett plugin får köra i mina agentsessioner, och när något irriterar mig försöker jag laga det där det hör hemma i stället för att forka för alltid.

Det jag letar efter är verktyg som håller en hel dag med flera agenter utan att själva bli ännu en sak att hålla koll på. Herdr är närmare det än jag trodde, men jag har fortfarande tuios att testa innan jag kan säga om mitt eget verktyg kommer att fortsätta användas.