UI-first makes your business conform to the product. Code-first lets the system conform to your business. That choice decides how far agents can take your go-to-market.
"Software is shifting from interfaces that you operate to systems that produce outcomes."
Grinich opened his talk, “The Death of UI”, with that line. It describes software in general. Go-to-market is where it bites hardest.
For decades, the person doing the work had to learn how the tool expected it done: where to click, which object to create, which fields to map. Agentic software flips that. The person states the outcome; the agent works out how.
A revenue team’s operating model (who to target, how to score them, who owns what, what happens next) never had a real home. At best it was written up in a Notion page. The rest lived in people’s heads, rebuilt piece by piece in the settings of every tool. Agents force the question of where it should live, and there are two answers.
In UI-first GTM, the product defines the operating model, people configure it, the logic is spread across settings, tools and people, and agents work inside the paths the vendor built. In code-first GTM, the business defines the operating model, context, logic and infrastructure are explicit and live together, changes are tested and reviewed, and agents operate the system while people supervise outcomes and approve consequential changes.
Code-first does not mean your RevOps team has to learn to code. The agent writes the code. Your team says what it wants and checks what changed.
UI-first forces the business through the product’s model #
If you have ever tried to add a custom button to Salesforce, say one that helps reps find the best contact on an account or an opportunity, you know the feeling: you almost need a PhD in Salesforce to get there through the interface.
We know it first-hand. When the button connects to an outside tool (in our case, a Cargo tool that does the research), it takes eleven steps across credentials, schemas, flows, variables, actions and page layouts. Our internal guide for that one button runs to eleven screen recordings.
One sentence of business intent, “find the best contact for this account”, becomes eleven configuration steps in Salesforce: named credential, external service with an OpenAPI schema, screen flow, record lookup, variables, assignment, HTTP callout, confirmation screen, object action, page layout and the Cargo tool on the other end. You are not only building the workflow. You are first translating it into the product’s worldview.
None of this is a flaw in Salesforce. Every step exists for a reason: authentication, reuse, permissions, a platform that has to serve every kind of company the same way.
The cost is elsewhere. Before you build what the business wants, you learn how the product’s designers imagined it should be built, so even the first version is shaped by the product’s grammar. The question quietly changes from what is the right system for our business? to how close can we get with the objects, screens and flows this product exposes?
Routing makes it plainer. Sales leadership defines the territory policy in a spreadsheet: regions, segments, named accounts, and the exceptions everyone on the team knows about. Then an operator rebuilds that policy, rule by rule, inside a routing tool. Every rule is recreated. Every exception is mapped. Logic the tool cannot express gets a workaround, and from then on the spreadsheet and the configuration have to be kept in sync by hand.
When the policy and the product’s model disagree, the company either bends the policy to fit or adds manual steps to cover the gap. Nobody decided that. The interface did.
UI-first software turns business design into product configuration.
Agents expose the ceiling of UI-first software #
Many “AI-native” GTM products add an agent on top of the same architecture. The agent clicks through the interface, calls the actions the vendor exposed, fills existing fields and triggers workflows someone already configured.
That makes execution faster. It does not raise the ceiling: the agent inherits a surface designed for a person with a mouse.
Go back to routing. If the territory policy lives in a routing tool’s settings, an agent can trigger the router. What it cannot do is read the policy, notice that one segment keeps landing with the wrong team, write a better rule, and test it against last quarter’s leads. The policy is not something it can see, so it is not something it can improve.
The agent is rarely limited by its intelligence. It is limited by the operating surface it is given.
Grinich makes the same point from the builder’s side: agents do not click buttons, they go straight to the API.
So the usual question, how do we teach an agent to use our existing interface?, is the wrong one. The useful question is: what would the agent build if it had the context, the primitives and the guardrails to reach the outcome?
Code-first starts from business intent #
A code-first system exposes the building blocks of the revenue engine directly: company context, ICP and personas, data models, scoring, routing and territories, workflows, tools, agents, permissions, evals, and the infrastructure underneath. Each one explicit, readable and changeable.
The person states the job in plain language:
Qualify every signup, resolve it to an account, score fit and intent, and route high-value accounts to the right rep.
The agent builds the implementation around that objective, against the company’s own definitions of fit, intent and ownership, and proposes it as a change a person can read before anything runs. Nobody on the revenue team has to write the code. They have to know what they want and be able to judge what came back.
The tools do not disappear. They become primitives:
- Salesforce stays the system of record.
- Enrichment vendors provide data.
- Engagement platforms send.
- Slack carries notifications and approvals.
- A GTM runtime provides the connectors, execution, state and observability.
Even the Salesforce button changes character. Its credential, flow, action and layout all exist as metadata that can be written, reviewed and deployed from files. The configuration does not vanish. The agent does the translating, and the result is something a person can read, instead of eleven screens someone has to remember.
The new build-versus-buy line: buy the common infrastructure, build the operating logic that is yours.
Buy connectors, credentials, execution, state, retries, rate limits, permissions, observability and security. Every company needs them and none of them differentiate.
Build context, scoring policy, routing logic, agents, workflows and the surfaces where people make decisions. That is the operating model, and it should look like your company, not like your vendor’s roadmap. Where exactly that line falls, layer by layer, is covered in build vs buy for GTM infrastructure.
Language expresses the intent. Code is the durable system that carries it out. A prompt laid on top of opaque configuration is still UI-first: the agent needs a system it can inspect, change and test, not one more layer hiding how the company works.
The UI moves downstream of reasoning #
The old stack runs human, UI, backend, result. The emerging stack runs human intent, model reasoning, actions plus interface, outcome. The interface does not disappear; it moves from the front of the stack to behind the model’s reasoning. The concept is Michael Grinich’s, from his talk “The Death of UI”.
That does not make the interface go away. It changes its job: from a builder interface, made for a person who executes, to a cockpit, made for a person who directs.
A builder interface is a steering wheel: the human configures the workflow, drags the nodes, edits every rule and operates every step. A cockpit is for a system that drives itself: the human sets the objective, sees what happened and why, approves consequential changes, handles the exceptions, and guides and corrects the system.
At our recent event, Your GTM belongs in git, Karl Rafidimanana from TRA showed a sales OS his team built for a client. Signals and enrichment run in Cargo. The ICP and the scoring model live in GitHub. Reps work from a custom app that ranks every account they should care about, breaks the score down, and says why the account matters now. When a rep thinks a suggested contact is wrong for an account, they say so in the app, and that feedback goes back to the agent that picked the contact.
The CRM remains the system of record. The app is where the human decision happens. TRA’s build is written up in full in the missing layer between your CRM and your reps.
Code-first did not remove the interface. It moved it to where judgment is needed.
When agents run the system, the UI stops being the steering wheel and becomes the cockpit.
Code-first turns configuration into governance #
Once agents can change the revenue system, every consequential change has to be visible, attributable, testable, previewed, reviewable and reversible.
Take the most ordinary change in GTM: a scoring threshold. In a UI-first stack, someone edits it in a settings screen and it goes live. Nobody can say why it changed, who approved it, or which accounts moved.
In a code-first stack, the agent proposes a diff, and the system around it can explain the reasoning, test the change against live or historical data, show the blast radius, run the evals, ask a person to approve, deploy, measure, and keep the change or roll it back.
The business rule can be identical. The operating model is completely different.
That sequence already runs in production. At the same event, Cole D’Ambra, head of growth at Plain, walked through a pull request opened by an agent. A weekly job had found a large company showing strong buying intent but scored outside the target market. The cause was a fit rule: at least 30% of a company’s headcount had to be engineers, and this company sat at 24.5%. The agent proposed lowering the bar to 20%, scored the new rule against every account in the CRM, and showed exactly which accounts would move before anyone approved it. Then a person said yes. Here is how the job works.
An agent proposed lowering an engineering-density fit rule from 30% to 20% of headcount. Before approval, the change was re-scored against every account in the CRM: roughly 200 moved from outside the target market into tier 3, 86 from tier 3 to tier 2, and 23 from tier 2 to tier 1. The change was proposed, tested and previewed, then waited for a human to approve it before deploying, with rollback available. Simplified from the pull request Cole D’Ambra of Plain showed at “Your GTM belongs in git”, San Francisco, 24 September 2026.
Speed makes this more important, not less. As Karl put it, a broken payment flow throws an error; a broken scoring rule fails silently, on every run. The faster agents change the system, the more each change needs a diff someone can read.
One boundary is worth stating. Git holds the definition of the system: the rules, thresholds, prompts and workflows. It is not where every record lives. Accounts, activities and run history stay in the CRM, the warehouse and the runtime. What goes through review is the logic that decides what happens to them.
Code-first creates the foundation for continuous improvement #
The goal was never code. It is a system that can improve itself, under supervision.
The self-improving revenue engine runs seven steps: observe signals, CRM changes, replies and calls; understand them against your ICP and context; decide what to score, prioritize and do next; act by enriching, routing, engaging and alerting the owner; measure what was opened, booked and won; learn which signals and messages convert; and improve the system by proposing a change that a human approves.
In a UI-first stack, the last two steps belong to a person with a spreadsheet and a free afternoon, so they happen once a quarter if at all. In a code-first stack, an improvement is a change like any other: proposed, tested, previewed and approved.
Plain’s path shows the transition. Before git, Cole lost roughly two months of the past year to rebuilds: the scoring logic was split between local files and CRM settings, with no history and no safe way to add one more signal. Moving it into a repository took him less than a day, without an engineer. Now every change, from a person or an agent, ships as a pull request, and the agents propose improvements of their own. His talk title says it: stop rebuilding, start improving.
That is the real shift: from agents executing workflows to agents improving the system that decides what work happens next, with a person approving every consequential change.
A new division of labor #
The future is not software without interfaces. It is a new division of labor:
- Code defines the system.
- Agents operate and improve it.
- Humans guide and govern it, from a cockpit built for judgment rather than configuration.
That is how we build Cargo. Your repository defines the engine. Cargo provides the data, connectors, runtime and observability it runs on. Agents operate it, and your team governs it.