Selling Developer Experience When AI Changes the Rules

TL;DR: The DevEx product market is getting squeezed from four directions: AI makes features free, developers expect free tools, the interface layer is collapsing to APIs, and big companies build in-house because it got cheap. What survives might be trust, not code.

I’ve spent 20 years building tools for developers. Some as products, some as internal platforms, some as open source that a handful of people actually used. Through all of that, one thing stayed constant: developers are the hardest customers on earth.

They’ll rewrite your tool over a weekend just to avoid signing up. They’ll mass-migrate off your platform because of a single bad API decision. They’ll adopt your competitor not because it’s better, but because one blog post made it look cooler.

Now add AI to that mix. The DevEx product market is getting squeezed from four directions at once, and if you’re building developer tools right now, you should understand which walls are closing in.

Why Is Yesterday’s Feature Today’s Free Tier?

A year ago, you could charge for a code review bot. For a test generator. For a CLI that scaffolds boilerplate. Today? Claude, Copilot, and a dozen open source tools do all of that for zero dollars. The feature you spent six months building is now a prompt away.

This isn’t slowing down. Every month, the baseline of what AI gives away for free creeps higher. If your product is a thin wrapper around something a foundation model can do natively, you’re on borrowed time.

Why Won’t Developers Pay for Your Tool?

Open source already trained developers to expect free tools. AI made it worse. Why would I pay for your fancy dashboard when Claude Code gives me the answer in my terminal?

The bar for “worth paying for” used to be convenience. Now convenience is table stakes. Your DevEx product has to solve something that free tools genuinely can’t touch. That’s a much smaller surface than it used to be.

What Happens When Agents Replace Browser UIs?

Developers used to want UIs. Dashboards. Web apps with graphs. Now the best developer experience is often no interface at all. It’s an API that an AI agent calls. It’s a CLI that outputs structured data. It’s a config file that gets generated automatically.

If your DevEx product still assumes a human sitting in a browser clicking through workflows, you’re building for last year. The interface layer is collapsing. Agents are the new users, and agents don’t care about your beautiful design system.

Why Did Enterprise Stop Writing Checks?

This is the one that kills quietly. Large engineering orgs look at commercial DevEx tools and increasingly say: we’ll build it ourselves.

Sometimes your tool genuinely breaks at their scale. A thousand engineers hitting your code review bot reveals every edge case. But often it’s not even about bugs. Your tool doesn’t quite fit their monorepo, their deployment model, their specific flavor of CI. Close enough isn’t close enough when you’re standardizing across a thousand people.

And now there’s a third reason: building in-house got cheap. A senior engineer with Claude Code can prototype in a week what used to take a team a quarter. The NIH instinct that managers used to squash? It’s becoming rational. Why negotiate a vendor contract when you can just… build the thing?

So What Actually Survives?

Honest answer? No clue. And every conference panel I’ve sat on this year, nobody else knows either.

Something is forming though, even if it’s blurry. The tools that lasted in my career weren’t the technically best ones. They were the ones where I felt like I belonged to something. Where trust built up between the people making the tool and the people using it. Not trust in the code. Trust in the humans behind it. That part is hard to prompt your way into.

I think about Nix here. Nix has survived waves of “better” alternatives partly because of the technology, sure. But mostly because there’s a community that genuinely cares about the problem space. People who show up to NixCon year after year. Who argue passionately about the right way to package software. Who maintain thousands of packages for no money because they believe in the approach. That’s not something you can replicate with a well-crafted prompt and a weekend of coding.

Open source might be changing too. When someone can reproduce your tool with a good test suite and an AI assistant and an afternoon, what’s the moat? Maybe it was never the code. Maybe it was always the people.

Who Are You Actually Building For Now?

One thing keeps nagging at me: the users themselves are changing. Developers still exist, obviously, but what they actually spend their time on looks different than it did two years ago. And alongside them, AI agents are becoming primary consumers of the tools we build today. They call your APIs. They read your CLI output. They configure your systems.

I see this at Flox every day. We build developer environment tools. Our users used to be humans typing commands in terminals. Now a growing chunk of our usage comes from AI coding assistants that need a reproducible environment to work in. Claude Code needs nix develop to give it the same tools every time. Cursor needs consistent LSP servers. GitHub Copilot needs deterministic test runners.

A whole new layer of DevEx tooling will emerge just to manage the complexity that agents themselves create. Who manages the MCP servers? Who makes sure your AI assistant has the right context? Who builds the feedback loops between agent output and human review? These are DevEx problems. They’re just not the ones we expected.

We’re not losing DevEx. We’re watching its audience transform.

The Complexity Moat Is Shrinking

Some of the things we’re building right now feel safe. They’re genuinely complex. AI can’t handle them today. But nothing I’ve seen suggests the improvement curve is flattening. What AI can’t do this year, it’ll probably handle in one or two.

I watched this play out with code formatting. Then with code review. Then with test generation. Each time, the response was the same: “sure, AI can do the simple cases, but the hard cases require real engineering judgment.” And each time, the boundary of what counts as a “hard case” moved further out.

The complexity moat is real, but it’s shrinking. Betting your company on “this is too hard for AI” is a countdown, not a strategy.

What I’d Actually Bet On

Nobody has clean answers for any of this. The four walls I described are real. The squeeze is real. But so is the fact that every time developer tooling got disrupted, something new grew in the gap. I’ve been around long enough to see developer tooling get disrupted and rebuilt three or four times over.

If someone forced me to place bets, I’d pick three areas. First, tools that make AI agents more reliable. Not the agents themselves, but the infrastructure underneath them. Reproducible environments, structured outputs, observable pipelines. The kitchen, not the chef.

Second, tools that help humans and agents collaborate. The handoff between “AI generated this” and “a human reviewed and shipped this” is clunky everywhere right now. Whoever makes that seam invisible wins.

Third, community. Real community, not a Discord server with a bot. The kind where people teach each other, where maintainers know users by name, where the roadmap reflects actual pain instead of investor narratives. AI can’t fake that. Not yet. Maybe not ever.

Things will change. That much is certain. The DevEx market as we knew it is gone. But the need for great developer tools? That’s only growing. The tools will look different. The buyers will look different. The users might not even be human. But someone still has to build the kitchen.