En erfaren udvikler, som ifølge Towards AI har hjulpet titusinder i gang med Claude Code, siger det fladt: opsætningen tager en eftermiddag, resten tager måneder. Nyheden er praktisk og tør: proof‑of‑concept er de lette cirka 20 procent. Seks måneder senere dukker problemerne op, stille: hukommelser rådner, connectors siger “Connected” mens de ikke er det, og headless subagents påstår, at de har løst opgaver, de aldrig fik lov til at udføre. Kilden er Anubhav på Towards AI, og tonen er deklareret anti‑glansbillede.
Det er ikke pessimisme. Det er drift. Du kan bygge hurtigt, men uden ingeniørmæssige værn og governance ender du med falsk tryghed — og uforudset ekstraarbejde. Det er pointen.
Proof‑of‑conceptet: hurtig at bygge, men vildledende
POC føles let, fordi Claude Code leverer et klart skelet: CLAUDE.md med regler, per‑directory instruktioner, subagents til specialopgaver og connectors til værktøjer. Man tænder, og det kører. Ifølge Anubhav kan en seriøs opsætning stå på få timer den første dag. Potentialet er tydeligt — og derfor vildledende om den faktiske indsats bagefter.
Driftens virkelighed: hvad går galt over tid
Hukommelsen rådner langsomt. Auto‑memory afkorter og kan forurene sig selv med forældede noter. Output bliver gradvist ringere, uden alarmer, beskriver kilden.
Connectors kan stå som “Connected” i UI’et, men fejle i headless eller planlagte jobs. Små afbrydelser og fornyelser glipper, og intet er reelt tilgængeligt, selvom status lyser grønt. Det er netop det lumre: grønt lys uden handling.
Headless subagents gør ondt værre. Når et værktøjskald afvises, kan agenten alligevel rapportere succes. Resultatet ser plausibelt ud, indtil man åbner loggen og finder — ingenting. Kilden kalder det hallucineret succes.
Hvorfor automatiske hukommelser og CLAUDE.md ikke er nok
CLAUDE.md er vejledning, ikke håndhævelse. Den ligger tidligt i prompten, men senere kontekst og tool‑feedback kan overdøve den. Derfor kræves system‑hooks og stateful kontrol, hvis regler skal efterleves i praksis.
Auto‑truncation skærer ofte det forkerte væk. “Memory that rots” opstår, når gamle fejlnoter overlever, mens præcision forsvinder. I produktion bliver det et mønster. Uden stærke lagre og versionsstyring ved man ikke, hvad der røg hvornår — og kan ikke rulle fornuftigt tilbage.
Context hygiene og compaction‑deadlocks
Context hygiene er en brændstofmåler: vid hvor fuld tanken er, før du hælder mere i. Overkorrigerer du, fylder du prompten med regler og dubletter, der fortrænger opgaven. Underkorrigerer du, sniger gamle fejl sig tilbage.
Compaction‑deadlocks opstår, når oprydning kun sker ved grænsen. Så stivner konteksten. Løsningen ifølge kilden: mål forbrug, kompaktér lidt før tærsklen, i små skridt, og nulstil periodisk, så man ikke bygger oven på forurenet bund.
Connectors og headless subagents: tro ikke “Connected” og “Success” uden bevis
Asynkrone og planlagte miljøer skjuler fejl. Et UI‑flag siger Connected, men i cron‑kørsler dør fornyelser eller rammer man grænser, og kaldene fejler i stilhed. Kilden beskriver netop fælden: status ser god ud, handlingerne fejler.
Behandl headless subagents som upålidelige, indtil de dokumenterer det modsatte. Et “Done” er værdiløst uden kvittering fra det værktøj, der faktisk gjorde arbejdet. Transaktionel logging — før, under og efter — er rygraden, når nogen spørger: “Hvorfor skete det?”
Skalering og orkestration: det virkelige arbejde
At få en agent til at kompilere første dag er fint. At holde 40 workflows kørende på tværs af repositories, teams og tidszoner er noget andet. Persistence‑grænser banker på, når logs og hukommelser vokser. Uden versioneret kontekst er rollbacks et lotteri. Uden overvågning opdager man forfald for sent.
Det lander to steder: ingeniørdisciplin og governance. Monitoring, fejlhåndtering, og klare SLAs for tredjepartsintegrationer. Nogen skal eje fejlen, når en connector “lyver”. Det er tørt — og dyrt at ignorere.
Konkrete mitigations — checkliste for engineering og drift
Hvis du kun kan nå få ting, så prioriter verificering og styr på kontekst. Resten bagefter. Kilden og den praktiske brief peger samme vej:
- Connector‑audits ugentligt i starten, senere månedligt. Aktiv bekræftelse, ikke UI‑status.
- Stateful context‑arkitektur med versionsstyring af regler, hukommelser og systembeskeder.
- Transaktionel logging, der korrelerer værktøjskald og agentudtalelser.
- Automatiserede health checks: fornyelser, alerts og sandheds‑pings.
- Fallback‑strategier: klare no‑tool‑tilstande og degraderet adfærd frem for tavshed.
- Testsuites for subagents inkl. fejlsimulationer, hvor tools nægtes eller svarer skævt.
- Runbooks for oprensning af hukommelser og nulstilling af forurenet kontekst.
- Ansvarsmodeller og SLAs for tredjepart. Hvem reagerer, når Connected lyver kl. 03.12?
Hvorfor CLAUDE.md alene ikke holder linjen
Regler i en fil er tekst. Uden hooks, der stopper farlig adfærd, vinder støj let over regeltekst i en overfyldt kontekst. Kilden beskriver glidebanen — derfor behovet for enforcement på systemniveau.
Vil du have forudsigelighed, så gem og versionér den operative kontekst, ikke kun kode. Så kan du se, hvad agenten faktisk læste, da den fejlede. Ellers gætter man — dyrt i både tid og tillid.
Praktiske tradeoffs og begrænsninger
Stærkere verifikation koster: mere logging, flere pings, retries, højere latency. Alternativet er supportbrande i det skjulte. Vælg, hvad der skal være hårdt verificeret, og hvad der kan være “best effort”.
Mere kompleksitet i datalagre og versionering øger vedligehold, men sænker antallet af uforståelige fejl. Ikke alle use cases kræver orkestreret hukommelse. Nogle gange er det rigtige at skære ned: kort kontekst, ingen persistens, tydelig reset mellem opgaver. Kilden prædiker ikke én sand vej — bare nøgternhed.
Hvad produktledere og ops‑teams bør gøre først
Tæl ikke POC som “done”. Budgettér fire til seks gange POC‑tiden til drift og hardening — kilden indikerer, at de første cirka 20 procent er opsætning. Kræv testsuites for subagents og connectors før bred udrulning.
Fastlæg ansvar og SLA’er nu. Hvem nulstiller forurenet hukommelse? Invester i observability før features. Sæt en månedlig driftstjek‑rutine: memory‑audits, connector‑health og fejllog‑gennemgang. To timer, der redder to uger senere.
Rapporterede huller i viden
Kilden mangler tal: hvor ofte fejler connectors, hvor tit ser man hallucineret succes i headless‑kørsler? “Ofte” er ikke en fordeling. Årsagerne bag connector‑fejl er heller ikke udredt i dybden. Memory‑arkitektur omtales uden konkrete størrelsesgrænser og implementeringsmønstre. Økonomien mangler også: hvad koster det at ignorere drift i timer hos en mellemstor afdeling?
Hvorfor det her betyder noget i hverdagen
Når en agent melder “success”, og kundeservice senere opdager, at intet skete, brænder tilliden. Logs og verifikation er ikke pynt; det er kundens oplevelse. En headless fejlhændelse kl. 02.11 kan stoppe en hel morgen.
Indimellem er det rigtige at køre uden memory en tid og stabilisere, før man skruer op igen. Hellere et simpelt system, der leverer, end en “klog” opsætning, der lyver pænt. Kilden er ikke romantisk — godt sådan.
Konklusion: vinderen er ikke den, der bygger hurtigt
Hurtig opsætning er ikke succeskriteriet. Succesen er, om kvaliteten holder efter et halvt år, når hukommelser har været igennem små storme, og connectors har mistet pusten om natten. POC er starten, ikke leverancen.
Anbefalingen er enkel: mistro antagelser, verificér det vigtige, hold konteksten ren og versioneret, og ryd op løbende. Ikke glamourøst — bare drift. Forskellen mærkes først, når fejlloggen ligger på bordet.
