Marketing as Code: Not a Move to GitHub. A Move to Agents.

This article was drafted inside a Git repository, the same kind of shared, change-tracked folder that software teams keep their code in. An AI agent wrote the first draft, working from a set of plain text files. No content management system was involved, and the moment the draft was approved, it published itself. That way of working has a name, and it is becoming one of the most asked-about ideas in marketing. Almost every article written about it gets the reason wrong.

Marketing as code is the practice of running a product marketing team out of a shared repository. The team’s knowledge, its brand and voice guidelines, its messaging, its campaign briefs, and even the instructions that tell its AI agents how to work, all live as plain text files that anyone can read and edit. Agents draft and operate against those files. It borrows a way of working software teams have used for over a decade, and adds the part that is new: agents that do the work. The repository is not the point. The agents are.

That last line is where most of the conversation loses the plot. The popular framing is that marketing teams are “moving to GitHub,” as if the shared folder itself were the upgrade. It is not. Move a marketing team into a repository and give them nothing else, and all you have done is hand a group of writers a tool built for engineers and made their week harder.

So is this just docs as code for marketers?

Almost, and the “almost” is the whole story. Marketing as code takes a way of working software teams already trust, keeping their words in plain text, tracking every change, reviewing before publishing, and points it at marketing’s material instead of a product’s manuals. The genuinely new part is not the shared folder. It is the agents that read all that knowledge and produce and ship the work.

The workflow itself has a decade of history. Engineers have long kept their documentation as plain text files right alongside their code, reviewed the same way the code is. The Write the Docs community named this “docs as code” around 2015, and teams like GitLab run their own manuals this way, treating a first draft of the docs as part of finishing any new feature. What none of it had was agents, because until recently there were none worth the trouble.

That is the line marketing as code crosses. The brand guidelines are text. The messaging is text. The instructions for each agent, what it does, what it is allowed to touch, how it should sound, are text too. A little of it is genuine code, the small scripts that generate social images, but most of it is plain writing a marketer can read and change. This article is the proof: written by agents that are themselves described in plain text, reviewed and published by the same repository it is describing.

How do you run a martech tool without ever opening it?

You pay for the tool and let an agent operate it for you. Buy access to the service, not a seat for a person. The agent works the tool directly, pulls back exactly what it needs, and nobody on the team ever logs into that tool’s dashboard again. The tool still does its job. The thing sitting in front of it is now an agent, not a person.

“

The future of martech is headless. People stop touching the tools at all. You pay for a service, an API key, and your agents operate it in the background, surfacing only what you asked them to surface. The dashboard you were supposed to open every morning becomes something no one on the team ever logs into again.

This is not science fiction, and it is not one company’s private bet. The connections that let an agent operate an outside tool are already an industry standard. Anthropic, the maker of Claude, introduced one such standard, the Model Context Protocol, in late 2024, and within a year the biggest AI companies, OpenAI, Google, and Microsoft among them, had all adopted it. The plumbing exists. What is new is pointing it at a marketing team’s tools.

The examples are ordinary. To size up search demand, an agent can pull the numbers straight from a data provider and drop the results into a file, for a tiny fraction of what a monthly per-seat subscription costs. To keep the customer database current, an agent can add, update, and look up records on its own rather than a person clicking through screens. In both cases an agent is doing the work a person used to do by hand, in the background, and reporting back.

There is a cost argument buried in here too. Marketers already use only about 42% of what their software can do, down from 58% a few years earlier, according to Gartner. A stack that agents operate changes what you are paying for: capability by the request, not a login you keep forgetting to use.

If it’s this good, why isn’t moving to GitHub the win?

Because the repository does nothing on its own. Move a marketing team into GitHub and change nothing else, and you have added process without adding any ability. Branches and reviews and approvals do not make a single piece of work better. The agents do. Most of the conversation has the cause and effect exactly backwards.

“

The solution is the agents. Fine-tuned skills with a stack of MCPs and CLIs they can actually operate. GitHub is just what makes that work: somewhere versioned, shared, and deployable for the knowledge to live. Moving a marketing team into a repo does not, on its own, make anything better. The repo is the floor you build on, not the reason you build.

The repository does earn its place, just not as the hero. It is where a whole team, and every agent, works from the same current source instead of a dozen slightly different copies. It keeps a history of every change, so you can see what moved and undo it if it was wrong. And it is what lets the approved work publish itself, with no one copying files around by hand. Those are real reasons to be there. They are also the ceiling of what the repository does by itself.

Where does marketing as code fit, and is this what a GTM engineer does?

It is the ground a GTM engineer stands on. The industry has been naming these pieces one at a time. GTM engineering is a new job title, the person who wires modern tools and AI into how a company goes to market. Marketing as code is the foundation that role works on.

The role is arriving fast. The company Clay coined the term “GTM engineer” in 2023, and it has spread through fast-growing software companies to roughly 100 job openings a month by early 2026. The pay is real and still being worked out: a 2026 study of 228 of these practitioners put the typical US salary around $135,000, while noting the market has not figured out how to price the role yet. Most of that energy has gone to sales operations so far. Product marketing is next, because the job is already getting more technical, and marketing as code is the ground it will grow on. You do not start with the whole thing. You start with one agent pointed at your own brand and messaging files, writing against them. The rest is what that grows into.

What does a marketing team running in a repo actually look like?

Like Calven’s own marketing, which runs this way today. The website has no content management system and no database behind it. Every article is a plain text file kept in the repository, checked automatically for mistakes, and published the moment it is approved. Agents write the work and the repository ships it. Here is the honest version of what that looks like in practice.

The content is written by a chain of agents, and it starts with a person. Someone on the team sets the direction: the topic, the angle, what the piece needs to do. An agent takes that brief and turns it into clear instructions for the rest of the chain. From there, one agent researches the subject and produces a sourced brief, another shapes the outline, another writes the draft, and then a fact-checker, an editor, and a panel of agents role-playing the target buyer all go over it. Nothing publishes until a person approves it. This article went through exactly that chain. A person decided what to say and whether it was good enough. The agents did the heavy lifting in between, and they are themselves plain text files anyone on the team can open and change, not a black box.

Research and admin work run the same way. To size up search demand, an agent pulls the numbers straight from DataForSEO for a fraction of a cent per query and saves them to a file the team keeps and reuses, currently a list of 143 tracked keywords, instead of paying for a seat in a tool like Semrush. To keep the CRM current, an agent runs every change through Attio, our customer database, adding records, updating them, looking things up, so no one has to open the Attio screens at all.

Reporting works this way too, and this is where it gets genuinely useful. Instead of anyone opening an analytics dashboard, an agent reads the website’s numbers from PostHog and posts a short weekly summary to the team’s Slack: how many people visited, where they came from, how many signed up. The report comes to the team, rather than the team going to find it.

One thing is worth saying plainly, because it would be easy to misread. These are Calven’s own internal agents, the way the team works day to day, not the product the company sells. The product is a different set of agents built for product marketers: competitive intelligence, positioning, and ideal customer profile agents. Everything above is proof that the approach works, not a tour of features.

When should a marketing team NOT do this?

When you are reaching for GitHub as a magic fix, which is the exact mistake this whole argument warns against. A repository adds real work to set up and learn, and it only pays that back when the agents, and the people who can direct them, are already in place. Without that, it is effort for its own sake.

There is a simpler starting point, and there is nothing wrong with it. If your team is not ready to build all of this, you can get a lot of the benefit from a tool like Claude’s Cowork: you teach an AI a few reusable skills, point it at your brand and messaging, and let it help with the work, all without a repository or anything technical. For many teams that is the smart way to begin, and it may be all they ever need. The full move described here only makes sense when two things are true: you have someone technical on the team, and the people on it actually want to go through the change. And it is a real change, with new tools to learn and a genuine learning curve. If the appetite is not there, forcing it will cost more than it returns.

A couple of other cases argue against it. A small team that publishes rarely and runs a handful of channels will spend more time climbing the learning curve than it ever saves. And work that is not really words or settings, the live event, the customer dinner, the brand film, does not get better by living in a repository. Marketing as code is for the part of the job that is knowledge and repeatable work. That is a large part of it now. It is not all of it.

The shift worth taking in is not that marketing is moving to GitHub. It is that marketing is gaining agents that can build and run against its own knowledge, and the repository is simply the place that knowledge can be trusted, tracked, and shipped. Calven’s own marketing works this way, and the product the team is launching is those product-marketing agents, not the internal ones shown here. Adopt the repository and never the agents, and you get all of the extra work and none of the payoff. The agents are the point.