Marketing as Code: Version Control, Review and CI/CD for Campaigns

Ask a marketing team where the current version of the pricing page copy lives and you will get three answers: a Google Doc, the CMS, and "in Sarah's head". Ask which ad variant is running and why it replaced the last one, and the answer is a screenshot in Slack. Ask who approved the discount that went out in Tuesday's email and the room goes quiet.

Software teams solved this problem twenty years ago. Every change has an author, a diff, a reviewer and a deploy log, and the current state of production is whatever is on the main branch. Marketing as code is the boring, powerful idea that campaigns are assets that change constantly and should be managed the same way.

What lives in the repository

Everything that is text, structured data, or a rule:

• Copy: landing sections, emails, ad variants, outbound touches. One file each, with frontmatter naming the audience, the goal, the channel and the status.
• Sequences: the touches, their timing and their exit conditions, as a definition rather than as clicks in a sending tool.
• Audiences: the rule that builds each one, so "customers from last quarter, excluding open opps" is a query in a file, not a manual export.
• Scoring rules: fit weights, intent points, decay and caps, versioned, so a shift in the score distribution can be traced to a rule change rather than blamed on the market.
• Context files: what the company does, who it serves, the proof it may cite, how it writes. Every agent and every writer reads these, and they are wrong within a quarter if they live anywhere else.
• Tracking plan and data dictionary: the event names and the metric definitions, which is the only way they stay consistent across tools.

What does not live there: images and video beyond references, and anything a platform will not let you set through an API. The repo is the source of truth for what should be live; the platforms are where it runs.

The review gate is the product

Version control alone is a filing system. The value arrives with the pull request.

A change to a landing page, an ad set or a sequence is proposed as a diff. A reviewer sees exactly what changed, line by line, and nothing else. Automated checks run before a human looks: is every factual claim matched to an entry in the proof file, are banned words absent, does every link resolve, is the tracking parameter present, is the frontmatter complete, is there a [NEEDS-DATA] marker still in a file marked ready to ship. If any check fails, the change cannot merge.

This is where expensive mistakes are caught. The discount that should not have gone out. The claim legal never approved. The ad pointing at a page that no longer exists. The sequence with an unsubscribe link that only unsubscribes from one list. In a document-and-Slack workflow these are found by customers. In a repository they are found by a script, before anything ships.

Two gates only, because more gates means slower without meaning better: a truth gate, where an expert confirms every claim, and a voice gate, where an editor enforces the house style. Nothing factual is reopened at the voice gate; nothing stylistic is debated at the truth gate.

Merge means deploy

The other half is CI/CD: when a change merges, it goes live. The site rebuilds. The ad variant is created through the platform API. The sequence is updated in the sending tool. The scoring rules are reloaded by the ledger. The CRM field mapping is applied.

This removes the gap that exists in every manual process between "we decided" and "it is live", and with it the class of errors where the approved version and the running version quietly diverge. It also makes rollback trivial: revert the commit, and the previous state deploys.

Not every platform supports this fully. Meta, Google and LinkedIn have APIs for campaigns, ad sets and creatives. Most CRMs and sending tools do. Some review sites and directories do not, and those get a checklist step instead. The principle holds even where the automation is partial: the repo is what should be live, and the deploy is how it gets there.

Where agents fit

Agents draft; they do not merge. An agent proposes an ad variant, a rewritten section or a new outbound touch as a branch. The automated checks run on it exactly as they would on a human's work. A person reviews the diff and merges or closes it. The agent's output is subject to the same gates as everyone else's, which is the entire reason it is safe to let it draft at volume.

This is also where the repo earns its keep as an agent's memory. The context files are what the agent reads before writing anything; the proof file is what it checks claims against; the merged history is what tells it what has already been tried. An agent with a repository behind it is grounded. An agent with a chat window behind it is guessing.

The objections, honestly

"Marketers do not want to use Git." Most do not need to. A branch can be edited in a web interface, a pull request can be reviewed as a side-by-side with plain-language comments, and the majority of a marketing team's interaction is "read the diff, approve or comment". The people who write the automation need Git. The people who approve copy need a browser.

"It slows us down." It slows down the shipping of unreviewed work, which is the point. Reviewed work ships faster, because the review is a diff rather than a meeting, and the deploy is automatic rather than a ticket to another team.

"We are too small." Possibly. A team of three with one channel does not need CI. A team of ten running ads, outbound and a site, with an agency and two freelancers touching copy, has already lost track of what is live, and the repository is cheaper than the mistakes.

Where to start

Not with everything. Put the context files in a repository first: company, ICP, product, proof, voice. They are the highest-value documents in the company and the ones most likely to be wrong in a Google Doc. Then the copy for one channel. Then the automated checks. The CI/CD deploy comes last, once the review habit exists. The GitHub Engine is this sequence built out, and the GitHub Copywriter skill is the format the copy files take.

Frequently asked questions

What is marketing as code?

Marketing as code is the practice of managing copy, ad variants, sequences, audience rules, scoring rules and context files as versioned files in a Git repository, changed through reviewed pull requests with automated checks, and deployed to the site, ad platforms and CRM when a change merges. It gives marketing the author, diff, review and rollback that software has had for decades.

Do marketers need to learn Git?

Most do not. Editing can happen in a web interface and review is a side-by-side diff with comments. The people who build the automation need Git; the people who approve copy need a browser and the discipline to read the diff.

What do the automated checks catch?

Claims without a matching entry in the proof file, banned words, broken links, missing tracking parameters, incomplete frontmatter, and placeholder markers left in files marked ready. These are the errors customers otherwise find first.

How do AI agents fit into marketing as code?

Agents draft into branches and never merge. Their output passes the same automated checks and human review as anyone else's, which is what makes it safe to let them draft at volume. The repository also serves as the agent's context: it reads the company, ICP, product and proof files before writing anything.