An AI blog writer for developers that lives in your GitHub repo: it writes in your codebase's voice, fact-checks claims, and opens a pull request you review.
Most AI writing tools make you leave your workflow. You open a separate web app, type a prompt, copy the output, paste it into a CMS, fix the formatting, find an image, and publish. For anyone who runs a blog as Markdown in a Git repo, that is a worse workflow than the one they already have. The tool that was supposed to save time adds a manual hop in the middle.
An AI blog writer for developers should do the opposite. It should meet the repo where it already is: Markdown in Git, your frontmatter, your slug conventions, pull-request review, your own API key. That is the whole argument of this post, and it is how we built Lyra, the autonomous AI blog writer. She connects to your GitHub repo, writes a post in the file format you already use, and opens a pull request you review like any other change.
The mismatch is the workflow, not the prose. A founder or engineer running a content blog already has a system: posts live in content/ or _posts/, frontmatter sets the title and tags, the slug is the filename, and changes ship through pull requests. That system exists for good reasons. It versions every post, it makes review a diff, and it keeps content next to the code it describes.
A generic AI writer ignores all of that. It produces a blob of text in a browser tab and leaves the integration to you. So you become the glue: reformatting Markdown, rewriting frontmatter by hand, fixing links, and pasting into a CMS that your repo-based blog may not even use. The writing might be fine. The fit is the problem.
There is a second, quieter failure: voice. A blank-prompt tool has no idea how you write. It defaults to the same flat, hedged, slightly robotic register every AI writer falls into, the one with the banned phrases and the throat-clearing intros. We wrote about why that voice is so easy to spot, and why it gets ignored by readers and answer engines alike, in our guide to answer engine optimization. The fix is not a better prompt you write every time. It is a writer that learns your voice from the posts already in your repo.
Start from the repo, not from a prompt box. When Lyra connects to your GitHub repo, the first thing she does is read it. She learns where your posts live, what your frontmatter looks like, how your slugs are formed, and how your existing posts sound. That is the difference between a tool you configure for an hour and a writer who already knows the house style. We wrote about how this grew out of running our own blog this way in why we built Lyra.
From there she runs a pipeline you can watch, stage by stage: Discovered, Writing, Reviewing, Ready, Released. She finds a winnable topic, drafts the post in your voice, and then does the part most tools skip entirely. She fact-checks every claim and verifies every external link. A broken link is a hard block: she will not open a pull request with a dead reference in it. If you have ever shipped a post and found a 404 in it a week later, you know why that matters. We go deeper on the verification step in how Lyra fact-checks every claim.
She also scores each draft out of 10 across five axes: content, SEO, technical accuracy, readability, and linking. Internal links are part of that score on purpose, because they are part of what makes a blog rank and what keeps readers moving through it. If you want the reasoning behind treating links as a first-class concern, we laid it out in internal linking automation.
Then she generates a banner and opens a GitHub pull request through a GitHub App, and tags you. That last step is the one that respects how developers work.
Developers already trust the pull request. It is where code gets reviewed, discussed, and approved before it ships. So the right place to review a blog post is the same place: a diff, in your repo, on your terms.
Lyra opens the post as a normal PR. You see exactly what file is being added, what the frontmatter says, and every line of the body, rendered as a diff you can read in seconds. The draft score and the fact-check notes come with it, so you are not reviewing blind. You can comment, request changes, edit the file directly, or close it. Nothing about this is special to "AI content." It is the review flow you use for everything else.
Here is roughly what lands in the diff, matched to whatever your repo already expects:
---
title: "Your post title"
slug: "your-post-slug"
date: "2026-06-23"
tags: ["primary keyword", "secondary tag"]
---The shape is learned from your repo, not imposed by Lyra. If your posts use a description field and a published boolean, that is what she writes. The goal is a PR that looks like you wrote it, because it follows your conventions.
And nothing auto-publishes. This is the part worth repeating, because the fear with any AI writer is that it will push something embarrassing live while you sleep. Lyra cannot. She opens the PR and stops. The post goes live when you merge, and not a moment before. You are still the editor. She just did the draft, the research, and the legwork.
The economics should be as transparent as the workflow. Lyra runs on a bring-your-own-key model: you connect your own Anthropic key, she encrypts it at rest, and she never marks up the usage. The model spend is billed to you, by Anthropic, at cost. There is no token resale, no opaque per-word pricing, no surprise invoice that scales with how much you write. A Gemini key for banners is optional and works the same way.
That matters more than it sounds. With most AI writing products, the per-word cost is bundled and marked up, so the more you publish the more you pay a middleman. With your own key, the marginal cost of one more post is the model cost and nothing else. If you want to know exactly what a post cost to write, you can read it off your Anthropic bill. For developers who already pay for an API key, this is the model that makes sense.
Getting into Lyra is simple while she's in early access: talk to the founder, and we'll walk through your blog and whether she's a fit. You bring your own Anthropic key, so the product and the model cost stay cleanly separated, which is how it should be.
Put the pieces together and the workflow looks like the one you already have, with the slow parts removed.
You connect the repo once through a GitHub App, with the scopes you choose. Lyra reads the repo and learns your structure and voice. From the dashboard, you watch her move a topic through Discovered, Writing, Reviewing, and Ready. When a draft clears its fact-check and scores well, she opens a pull request and tags you. You review the diff like any other change and merge when it is right. Your CI builds and deploys it the same way it deploys everything else, because to your pipeline it is just another Markdown file that landed via PR.
No copy-paste. No second CMS. No format wrangling. No worrying that something published itself. The autonomous part is the research and the draft and the checks. The control stays with you, in the tool you already use to ship.
That is what an AI blog writer for developers should be: not a separate app you visit, but a contributor to your repo who opens pull requests and waits for your review. If your blog already lives in Git, the writer should too.
Lyra is the autonomous writer built for repos, opening pull requests in your GitHub blog instead of asking you to copy-paste from a separate app.
FAQ
It meets the repo where it already is. A good AI blog writer for developers writes Markdown with your frontmatter into your Git repo, learns your voice from existing posts, fact-checks claims, and opens a pull request you review and merge. No copy-paste into a separate CMS, no auto-publishing.
In most cases, yes. Lyra writes Markdown with frontmatter into your repo via a pull request, which fits common Git-based blogs like Next.js, Astro, Hugo, and similar setups. On connect she reads your repo to learn where posts live, your frontmatter shape, and your slug rules, so the file she opens matches what your generator already expects. She doesn't touch your build or deploy.
Yours. You bring your own Anthropic key, which Lyra encrypts at rest and never marks up, so the model spend is billed to you at cost. A Gemini key for banners is optional. Lyra herself is in early access while we build in the open, so the best way in right now is to talk to the founder and see whether it's a fit.
No. Lyra opens a GitHub pull request and tags you. You review the diff, the score, and the fact-check notes, then hit merge yourself. Nothing goes live until you do.
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? Tell us about your blog and the founder will walk through it with you.
Keep reading
The origin story of Lyra. We grew a developer product from zero to millions of monthly search impressions on blog content, then automated the whole thing.
A practical guide to SEO for SaaS. How to pick winnable keywords, build topic clusters, and turn content into a channel that compounds instead of resetting.
A Surfer SEO alternative, compared honestly. Surfer scores a draft you write; Lyra writes the whole post, verifies every claim, and opens a pull request.