Coding agents als team-infrastructuur: waarom 143.dev het verschil maakt

Laten we eerlijk zijn: als je coding agents gebruikt in je engineering team, heb je waarschijnlijk een beetje chaos.

De ene developer heeft zijn eigen MCP-configuraties, aangepaste prompts en persoonlijke scripts waar niemand anders bij kan. De andere draait zijn eigen opzet met Slack-notificaties en Sentry-integratie. Jouw "team-infrastructuur" is eigenlijk een verzameling persoonlijke oplossingen die bij elkaar worden gehouden door hoop en overgedragen kennis.

Assembled liep tegen dit probleem aan. Hun coding agents werkten prima voor individuele engineers—maar de workflow eromheen was rommelig. Heel rommelig.

Het probleem met persoonlijke coding agents

Wat er typisch gebeurt: Developer A heeft een Claude Code setup die verbindt met zijn GitHub fork en Linear. Developer B werkt liever met Codex en zijn eigen Slackmeldingen. Developer C heeft eigenlijk een ingewikkeld scriptsalam-gebouw dat alleen hij begrijpt.

Wanneer iemand vertrekt? Wanneer je wilt reproduceren wat de agent precies heeft gedaan? Wanneer je wilt controleren of de output van de agent overeenkomt met wat er daadwerkelijk is gecommit?

Dan zit je vast.

Het echte probleem is niet of coding agents nuttig zijn (dat zijn ze). Het is dat we ze behandelen als persoonlijke tekstbewerkers in plaats van team-infrastructuur. En dat veroorzaakt drie problemen:

1. Kennissilo's — Slechts één persoon weet hoe de agent is geconfigureerd
2. Reproduceerbaarheidsproblemen — Je kunt agent-acties niet makkelijk herhalen of controleren
3. Samenwerkingsbarrières — Wat voor de ene engineer werkt, helpt het team niet

143.dev: coding agents als gedeelde infrastructuur

Assembled bouwde een intern systeem om dit op te lossen, en heeft het nu open source gemaakt. Het resultaat is 143.dev—een platform dat coding agents omzet in voor iedereen toegankelijke infrastructuur.

De kernbenadering is slim: in plaats van agents lokaal op individuele machines te draaien, draai je ze in gestandaardiseerde omgevingen met consistente tooling en zichtbaarheid.

Zo ziet dat in de praktijk eruit:

Meerdere agents, één platform. Het systeem draait Codex, Claude Code, OpenCode en andere agent-harnassen in gVisor-sandboxes. Dat betekent dat je kunt mixen en matchen op basis van kosten, mogelijkheden en taaktype. Het team van Assembled gebruikt bijvoorbeeld GLM 5.2 voor routine-automatiserings-taken (goedkoper, snel) en Codex of Claude Code voor complexere handmatige werkzaamheden. Dezelfde infrastructuur, verschillende agents voor verschillende klussen.

Tool-integraties standaard ingebouwd. Het systeem verbindt met GitHub, Linear, Sentry, Slack, PagerDuty en meer. Previews zijn makkelijk te genereren. Je agents draaien niet geïsoleerd—ze zijn aangesloten op je bestaande workflow.

Beveiliging zonder gedoe. gVisor-sandboxes bieden isolatie zonder de hoofdpijn van het beheren van volledige VMs. Agents kunnen hun ding doen, maar ze zijn ingesloten.

MIT-gelicenseerd en zelf te hosten. Dit is geen gehoste SaaS waar je je code aan moet toevertrouwen. Je kunt het inspecteren, draaien op je eigen infrastructuur en aanpassen aan je behoeften. Assembled liet zich inspireren door Stripe's Minions en Ramp's Inspect-systeem, maar wilde iets dat de bredere community daadwerkelijk kon gebruiken en aanpassen.

Waarom dit belangrijk is voor startups en groeiende teams

Het ding over coding agents: ze worden alleen maar meer gebruikt. En naarmate je team groeit, werkt de "persoonlijke script"-aanpak niet meer.

Je hebt nodig:

• Audit trails — Wat heeft de agent daadwerkelijk veranderd?
• Reproduceerbaarheid — Kun je dezelfde taak opnieuw draaien?
• Kennisdeling — Kan iedereen in het team agent-werkwijzen gebruiken?
• Beveiliging — Hebben agents alleen toegang tot wat ze zouden moeten?

143.dev pakt deze problemen direct aan. En het feit dat het open source is betekent dat je je infrastructuur niet hoeft toe te vertrouwen aan een startup die over twee jaar misschien niet meer bestaat.

Het grotere plaatje

We gaan een fase in waarin AI coding tools geen noviteiten meer zijn—ze zijn infrastructuur. En infrastructuur moet beheerd worden als infrastructuur: met zichtbaarheid, reproduceerbaarheid en toegang voor het hele team.

Persoonlijke coding agents zijn een begin. Door het team beheerde agent-infrastructuur is waar het interessant wordt.

Als je een startup runt of een engineering team beheert, is het de moeite waard om 143.dev te bekijken. De code staat op GitHub en is MIT-gelicenseerd. Geen vendor lock-in, geen verborgen kosten—gewoon open infrastructuur die je kunt aanpassen aan hoe je team daadwerkelijk werkt.

Soms zijn de beste interne tools de moeite waard om te delen.