Fra Bash Scripts til AI CTO

Fra Bash Scripts til AI CTO

Prateek Karnal havde ikke til hensigt at bygge en AI, der kunne lede softwareteams. Som de fleste byggere startede han med et specifikt problem: at koordinere flere AI-kodningsagenter uden at de trådte hinanden over tæerne eller sad fast i uendelige loops. [7]

Den traditionelle tilgang—ReAct loops hvor agenter ræsonnerer, handler og observerer i sekvens—fungerer fint til enkelt-agent opgaver. Men når man skalerer til flere agenter, der arbejder på den samme kodebase, støder man på umiddelbare problemer. Agenter overskriver hinandens ændringer. De kan ikke håndtere merge-konflikter. Når CI fejler, er der ingen klar eskaleringssti. Mest kritisk opererer de isoleret uden at lære af hinandens succeser og fiaskoer.

Composios gennembrud var at erkende, at multi-agent koordination er fundamentalt anderledes end enkelt-agent intelligens. I stedet for at gøre individuelle agenter klogere byggede de infrastruktur til at gøre agent-teams mere effektive. Resultatet er et system, der autonomt kan rette 84,6% af CI-fejl på tværs af 41 testcases og håndtere 68% af code review-problemer uden menneskelig indgriben. [3]

Men den rigtige validering kom, da de vendte systemet mod sig selv. "Tingen, der blev bygget, var tingen, der ledede sin egen konstruktion," forklarer Karnal. "Vi ville se, om et AI-system ikke bare kunne skrive kode, men lede en hel softwareudviklingsproces." [2]

Arkitektur: Orkestreringslagret

I sin kerne løser Agent Orchestrator tre fundamentale problemer, der ødelægger traditionelle multi-agent systemer: isolation, feedback-routing og detektion af fastlåste agenter. [4]

Isolation sker gennem Git worktrees—hver agent får sin egen branch og workspace, hvilket eliminerer de filkonflikter, der plager naive multi-agent setups. Når Agent A refaktorerer autentificeringssystemet, mens Agent B tilføjer nye API-endpoints, arbejder de i helt separate miljøer indtil merge-tidspunktet.

Feedback-routing sikrer, at CI-fejl, code review-kommentarer og merge-konflikter når de rigtige agenter. I stedet for at broadcaste hver event til hver agent (dyrt og støjende) eller håbe på, at agenter vil polle for opdateringer (upålideligt), vedligeholder orchestratoren en rettet graf over, hvilke agenter der bekymrer sig om hvilke events. Når en test fejler, bliver kun de agenter, der er ansvarlige for den kodesti, notificeret.

Detektion af fastlåste agenter bruger JSONL event-tracking til at identificere, hvornår agenter holder op med at gøre fremskridt. Traditionelle systemer stoler på timeouts eller manuel indgriben. Agent Orchestrator holder øje med mønstre—en agent der laver det samme API-kald gentagne gange, eller genererer identiske kodeændringer—og eskalerer eller omfordeler automatisk arbejdet.

Plugin-arkitekturen gør dette praktisk for rigtige ingeniørteams. Otte udskiftelige slots håndterer alt fra runtime-miljøer (tmux, Docker, Kubernetes) til agent-typer (Claude Code, Aider, Codex) til workspace-management (worktrees, clones) til issue tracking (GitHub, Linear). [1]

Konfiguration sker gennem YAML-filer, der definerer reaktive workflows. Når CI fejler, prøv igen to gange med den samme agent, eskaler derefter til en senior agent, og så page et menneske, hvis det stadig fejler. Når en PR får review-kommentarer, rut dem til den oprindelige forfatter-agent først, derefter til en code review-specialist, hvis det ikke løses inden for 2 timer.

Selvbyggeriet: 8 Dages Autonom Udvikling

Den mest overbevisende demonstration af Agent Orchestrators kapaciteter er dets egen skabelseshistorie. Fra 13.-20. februar 2026 byggede systemet sig selv med minimal menneskelig indgriben—en virkelig stresstest af multi-agent koordination i stor skala. [2]

Tallene fortæller historien: 30 samtidige agenter på toppen, 747 commits, 102 pull requests med 86% skabt af AI og 65% succesfuldt merged, 700 review-kommentarer med 99% håndteret af AI. Claude Opus 4.6 bidrog med 512 commits, mens Sonnet 4.5 tilføjede 373. Menneskelig indsats: cirka 3 fokuserede dage med overordnet retning og eskalerings-håndtering.

Men de interessante indsigter kommer fra fejlmoduserne. Merge-konflikter ødelagde oprindeligt systemet, indtil agenter lærte at koordinere gennem orchestratorens konfliktløsnings-workflows. Code review-cykler skabte uendelige loops, indtil timeout- og eskaleringslogik blev tilføjet. Test-fejl spredte sig på tværs af agenter, indtil isolerede worktrees og målrettet feedback-routing indeholdt skaden.

"Orkestrering betyder mere end enhver individuel agent-forbedring," reflekterer Karnal. "Spørgsmålet er ikke, hvor kloge vi kan gøre én agent, men hvor godt et system kan blive til at deploye, observere og forbedre snesevis af agenter, der arbejder parallelt." [2]

Selvbyggeriet afslørede også emergente adfærd, der ikke var eksplicit programmeret. Agenter begyndte at specialisere sig—nogle fokuserede på frontend-komponenter, andre på backend-services, igen andre på test og dokumentation. De udviklede uformelle handoff-protokoller med agenter, der efterlod detaljerede commit-beskeder og PR-beskrivelser til deres kolleger.

Ud over ReAct: Strukturerede Workflows til Produktion

Traditionelle AI-agenter stoler på ReAct loops—ræsonner om problemet, tag en handling, observer resultatet, gentag. Dette fungerer til isolerede opgaver, men bryder sammen i komplekse, multi-step workflows, hvor handlinger har afhængigheder og sideeffekter. [3]

Agent Orchestrator introducerer strukturerede tilstandsfulde workflows med eksplicit planner/executor-adskillelse. I stedet for at hver agent ræsonnerer om alt fra bunden mapper en central planner arbejdet ud og tildeler specifikke, afgrænsede opgaver til executor-agenter. Dette reducerer den kognitive belastning på individuelle agenter, mens global sammenhæng bevares.

Just-in-time værktøjs-routing betyder, at agenter kun får adgang til de værktøjer, de har brug for til deres nuværende opgave. En agent, der arbejder på frontend-styling, har ikke brug for database-migrations-værktøjer. En agent, der retter CI-fejl, har ikke brug for adgang til deployment-pipelinen. Dette reducerer både omkostninger (færre tokens i kontekst) og risiko (færre måder for agenter at forårsage utilsigtede sideeffekter).

Fejlgenoprettelse-branches håndterer realiteten, at AI-agenter fejler på uforudsigelige måder. I stedet for at håbe på, at agenter elegant vil håndtere alle edge cases, definerer orchestratoren eksplicitte genoprettelsessti. Hvis en agent ikke kan løse en merge-konflikt efter 3 forsøg, eskaler til et menneske. Hvis CI bliver ved med at fejle på den samme test, tildel en anden agent med frisk kontekst.

Resultatet er observabilitet, der faktisk hjælper med at debugge multi-agent systemer. Traditionelle setups giver dig en væg af agent-logs uden klar narrativ. Agent Orchestrator giver en tidslinje-visning, der viser, hvilke agenter der arbejdede på hvad, hvornår de afleverede arbejde, hvor de sad fast, og hvordan konflikter blev løst.

Byggerens Guide: Fra Kaos til Koordination

At komme i gang med Agent Orchestrator er bevidst simpelt: ao start <repo> starter en grundlæggende konfiguration med fornuftige standarder. Men kraften kommer fra tilpasning til dine specifikke udviklingsworkflows. [4]

Konfiguration starter med at definere dine agent-roller. Kast ikke bare generiske kodningsagenter efter problemer. Skab specialister: en frontend-agent, der forstår dit komponentbibliotek, en backend-agent, der kender dine API-mønstre, en test-agent, der kender dine kvalitetsstandarder, en DevOps-agent, der forstår din deployment-pipeline.

Eskaleringssti er kritiske for produktionsbrug. Definer klare handoff-regler: hvornår giver en agent op og beder om hjælp? Hvor længe skal en agent arbejde på et problem, før den eskalerer? Hvem bliver paget, når systemet ikke kan gøre fremskridt? Selvbyggeriet afslørede, at de fleste fejl sker ved grænser—merge-konflikter, integrationstest, deployment-problemer—hvor klar eskalering forhindrer uendelige loops.

Feedback-loops har brug for omhyggelig tuning. For meget feedback skaber støj og forvirring. For lidt efterlader agenter, der arbejder med forældet information. Det søde punkt er målrettet, handlingsanvisende feedback rutet til de specifikke agenter, der kan handle på det. CI-fejl går til de agenter, der rørte den fejlende kode. Code review-kommentarer går til de oprindelige forfattere. Ydeevne-regressioner går til optimerings-specialisterne.

Human-in-the-loop bør være minimal, men strategisk. Agenter håndterer rutinemæssig udførelse. Mennesker håndterer arkitektoniske beslutninger, krav-afklaring og kompleks debugging. Målet er ikke at eliminere menneskelig dømmekraft, men at fokusere den på de beslutninger, der betyder mest.

Hvad Ændrer Sig, Når AI Bygger Softwaren

Agent Orchestrator peger mod et fundamentalt skift i, hvordan software bliver bygget. Vi bevæger os fra individuelle produktivitetsværktøjer (Copilot, Cursor) til autonome udviklingsteams, hvor mennesker giver retning, og agenter håndterer udførelse.

Dette handler ikke kun om hastighed—selvom produktivitetsgevinsten er betydelig. Det handler om at ændre naturen af softwareudviklingsarbejde. Når agenter kan håndtere rutinekodning, test og deployment, bliver menneskelige udviklere arkitekter, produktdesignere og systemintegratorer. Flaskehalsen skifter fra at taste kode til at træffe beslutninger om, hvad der skal bygges, og hvordan det skal organiseres.

Nordiske virksomheder er særligt godt positioneret til denne overgang. Regionens vægt på automatisering, systematisk tænkning og menneskecentreret design stemmer perfekt overens med orkestreret AI-udvikling. Mens Silicon Valley jager de seneste model-forbedringer, fokuserer nordiske byggere på at gøre AI-systemer pålidelige, forudsigelige og nyttige for rigtige ingeniørteams.

Implikationerne strækker sig ud over individuelle virksomheder. Når softwareudvikling primært handler om orkestrering snarere end implementering, skifter konkurrencefordele. De virksomheder, der vinder, vil ikke nødvendigvis have de bedste individuelle udviklere—de vil have de bedste systemer til at koordinere AI-udviklingsteams.

Open source bliver endnu mere kritisk i denne verden. Agent Orchestrators succes kommer delvist fra dets åbne arkitektur—teams kan tilpasse, udvide og bidrage med forbedringer. Proprietære agent-systemer bliver sorte bokse, der ikke kan tilpasse sig specifikke workflows. Åbne orkestreringsplatforme bliver fundamentet for hele økosystemer af specialiserede agenter og værktøjer.

Post-Kode Æraen: Orkestrering som den Nye Programmering

Vi går ind i det, Up North AI kalder post-kode æraen—ikke fordi kode forsvinder, men fordi at skrive kode bliver en råvare. Den knappe ressource skifter fra implementering til dømmekraft: hvad der skal bygges, hvordan det skal organiseres, hvornår det skal sendes, hvordan det skal vedligeholdes.

Agent Orchestrator repræsenterer den første produktionsklare infrastruktur til denne overgang. Den gør udførelse til en råvare, mens den sætter fokus på menneskelig dømmekraft omkring arkitektur, koordination og eskalering. Kode er gratis. Dømmekraft er ikke.

De byggere, der trives i dette miljø, vil ikke være de hurtigste kodere eller de mest produktive committere. De vil være dem, der bedst forstår, hvordan man orkestrerer autonome systemer til at opnå menneskelige mål. De vil designe workflows, definere kvalitetsstandarder og træffe arkitektoniske beslutninger, mens agenter håndterer det mekaniske arbejde med implementering.

Dette er fremtiden for softwareudvikling: menneskelig kreativitet og dømmekraft, der dirigerer AI-udførelse og optimering. Agent Orchestrator viser os, hvordan den fremtid ser ud—og den ankommer hurtigere, end de fleste mennesker indser.

Kilder

1. https://github.com/ComposioHQ/agent-orchestrator
2. https://composio.dev/blog/the-self-improving-ai-system-that-built-itself
3. https://www.marktechpost.com/2026/02/23/composio-open-sources-agent-orchestrator-to-help-ai-developers-build-scalable-multi-agent-workflows-beyond-the-traditional-react-loops
4. https://mintlify.com/ComposioHQ/agent-orchestrator/introduction
5. https://composio.dev/
6. https://www.reddit.com/r/machinelearningnews/comments/1rd8cfk/composio_open_sources_agent_orchestrator_to_help
7. https://pkarnal.com/blog/open-sourcing-agent-orchestrator