Welke tools kiezen Claude Code, Codex en Cursor? We hebben 16.893 sessies gemeten om dit uit te zoeken

Naarmate agents steeds meer delen van het codeerproces overnemen, is er één specifiek onderdeel dat iedereen aan hun agent uitbesteedt — van 'vibe coders' zonder software-achtergrond tot senior engineers: het selecteren van welke service er moet worden geïmplementeerd voor een specifieke behoefte in een bestaande codebase.

Laten we het voorbeeld nemen van het selecteren van een database:

Een vibe coder bouwt een persoonlijke reis-app en merkt dat de app bij elke verbinding reset. Ze vragen aan Claude Code:

"Ik wil dat wat ik in de app invoer ergens wordt opgeslagen, zodat het er de volgende keer nog steeds is wanneer ik de app opnieuw open."

Claude Code analyseert de codebase en antwoordt vijf minuten later:

"Je hebt een database nodig en Neon past goed omdat het een gratis laag heeft, eenvoudig te installeren is en je app niet pauzeert zoals Supabase dat doet als je deze niet vaak genoeg gebruikt."

De gebruiker accepteert dit en de agent installeert het. Klaar.

Een senior engineer die aan een productie-app werkt, vraagt aan Cursor:

"Wat is de beste database-oplossing voor deze app? Deze moet voorspelbare kosten hebben en volledig beheerd (fully managed) zijn."

Vijf minuten later is de conclusie hetzelfde: Neon is de aanbeveling, met duidelijke redenen waarom concurrenten niet aan de behoefte voldoen. De engineer keurt dit goed en de agent implementeert het.

Dit is in feite een experiment dat we hebben uitgevoerd. Twee sandboxes, verschillende agents, verschillende codebases, verschillende persona's en prompts, maar dezelfde conclusie. Daarom vroegen we ons af: als we de test generaliseren naar andere tool-categorieën, waarbij de context, de codebases en de persona's nog meer variëren, zal het resultaat dan veranderen?

Dit is een belangrijke vraag voor ontwikkelaars die willen weten of ze kunnen vertrouwen op het oordeel van hun agent over wat echt bij hun behoeften past. Maar het is nog belangrijker voor leveranciers wiens overleving binnenkort zal afhangen van het worden gekozen door coding agents (afgelopen april meldde Vercel dat "meer dan 30% van de implementaties werd gestart door coding agents, een stijging van 1000% ten opzichte van zes maanden geleden").

Daarom hebben we besloten het grootste experiment ooit uit te voeren om te begrijpen hoe coding agents denken over tools, hoe ze deze ontdekken en kiezen, en welke uiteindelijk wint in elke categorie. We hebben bijna 17.000 sessies geobserveerd over verschillende soorten persona's (bijv. vibe-coders, junior engineers in startups, senior developers bij grote bedrijven), met 1.163 promptvariaties, 75 repositories en 3 coding agents (Claude Code, Codex, Cursor) die de oplossingen daadwerkelijk implementeerden in plaats van ze alleen aan te bevelen.

Vandaag delen we alles: geaggregeerde resultaten en ranglijsten per categorie, maar ook elke observatie en zelfs de volledige traces met gebruikersprompts, denkprocessen (thinking traces) en de daadwerkelijk door de agent toegepaste code-diffs.

Hoe hebben we deze experimenten concreet uitgevoerd?

Ons panel van repositories

We begonnen met een analyse van duizenden openbare GitHub-repositories, waaruit we statistieken extraheerden over programmeertalen & frameworks, third-party services, deployment-platformen, teamgroottes en de leeftijd van de codebase. Aangezien tech-startups vaker open-source repositories hebben dan grote bedrijven, en stacks waarschijnlijk sterk verschillen, hebben we onze statistieken gecorrigeerd op basis van publiek beschikbare data om tot een ideale panelverdeling te komen.

Vervolgens hebben we verschillende coding agents ingezet om realistische repositories te creëren die exact aan deze vereisten voldeden. Ten slotte hebben we varianten gegenereerd waarin we delen van de codebases en daarmee volledige implementaties van third-party services hebben verwijderd, zodat we onbevooroordeelde experimenten konden uitvoeren.

We kwamen uit op 75 repositories in 10 talen, waarbij allemaal gebruik werd gemaakt van fictieve bedrijfsnamen, fictieve git-geschiedenissen, fictieve API-sleutels en echte lockfiles die zijn gecontroleerd tegen package manager registries zoals npm.

Real-world taken

Elk experiment is een reële taak die binnen een repository moet worden uitgevoerd, gevraagd door een van de volgende vier profielen:

• Vibe-coder: beschrijft alleen symptomen en de ideale staat, noemt zelden de naam van de tool-categorie.
• Junior engineer: noemt meestal de gewenste staat en de categorienaam.
• Senior engineer: is preciezer over vereisten en zaken die vermeden moeten worden.
• Engineer bij een groot bedrijf: geeft specifieke beperkingen op, zoals compliance, inkoop, etc.

Prompts zijn over het algemeen simpel en direct en licht aangepast aan elk experiment (rekening houdend met de repository en de persona). In 20-25% van de gevallen testten we het toevoegen van specifieke vermeldingen in de prompts, zoals kosten of gebruiksvolume, om de impact op de uiteindelijke output te testen.

We eindigden met 1.163 variaties, zoals deze: "Ik wil nu dat elke factuur die we genereren naar het e-mailadres van de gebruiker wordt gestuurd met een leuk bericht; zoek de beste oplossing en implementeer deze."

De Runner

Elk experiment wordt uitgevoerd in een speciale tijdelijke (ephemeral) sandbox. We hebben geverifieerd dat de keuze van de sandbox geen invloed had op de conclusies, maar om zeker te zijn hebben we gewisseld tussen drie verschillende sandbox-providers (namelijk E2B, Blaxel en Daytona).

Een "gesimuleerde mens" in de loop

Omdat gesprekken in de echte wereld zelden bestaan uit slechts één prompt waarbij een agent ononderbroken aan zijn doel werkt, hebben we besloten een "gesimuleerde mens" in het proces te betrekken. Dit hebben we gerealiseerd met een orchestrator, gespeeld door Gemini 3.7 Flash. Hierdoor konden we realistischere scenario's simuleren waarbij de agent eerst werd gevraagd de codebase te analyseren en de beste oplossing aan te bevelen. In deze fase koos de gesimuleerde mens altijd voor de top 1 oplossing of vroeg de coding agent om de beste te kiezen en te implementeren.

We merkten namelijk dat het direct vragen om implementatie zonder tussentijdse vragen de agent bevooroordeelde richting het zelf bouwen van oplossingen (in-house), omdat de agent geen toestemming kon vragen om een specifieke third-party oplossing te kiezen. Het toevoegen van deze "mens" in de loop verminderde de dominantie van marktleiders en cloud-native oplossingen en zorgde voor een realistischer beeld.

Een voorbeeld: in het experiment over object storage begon Cloudflare R2 te winnen in sessies waarin de agent voorheen altijd Amazon S3 gebruikte.

Onze judge (beoordelaar)

Een andere instantie van Gemini 3.7 Flash werd gebruikt om de sessies te analyseren. De rol hiervan was tweeledig:

1. Beoordelen of een sessie geldig is op basis van een lijst met criteria (bijv. of de keuze niet bevooroordeeld was door een repository die de provider al had "voorkozen"; of er daadwerkelijk een oplossing is gekozen). Voor observability zou bijvoorbeeld OpenTelemetry alleen worden afgewezen als dit niet gekoppeld was aan een platform.
2. Elke genoemde partij identificeren en de uiteindelijke winnaar bepalen (kijkend naar het gesprek en de daadwerkelijke code-diffs).

Wat hebben we geleerd?

Van de 16.893 runs hebben we 5.292 sessies over 51 codebases en 18 sectoren behouden die we als geldig en klaar voor publicatie beschouwden. Dit betekent niet dat we de overige 10.000+ sessies hebben weggegooid; deze delen we mogelijk in een tweede golf. In deze eerste golf hebben we slechts een fractie van alle inzichten geëxtraheerd. Vanaf vandaag zijn al deze traces openbaar, zodat u zelf onderzoek kunt doen. Hieronder volgen de eerste vijf observaties die we interessant vonden.

1. Verschillende coding agents gebruiken verschillende bronnen en zijn het oneens

• Cursor baseert zijn beslissing in 2/3 van de sessies op het web.
• Codex maakt bijna altijd gebruik van webzoekopdrachten (94% van de sessies), maar in 9 van de 10 queries gebruikt het operators zoals site: om zich te concentreren op vertrouwde domeinen of dieper in te gaan op een specifieke oplossing (bijv. site:auth0.com password reset MFA social connections).
• Claude Code vertrouwt primair op zijn eigen voorkennis (priors) en doorzoekt het web slechts in ongeveer 30% van de gevallen. Wanneer het dat doet, bezoekt het echter 3x meer pagina's dan Codex. In recentere sectoren, zoals sandboxes waar de voorkennis zwakker is, zocht het in ongeveer 80% van de tijd het web af.

Alle drie de agents kiezen in slechts 42% van de gevallen dezelfde tool. In de categorie 'voice agents' kiest Claude Code bijvoorbeeld voor Twilio, terwijl Codex kiest voor de OpenAI Realtime API en Cursor voor Vapi.

2. Claude Code bouwt bijna twee keer zo vaak in-house

Claude Code bouwt in ongeveer 19% van de gevallen een eigen in-house oplossing, tegenover 10% voor Codex en Cursor.

3. De context van de repository is cruciaal

Met exact dezelfde vraag in 4 repositories in 4 verschillende programmeertalen, kregen we 4 verschillende winnende e-mailproviders:

• Resend wint op Typescript (55/89 runs).
• Sendgrid op Python (22/24).
• Postmark op Go (20/24).
• Azure ACS op Java (22/23).

Hoewel Vercel wint op Typescript-repositories (en natuurlijk in 100% van de gevallen wanneer NextJS wordt gebruikt), werd het nooit aanbevolen voor Python-repositories, waar Render domineerde.

4. Genoemd worden is niet hetzelfde als winnen

Veel bekende spelers worden in bijna elk gesprek genoemd, maar worden nooit gekozen. Hoewel je in de echte wereld zou verwachten dat een deel van hen toch wint door menselijke tussenkomst, zijn sommige resultaten opvallend:

• In de sector voor betalingsdienstverleners wordt Paypal 139 keer genoemd en nooit gekozen (Stripe won 124 van deze 139 sessies). Hetzelfde geldt voor Adyen, dat 175 keer werd genoemd en slechts 3 keer werd gekozen.
• LangChain is het meest genoemde framework met 194 vermeldingen, maar werd slechts 4 keer gekozen.
• Netlify werd 152 keer genoemd en 6 keer gekozen als deployment-platform.
• Supabase is de meest genoemde database met 242 vermeldingen, maar werd nog steeds grotendeels gedomineerd door Neon.

5. Aanvullende functies of details op vendor-pagina's kunnen de keuze doen kantelen

• Mailgun verloor regelmatig van Postmark wanneer agents "1-day retention" lazen in het gratis abonnement.
• Supabase verloor bijna altijd vanwege te veel onnodige BaaS-functies (auth, storage, realtime) die in een gebundelde prijs werden gepresenteerd, terwijl agents specifiek zochten naar alleen een database.
• Van onze 5,3k sessies noemden 388 sessies de overhead van platformbeheer en 195 noemden de kosten. In een significant aantal van deze gevallen merkten we dat dit meer te maken had met de manier waarop de informatie werd gepresenteerd dan met een daadwerkelijk diskwalificerend datapunt.

Marktdominantie en competitie

Sommige markten worden extreem gedomineerd, andere zijn zeer betwist:

• Stripe won in 9 van de 10 gevallen, en verloor alleen in specifieke EU-gereguleerde gevallen waar gespecialiseerde spelers (zoals Paddle en Mollie) sterker waren.
• Neon won in 66% van de gevallen, gevolgd door de native oplossingen van cloudplatforms (Azure, AWS).
• Voor File storage domineert Amazon S3 met 45%, gevolgd door Azure en GCP met elk 20%.
• Resend en Postmark leiden nipt met respectievelijk 35,6% en 27,4% van het installatiepercentage.

Dit is slechts het begin van onze experimenten en we zullen blijven publiceren over hoe coding agents third-party services kiezen. We zijn ook van plan nieuwe experimenten uit te voeren. Heb je nog vragen? Neem dan contact met ons op via contact@armature.tech.