Two research teams, seven months apart, pointed the same question at coding agents: when an engineer says "add payments," who actually chooses the vendor? The answer is that the agent does, at scale, and its most frequent answer is not a vendor at all. North Wayne reads the leaderboards as what they are - a procurement record nobody in the company signed. Her call is unusually specific, and it does not involve a policy document. — Muximus
Armature published a study yesterday that watched three coding agents add capabilities to 51 codebases and recorded what each one installed. Stripe took 88.4% of payment integrations. Neon took 66.3% of databases. AWS took 61.9% of cloud. The numbers are being read this week as market share.
They are better read as a purchase ledger. Each of those picks is a dependency some company now runs on, selected in a five-minute session, by a process nobody there designed, priced, or approved.
The framework: one act, two decisions
Start with what "the agent implemented it" actually covers, because it covers two things that a business would never normally handle the same way.
The first is engineering. Write the code, wire the calls, make the tests pass. That decision is reviewed. It arrives as a diff and a human approves it.
The second is procurement. Which vendor - or, frequently, no vendor at all. That decision produces a dependency, a renewal, a data-residency question, and a maintenance burden someone carries for years. It arrives as an import statement. Nothing about its shape says a purchase was made, so nothing in the company treats it as one.
These two decisions used to be separated by weeks and at least one meeting. They are now separated by nothing.
What the agents actually chose
The larger finding belongs to Amplifying, which ran Claude Code against four greenfield repositories in February: 100 open-ended prompts across 20 categories, five phrasings each, three model versions, three runs apiece. That produced 2,430 responses, 2,073 with an identifiable primary pick.
The report's own summary line is "The biggest finding: agents build, not buy." Custom implementations took 252 of those 2,073 primary picks, across 12 of the 20 categories. Counted as one option, "we will write it ourselves" was the most common answer in the study - ahead of GitHub Actions at 152 picks, ahead of any named product.
The aggregate matters less than where it landed. Asked to add feature flags, the agent built its own system 68.8% of the time against LaunchDarkly's 21.3% - and the report notes the model knew the alternatives, listing Flagsmith, PostHog and Unleash as second choices, and "still prefer building." Asked to add authentication, it built its own 47.7% of the time overall, and on the Python repository, 100% of the time.
Armature's panel, three different agents against a different set of repositories, found the same behavior at a lower rate: roughly 13% of all runs built in-house, rising to 52.3% in performance testing, 25.0% in agent frameworks, 23.1% in search and 22.6% in product analytics.
This column has argued before that cheap software makes build-vs-buy a capability question rather than a build order. That argument assumed a person weighing the two. Here the weighing happens without one.
Building authentication in-house is a decision most companies escalate. It gets a meeting, usually an argument, and occasionally a security review. In these runs it took five minutes and no meeting, because the question on the desk was "add user authentication" rather than "should we build auth."
One caveat travels with that figure. Amplifying hand-reviewed 50 of its custom-implementation results and found roughly 80% were genuine build-from-scratch responses, so the real rate sits somewhat below 12%.
The selection is not responding to the requirement
If the agent were weighing the business need, the same need would produce the same answer. It does not.
One of Armature's published prompts reads: "Now I need that each invoice that we generate gets sent to the user's email address with a nice message, find the best solution and implement it." The last nine words are where the money is. Asked that same question across four languages, the agents returned four different winners - Resend on TypeScript in 55 of 89 runs, SendGrid on Python in 22 of 24, Postmark on Go in 20 of 24, Azure Communication Services on Java in 22 of 23. Vercel won on TypeScript repositories and was never recommended on Python ones, where Render dominated. The requirement never changed. The file extension did.
The agents also disagree with each other. Across Armature's grid, all three picked the same tool in only 42% of cells. For voice agents, Claude Code picked Twilio, Codex picked OpenAI's Realtime API, and Cursor picked Vapi. Three defensible answers, three different vendors, one question.
Marketing copy moved outcomes on its own. Armature reports that Mailgun regularly lost to Postmark once agents read "1-day retention" on its free plan, and that Supabase kept losing database runs because its pricing bundled auth, storage and realtime when the agent had been asked only for a database. Of the published sessions, 388 raised platform management overhead and 195 raised cost, and Armature's read is that in a significant share of those, what triggered the objection was how the page presented the information rather than a genuinely disqualifying fact.
Then there is version drift. Within the same ecosystem, Amplifying watched Prisma fall from 79% of ORM picks on Sonnet 4.5 to 0% on Opus 4.6, while Drizzle rose from 21% to 100%. Celery went from 100% to 0%. Redis fell from 71% to 31% to 18% across three model versions. A model upgrade is not filed anywhere as a procurement event, and it changes the default supplier.
Amplifying is blunt about the mechanism. The picks, it writes, "reflect its training data, RLHF tuning, and system prompt, not independent evaluation of tool quality."
Where the default is real enough to treat as real
Not all of it is noise, and the distinction is worth money.
Payments is the cleanest case, because two different designs landed in the same place. Stripe took 88.4% in Armature's panel and 91.4% in Amplifying's. These are not blind corroboration - Armature cites Amplifying in its own methodology and separates the designs: Amplifying measured open-ended recommendations, while Armature's boards "also require an approved implementation and a production operating path." That makes the agreement stronger, not weaker. The second study raised the bar, added two more agents, ran seven months later, and got the same number.
The infrastructure layer behaves the same way. GitHub Actions took 93.8% of continuous integration in Amplifying's runs, with GitLab CI, CircleCI and Jenkins receiving zero primary picks between them. shadcn/ui took 90.1% of UI components. Vercel took every JavaScript deployment run.
In those categories, the agent's default is stable enough to function as a house standard, whether or not anyone in the house chose it.
Being known is not being on the shortlist
The result that should unsettle anyone with a long-standing supplier is what happens to the well-known products that lose.
In Armature's sessions, PayPal was cited 139 times and picked zero times; Stripe won 124 of those same 139 sessions. Adyen was mentioned 175 times and picked three. LangChain, the single most-cited framework at 194 mentions, was picked four times. Netlify: 152 mentions, six picks. In Amplifying's runs, Redux drew 23 mentions, two second-choice recommendations and no primary picks at all, and Express appeared in neither primary nor alternative recommendations.
Amplifying defines the gap precisely: "A mention means the model knows the tool exists but chose not to recommend it, even as an alternative."
An incumbent's brand recognition survives this transition. Its position on the shortlist does not necessarily. The discipline of evaluating the tool underneath the brand is one buyers were told to adopt. The agent adopted it first, and applied it to the buyer's own suppliers.
Both studies are sold by somebody
Neither source is disinterested, and they are not equally candid about it. That difference is part of the evidence.
Armature discloses at the top of its post: "Armature sells growth services to dev tools. This study is part of our broader work on how to influence coding agents choices and get products picked." Its methodology is specific and its session traces are published on a leaderboard where every percentage quoted here can be checked - and its product is the ability to move those percentages. Its prose and its board also disagree slightly, the post rounding Stripe to nine cases in ten where the board records 88.4%; the board is the number used here. Two of the three sandbox providers it rotated runs across, E2B and Daytona, sit on its own agent-sandbox leaderboard. Its headline 16,893 is the number of sessions run; the percentages come from the 5,292 it judged valid, with the rest held back for a possible later release.
Amplifying publishes no conflict statement of any kind, while operating a "For Vendors" page and a FAQ entry advising vendors whose tools received zero picks. Its scientific caveats, by contrast, are unusually careful: a revealed-preference study of one assistant rather than developer consensus or a quality ranking; extraction performed by Claude Code on its own output at roughly 85% validated accuracy; confidence intervals that exclude that extraction error; a JavaScript and Python panel with no Go, Rust or Java; and an explicit snapshot of early-2026 models.
What survives both interests is the behavior, not the ranking. Whether Neon deserves 66% is a question neither study claims to answer. That the choice is being made this way, at this volume, is not in dispute between them.
The control belongs in the repository, not in the policy
The most useful result in either study is sitting in the methodology, where nobody looks.
Amplifying wrote each category's prompts five different ways and found the picks 76% stable across the rewordings, and fully stable in payments, authentication, CI, databases and deployment. The same category asked in the same words on a different repository produced different winners: Vercel on every Next.js deployment run, Railway on 82% of Python ones; NextAuth.js on 91% of Next.js authentication runs, custom-built on 100% of Python ones. Armature's four-language email result is the same finding from an independent panel.
So the selection barely notices how the request is worded and responds strongly to what is already in the repository. That is an inference from the two studies rather than a result either one set out to test, and it points somewhere narrow and useful: a rule written into the repository - the agent instructions file, checked in, reviewed like any other code - sits on the side of the lever that moves. A procurement policy, a prompt template, and a paragraph in the engineering handbook sit on the side that does not.
The verdict
Do not write a policy about this. It will not bind, for the reason above, and it will consume the quarter that the actual fix needs.
Do two things instead.
First, name the two or three categories where "the agent built it" is not an acceptable answer, and write them into the repository rather than into a document. Authentication is the obvious first entry. Anything carrying regulated data is the second. Where an approved vendor already exists for a category, name it in the same file, because the agent will otherwise pick by file extension.
Second, go and read what is already in the repositories. Both studies point at the same uncomfortable possibility, which is that these decisions were made months ago, in commits that were reviewed carefully as code and never once as purchases. The vendors in the stack are already chosen. The only open question is whether anyone at the company knows which ones, or why.
Sources
- Armature, "Which tools do Claude Code, Codex and Cursor choose? We measured 16,893 sessions to find out," September 3, 2026: the write-up and the leaderboards, where the per-sector percentages live.
- Amplifying, "What Claude Code Actually Chooses: A Systematic Survey of 2,430 Tool Picks," version 1.0, February 2026: the full report.
