What Tech Stack Does Claude Code Choose? A Study and Its Limits

Coding agents can contribute to real codebases, but they also make choices about the tools we build with. I saw an example in which Claude falsely claimed PlanetScale had shut down its database service. A confident mistake like that matters when someone lets an agent choose their stack without checking its sources.

Amplifying ran a study of the tools Claude Code chooses for common development tasks. I find it interesting because recommendations are becoming a distribution channel: an agent can turn a vague request into dependencies and configuration before a developer has compared the options.

The report frames the agent as a new gatekeeper for tool discovery. That framing may be dramatic, but the underlying question is worthwhile: if the default answer determines what gets installed, whose tools are visible and what assumptions are baked into the project?

I have also been running my own deliberately self-interested benchmark: whether models mention my file-upload service, UploadThing, when asked about secure uploads in a Next.js app. I built the benchmark to promote a product I own, so its results are not an independent measure of the best upload service.

The Amplifying study used four example project types, 20 tool categories and three Anthropic models, with repeated runs and open-ended prompts that did not name vendors. Its report is at https://amplifying.ai/research/claude-code-picks/report. The results describe those tested projects and prompts, not every possible Claude Code session.

The projects included a Next.js application, a Vite and React application, a Python FastAPI data pipeline, and a Node.js command-line tool. Their existing dependencies give the agent useful context, so recommendations for one repository should not automatically be generalized to a different stack.

The study counted 252 custom or DIY primary picks among 2,073 extractable responses. That aggregate covers 12 categories, while any single named tool usually belongs to one category, so it is not a direct head-to-head comparison. The striking result is that agents often build a feature themselves rather than select a service.

When the agents chose third-party tools, common picks included GitHub Actions, Stripe, shadcn/ui, Vercel, Tailwind CSS, PostgreSQL and pnpm. The study also found that the existing ecosystem influenced results and that rephrasing the same category in one project often produced a similar choice.

The initial comparison used Sonnet 4.5, Opus 4.5 and Opus 4.6, all from Anthropic. It is not a survey of developer preferences, a quality benchmark or a way to distinguish training-data frequency from genuine suitability. A separate comparison examines Codex, which I discuss later.

Not every response chose a tool. Sometimes the agent asked clarifying questions or requested permission, especially for certain tasks. That can be a reasonable reaction to missing information; it should not automatically be scored as confusion or failure.

Feature flags were one of the strongest DIY categories, at roughly 69% in the report. Python authentication was also often implemented with framework primitives in these test cases. I find it amusing that the Claude Code product itself uses a separate feature-flag service, even though the agent often builds its own in the study.

DIY is not automatically wrong, but it moves maintenance and operational risk into your project. I would be especially cautious about rolling my own email delivery or real-time infrastructure without understanding the failure modes. A service can provide capabilities that a quick generated implementation does not include.

The implication for vendors is that an agent might assemble a solution from primitives instead of selecting an end-to-end product. Mitchell Hashimoto’s discussion of a building-block economy makes a related point: useful components can be adopted inside many products, not only as a single finished application.

In the study’s CI/CD category, GitHub Actions was the primary pick in roughly 94% of extractable responses; Stripe was about 91% for payments and shadcn/ui about 90% for UI components. Vercel was selected for all the JavaScript deployment cases in this particular test. These are conditional study results, not market shares.

I am pleasantly surprised to see Zustand as a frequent state-management choice. I like it for client state, while TanStack Query is valuable for fetching and managing server state. Those tools solve overlapping but different problems; the prompt should say what sort of state the application actually needs.

PostgreSQL leads the database picks. My own preferences differ: I like SQLite for some smaller cases, MySQL with Vitess for certain scaling needs, and Convex when its application integration fits. Those are opinions and tradeoffs, not a universal ranking; workload and operational experience should drive the decision.

The report lists tools across multiple ecosystems, so an overall percentage can be misleading if a tool only applies to one of them. FastAPI, Pytest and Next.js API routes are not interchangeable recommendations for every project. Compare choices inside the relevant stack before drawing conclusions.

For CI I often use alternatives such as Depot, Blacksmith or RWX, despite GitHub Actions dominating this test. Depot sponsored this video. A model’s recurring default is useful to observe, but it does not prove that other tools lack users or that the default is best for a specific team.

Stripe led payment recommendations, with some alternatives appearing less often. My own company uses Autumn for T3 Chat, and I disclose that I invested in it. For UI, shadcn/ui was a frequent pick; alternatives appeared, but the specific ecosystem and requirements still matter.

The deployment results vary by project: Vercel was the favored JavaScript pick in the test, while Railway appeared frequently for Python. I use Railway for side projects and find it inexpensive, but availability, plans and prices change, so verify current terms before deciding.

Tailwind was a strong styling default, with CSS modules and custom solutions also appearing. Sentry led observability, while Resend led email in the reported categories. The answer depends on the job: browser testing with Playwright, for example, is not exactly the same task as choosing a unit-test runner.

I have reservations about how some Supabase application state and permissions are managed, and I would rather keep more of that configuration in code. That is my assessment, not an established defect in every Supabase project. Teams should evaluate access control, migrations and operational requirements for themselves.

pnpm was the leading package-manager pick in the study. I like pnpm and Bun, although my team has encountered Bun issues in a monorepo. A package manager, a JavaScript runtime and a build tool are different parts of the toolchain; changing one does not necessarily change the others.

For forms, React Hook Form and Zod appeared in the results. They do different jobs: Zod validates data, while a form library helps manage form state and interaction. Regardless of the library, validation needs to reflect the actual application and its trust boundaries.

Authentication was a competitive category with many DIY picks. NextAuth appeared prominently for Next.js, and I wonder whether model recommendations reflect older naming or documentation. I personally like Clerk, WorkOS and Better Auth; I am also building an authentication service, so I have a direct interest in this category.

Caching choices also varied by stack: Redis appeared often, and Next.js applications sometimes received framework-specific caching recommendations. The report’s API-layer results likewise mix tools that can work together rather than always compete. Context explains much more than a single overall ranking.

UploadThing did not appear in the report’s displayed file-storage list. In my own separate benchmark, several Claude models did mention it for the specific secure-upload question I designed. That is useful feedback for me, but it is a product-awareness test, not proof that one model is smarter or that my product is universally preferable.

ORM recommendations also followed ecosystem: SQLModel was prominent in the tested Python projects, and Drizzle in JavaScript, with Prisma and SQLAlchemy also appearing. Background-job choices were more fragmented, including BullMQ, Inngest and Celery. Trigger.dev was another option I liked; it has sponsored my work.

The study found many custom feature-flag implementations, while LaunchDarkly and PostHog appeared as named options. In real-time, there was no comparable dominant choice: the results included DIY approaches, Supabase, server-sent events and Socket.IO. Different collaboration and delivery requirements deserve different designs.

Across the tested Anthropic models, some tools changed position. The report shows differences between Prisma and Drizzle within JavaScript projects, for example. I would not overread small samples or stochastic model outputs as a definitive trend, but it is interesting to ask whether newer models can surface newer tools.

A separate Amplifying comparison looks at Codex and Claude Code. In the examples shown, both often chose custom approaches, but they differed in runtime, search, scheduled tasks and edge compute. These are comparisons under particular prompts and versions, not a general claim that either agent is better at every task.

I noticed Claude was more likely to suggest Bun in the runtime comparison, while Codex more often selected Node.js. I speculate about why some vendor recommendations differ, but those frequencies alone cannot show that a company has deliberately suppressed a competitor or favored its own products.

My own UploadThing test produced strong recommendation rates for some models, although some runs timed out. I am explicitly promoting something I built, and I say the service was losing money at the time. Both the prompt and the incomplete runs limit what can be concluded from the result.

In one Next.js 14 example, Claude recommends Bun as a runtime while also discussing package installation. I criticize the answer for blurring runtime compatibility with install speed. Compatibility depends on exact versions, commands and deployment environment; the displayed answer alone does not prove that Next.js can never run on Bun.

The Codex example recommends retaining Node.js as the primary runtime and separately discusses faster package installation and a staged runtime experiment. I prefer that structure because it answers the actual question, distinguishes the alternatives and cites sources. One example is illustrative, not a comprehensive benchmark of both systems.

The edge-compute comparison also needs a better question. Putting compute closer to users is not automatically faster if each request must travel back to a centralized database. Measure the whole request path and data access pattern before choosing a deployment model.

The two agents also differed on image processing, rate limiting and other categories. A recommendation can be a starting point, but it needs review against security, maintenance, compatibility and cost. Neither a brand name nor a high recommendation frequency substitutes for that review.

Simon Willison argues that modern coding agents can work with newer or private tools by reading documentation, examining existing examples and testing their output: https://simonwillison.net/2026/Mar/9/not-so-boring/. I have seen similar behavior. Training-data familiarity matters, but it need not be the only source of knowledge.

I also put my own preferences in a global CLAUDE.md: TypeScript conventions, which commands I do not want run automatically, preferred package managers and a short list of technologies. That gives the agent context across projects. These are my personal defaults, not instructions that every team should copy unchanged.

The encouraging result is that an agent is not permanently locked to its first default. Give it your constraints, relevant documentation and examples, then review its reasoning and test the result. I am curious which of these recommendations readers find useful or concerning.