Därför behöver du bättre koll på dina kodande agenter

Låt mig vara ärlig: om du har kodande agenter i din tekniska organisation så har du förmodligen lite kaos på gång.

Varje utvecklare har sin egen MCP-konfiguration, egna prompts, personliga automationsskript som ingen annan kommer åt, och noll insyn i vad som faktiskt hände när agenten körde. Din "teaminfrastruktur" är egentligen bara en samling personliga genvägar som hålls ihop av hopp och informell kunskap.

Assembled stötte på exakt det här problemet. Deras kodande agenter fungerade utmärkt för enskilda ingenjörer — men arbetsflödet runtomkring var rörigt. Verkligen rörigt.

Problemet med personliga kodande agenter

Så här brukar det se ut: Utvecklare A har Claude Code inställt på sin GitHub-fork och Linear. Utvecklare B föredrar Codex med Sentry-integration och egna Slack-notifikationer. Utvecklare C har i praktiken byggt en Rube Goldberg-maskin av skript som bara hen förstår.

När någon slutar? När du behöver återskapa vad agenten faktiskt gjorde? När du vill granska om agentens output matchar det som faktiskt committades?

Då är du körd.

Det egentliga problemet är inte om kodande agenter är användbara (det är de). Det är att vi har behandlat dem som personliga textredigerare istället för teaminfrastruktur. Och det skapar tre problem:

1. Kunskapssilor — Bara en person vet hur agenten är konfigurerad
2. Reproducerbarhetsglapp — Du kan inte enkelt spela upp eller granska agentens handlingar
3. Samarbetshinder — Det som fungerar för en ingenjör hjälper inte teamet

Enter 143.dev: Kodande agenter som delad infrastruktur

Assembled byggde ett internt system för att lösa detta, och nu har de open sourceat det. Resultatet är 143.dev — en plattform som förvandlar kodande agenter till teamåtkomlig infrastruktur.

Kärnidén är smart: istället för att köra agenter lokalt på enskilda maskiner kör du dem i standardiserade miljöer med konsekvent verktygsstöd och insyn.

Så här ser det ut i praktiken:

Flera agenter, enad plattform. Systemet kör Codex, Claude Code, OpenCode och andra agent-harnesses i gVisor-sandlådor. Det betyder att du kan blanda och matcha baserat på kostnad, kapacitet och uppgiftstyp. Assembleds team använder till exempel GLM 5.2 för rutinmässiga automationsuppgifter (billigare, snabbare) och Codex eller Claude Code för mer komplext manuellt arbete. Samma infrastruktur, olika agenter för olika jobb.

Tool-integrationer direkt. Systemet kopplar till GitHub, Linear, Sentry, Slack, PagerDuty och mer. Previews är enkla att generera. Dina agenter kör inte i isolering — de är inkopplade i ditt befintliga arbetsflöde.

Säkerhet utan friktion. gVisor-sandlådor ger isolering utan huvudvärken med att hantera fullständiga virtuella maskiner. Agenter kan göra sitt, men de är begränsade.

MIT-licensierat och självhotat. Det här är inte en hosted SaaS du måste lita på med din kod. Du kan granska det, köra det på egen infrastruktur och anpassa det efter dina behov. Assembled blev inspirerade av Stripes Minions och Ramps Inspect-system, men ville ha något som den bredare gemenskapen faktiskt kan använda och modifiera.

Varför det här spelar roll för startups och växande team

Det är så här med kodande agenter: de kommer bara bli vanligare. Och när ditt team växer faller "personliga skript"-metoden isär.

Du behöver:

• Audit trails — Vad ändrade agenten egentligen?
• Reproducerbarhet — Kan du köra samma uppgift igen?
• Kunskapsdelning — Kan vem som helst i teamet dra nytta av agentarbetsflöden?
• Säkerhet — Får agenterna bara åtkomst till det de ska?

143.dev tar tag i de här problemen direkt. Och det faktum att det är open source betyder att du inte behöver satsa din infrastruktur på ett startup som kanske inte finns om två år.

Den större bilden

Vi går in i en fas där AI-kodningsverktyg inte längre är nymodigheter — de är infrastruktur. Och infrastruktur behöver hanteras som infrastruktur: med insyn, reproducerbarhet och teamgemensam åtkomst.

Personliga kodande agenter är en start. Teamhanterad agentinfrastruktur är där det blir intressant.

Om du driver en startup eller leder ett tekniskt team kan det vara värt att kolla in 143.dev. Koden finns på GitHub och är MIT-licensierad. Ingen vendor lock-in, inga dolda kostnader — bara öppen infrastruktur du kan anpassa till hur ditt team faktiskt arbetar.

Ibland är de bästa interna verktygen de som är värda att delas.