Your CI pipeline builds, tests, packages, signs and deploys. It produces a changelog. It notifies a Slack channel. Then it stops, and everything downstream of "the code is live" — the blog post, the release note anyone outside the team will read, the social post that tells the eleven people who care that the thing they asked for now exists — happens by hand, or does not happen.
For most small teams it does not happen. Not because it is hard, but because it is unowned. There is no failing check for "shipped in silence."
That gap is worth looking at directly, because the tooling around it has changed in the last two years and most engineering teams have not noticed.
Where the gap comes from
Developer marketing has always sat in an awkward place. It requires understanding what the code does, which marketers usually do not, and it requires writing for people, which engineers usually deprioritise. The traditional resolution is a developer-advocate or technical-marketing hire, and that hire is expensive and does not happen until a company is well past product-market fit.
So the small-team default is a blog with three posts, the newest eighteen months old, and a launch announcement that got written because a launch is an event and events force the issue. Meanwhile the repository has 400 commits, nine releases, and a genuinely useful feature that shipped in March and has never been mentioned anywhere a user would see it.
The asymmetry is worth stating plainly: the expensive part — building the thing — is done. The cheap part is what is missing.
What changed
Three things, roughly at once.
Drafting stopped being the bottleneck. A capable model given a diff, a changelog and some product context produces a serviceable first draft of a release post. Not a finished one. Serviceable — which matters, because the real cost was never the typing, it was the blank page. Editing a draft that is 70% right is a ten-minute job. Starting from nothing is a task that gets deferred indefinitely.
Publishing became an API problem. Dev.to, Hashnode, Bluesky, Mastodon, Medium, WordPress and Buttondown all take programmatic writes. Bluesky's AT Protocol in particular is an open, well-documented, free write API with a developer-dense audience, which is an unusually good combination. Cross-posting stopped being a copy-paste chore and became an integration.
Repository events became reliable triggers. Webhooks and the commits/releases APIs mean "something shipped" is a signal you can subscribe to rather than a thing you have to remember.
Individually, none is remarkable. Together they mean the loop from merged to published can be closed with ordinary software.
The uncomfortable part
Here is the objection, and it is correct: the internet does not need more automatically generated content. LLM-written blog spam is a real and growing problem, search results are measurably worse for it, and "we automated our content" is exactly what someone about to make things worse would say.
So the distinction has to be load-bearing, and it is this: automate the pipeline, not the judgement.
There is a version of this that generates posts from commits and publishes them unattended. It produces content nobody wants, degrades the signal on the platforms it posts to, and is bad for the person doing it. It should not be built.
The version that works keeps a human in exactly one place — approval — and automates everything on both sides of it:
- Detecting that something shipped worth writing about.
- Drafting from real repository activity, not from a topic prompt.
- Putting the draft in a review queue where a human reads it and, importantly, can reject it.
- Handling scheduling, cross-posting, canonical URLs and syndication delays.
- Tracking what happened afterwards.
The pipeline is automated. The publish decision is not. That single retained decision is what separates a tool from a spam cannon, and it is the reason a review queue is a feature rather than friction.
It also has a practical effect: knowing a human will read the draft changes how you build the generator. You stop optimising for volume and start optimising for the draft being worth approving.
Details that turn out to matter
Once you build this, a set of unglamorous problems shows up. They are worth knowing about in advance.
Canonical URLs are the whole syndication game. Publish the same article to Dev.to, Hashnode and Medium with no canonical and you have three pages competing for the same query, splitting whatever ranking they would have had. Publish the original, take its URL, and set it as the canonical on every copy, and you have one page with three sources of traffic. Every platform in this list supports the tag. Nearly every naive cross-poster ignores it.
The ordering implication is subtle: the copies cannot go out until the original has a URL. Which means syndication is inherently staggered, and the delay is a feature.
Cross-network posts should link, not duplicate. A Bluesky post carrying an article's first 280 characters is worse than useless — it competes with the article and reads as a bot. A one-line hook plus the canonical link is what a human posts.
Every platform's limits are different and none of them are characters. Bluesky counts graphemes and does not shorten links, so a 90-character URL genuinely consumes 90 of your 300. Its rich-text facets index into byte offsets, so a single em dash before a link shifts everything and the link silently breaks. Get that wrong and you find out from a user.
Timing is per-platform and empirical. The best time to post to Dev.to and the best time to post to Bluesky are not the same time, and both are properties of your audience rather than of the platform. Which means it is a thing to learn from your own history, not a constant to hardcode.
Dead links block publishing, and should. Generated copy invents URLs. A definitive 404 in a published post is embarrassing and permanent. A pre-publish link check that treats a 404 as blocking and a timeout as inconclusive costs one request per link and saves the occasional public mistake.
Measure, or none of it was worth doing. Views and engagement per piece, pulled from the platforms' own APIs, is what tells you whether the tutorials outperform the release notes. Without it you are automating a process with no feedback, which is just producing output faster.
Is this a trend or a niche?
Honestly: partly a niche. Plenty of teams have a marketing function and do not need this, and plenty of projects should be promoted by a human who cares, at their own pace, and would be worse for a pipeline.
But the shape generalises beyond marketing, and that is the part worth noticing. The pattern is automate the mechanical span around a retained human decision. Dependency bots do it — detect, prepare, open a PR, wait for a human to merge. Release tooling does it. The interesting AI-adjacent tools of the last two years mostly do it, and the ones that tried to remove the human decision instead of the work around it have mostly not aged well.
Content is a good fit for that pattern because the mechanical parts are large and tedious — cross-posting, canonicals, scheduling, metrics — and the judgement part is small and genuinely irreducible. Someone has to decide this is worth publishing. Nobody has to decide what the canonical URL should be.
The teams that will get value from this are the ones shipping steadily with nobody assigned to say so. That is a lot of teams. It is most side projects, and a good share of small companies that are strong technically and invisible commercially.
Herald is a working implementation of this. It watches project repositories, drafts posts from real commit and release activity, parks them in a review queue for a human, then publishes on a schedule to Dev.to, Hashnode, Bluesky, Mastodon, Medium, WordPress, Buttondown or a commit to your blog repo — handling canonical URLs, syndication delay, per-platform formatting and UTM attribution — and tracks views and engagement afterwards.
It is FastAPI, PostgreSQL, Celery and React, with an LLM router that falls back across providers and degrades to a static template rather than failing. The whole thing is driven by an HTTP API, which means it can be scripted, or driven from an MCP client, or left to run itself. The review queue stays.
Top comments (0)