Derfor bør du slutte med personlige kodende agenter

La meg være direkte: hvis du har kodende agenter i bruk hos utviklerne dine, har du sannsynligvis et rotete kaos du knapt har kontroll på.

Hver eneste utvikler har sine egne MCP-oppsett, egendefinerte prompts, personlige automasjonsskript som ingen andre får tilgang til, og null oversikt over hva som faktisk skjedde da agenten kjørte. Din "teaminfrastruktur" er egentlig bare en samling personlige snarveier limt sammen av håp og intern kunnskap.

Assembled møtte akkurat dette problemet. Deres kodende agenter fungerte utmerket for enkeltutviklere—men arbeidsflyten rundt var rotete. Virkelig rotete.

Problemet med personlige kodende agenter

Her er hva som typisk skjer: Utvikler A har et Claude Code-oppsett som kobles til deres GitHub-fork og Linear. Utvikler B foretrekker Codex med Sentry-integrasjon og egne Slack-varsler. Utvikler C har i praksis bygget en Rube Goldberg-maskin av skript som bare de forstår.

Når noen slutter? Når du trenger å gjenskape hva agenten faktisk gjorde? Når du vil sjekke om agentens output matcher det som faktisk ble commitet?

Da sitter du fast.

Det virkelige problemet er ikke om kodende agenter er nyttige (det er de). Det er at vi har behandlet dem som personlige tekstredigeringsverktøy i stedet for teaminfrastruktur. Og det skaper tre problemer:

1. Kunnskapssiloer — Bare én person vet hvordan agenten er konfigurert
2. Reproduksjonshull — Du kan ikke enkelt spille av eller granske agenthandlinger
3. Samarbeidshindringer — Det som fungerer for én utvikler hjelper ikke teamet

Enter 143.dev: Kodende agenter som delt infrastruktur

Assembled bygget et internt system for å løse dette, og nå har de åpenkjernet det. Resultatet er 143.dev—en plattform som gjør kodende agenter til team-tilgjengelig infrastruktur.

Kjerneidéen er smart: i stedet for å kjøre agenter lokalt på individuelle maskiner, kjører du dem i standardiserte miljøer med konsekvent verktøy og synlighet.

Her er hvordan det ser ut i praksis:

Flere agenter, én plattform. Systemet kjører Codex, Claude Code, OpenCode og andre agent-rammeverk i gVisor-sandkasser. Det betyr at du kan mikse og matche basert på kostnad, kapasitet og oppgavetype. Assembled-teamet bruker for eksempel GLM 5.2 for rutinemessige automasjonsoppgaver (billigere, raskere) og Codex eller Claude Code for mer komplekst manuell arbeid. Samme infrastruktur, ulike agenter for ulike jobber.

Verktøyintegrasjoner rett ut av boksen. Systemet kobles til GitHub, Linear, Sentry, Slack, PagerDuty og mer. Previews er enkle å generere. Agentene dine kjører ikke i isolasjon—de er plugget inn i din eksisterende arbeidsflyt.

Sikkerhet uten friksjon. gVisor-sandkasser gir isolasjon uten bryet med å administrere fullstendige virtuelle maskiner. Agenter kan gjøre jobben sin, men de er inneholdt.

MIT-lisensiert og mulig å drift selv. Dette er ikke en hosted SaaS du må stole på med koden din. Du kan inspisere det, kjøre det på egen infrastruktur og tilpasse det til dine behov. Assembled ble inspirert av Stripes Minions og Ramps Inspect-system, men ønsket noe fellesskapet faktisk kunne bruke og modifisere.

Hvorfor dette har betydning for startups og voksende team

Her er greia med kodende agenter: de kommer bare til å bli mer utbredt. Og etter hvert som teamet ditt vokser, slår "personlig skript"-tilnærmingen feil.

Du trenger:

• Revisjonsspor — Hva endret agenten egentlig?
• Reproduksjon — Kan du kjøre samme oppgave igjen?
• Kunnskapsdeling — Kan hvem som helst på teamet dra nytte av agent-arbeidsflyter?
• Sikkerhet — Får agentene tilgang til bare det de skal?

143.dev tar tak i disse problemene direkte. Og det faktum at det er åpen kildekode betyr at du ikke trenger å satse infrastrukturen din på en startup som kanskje ikke eksisterer om to år.

Det større bildet

Vi går inn i en fase der AI-kodingsverktøy ikke lenger er nyvinninger—de er infrastruktur. Og infrastruktur må administreres som infrastruktur: med synlighet, reproduksjon og tilgang for hele teamet.

Personlige kodende agenter er en start. Teamadministrert agentinfrastruktur er der det blir interessant.

Hvis du driver en startup eller administrerer et ingeniørteam, er det verdt å sjekke ut 143.dev. Koden ligger på GitHub, og den er MIT-lisensiert. Ingen leverandørlås, ingen skjulte kostnader—bare åpen infrastruktur du kan tilpasse til hvordan teamet ditt faktisk jobber.

Noen ganger er de beste interne verktøyene de som er verdt å dele.