Why AI Agents Build Instead of Buy
A study by Amplifying AI ran Claude Code against 2,430 real repositories with open-ended prompts like "add feature flags," "add auth," "add a job queue" - without naming any specific tools. The headline finding got some attention: Claude Code has strong default preferences. But the bigger story got overlooked. In 12 of 20 tool categories, Claude Code didn't pick a tool at all. It built a custom feature flag system with config files and environment variables instead of using LaunchDarkly. It wrote JWT and bcrypt auth from scratch instead of pointing to Auth0. It spun up an in-memory TTL cache instead of reaching for Redis. The agent didn't buy. It built.
This isn't a fluke or a training quirk. It's what happens when writing code gets cheap, and the consequences haven't sunk in yet.
The buy-vs-build rule of thumb that's guided software teams for twenty years assumes one thing: developer time is expensive enough that paying for off-the-shelf tools almost always beats building your own. That assumption is breaking down. When writing code costs next to nothing, the math flips. Every outside dependency is something you have to maintain, secure, pay for, and work around when it doesn't quite fit your needs. Claude Code, unbothered by how many lines of code it writes, consistently picks fewer dependencies over less code - because in its world, code is free but dependencies aren't. And honestly, for a lot of cases, that's the right call. Human teams were making the wrong choice for years, not because they were bad at their jobs, but because their time was expensive enough to tip the scales.
The tools that did survive tell you exactly what has real staying power. Stripe hit 91% adoption, GitHub Actions 94%, shadcn/ui 90%. What these tools have in common: their value isn't in the code abstraction - it's in the stuff behind it. Stripe isn't useful because it has a clean API. It's useful because it handles fraud detection, PCI compliance, card network relationships, and chargebacks - things no single team can reasonably build. GitHub Actions isn't just a YAML runner; it works because it's baked into where code already lives. The tools that got cut - basic auth wrappers, feature flag services, simple job queues - were selling time savings on problems that are pretty straightforward to solve once coding is cheap.
The devtools boom of the 2010s is facing a structural problem that most of the industry hasn't caught up to yet. A huge number of tools were built on the pitch "save your engineers time on X." When engineering time stops being the bottleneck, that pitch gets a lot weaker. What'll survive tends to fall into a few buckets: regulatory moats (payments, identity verification, data residency), network effects (platforms deeply wired into how teams already work), and tools that get smarter from aggregating data across millions of users. Everything else - the neat wrappers around standard engineering problems - is increasingly something an AI agent will just write for you. The study's data makes the trend clear: Opus 4.6 builds custom solutions 11.4% more often than Sonnet 4.5, and in some categories the jump is dramatic. Prisma goes from 79% adoption on Sonnet 4.5 to 0% on Opus 4.6. Celery drops from 100% to nearly zero. Newer models build more and buy less, which means today's numbers understate where this is heading.
The takeaway for teams building software right now: the old buy-vs-build rule needs updating. "Is this core to our business?" still matters, but it's not enough anymore. The better question is: "Does this tool do something that code alone genuinely can't?" If the answer is no, you're paying rent on something an AI agent would just build. The companies most at risk aren't necessarily the ones with bad products - they're the ones whose whole pitch depended on developer time being scarce. That's changing fast, and Claude Code's preferences are one of the clearest early signals of what's coming.