Bash-skripteistä AI-teknologiajohtajaksi

Bash-skripteistä AI-teknologiajohtajaksi

Prateek Karnal ei lähtenyt rakentamaan tekoälyä, joka voisi johtaa ohjelmistotiimejä. Kuten useimmat rakentajat, hän aloitti tietystä kipupisteestä: useiden AI-koodausagenttien koordinoinnista ilman, että ne astuvat toistensa töiden päälle tai juuttuvat äärettömiin silmukoihin. [7]

Perinteinen lähestymistapa—ReAct-silmukat, joissa agentit päättelevät, toimivat ja havaitsevat peräkkäin—toimii hyvin yksittäisten agenttien tehtävissä. Mutta kun skaalaat useisiin agentteihin, jotka työskentelevät samassa koodipohjassa, törmäät välittömiin ongelmiin. Agentit ylikirjoittavat toistensa muutokset. Ne eivät osaa käsitellä yhdistämiskonflikteja. Kun CI epäonnistuu, ei ole selvää eskalaatiopolkua. Kriittisintä on, että ne toimivat eristyksissä oppimatta toistensa onnistumisista ja epäonnistumisista.

Composion läpimurto oli tunnistaa, että usean agentin koordinointi on pohjimmiltaan erilaista kuin yksittäisen agentin älykkyys. Sen sijaan, että olisivat tehneet yksittäisistä agenteista älykkäämpiä, he rakensivat infrastruktuurin agenttien tiimien tehostamiseksi. Tuloksena on järjestelmä, joka voi autonomisesti korjata 84,6% CI-virheistä 41 testitapauksessa ja käsitellä 68% koodikatselmusongelmista ilman ihmisen väliintuloa. [3]

Mutta todellinen validointi tuli, kun he käänsivät järjestelmän itseään vastaan. "Rakennettava asia oli se, joka hallitsi omaa rakentamistaan", Karnal selittää. "Halusimme nähdä, voiko AI-järjestelmä paitsi kirjoittaa koodia, myös hallita koko ohjelmistokehitysprosessia." [2]

Arkkitehtuuri: Orkestrointikerros

Ytimessään Agent Orchestrator ratkaisee kolme perustavanlaatuista ongelmaa, jotka rikkovat perinteiset usean agentin järjestelmät: eristäminen, palautteen reititys ja juuttuneiden agenttien havaitseminen. [4]

Eristäminen tapahtuu Git-työpuiden kautta—jokainen agentti saa oman haaransa ja työtilansa, eliminoiden tiedostokonfliktit, jotka vaivaavat naiiveja usean agentin asetuksia. Kun Agentti A refaktoroi autentikointijärjestelmää samalla kun Agentti B lisää uusia API-päätepisteitä, ne työskentelevät täysin erillisessä ympäristössä yhdistämisaikaan asti.

Palautteen reititys varmistaa, että CI-virheet, koodikatselmuskommentit ja yhdistämiskonflikteista tavoittavat oikeat agentit. Sen sijaan, että lähetettäisiin jokainen tapahtuma jokaiselle agentille (kallista ja meluisaa) tai toivottaisiin agenttien kyselevän päivityksiä (epäluotettavaa), orkestroija ylläpitää suunnattua graafia siitä, mitkä agentit välittävät mistäkin tapahtumista. Kun testi epäonnistuu, vain kyseisestä koodipoluista vastaavat agentit saavat ilmoituksen.

Juuttuneiden agenttien havaitseminen käyttää JSONL-tapahtumien seurantaa tunnistaakseen, milloin agentit lakkaavat tekemästä edistystä. Perinteiset järjestelmät luottavat aikakatkaisuihin tai manuaaliseen väliintuloon. Agent Orchestrator tarkkailee malleja—agentti tekee samaa API-kutsua toistuvasti tai generoi identtisiä koodimuutoksia—ja eskaloi tai uudelleenjakaa työn automaattisesti.

Plugin-arkkitehtuuri tekee tästä käytännöllistä oikeille insinööritiimeille. Kahdeksan vaihdettavaa paikkaa käsittelee kaiken suoritusympäristöistä (tmux, Docker, Kubernetes) agenttityyppeihin (Claude Code, Aider, Codex) työtilan hallintaan (työpuut, kloonit) ja ongelmien seurantaan (GitHub, Linear). [1]

Konfigurointi tapahtuu YAML-tiedostojen kautta, jotka määrittelevät reaktiivisia työnkulkuja. Kun CI epäonnistuu, yritä kahdesti samalla agentilla, sitten eskaloi vanhemmalle agentille, sitten hälyytä ihminen, jos edelleen epäonnistuu. Kun PR saa katselmuskommentteja, reitittää ne ensin alkuperäiselle tekijäagentille, sitten koodikatselmusasiantuntijalle, jos ei ratkaista 2 tunnissa.

Itsensä rakentaminen: 8 päivää autonomista kehitystä

Agent Orchestratorin kyvykkyyksien vakuuttavin demonstraatio on sen oma luomistarina. 13.-20. helmikuuta 2026 järjestelmä rakensi itsensä minimaalisella ihmisen väliintulolla—todellisen maailman stressitesti usean agentin koordinoinnille mittakaavassa. [2]

Numerot kertovat tarinan: 30 samanaikaista agenttia huipussaan, 747 committia, 102 pull requestia, joista 86% AI:n luomia ja 65% onnistuneesti yhdistettyjä, 700 katselmuskommenttia, joista 99% AI:n käsittelemiä. Claude Opus 4.6 teki 512 committia kun Sonnet 4.5 lisäsi 373. Ihmisen panos: noin 3 keskittynyttä päivää korkean tason ohjausta ja eskalaation käsittelyä.

Mutta mielenkiintoiset oivallukset tulevat vikaantumistiloista. Yhdistämiskonflikteista hajosi aluksi järjestelmä, kunnes agentit oppivat koordinoimaan orkestroijan konfliktinratkaisutyönkulkujen kautta. Koodikatselmusyklit loivat äärettömiä silmukoita, kunnes aikakatkaisu- ja eskalaatiologiikka lisättiin. Testivirheet levisivät agenttien välillä, kunnes eristetyt työpuut ja kohdistettu palautteen reititys hillitsi vahingon.

"Orkestrointi merkitsee enemmän kuin mikään yksittäisen agentin parannus", Karnal pohtii. "Kysymys ei ole, kuinka älykkään voimme tehdä yhdestä agentista, vaan kuinka hyväksi järjestelmä voi tulla käyttöönottamaan, havainnoimaan ja parantamaan kymmeniä agentteja, jotka työskentelevät rinnakkain." [2]

Itsensä rakentaminen paljasti myös emergenttejä käyttäytymismalleja, joita ei ollut eksplisiittisesti ohjelmoitu. Agentit alkoivat erikoistua—jotkut keskittyivät frontend-komponentteihin, toiset backend-palveluihin, toiset edelleen testaukseen ja dokumentointiin. Ne kehittivät epävirallisia luovutusprotokolia, jolloin agentit jättivät yksityiskohtaisia commit-viestejä ja PR-kuvauksia kollegoilleen.

ReActin tuolla puolen: Strukturoidut työnkulut tuotantoon

Perinteiset AI-agentit luottavat ReAct-silmukoihin—päättele ongelmasta, tee toimenpide, havaitse tulos, toista. Tämä toimii eristyneissä tehtävissä, mutta hajoaa monimutkaisissa, monivaiheisissa työnkuluissa, joissa toimenpiteillä on riippuvuuksia ja sivuvaikutuksia. [3]

Agent Orchestrator esittelee strukturoidut tilalliset työnkulut eksplisiittisellä suunnittelijan/toteuttajan erottelulla. Sen sijaan, että jokainen agentti päättelisi kaiken alusta alkaen, keskussuunnittelija kartoittaa työn ja jakaa tiettyjä, rajattuja tehtäviä toteuttaja-agenteille. Tämä vähentää yksittäisten agenttien kognitiivista kuormaa säilyttäen samalla globaalin koherenssin.

Just-in-time työkalujen reititys tarkoittaa, että agentit saavat pääsyn vain niihin työkaluihin, joita ne tarvitsevat nykyiseen tehtäväänsä. Frontend-stylingiä tekevä agentti ei tarvitse tietokannan migraatiotyökaluja. CI-virheitä korjaava agentti ei tarvitse pääsyä käyttöönottopipelineen. Tämä vähentää sekä kustannuksia (vähemmän tokeneita kontekstissa) että riskiä (vähemmän tapoja agenteille aiheuttaa tahattomia sivuvaikutuksia).

Virheiden palautumishaarat käsittelevät todellisuuden, että AI-agentit epäonnistuvat arvaamattomilla tavoilla. Sen sijaan, että toivottaisiin agenttien käsittelevän sujuvasti jokaisen reunatapauksen, orkestroija määrittelee eksplisiittiset palautumispolut. Jos agentti ei voi ratkaista yhdistämiskonfliktiä 3 yrityksen jälkeen, eskaloi ihmiselle. Jos CI jatkaa epäonnistumista samassa testissä, määrää eri agentti tuoreella kontekstilla.

Tuloksena on havaittavuus, joka todella auttaa debuggaamaan usean agentin järjestelmiä. Perinteiset asetukset antavat sinulle seinän agenttilogeja ilman selvää narratiivia. Agent Orchestrator tarjoaa aikajanonäkymän, joka näyttää, mitkä agentit työskentelivät minkä parissa, milloin ne luovuttivat työn, missä ne juuttuivat ja miten konfliktit ratkaistiin.

Rakentajan opas: Kaaoksesta koordinointiin

Agent Orchestratorin aloittaminen on tarkoituksella yksinkertaista: ao start <repo> käynnistää peruskonfiguraation järkevilla oletuksilla. Mutta voima tulee räätälöinnistä omille kehitystyönkuluillesi. [4]

Konfigurointi alkaa agenttiroolien määrittelyllä. Älä vain heitä yleisiä koodausagentteja ongelmiin. Luo asiantuntijoita: frontend-agentti, joka ymmärtää komponenttikirjastosi, backend-agentti, joka tuntee API-mallit, testausagentti, joka tietää laatustandardisi, DevOps-agentti, joka ymmärtää käyttöönottopipelinesi.

Eskalaatiopolut ovat kriittisiä tuotantokäytössä. Määrittele selkeät luovutussäännöt: milloin agentti luovuttaa ja pyytää apua? Kuinka kauan agentin tulisi työskennellä ongelman parissa ennen eskalointia? Kuka saa hälytyksen, kun järjestelmä ei voi edetä? Itsensä rakentaminen paljasti, että useimmat virheet tapahtuvat rajoilla—yhdistämiskonflikteissa, integraatiotesteissä, käyttöönotto-ongelmissa—joissa selkeä eskalointi estää äärettömät silmukat.

Palautesilmukat tarvitsevat huolellista viritystä. Liikaa palautetta luo melua ja hämmennystä. Liian vähän jättää agentit työskentelemään vanhentuneella tiedolla. Kultainen keskitie on kohdistettu, toimintakelpoinen palaute, joka reititetään tietyille agenteille, jotka voivat toimia sen perusteella. CI-virheet menevät agenteille, jotka koskivat epäonnistuvaa koodia. Koodikatselmuskommentit menevät alkuperäisille tekijöille. Suorituskykyregressiot menevät optimointiasiantuntijoille.

Ihminen silmukassa tulisi olla minimaalista mutta strategista. Agentit käsittelevät rutiininomaisen toteutuksen. Ihmiset käsittelevät arkkitehtuuripäätökset, vaatimusten selventämisen ja monimutkaisen debuggauksen. Tavoite ei ole eliminoida ihmisen harkintaa vaan keskittää se tärkeimpiin päätöksiin.

Mitä muuttuu, kun AI rakentaa ohjelmiston

Agent Orchestrator osoittaa kohti perustavanlaatuista muutosta siinä, miten ohjelmistoja rakennetaan. Siirrymme yksittäisistä tuottavuustyökaluista (Copilot, Cursor) autonomisiin kehitystiimeihin, joissa ihmiset antavat suunnan ja agentit hoitavat toteutuksen.

Tämä ei ole vain nopeudesta—vaikka tuottavuushyödyt ovat merkittäviä. Kyse on ohjelmistokehitystyön luonteen muuttamisesta. Kun agentit voivat hoitaa rutiininomaisen koodauksen, testauksen ja käyttöönoton, ihmiskehittäjistä tulee arkkitehteja, tuotesuunnittelijoita ja järjestelmien integroijia. Pullonkaula siirtyy koodin kirjoittamisesta päätösten tekemiseen siitä, mitä rakentaa ja miten järjestää se.

Pohjoismaiset yritykset ovat erityisen hyvin asemoituja tälle siirtymälle. Alueen painotus automaatioon, systemaattiseen ajatteluun ja ihmiskeskeiseen suunnitteluun sopii täydellisesti orkestroituun AI-kehitykseen. Kun Piilaakso jahtaa viimeisimpiä malliparannuksia, pohjoismaiset rakentajat keskittyvät AI-järjestelmien tekemiseen luotettaviksi, ennustettaviksi ja hyödyllisiksi oikeille insinööritiimeille.

Vaikutukset ulottuvat yksittäisten yritysten ulkopuolelle. Kun ohjelmistokehityksestä tulee ensisijaisesti orkestrointia toteutuksen sijaan, kilpailuedut siirtyvät. Voittavat yritykset eivät välttämättä ole niitä, joilla on parhaat yksittäiset kehittäjät—ne ovat niitä, joilla on parhaat järjestelmät AI-kehitystiimien koordinointiin.

Avoin lähdekoodi tulee entistä kriittisemmäksi tässä maailmassa. Agent Orchestratorin menestys tulee osittain sen avoimesta arkkitehtuurista—tiimit voivat räätälöidä, laajentaa ja osallistua parannuksiin. Omistusoikeudelliset agenttijärjestelmät tulevat mustiksi laatikoiksi, jotka eivät voi sopeutua tiettyihin työnkulkuihin. Avoimet orkestrointialustat tulevat koko erikoistuneiden agenttien ja työkalujen ekosysteemien perustaksi.

Koodin jälkeinen aikakausi: Orkestrointi uutena ohjelmointina

Olemme siirtymässä siihen, mitä Up North AI kutsuu koodin jälkeiseksi aikakaudeksi—ei siksi, että koodi katoaisi, vaan koska koodin kirjoittamisesta tulee hyödyke. Niukka resurssi siirtyy toteutuksesta harkintaan: mitä rakentaa, miten järjestää se, milloin toimittaa se, miten ylläpitää sitä.

Agent Orchestrator edustaa ensimmäistä tuotantovalmista infrastruktuuria tälle siirtymälle. Se tekee toteutuksesta hyödykkeen samalla kun korostaa ihmisen harkintaa arkkitehtuurissa, koordinoinnissa ja eskaloinnissa. Koodi on ilmaista. Harkinta ei ole.

Rakentajat, jotka menestyvät tässä ympäristössä, eivät ole nopeimpia koodaajia tai tuotteliaimpia committereita. He ovat niitä, jotka ymmärtävät parhaiten, miten orkestroida autonomisia järjestelmiä saavuttaakseen inhimilliset tavoitteet. He suunnittelevat työnkulkuja, määrittelevät laatustandardeja ja tekevät arkkitehtuuripäätöksiä samalla kun agentit hoitavat toteutuksen mekaanisen työn.

Tämä on ohjelmistokehityksen tulevaisuus: ihmisen luovuus ja harkinta ohjaamassa AI:n toteutusta ja optimointia. Agent Orchestrator näyttää meille, miltä tuo tulevaisuus näyttää—ja se saapuu nopeammin kuin useimmat ihmiset ymmärtävät.

Lähteet

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