The GTM for Developer Tools Is Breaking in Two Places at Once
Two shifts hit dev-tool go-to-market at once. The funnel was built for neither.
A product manager opens Cursor on a Tuesday afternoon. The app they’ve been shipping for the last three weeks needs transactional email. They type a prompt asking the agent to wire it up. Cursor picks an SDK, installs it, writes the integration, and they keep building. They never open your docs, and there’s no comparison post for them to read because they don’t know there’s a comparison to be made. They find out which provider they signed up for when the welcome email lands.
That provider is Resend, picked by an agent before they knew there was a choice to be made.
This is happening at scale right now to every developer-facing company, and most of them are still running the GTM playbook that worked five years ago. The playbook isn’t exactly wrong, it’s just covering a smaller share of the actual audience than it used to.
What’s happening across the industry is that two distinct shifts hit dev-tool GTM at the same time. Most companies are only responding to one of them, or neither. In this article, I work through both shifts, what breaks underneath them, and what engineering, product, and DevRel teams should be doing differently. Today, we cover:
What the old funnel looked like, and where it breaks
Developers are starting to ask, not search
There’s a new persona in your funnel
What engineering and product do differently, together
What DevRel becomes when the old shape is gone
The old funnel, and where it breaks
The traditional dev-tool funnel is well-understood. Engineering builds the product, and product packages it into something adoptable. DevRel runs the last leg to the developer through docs, blog posts, conferences, sample apps, Discord, podcast appearances, and Twitter presence. Developers evaluate the tool against alternatives by searching, reading, asking peers, attending talks, and trying things in side projects. When they’re convinced, they bring it to work, and the company buys.
Each function in that chain owned its segment cleanly. Engineering stayed mostly inside the company, talking to developers through interfaces rather than in public. Product worked with a few design partners. The audience-at-scale conversation belonged to DevRel. The handoff was clean, the skills were specialized, and the metrics were attributable.
That model is breaking, and the interesting part is that it’s breaking in two distinct ways at once. One break is about who buys. The other is about how the buying decision gets made. They look related from a distance, and they compound in practice, but they’re separate problems and they need separate responses.
Developers are starting to ask, not search
The developer is still the decision-maker for the kinds of tools developers buy. That part of the funnel is intact. What’s changing is the research and evaluation layer underneath the decision, and it isn’t changing evenly.
Plenty of developers still evaluate the way they always did. A senior engineer who has shipped auth six times does not open Claude to ask which provider to use. They decide from hard-won experience, sometimes from a conversation with someone they trust, sometimes from a prototype thrown together on a Friday. That developer is still reachable the old way, through conferences and peers and the kind of deep documentation you read when you are comparing things seriously. The old funnel still works on them, which is exactly why you do not switch it off.
But a growing share of developers don’t work that way anymore, and it isn’t only juniors. By Stack Overflow’s 2025 developer survey, about half of professional developers were using AI tools every day. They open Cursor or Claude, ask for a recommendation, get a shortlist of two or three options with reasoning, and start building with the one that fits. The evaluation work that used to take two weeks takes about ten minutes. They still make the call, and they’re often well-equipped to catch a bad suggestion. What changed is that the agent assembles the shortlist before they apply any of that judgment.
That’s the same behavior the builder shows, just with more ability to second-guess the output. Which means this isn’t a clean split between developers and a new audience. It’s a shift in where research happens, and it’s already moved through part of the developer population. The builder is the far end of it, not a separate species.
The interesting consequence is that this group of developers didn’t lose the decision. The dev-tool company lost the consideration set. If the agent doesn’t reach for your product when it builds the shortlist, you’re not evaluated. You don’t lose on the merits. You lose by being absent.
What determines whether the agent reaches for your product turns out to be a different kind of work than what DevRel teams optimized for. The agent doesn’t care about your conference talk. It cares about your docs being self-contained, your error messages being clear, your SDK being internally consistent, your examples being copy-pasteable, and your product being commonly mentioned in the training data and current retrieval results the agent has access to. That last point is partly about brand and presence. The first four are engineering and product work, not marketing work.
The old funnel treated docs as a content surface DevRel could rewrite at will, and that no longer holds. The product itself has to be legible to a non-human reader, and legibility is not something a content team can patch in from the outside.
Resend is the cleanest example of this I can point to. The whole product feels designed to be picked up by an agent and dropped into a builder’s project without modification. The API surface is small enough that the agent can hold it in context. The error messages tell the agent what to do next, and the SDK names are consistent enough to guess. None of that is marketing copy. All of it is engineering and product decisions that happen to also be the most powerful GTM move the company has made.
There’s a new persona in your funnel
The last section ended on the builder as the far end of the research shift. This section is about what that far end actually looks like, because the behavior is the same but almost everything else about reaching this audience is different.
The builder is the term I’ll use here for the non-developer who ships production software, and the persona itself is not new. Webflow, Bubble, and Glide spent the last decade serving people who build real things without writing much code. What changed is the ceiling on what they can build. The no-code user used to be capped by whatever their platform could do. The AI-era builder is not capped the same way, because the agent will reach for whatever infrastructure the job actually needs.
Picture the product manager who lives in Cursor. They scope a feature, describe it to the agent, and push it to staging without filing a ticket. When the feature needs authentication, the agent picks a provider and wires it in, and the PM approves a working result rather than evaluating the provider. Or picture the operations lead building internal dashboards in Claude, provisioning a database and a hosting layer they could not have configured by hand two years ago. Same pattern in both cases: the person directs the work, the agent does the wiring, and real infrastructure gets bought along the way.
These people are shipping real software and paying for the infrastructure under it: auth, email, databases, observability, hosting. And this is not a fringe group. Vercel’s data on vibe coding put the non-developer share of users at 63 percent, and Lovable, one of the prompt-to-app builders, reported close to 8 million users with 100,000 new projects created every day by late 2025. They are a real and growing share of dev-tool revenue, and they do not show up in the traditional funnel, because the funnel assumes the buyer is a developer. The old channels do not reach them either. They are not at your conference or in your Discord, and an SDK comparison post is written in a vocabulary they were never given.
For this audience, the agent isn’t one input among many. It’s frequently the only input, which makes agent legibility from the first shift even more existential here. There’s no second path through the funnel for builders.
The offline problem is the other half. Even when builders do gather in person, they don’t gather where developers gather, and the developer conference circuit that dev-tool companies have spent twenty years learning doesn’t reach them. The venues that do reach them are still forming. This is net-new GTM work, not a refinement of the developer playbook, and most companies haven’t started building it.
Both shifts land on different teams. Engineering owns the product surface that determines whether the agent reaches for you. Product owns onboarding and pricing for an audience that doesn’t procure software the way developers do. DevRel owns audience definition and GTM motions for venues that didn’t exist on the marketing calendar two years ago.
What engineering and product do differently, together
The place to start is the product surface itself. The API, the SDK, the error messages, the example code, the docs structure, the onboarding flow, the pricing page. All of this is read by agents and by builders, and every decision about it is now load-bearing for whether the company gets picked. Most of this work used to be possible to split cleanly between the two functions. Here is what each piece needs now, and where the line between engineering and product actually falls.
The API and SDK layer is where the agent first meets the company, and it’s mostly engineering work shaped by product judgment. Naming consistency, error messages that tell the caller what to do next, SDK ergonomics that don’t require the reader to hold five concepts in their head at once. Vercel is worth studying at the framework and tooling layer. The conventions in create-next-app, the way errors surface in the CLI, the defaults across their SDKs. Design choices that read as developer experience polish but also happen to make the product clearly legible to an agent picking it up cold.
Onboarding is where the two personas split, and the design implications haven’t been worked out at most companies. The developer wants minimal friction to API key plus first request. The builder wants the agent to be able to wire up the integration without ever seeing an API key directly, or with a flow that hides the key behind a manageable abstraction. Most onboarding flows handle the developer case well and the builder case badly. This sits mostly with product, but only because engineering shipped an API surface clean enough to wrap two different flows around.
Pricing and packaging is where builder procurement breaks the existing model, and it sits with product more or less entirely. Developer procurement is well-understood, and builder procurement works nothing like it. Builders often don’t go through company procurement at all. They put it on a credit card and scale up over months. They need pricing that doesn’t require a conversation with sales until they’re big enough to want one. The pricing models that worked for developer-led adoption need a second variant for builder-led adoption, and a lot of dev-tool companies are losing builder revenue at the procurement step without realizing it.
Instrumentation is the most fixable of these problems, and the one most worth fixing first. The metrics product teams have leaned on for years correlate with developer adoption and not with the new audience. GitHub stars, npm install counts, sign-up rates from doc pages. Builders don’t generate those signals, because they don’t star repos and they don’t land on doc pages from search. Agents don’t generate them either, so the dashboard ends up tracking only the developers who still behave the old way. The new instrumentation is agent-traced usage, SDK telemetry that tells you when the product is being wired up through a tool like Cursor, and conversion rates from builder-shaped sign-up flows that look different from developer ones. Run your own product through Cursor and Claude and watch where the agent stumbles. If it can’t confidently use your product, builders won’t either, and most teams have never actually checked.
Docs belong with this surface too, and they belong to engineering. The most expensive docs to fix are the ones papering over a bug in the underlying product abstraction, where the doc team has spent three years compensating for something only engineering can actually fix.
Public communication used to sit entirely with DevRel, and it doesn’t anymore. When engineers show the product in public, in a walkthrough video, a livestreamed build, a thread explaining a design decision, that material becomes part of what agents and builders encounter when they go looking. It also becomes part of what the next model trains on. Engineering teams that treat public communication as someone else’s job end up invisible to both audiences at once.
What DevRel becomes when the old shape is gone
The DevRel role gets narrower. The DevRel practice gets bigger. Engineering takes on public-facing work that used to be DevRel’s, and product takes on audience definition that was partly DevRel’s. The function called DevRel ends up smaller, even as the total customer-facing work across the company goes up.
What replaces the work that moved out is upstream work the function never had a clean home for before. Doc architecture as a product decision, not a content decision. API design review from an audience perspective. Reviewing onboarding flows for the agent and the builder, not just the developer. These were always adjacent to DevRel and they were always somebody else’s call. They aren’t somebody else’s call anymore.
The other half is net-new GTM motion for the builder. The conference circuit DevRel spent twenty years learning was built for developers, and it does not reach the builder. The venues that do are smaller and less established: builder meetups, founder gatherings adjacent to the no-code world, AI tinkerer nights. Resend, the email API, said its 2026 plan includes hosting its own meetups and launching a community program, which is one small concrete example of a company building this muscle before it is obvious. Sponsoring these venues is cheap and noisy, and the ROI is hard to attribute. The company that finds them early gets an advantage that compounds, and the company that waits for the builder circuit to be legible will be late to it.
Somebody has to lead the rebuild, because nobody else has the full view. Engineering sees the product clearly but not the funnel. Product owns the roadmap but not the channels. DevRel is the only function that watches the audience, the channels, the agents, the docs, and the funnel as one system, and notices when the connections between them fail. That is the job that just got created. The title for it doesn’t exist yet at most companies, and the work is showing up anyway. DevRel either steps into that job, or watches a Head of AI GTM role get posted next quarter to do it without the function’s name on the door.
Takeaways
A few things I’ve come to after working through this and watching how it’s playing out across companies I talk to.
Some companies are carrying structural debt into this, and they should name it before they reorganize anything.This is the part that’s hard to fake. A company where engineering, product, and DevRel had been working closely for years didn’t need to break a wall, because the wall was already porous. A company that ran a strict relay model for a decade is reorganizing for a world that doesn’t accept relays anymore, and the reorg is harder than the new model itself. If you’re at a company in the second bucket, that history is the first thing to be honest about.
The dev-tool category is bifurcating, and most companies will end up serving one of the two halves badly.Building well for developers and for builders is genuinely two jobs. Onboarding, pricing, content, the venues you show up in, all of it splits, and underneath the surface the product decisions pull in directions that don’t optimize cleanly for either persona alone. Most companies will pick a side without admitting they picked one, because doing both well is harder than doing one well. The companies that succeed at both will look unusual three years from now, and the ones that quietly defaulted to one will have a worse business than they realize.
What disappeared is the clean handoff between functions, not the functions themselves. The temptation when work starts sharing across teams is to merge the teams, and I see companies reaching for that move. It’s the wrong one, because engineering, product, and DevRel still have distinct expertise that doesn’t survive being collapsed into a single growth pod. The model that broke is the relay where engineering builds and tosses to product, product packages and tosses to DevRel, DevRel distributes and tosses to the funnel. The companies adapting well kept the functions and broke the wall between them. The ones reorganizing into mega-pods are mistaking the symptom for the cause.
A last thought, because I keep coming back to it. The PM in the opening, the one whose agent picked Resend, didn’t lose anything in the experience. They got the integration they needed. The agent did a competent job, and the product worked. There’s no friction in their experience to alert anyone that the funnel didn’t reach them. A competitor lost that customer and has nothing in their data to point at. The lost deal never entered a pipeline to begin with, so there’s no event to review and nothing drops in a funnel report. When the old funnel failed, you could usually see it happening. This version doesn’t give you that, and the companies that wait for a clear signal before they act are going to be waiting through a lot of quarters where the only thing wrong is that the numbers are quietly lower than they should be.
Thanks for reading!