AI writing pipeline
A local model turns engineering work into blog drafts, with a pull request and my review between each draft and publication.
- Who it is for
- Readers of this blog, and me as the person responsible for what it publishes.
- My role
- Builder and editor — local-model workflow, publishing integration, and review.
- Where it stands
- AI-assisted posts are published on this site. I review and edit drafts before publishing.
NVIDIA DGX Spark · vLLM · llama.cpp · GitHub PRs · MDX · CI
The problem#
Useful engineering work does not automatically become useful writing. Experiments leave behind measurements, fixes, and failed attempts; a reader needs an account they can follow. I wanted a working way to turn that material into drafts while keeping responsibility for the result.
What I built#
A local language model, served through vLLM or llama.cpp on my NVIDIA DGX Spark, drafts posts and opens a pull request against this site's repository. The draft goes through the site's checks and a rendered review before I decide whether it should publish.
The output is already visible in the blog. For example, the evaluation write-up carries the same disclosure used for AI-assisted posts throughout the site: Drafted by AI · reviewed & edited by Michael.
Decisions that mattered#
- Use the existing publishing workflow. A pull request puts the draft, its changes, and build results in one place for review.
- Review the rendered article. The words need to work on the page a reader will see, not just in an MDX file.
- Keep the human publication gate. I edit and fact-check the draft and can reject it. Producing text is not permission to publish it.
- Disclose the assistance where people read. Posts use the
draftedBy: pipelinefield to show the disclosure. The byline remains Michael Hospedales; the site does not present a separate machine author.
What I learned#
The review boundary is a product decision, not just a technical setting. On this site, a draft waits for me. The Agentic Daily explores the version without that gate. Running both makes the difference concrete: a successful generation is only the beginning of deciding whether the result is worth a reader's time.
The next question#
How much of the work can the pipeline take on while keeping my review meaningful? The useful outcome is an article I can stand behind, with enough evidence to check its claims. Draft volume alone would not answer that question.