Koodausagentit ovat hajautuneet – ja se on ongelma

Ollaan rehellisiä: jos yrityksesi kehittäjät käyttävät koodausagentteja, sinulla on todennäköisesti hallitsematon tilanne.

Jokaisella kehittäjällä on omat MCP-konfiguraationsa, räätälöidyt promptinsa ja automaatioskriptinsä, joihin kukaan muu ei pääse käsiksi. Ei näkyvyyttä siihen, mitä agentti oikeasti teki. Se "tiimin infrastruktuuri" on oikeastaan vain kasa henkilökohtaisia lyhytkoodeja, jotka pysyvät kasassa toiveajattelun ja suullisen tiedon varassa.

Assembled törmäsi tähän ongelmaan. Heidän koodausagenttinsa toimivat hyvin yksittäisille kehittäjille – mutta ympäröivä työnkulku oli sekaisin. Erittäin sekaisin.

Henkilökohtaisten koodausagenttien ongelma

Näin se tyypillisesti menee: Kehittäjä A:lla on Claude Code -konfiguraatio, joka yhdistää GitHub-forkkiin ja Lineariin. Kehittäjä B suosii Codexia Sentry-integraatiolla ja omilla Slack-ilmoituksilla. Kehittäjä C on rakentanut melkein Rube Goldberg -koneiston skriptejä, joita vain hän ymmärtää.

Kun joku lähtee? Kun pitää toistaa, mitä agentti oikeasti teki? Kun haluaa tarkistaa, vastaako agentin tuotos sitä, mitä koodiin lopulta päätyi?

Olet pulassa.

Varsinainen ongelma ei ole se, ovatko koodausagentit hyödyllisiä (ovat). Ongelma on, että olemme kohdelleet niitä henkilökohtaisina tekstieditoreina tiimin infrastruktuurin sijaan. Ja se luo kolme ongelmaa:

1. Tietosiloot – Vain yksi henkilö tietää, miten agentti on konfiguroitu
2. Toistettavuusongelmat – Et pysty helposti toistamaan tai tarkastamaan agentin toimintoja
3. Yhteistyöesteet – Se, mikä toimii yhdelle kehittäjälle, ei auta koko tiimiä

143.dev: Koodausagentit jaetuksi infrastruktuuriksi

Assembled rakensi sisäisen järjestelmän tämän ratkaisemiseksi, ja nyt he avasivat sen lähdekoodin. Tuloksena on 143.dev – alusta, joka muuttaa koodausagentit kaikkien tiimin jäsenten käytettäväksi infrastruktuuriksi.

Ydinlähestymistapa on fiksu: sen sijaan, että agentteja ajettaisiin paikallisesti yksittäisillä koneilla, ne ajetaan standardoiduissa ympäristöissä yhtenäisillä työkaluilla ja näkyvyydellä.

Näin se käytännössä näyttää:

Useita agentteja, yhtenäinen alusta. Järjestelmä ajaa Codexia, Claude Codea, OpenCodea ja muita agenttiharnesseja gVisor-sandboxeissa. Tämä tarkoittaa, että voit yhdistellä eri agentteja kustannusten, kykyjen ja tehtävätyyppien mukaan. Assembledin tiimi käyttää esimerkiksi GLM 5.2:ta rutiininomaisiin automaatiotehtäviin (halvempi, nopeampi) ja Codexia tai Claude Codea monimutkaisempaan käsityöhön. Sama infrastruktuuri, eri agentit eri töihin.

Työkaluliitännät heti käyttövalmiina. Järjestelmä yhdistää GitHubiin, Lineariin, Sentryyn, Slakiin, PagerDutyyn ja muihin. Esikatselut syntyvät helposti. Agenttisi eivät pyöri eristyksissä – ne on kytketty olemassa olevaan työnkulkuusi.

Turvallisuutta ilman hankaluuksia. gVisor-sandboxit tarjoavat eristyksen ilman täysien virtuaalikoneiden hallinnointia. Agentit voivat tehdä työnsä, mutta ne ovat kontrolloituja.

MIT-lisensoitu ja omalla palvelimella ajettava. Tämä ei ole isännöity SaaS, jonka kanssa sinun pitää luottaa koodiisi. Voit tarkastaa sen, ajaa omalla infrastruktuurillasi ja mukauttaa tarpeisiisi. Assembled sai innoituksensa Stripen Minionsista ja Rampin Inspect-järjestelmästä, mutta halusi luoda jotain, mitä laajempi yhteisö voi aidosti käyttää ja muokata.

Miksi tämä on tärkeää startupeille ja kasvaville tiimeille

Koodausagenttien yleistyminen vain kiihtyy. Ja kun tiimisi kasvaa, "henkilökohtainen skripti" -lähestymistapa rikkoutuu.

Tarvitset:

• Audit trailit – Mitä agentti oikeasti muutti?
• Toistettavuus – Pystytkö ajamaan saman tehtävän uudelleen?
• Tiedon jakaminen – Pystyykö kuka tahansa tiimissä hyödyntämään agenttityönkulkuja?
• Turvallisuus – Pääsevätkö agentit käsii vain siihen, mihin niiden pitäisi?

143.dev kohtaa nämä ongelmat suoraan. Ja se, että projekti on avointa lähdekoodia, tarkoittaa että sinun ei tarvitse lyödä vetoa infrastruktuuristaan startupin varassa, joka ehkä ei ole olemassa kahden vuoden päästä.

Suurempi kuva

Olemme siirtymässä vaiheeseen, jossa AI-koodaustyökalut eivät ole erikoisuuksia – ne ovat infrastruktuuria. Ja infrastruktuuria pitää hallinnoida kuin infrastruktuuria: näkyvyydellä, toistettavuudella ja koko tiimin pääsyllä.

Henkilökohtaiset koodausagentit ovat lähtökohta. Tiimin hallinnoima agentti-infrastruktuuri on se, missä juttu oikeasti alkaa.

Jos pyörität startuppia tai hallinnoit insinööritiimiä, kannattaa tutustua 143.dev:ään. Koodi on GitHubissa, ja se on MIT-lisensoitu. Ei vendor lock-in -riippuvuuksia, ei piilotettuja kuluja – vain avointa infrastruktuuria, jota voit mukauttaa siihen, miten tiimisi oikeasti työskentelee.

Joskus parhaat sisäiset työkalut ovat niitä, jotka kannattaa jakaa.