AI blog automation ownership: a named model for who drafts, who holds the merge gate, and who owns voice, sized for a 5-person startup and a 200-person company.
A founder installs an AI blog writer, it opens its first pull request, and then nobody in the company is quite sure who's supposed to click merge. That's not a writing-quality problem. It's an org-chart problem, and most startups have never actually answered it. AI blog automation ownership sits at an odd angle to how teams already divide labor: marketing owns the blog, engineering owns the repo it now lives in, and DevRel, where it exists at all, owns neither and both. This post is a named ownership model, not a tool pitch: who drafts, who technically holds the merge gate, and who owns voice, sized for a five-person startup with no committee and for a two-hundred-person company with an actual RACI.
A modern AI blog writer commits a file to a Git branch and opens a pull request, a workflow marketing has never owned and most marketers have never touched. That single mechanical fact, not the writing quality, is why deciding who owns the tool turns into a cross-functional argument instead of a marketing subscription purchase.
Every content tool marketing has run before lives inside marketing's own stack: a CMS login, a Google Doc, a HubSpot draft. A Git-based AI blog writer breaks that pattern on purpose. It writes Markdown into the same repository engineering's CI runs against and opens a pull request, the review surface engineering already uses for code, not a doc marketing already owns. That's a deliberate design choice, not an accident: nothing auto-publishes, and the only way a post goes live is someone with repo access reviewing the diff and merging it. But it also means the tool's natural home isn't obviously marketing's, because marketing has no existing habit of reviewing a diff, resolving a merge conflict, or even knowing what a pull request is. If you're still comparing writers on features rather than on who inside your company can actually operate one, our buyer's checklist covers the tool-selection half of this question; this post covers the half that checklist doesn't touch, which is who inside your company holds the button once you've picked one.
A single-department pitch for an AI writing tool usually stalls, and the reason shows up in how B2B teams already buy anything with this shape. Gartner's own sales research found that 74% of B2B buyer teams demonstrate "unhealthy conflict" during their decision process, defined as members having conflicting objectives, disagreeing on the best course of action, or getting overruled by an external decision-maker, in a survey of 632 B2B buyers run in August and September 2024 (Gartner). Technology purchases pull in a comparably wide group: Gartner's Future of Sales research puts the median enterprise buying group at 11 stakeholders for software and SaaS purchases above $100,000 in annual contract value (The Starr Conspiracy, citing Gartner). An AI blog writer is a smaller purchase than most of what that research covers, but it touches the same number of functions: marketing cares about voice and calendar, engineering cares about repo access and CI, and DevRel, if it exists, cares about whether a technical reader will trust what ships under the company's name. Pitch it to one department and you've quietly created the exact setup that research already told you produces conflict, not a done deal.
Direct answer: on posts that make a genuine technical claim, an engineer or DevRel reviewer should hold the merge gate, because they're the only reviewer positioned to catch the specific class of error that would actually cost you credibility with a technical reader. On everything else, that gate is unnecessary overhead.
A marketing editor can catch a typo, a broken link, a claim that contradicts the pricing page. What they usually can't catch is a technical claim that's confidently wrong in a way only someone who works with the underlying system would notice, a permission scope described backwards, an API behavior that changed last quarter, a security claim stated more strongly than the docs support. Our own breakdown of GitHub App permissions is a useful test case: getting the difference between Contents access and Administration access wrong in a blog post isn't a style problem, it's a factual one, and it takes someone who's actually read the permission model to catch it. GitHub's own guidance on this is blunt: "you should select the minimum permissions required for the app" (GitHub). That's advice about which permissions to grant a GitHub App, but the same minimum-privilege instinct applies to who reviews a claim about them: give the review to the person who understands the scopes, not the person closest to the publish button.
Technical buyers already have a strong, quantified preference for who they trust to write about technical topics, and it isn't AI and it isn't marketing by default. TREW Marketing's State of Marketing to Engineers research found engineering experts at vendor companies are the most trusted source of technical content, at 66% of technical buyers rating them "very" or "extremely" trustworthy, while generative AI as a content author sits at just 10%. Overall trust in AI-generated answers scored 4.7 out of 10 in the same research, down from 6.5 in 2024 (TREW Marketing). The gap isn't really about AI versus human. It's about whether a technical reader can tell someone who understands the system actually touched the post. Lee Robinson makes the failure mode concrete: misusing a technical term, his example is calling something a JavaScript framework feature when it's actually a CSS behavior, "can degrade trust because it shows the author might not have a deep understanding of the subject" (Lee Robinson). A byline doesn't fix that. A reviewer who'd actually catch the error does.
Routing every post through a senior engineer's review time isn't a free safety net, it's a real cost decision once you price that engineer's loaded hourly rate. Benefits alone add roughly 30.5% on top of a hire's base salary before recruiting costs are even counted (Frac.tl), which is the number to multiply against however many minutes of a senior engineer's week a full technical review actually costs you. That math argues for triage, not a blanket policy: a post with a genuine technical claim, an API behavior, a security or permissions detail, a benchmark number, earns the engineering review. A general SEO post, a comparison page, or a company update doesn't need the same gate, and running everything through it is how a five-person team burns its most expensive hour on posts that never needed it. This triage is also the exact kind of decision an audit trail should record: not just that a review happened, but which reviewer's name is actually on which kind of post.
Direct answer: at five people there's no committee to convene, so the model collapses to one decision. A single named person, usually the founder or the technical co-founder, reads the diff and holds the merge button, full stop.
The standard early-stage marketing advice is to "hire generalists first, and as you scale you can bring in specialists," since a team that's all specialists with no generalist coverage is one of the more common early hiring mistakes (mkt1). Specialization into a dedicated content role is a later-stage move. At five people, you're before that first hire, which means there's no "marketing" and no "DevRel" to argue about yet, just whoever on the team is closest to both the product and the repo. If that's you, our piece on content marketing with no writer and no agency covers the actual time budget this takes, and the honest answer is under an hour and a half a week for a fact-checked pipeline: reading the diff, spot-checking the claim that would actually hurt you if wrong, and deciding whether it merges. Building a formal RACI at this stage is a solution to a conflict you don't have yet. Name one merge owner, skip the committee, and revisit the question when the org actually grows past it.
Direct answer: at two hundred people, the generalist-founder model has already broken down structurally, so the same decision has to move from one person's judgment to two named roles, one that owns voice and calendar, and one that technically holds the merge gate on anything technical.
| Question | 5-person startup | 200-person company |
|---|---|---|
| Who drafts | Founder, or an AI writer the founder directs | Marketing's content lead, or an AI writer they direct |
| Who owns voice and calendar | Founder, informally | Marketing, against a written style guide |
| Who holds the technical merge gate | Founder, usually also the engineer | DevRel or a named engineering reviewer |
| Who's accountable if a claim is wrong | Founder | Whoever's name is on the merge, per the audit trail |
One DevRel practitioner puts it plainly from her own track record: "every developer-focused company I've done Developer Relations at has had the team in the Marketing org" (Maida Kim), though that's one person's history, not a survey, and plenty of teams place DevRel inside product, engineering, or reporting straight to the executive level instead. Which fit is right depends on whether your primary product actually targets developers. The tradeoff is real either way: "reporting to engineering gives technical credibility but can limit go-to-market impact," while "reporting to marketing provides budget and distribution but can feel inauthentic" (Strategic Nerds). Lee Robinson's own observation about who ends up leading developer marketing well is worth sitting with here: "developer marketing leaders come from non-marketing roles (engineering, developer relations)" (Lee Robinson). That's a signal about where to actually source the reviewer, not just where to draw the org-chart box. Whichever way you draw it, marketing's real stake in this argument isn't the merge button, it's voice, and that's worth writing down rather than relitigating post by post: our brand voice style guide covers the part of the RACI marketing should actually own.
Applied to a blog post, a RACI reads like this in a single pass: the drafter, a marketer or the AI writer they're directing, is Responsible for producing the post; whoever's name is actually on the merge, DevRel or an engineering reviewer for anything technical, is Accountable for the outcome, which in practice means the GitHub App permissions question of who can literally click the button, not just who's supposed to; the other function is Consulted whenever the post crosses into its territory, engineering gets pulled in when a marketing-led post makes a technical claim, marketing gets pulled in when an engineering-led post touches tags or brand voice; and everyone else on the team is Informed, through the shared content calendar, once it ships. Write that sentence down once and most of the future arguments about a specific post resolve themselves against it instead of getting re-litigated from scratch.
Bring these five questions into the room before the next AI writing tool gets pitched to anyone, and answer each with a name, not a department:
None of these questions require a new tool to answer. They require a name, on the record, before the next post ships. Lyra's own GitHub App connection forces the first two questions the moment you install her, because she's scoped to Contents and Pull requests on the one repo you pick, nothing more, which is exactly the mechanism that lets a non-engineer hold the merge button on a technical post without engineering losing any actual control.
If your team is still arguing about who owns the merge button instead of arguing about the post itself, that's the problem Lyra is built to remove: she drafts, fact-checks, and opens the pull request, and the only decision left is who on your team clicks merge.
FAQ
There's no universal answer, but there's a clean way to split it: marketing (or the founder, at 5 people) owns the calendar, the keyword targets, and brand voice, while whoever can actually catch a wrong technical claim, usually DevRel or an engineering reviewer, holds the merge gate on posts that make technical claims. Below a certain headcount that split collapses into one person anyway.
It depends on whether your product is built for developers. One DevRel practitioner's account of working across multiple developer-focused companies found the team sitting inside marketing every time, though it also regularly reports into product, engineering, or the executive level elsewhere. Reporting into engineering buys technical credibility but limits go-to-market reach; reporting into marketing buys budget and distribution but risks feeling inauthentic to a developer audience.
RACI names who's Responsible for doing the work, Accountable for the outcome, Consulted before it ships, and Informed after. Applied to a blog post: the drafter (a marketer or the AI writer they direct) is Responsible, whoever's name is on the merge is Accountable, the other function is Consulted when the post crosses into its territory, and the rest of the team is Informed through the calendar.
Yes. At 5 people there's no committee to convene and no department to argue with itself, so the model collapses to one decision: a single named person, usually the founder or technical co-founder, reads the diff and holds the merge button. Building a formal RACI at this stage is overhead the org doesn't need yet.
Built by the tool you're reading about
Lyra finds the topics worth ranking for, writes them in your repo's voice, fact-checks every claim, and opens a pull request scored and ready to merge. You review and hit merge. Want to see what she'd write for you? Start free with three posts, no card.
Keep reading
Multilingual SEO for AI content breaks in three places: keyword cannibalization, hreflang errors, and raw machine translation. Here's the PR-reviewed fix.
Here's how to test AI vs human blog posts ranking properly: a matched-pair split test using GSC data to see which one actually earns clicks, not just position.
ChatGPT and Perplexity cite almost none of the same sources on vs queries. Here's how to structure a comparison page either engine can lift and recommend.