Coding Agents Are Changing GTM Operations, Just Not How You Think

My take, up front

Every AI-in-sales headline this year has been about agents replacing sellers. AI SDRs booking meetings, AI closing tickets, AI running full sequences without a human in the loop. I run one of those agents myself and I think that conversation is real, but it is not the biggest thing happening in GTM right now. The bigger thing is happening one level down, in the tooling layer, where the person who used to file a ticket with engineering or buy the fourteenth point solution of the year is now opening a terminal and building the thing themselves.

I build GTM systems for a living and I have watched this shift happen inside my own workflow over the last year. This piece is my case for why coding agents, not AI SDRs, are the change that quietly resets who builds GTM software, and what I think that means for how you staff and tool your revenue team.

The AI story everyone is watching is the wrong one

Ask most revenue leaders what "AI in GTM" means and they will describe an agent doing outreach: writing the email, sending the sequence, booking the call. That framing puts every AI conversation on a single axis, does it replace a rep or not, and it misses what is actually changing underneath. The tools a GTM team uses to run its motion, the enrichment scripts, the CRM hygiene jobs, the reporting dashboards, used to require either a vendor contract or an engineering favor. Both of those are now optional for a growing share of that work, because the person who owns the workflow can describe it in plain language to a coding agent and get a working first version the same afternoon.

That is a much bigger structural change than one more AI SDR vendor entering the market. It changes who is allowed to build, not just who executes.

The number that made me stop and check the math

The stat that made me actually sit down and write this: JetBrains' Developer Ecosystem research, surveying over 10,000 professional developers, found Claude Code's workplace adoption went from roughly 3% in April to June 2025, to 12% by September 2025, to 18% in January 2026, a sixfold jump in nine months. In the US and Canada specifically, adoption hit 24% in the same January 2026 wave. (JetBrains, April 2026)

Adoption curves that steep do not stay contained to the group that was surveyed. When a tool that started as "for engineers" moves that fast, it is almost always because non-engineers found a use for it too, and revenue teams are one of the loudest examples I see in practice. I did not need a survey to notice this. I noticed it because prospective clients started mentioning "we had someone build this in Claude Code" months before I saw a single vendor case study about it.

"Most loved" is not a vanity metric here

The other number worth sitting with comes from the Pragmatic Engineer's 2026 AI tooling survey, 906 respondents surveyed between January 27 and February 17, 2026. Claude Code came out as the "most loved" tool at 46%, more than double Cursor's 19%. (The Pragmatic Engineer, 2026)

I care about this number for a specific reason. Adoption tells you a tool got installed. Loyalty tells you people kept reaching for it once the novelty wore off, which is the harder bar to clear and the one that actually matters for whether a GTM operator sticks with building their own tooling instead of reverting to buying another SaaS seat. Tools people merely tolerate get abandoned the first time a workflow gets hard. Tools people love get pushed further into harder problems, which is exactly the pattern I have seen with revenue ops people who started with a small enrichment script and are now maintaining a full internal pipeline.

What an operator actually builds with a coding agent

None of this is theoretical to me. In my own stack, the tasks I now hand to a coding agent instead of a vendor tool or an engineering request fall into a short, repeatable list: pulling and normalizing a lead list against an ICP definition, writing a one-off script to dedupe a CRM field that got messy after a migration, building a lightweight dashboard that tracks reply rate by segment instead of waiting on a BI ticket, and drafting the first pass of a sequence variant that a human then edits for tone. None of that replaces a seller. All of it used to either not get built at all, because it was not worth a vendor contract for a one-off need, or it sat in an engineering backlog behind product work that always outranked it.

The pattern across every example: these are workflows that were too specific for off-the-shelf software and too small to justify a headcount request, so they simply did not exist before. Coding agents did not take a job away from anyone in these cases. They created capability that was not there.

Old GTM tooling model vs. the coding agent model

This is a software buying shift before it is a headcount shift

Here is the part I think most vendors in this space are underestimating. The threat from coding agents is not primarily to sales headcount, it is to the long tail of narrow point-tool software that GTM teams buy to solve one specific, specific-to-them problem. Nobody is going to build their own sending infrastructure or their own deliverability monitoring from scratch, that is real, hard, ongoing engineering with real stakes if it breaks. But the small utility that formats a CSV a certain way, or the internal Slack bot that pings a channel when a target account visits pricing, those are exactly the kind of narrow, single-purpose tools that a coding agent replaces the need to buy or requisition. If you sell a point solution whose entire value is "does this one specific small thing," that is where I would be paying the closest attention right now.

Where I have felt this building on the Forge stack

I run the Forge ecosystem, Salesforge for sequencing, Leadsforge for the list layer, Agent Frank for the AI SDR execution, and I have not tried to replace any of that core stack with something I built myself in an afternoon. Deliverability, warm inboxes and send-time logic are exactly the kind of hard, ongoing infrastructure I mentioned above, and that is precisely why I keep them on dedicated tools built for that job instead of a script I maintain solo. Where I do reach for a coding agent constantly is everywhere around that core: building the enrichment pass before a list ever hits Leadsforge, writing a script that flags accounts matching a specific ICP signal before they get loaded into a sequence, or standing up a small internal view of reply rates segmented in a way no off-the-shelf dashboard offers. The stack I actually run is Forge for the parts that need to be bulletproof, and a coding agent for the parts that need to be fast and specific to me.

The skill that matters now is not prompting, it is scoping

I get asked a lot whether GTM people need to "learn to code" now. My honest answer is no, but they do need to get good at a related skill: scoping a problem tightly enough that a coding agent can solve it in one sitting. The operators I have seen get real value out of this are not the ones who write clever prompts, they are the ones who can describe exactly what a script needs to input, output and do in between, the same way a good manager writes a clear brief for a contractor. That is closer to a product-thinking skill than an engineering one, and it is the actual bottleneck I see on teams that try this and stall out.

The quality control problem nobody wants to talk about

I want to be honest about the downside here because it is real. A script an operator builds themselves has no code review, no second engineer checking the edge cases, and no one flagging that it silently mishandles a weird CSV encoding until a list gets corrupted. I have seen this go wrong exactly once in my own work, a dedupe script that quietly dropped records with a specific character in the email field, and I only caught it because I happened to spot-check the output count against the input count. The fix is not complicated, treat anything a coding agent builds for you the way you would treat a new hire's first output: check it against a known-good sample before it ever touches a live list or a real prospect, every time, no exceptions.

What I would actually do about this next quarter

If you run a revenue team, I would not start by mandating anyone learn a coding agent. I would start by listing the narrow, specific workflows your team currently either lives without or has been waiting on an engineering ticket for, more than a quarter, for something too small to prioritize. Pick the least risky one, something that touches reporting or list prep rather than live sends, and let one operator who is curious try building it with a coding agent over a week. Review the output the way you would review a new vendor's first delivery. If it works, you have a repeatable pattern. If it does not, you have lost a week, not a quarter.

Where this goes from here

I expect the adoption numbers above to keep climbing through the rest of 2026, and I expect the GTM-specific use cases to keep showing up faster than any vendor case study documents them, because this kind of adoption happens person by person, not through a procurement process. The teams that get ahead of it are not the ones debating whether AI will replace their sellers. They are the ones who quietly let one curious operator start building the small, specific tools nobody else was ever going to prioritize for them.

FAQ