Het Besturingssysteem voor AI-agents Is Nu Strategische Infrastructuur

Iets waar we te weinig bij stilstaan: waar je AI coding agents draaien, waar hun transcripts worden opgeslagen, en hoe diffs worden beoordeeld — dat is allang geen productkeuze meer. Het is de basislaag voor moderne softwareontwikkeling aan het worden.

Toen ctx aankondigde dat ze open source gingen, ging het eigenlijk niet om één tool. Het was een teken dat steeds meer mensen doorhebben dat de infrastructuur voor AI-gestuurde ontwikkeling te belangrijk is om achter gesloten deuren te verstoppen.

Waarom Dit Groter Is Dan Je Gewone Open Source-release

Laat me uitleggen wat hier eigenlijk gebeurt.

Het ctx-team had aanvankelijk plannen voor een gesloten desktop-app met een freemium-model — gratis voor individuen, betaald voor teams en enterprises. Klassieke SaaS-aanpak. Maar nadat ze zelf met het product werkten en zagen hoe vroege gebruikers ermee omgingen, veranderden ze van gedachten.

En eerlijk? De timing voelt achteraf slim.

We zien de AI-toolsmarkt snel consolideren. Als je nieuws ziet als de mogelijke overname van Cursor door SpaceX, of de sluiting van Fable en Mythos, dan is de boodschap helder: agent tooling is nu strategische infrastructuur. Bedrijven proberen de hele stack te bezitten — van model tot harness tot interface.

Dat is een riskante omgeving voor developers en startups.

De Pi-filosofie Die Alles Veranderde

Hier is wat voor het ctx-team duidelijk werd, en wat eigenlijk voor ons allemaal zou moeten kloppen:

Pi — een minimale agent harness gebouwd rond extensiepunten, skills, prompts, thema's en herbelaadbare workflow-aanpassingen — liet zien dat gebruikers hun tools moeten aanpassen aan hun workflow, niet andersom.

Dit is het tegenovergestelde van hoe de meeste AI coding tools vandaag werken. De meeste agent harnesses zijn krachtig, ja, maar ze zijn niet ontworpen voor uitbreiding. Je kunt wel dingen aanpassen, maar het vereist "diepchirurgie" op de interne werking.

De conclusie van ctx? De ADE-laag heeft dezelfde filosofie nodig. Als daar de agent-sessies draaien, waar transcripts zich ophopen, waar diffs worden beoordeeld, en waar worktrees worden aangemaakt, dan moet het inspecteerbaar, uitbreidbaar en buigbaar zijn naar jouw workflow.

Het Echte Probleem: Er Bestaat Geen Perfecte ADE

Het ctx-team ontdekte iets waardevols van hun vroege gebruikers: iedereen wilde iets anders.

• De één wilde een schonere desktop-werkbank rond agents die ze al gebruikten
• De ander wilde striktere containerisatie
• Weer een ander wilde remote devboxes
• Sommigen wilden transcript- en provenance-tools
• Er waren gebruikers die een lokale merge queue zochten
• Enkele wilden programmeerbare agent-bekabeling
• Sommigen wilden dicht bij terminal-workflows blijven
• En er waren er die wilden dat de terminal helemaal zou verdwijnen

Deze diversiteit aan behoeften is geen bug — het is een feature. De ADE zou niet iedereen door één gezegende workflow moeten duwen. Het zou primitives moeten blootleggen die mensen kunnen samenstellen rond hun eigen processen.

Wat Dit Betekent Voor Het Developer-ecosysteem

Hier wordt het interessant, of je nu een solo developer bent, een startup, of een gevestigd team.

Wanneer je ontwikkelworkflow afhankelijk is van één gesloten model, één gesloten harness, of één gesloten applicatie, kan een externe beslissing van de ene op de andere dag een belangrijk deel van je omgeving weghalen. We hebben dit eerder in de techwereld zien gebeuren — afhankelijkheden van proprietaire platformen dragen altijd verborgen risico's met zich mee.

Open source gaat niet alleen om gratis software. Het draait om:

Duurzaamheid: Je workflow overleeft beslissingen van elk willekeurig bedrijf Aanpasbaarheid: Je kunt het gereedschap buigen naar je proces, niet andersom Gemeenschap: Verbeteringen komen van echte gebruikers die echte problemen oplossen Transparantie: Je kunt controleren wat er daadwerkelijk draait in je ontwikkelomgeving

De Technische Koers Om In De Gaten Te Houden

Voor wie geïnteresseerd is in de technische kant: ctx is momenteel een Rust-daemon met een desktop UI. De runtime-pad is snel omdat de daemon eigenaar is van sessies, transcripts, artifacts, diffs, workspace state, provider setup, containers en merge queue state.

De roadmap? Naar een Pi-achtig model voor de ADE-laag — extensiepunten, plugins, hot-reloadable workflow-onderdelen en door gebruikers eigenaar customization.

Het idee is slim: houd de core runtime in Rust waar het uitblinkt (storage, process supervision, worktree management, container boundaries), maar verplaats de customizatielaag naar TypeScript waar het zinvol is — adapters, workflows, UI en policy-edges.

Het Grotere Plaatje

Dat ctx open source gaat, is een signaal. Het zegt dat de developer tools-markt volwassener wordt dan de "bouw het gesloten en kijk of het aanslaat"-fase. De teams die deze infrastructuur bouwen, doorzien dat de waarde niet zit in het bezitten van de laag — maar in het maken van een laag die zo capabel en uitbreidbaar is dat het hele ecosysteem errond groeit.

Of je nu AI coding tools evalueert voor je team, producten bouwt in deze ruimte, of gewoon probeert sneller betere software te verschepen — dit is relevant. De tools die we gebruiken vormen hoe we bouwen.

Een open, hackbare, uitbreidbare ADE-laag betekent dat de toekomst van AI-gestuurde ontwikkeling wordt bepaald door de mensen die het daadwerkelijk bouwen. Daar mogen we best trots op zijn.

Wat denk jij? Wordt de ADE-laag de nieuwe strategische infrastructuur voor ontwikkelteams? Laat hieronder je gedachten achter — we horen graag hoe jij hiertegenaan kijkt bij het evalueren van AI tooling voor je projecten.