Agenter Får Navne, og Vi Holder Op Med Noget Dumt
Fire Features, Én Lørdag
Nogle dage bygger man én ting ordentligt. Andre dage bygger man fire ting, fixer et dusin bugs og glemmer at spise frokost. Det her var den anden slags dag.
Agenter Signerer Deres Arbejde
Her er noget der virker indlysende i bakspejlet, men tog os et stykke tid at fixe.
Hver AI-agent der arbejder på oUTPOSt laver commits til kodebasen — det er sådan deres arbejde bliver gemt. Men indtil i dag så alle commits fra alle agenter ens ud i git-loggen. Samme navn, samme email. Det var som at have fem snedkere i et værksted, og hvert møbel bare siger "Lavet af: En Snedker."
Ikke super brugbart når noget går i stykker og man skal vide hvem der savede det bræt.
Nu får hver agent sin egen identitet. Git-loggen bliver en læsbar historie:
a1727ca Kimi (oUTPOSt Agent) Fix review feedback: guard --dry-run
367a42a Claude (oUTPOSt Agent) Add CHANGELOG.md
Når den automatiserede review-pipeline godkender og merger nogens arbejde, siger merge-committet nu hvem der reviewede det, hvad de syntes, og et resumé af deres fund. Hvert merge fortæller en lille historie.
Sporing af Hvad Der Faktisk Ændrede Sig
Relateret opgradering: vi tilføjede git activity tracking. Før en opgave starter, tager systemet et snapshot af kodebasen. Når opgaven er færdig, sammenligner det de to tilstande og registrerer præcis hvad der skete — hvilke filer ændrede sig, hvor mange linjer blev tilføjet eller fjernet, hvilke commits blev lavet.
Det forvandler opgavehistorik fra "en agent arbejdede på noget" til "denne agent tilføjede 47 linjer på tværs af 3 filer i 2 commits, her er GitHub-links."
Det er forskellen mellem en følgeseddel der siger "diverse" og en der lister hver ting i kassen.
Vi Holder Op Med at Bede Serveren om Lektier
OK, tilståelsestid.
Vores frontend bruger Tailwind CSS, som er et værktøj der genererer den visuelle styling til admin-grænsefladen. Det fungerer sådan: et program kaldet Vite scanner alle filer i projektet, finder alle de stilnavne vi har brugt, og bygger én optimeret CSS-fil.
På en moderne bærbar tager det omkring otte sekunder. Ingen big deal.
På vores server? Fire minutter. Nogle gange længere. Nogle gange dræbte serverens styresystem bare processen for at bruge for meget hukommelse — Tailwind v4 æder gladeligt 3-4 GB RAM mens den scanner, og vores server havde bedre ting at bruge den hukommelse på. Som, du ved, at køre selve applikationen.
I månedsvis inkluderede hvert eneste deploy dette fire-minutters byggetrin. Vi pushede kode, og så ventede vi. Og ventede. Og kiggede på en timer. Og undrede os over om det her var den deploy hvor det ville crashe igen.
Løsningen, da vi endelig kom til det, var næsten pinligt simpel: byg det på udviklingsmaskinen (hvor det tager otte sekunder fordi bærbare er hurtige), gem resultatet, og send de færdigbyggede filer til serveren. Serveren behøver aldrig bygge noget — den modtager bare det færdige produkt.
Tænk på det sådan: I stedet for at sende råt tømmer til en kunde og bede dem bygge deres eget bord, sender vi nu det færdige bord. Kundens stue behøver ikke have et værksted i sig.
Deploy gik fra "fem nervøse minutter" til "42 kedelige sekunder." Hvilket er præcis hvad deploys bør være: kedelige.
{
"type": "bar",
"title": "Deploy-Varighed (sekunder)",
"labels": ["Før: Serveren Bygger Alt", "Efter: Send Det Færdige Produkt"],
"datasets": [
{ "label": "Sekunder", "data": [300, 42] }
]
}
Vi tager kedelig.
Den Høflige Vedligeholdelsesside
Tidligere betød deployment at brugerne så ødelagte sider eller kryptiske fejlmeddelelser i nogle sekunder mens serveren opdaterede sig. Ikke det bedste look.
Nu er der et ordentligt venteværelse. Når en deploy starter, opfanger webserveren al indgående trafik og viser en pæn statusside — hvilket trin kører, en progress bar, hvor lang tid det har kørt. Ingen kompleks backend, bare en simpel side der tjekker en statusfil.
Når deployen er færdig, redirecter siden dig automatisk tilbage. Hvis du allerede var på sitet, får du en live-notifikation om at opdateringen er klar.
Detaljerne var bøvlede (det er de altid), men resultatet er fint: deploys gik fra "mystisk nedetid" til "høflig 42-sekunders pause."
Agent Workspaces
Én ting mere: man kan nu browse hver agents workspace i kode-editoren — deres instruktioner, personlighedsindstillinger, seneste aktivitet. Det er begyndelsen på at behandle agent-adfærd som noget man konfigurerer gennem redigerbare filer i stedet for begravet kode.
Tænk på det som at hver agent får deres egen værktøjskasse med et mærkat på, i stedet for at alle roder rundt i den samme skuffe.
Fire tasks. Tolv bug fixes. Én meget kedelig deploy-pipeline. Fremskridt.