Building GTM Is Starting to Look a Lot Like Building Software

Who would have guessed, three years ago, that a sales team’s ICP would end up in a GitHub repository?

Nobody. Me included. 😅

Yet on 2026-09-24, at our GTM Belongs in Git event in San Francisco, four speakers from four companies showed versions of the same thing on stage: scoring models, routing rules and agent instructions living as code, changed through pull requests, tested before they ship. Different teams, different stacks, same architecture.

That is not a coincidence. It is what happens when the interface changes.

The interface changed #

AI is turning natural language into code. You write one prompt, and behind it an agent may generate, modify and run thousands of lines.

So the visible interface gets simpler while the system underneath gets more programmable.

GTM is entering the same transition. Scoring, routing, enrichment, research, territories, context and agents used to be settings scattered across a dozen tools. They can now be expressed as one explicit system that agents build and operate.

Building GTM starts to look like building software when the rules that decide who you sell to, when and how stop living in tool settings and become code: written by agents from plain-language intent, reviewed as a diff, tested before deploy, and improved from outcomes.

Four shifts are driving it. Each one is already running in production somewhere, and I will show you where.

1. Why is code replacing configuration in GTM? #

Because configuration hides the system, and agents need to see it.

Traditional GTM is built by clicking (what we call ClickOps):

• configure a workflow in one tool;
• add a rule in the CRM;
• edit a scoring model in a third;
• connect another tool;
• document the reasoning somewhere else, if anyone does.

The system exists. It is just fragmented and implicit, and a good chunk of it lives in the head of whoever configured it.

When GTM becomes code, the same rules become explicit:

• this is how we define the ICP;
• this is how an account is scored;
• this is how it is routed;
• these are the signals that matter;
• this is what an agent is allowed to do.

Pause here, because this is where most people get the shift wrong. Nobody on the GTM team has to write the code. They describe the intent. The agent writes and changes the code underneath.

Natural language = the interface. Code = the operating layer.

Here is what that looks like on one rule. This diff was shown on stage at the event, one threshold inside an account-scoring function (simplified):

  // scoreAccount(): company size threshold for fit
- const MIN_HEADCOUNT = 100;
+ const MIN_HEADCOUNT = 50;

One line. A 75-person Series B SaaS company goes from 27 to 33 out of 40 on fit, from “good” to “strong”.

Buried in a settings screen, that’s a number someone typed into a field. In a repository, it is a named value with a history: who changed it, when, why, and what it was before.

Cole D’Ambra, head of growth at Plain, learned why that matters the hard way. He rebuilt Plain’s scoring model five times. Half of it sat in folders on a laptop, the other half in CRM settings, so one new signal could rewrite the whole thing, and nobody could say what had changed or go back to the version that worked. Moving it into a repository took under a day: one TypeScript file, more than 500 automated checks behind it, the Cargo workspace declared as code next to it, and every change, human or agent, arriving as a pull request.

The logic did not change. Where it lived did. And it stopped living only in one person’s head. The full migration path is in why GTM teams need to migrate their stack to Git.

Traditional GTM is configured across tools. Software-like GTM is defined as one system.

2. Why does versioning change how GTM is governed? #

Because one number can change which accounts your entire sales team works this quarter.

Go back to that headcount diff. Once revenue logic decides where reps spend their time, a small scoring edit can change:

• which accounts enter the TAM;
• which rep receives them;
• which campaigns they enter;
• which signals trigger action;
• where the team spends its week.

That is a production change. Most GTM stacks treat it like a preference: someone edits a field, presses save, and the previous state is gone.

Software went through this exact phase. Nobody serious ships code in 2026 by editing a production server by hand, and the reason is not taste. A meaningful change in software carries:

• a diff;
• an author;
• a reason;
• tests;
• an impact preview;
• an approval;
• a rollback.

Most GTM changes carry none of them.

Now add agents. A bad rule typed by a human creates a few mistakes before someone notices. A bad rule run by an agent creates the same mistake every morning, on every account. Karl Rafidimanana from TRA said it best at the event: when payments break, everybody hears about it, and when GTM breaks, the workflow keeps running.

Agents make governance more important, not less. The faster a system can change, the more it matters to know what changed, who changed it and why.

The best example I have seen of this in production came from Plain. A weekly job reads pipeline and intent data and asks whether the scoring model is suppressing accounts it should not. It caught one: a high-intent enterprise marked out of market by an engineering-density rule written in 2025. The agent opened a pull request lowering that bar from 30% to 20% for companies above 500 people, and before anyone approved it, ran the new rule across all 55,000 accounts in Plain’s CRM. Roughly 200 accounts would enter tier 3, 86 would climb to tier 2, and 23 would reach tier 1.

Then it waited. Cole read the preview and merged, and by the next morning a few hundred accounts sat in a new tier.

Look at what the agent did, and what it did not do. It did not run a workflow faster. It found a flaw in the system, wrote the fix, priced it, and asked. Aurélien broke down how to build the same job in let an agent propose changes to your scoring model.

The real upgrade is not an agent executing a workflow. It is an agent proposing a system change, showing its impact, and waiting for approval.

3. How are coding agents changing build vs. buy for GTM? #

They make the company-specific part cheap to build, and that moves the line.

Unpopular opinion: SaaS is not dead. I’m not 100% aligned with the “just build everything” crowd on my feed. What is changing is which part you buy.

Software used to be expensive to build. So companies bought standard SaaS apps and bent their process to whatever the UI allowed.

I lived the expensive version. At Spendesk, Aurélien and I built a revenue engine before Cargo existed: Snowflake, Hightouch and a lot of custom scripts. It fed 200+ salespeople across three markets and took the meeting-booked rate from roughly 5% to 15%. It worked because we could write the code ourselves. Most revenue teams could not, so they bought the closest app and adapted.

Coding agents change that equation. Companies can now build around:

• their own data model;
• their own context;
• their own workflows;
• their own operating model;
• their own competitive edge.

That does not mean rebuilding Salesforce, email delivery or a data warehouse. It means the boundary moves.

Buy the infrastructure. Build the company-specific system.

Engineering teams already work this way. They buy cloud, databases and payments, then build the product that makes them different. GTM is following:

Karl’s story is the cleanest example of the boundary moving. One of TRA’s clients churned an account-prioritization tool that cost around $50,000 a year. Bad scores weren’t the problem. No rule had a history, and no rep could get an answer to “why is this account ranked first?” What replaced it has three layers: Cargo holds the data and runs the hosting, GitHub holds the ICP and the scoring logic, and a purpose-built app is where reps actually work. The CRM keeps its job as the record. The new layer is where decisions turn into actions.

One nuance, because this is where builders over-rotate: not everything belongs in Git. John Kutay, who runs growth GTM engineering at Rippling, keeps the GTM brain in plain files for as long as he can: they come with history, humans can read them, and agents read them natively. Data graduates to a database or a warehouse once so many writers hit it at once that pull requests become the bottleneck.

Git defines how the system works. Cargo and your data systems hold its state and run it.

That is the real SaaS shift. Software is not disappearing. Rigid application layers are losing value, and programmable infrastructure is gaining it. We went deeper on what to build and what to buy in build vs buy for your GTM engineering stack.

4. What happens when GTM stops being rebuilt? #

It starts improving. That is what the first three shifts are for.

Cole titled his talk “How to stop rebuilding and start improving,” and he had earned the title: by his count, starting over cost him roughly two months of a year.

Code and versioning are not the outcome. They are the foundation that makes continuous improvement possible.

Traditional GTM improvement is slow:

• inspect results;
• schedule a meeting;
• form a hypothesis;
• ask someone to modify the workflow;
• launch again;
• wait for more data.

Weeks per loop, when the loop happens at all.

Software engineering built CI/CD to shrink the time between a change and its safe deployment. The GTM equivalent is a loop:

Observe → learn → propose → test → approve → deploy → measure

In practice, the engine:

1. reads replies, meetings, pipeline, calls and system errors;
2. spots a pattern or a failure;
3. proposes a change to scoring, policy, messaging or a workflow;
4. tests it against historical or live data;
5. previews the expected impact;
6. asks for approval where it is required;
7. deploys;
8. measures the outcome;
9. keeps the change, or rolls it back.

The Plain story above is one turn of this loop. What surprised Cole was the order of events. Moving to a repository solved durability first. Then, once every change was durable and readable, the agents started proposing improvements on their own.

At first, humans approve every meaningful change. Over time, agents take responsibility for more of the low-risk ones.

We run Cargo’s own GTM from a repository, so I pulled our numbers before writing this. Since 2026-07-30, the repo has merged 745 pull requests, and agents opened 599 of them. Of those 599, 363 waited for a person to merge them. The other 236 merged on their own, mostly reports and daily logs. That is the honest picture of the dial today: agents propose four changes out of five, and people still approve most of what ships.

That is the transition:

• from agents executing tasks
• to agents improving the system that decides which tasks should happen.

Stop rebuilding. Start improving.

It also changes what you should measure. I call it System Improvement Velocity: how quickly your GTM turns outcomes into a tested, deployed, better next version of itself.

The company with the best starting workflow does not necessarily win. The company whose system improves fastest does.

What this means for GTM teams #

GTM is starting to look like software because its operating model is changing:

1. Code makes the system explicit and programmable.
2. Versioning makes every change reviewable and reversible.
3. New build-vs-buy economics make company-specific systems worth building.
4. Continuous improvement lets agents progressively operate the engine, then improve it.

Operator move: learn data design before anything else. Asked at the closing fireside where someone without an engineering background should start, both speakers landed on the same answer: durable tables, unique keys, system design. Skip it and every new workflow bolts onto a Frankenstein that gets scarier to change each month.

And no, the end state is not a GTM team staring at code all day. At Rippling, the highest-value accounts moved back to human reps and automated outbound volume went down, while the systems scale whatever those reps discover. Humans push the frontier. Systems make the pattern repeatable.

Humans define intent and judgment. Agents build, operate and improve the system underneath.

Your revenue engine is already software. The only question is whether anyone can read it.

How Cargo fits #

Cargo is the infrastructure half of that split: connectors, data models, runtime, state and observability for revenue workflows and agents. The company-specific half (your ICP, scoring, workflows and agents) is declared as code in a repository you own and deployed with the Cargo CLI, which is what lets a coding agent propose the change as a pull request. Start with GTM as Code for the practice, or watch the full event recording.

FAQ #