April 13, 2026 · 5 min read
FROM PROMPT TO PUBLISHED
Generation is cheap. Verification is where the engineering lives.
Everyone fixates on generation. How do you get AI to write a good article? That is the question I get most often.
It is also the wrong question.
Writing is the easiest part of the pipeline. The harder part, and the part that took far longer to build, is everything that happens after the words exist: preview rendering, approval routing, asset handling, deployment sequencing, and avoiding race conditions between systems that can both trigger a publish.
That is the layer that makes the whole thing trustworthy.
This is how a single article goes from idea to live on The AI Signal. Every step reflects a deliberate design decision.
FINDING SOMETHING WORTH WRITING ABOUT
The pipeline starts with a scheduled Claude Code session that searches for trending AI and development news through DuckDuckGo. Before it writes anything, it checks existing posts and drafts for overlap.
That duplicate detection is not glamorous, but it matters. Without it, I would already have published several slightly different versions of the same article.
Each article follows an internal playbook with five categories: breaking news, opinion, tools, tutorial, and deep-dive. Each has its own editorial rules and visual treatment. That distinction matters partly because it also affects cost.
The generator writes a 600 to 800 word draft in an opinionated voice and saves it as a markdown file in a drafts directory. There is no CMS or database involved. The article begins as a file with frontmatter.
That choice is intentional. Markdown is version-controllable, diffable, and readable without a running service. The tradeoff is fragility: a missing field or invalid date can sit quietly until the build fails. So far, that has been a trade worth making.
MAKING IT LOOK RIGHT
Image generation is the most cost-sensitive part of the pipeline.
I run a local ComfyUI instance connected to Black Forest Labs’ Flux 2 Pro Preview model. It produces strong editorial illustration, but keeping costs acceptable means being deliberate about when and how often to generate.
The playbook assigns each category its own visual treatment. Tools pieces use architectural imagery, geometric lines, and structural patterns. Deep-dives lean on topology, network graphs, and layered systems. Opinion pieces use kinetic typography, and breaking news uses animated code rain. Those last two run entirely in CSS, which is easily the most effective cost decision in the pipeline. The animations run client-side in vanilla JavaScript and require no generation budget at all.
The prompt builder translates topics into visual concepts instead of literal objects:
¬ A database becomes “structured data layers”
¬ APIs become “interface connections”
¬ React becomes “component architecture”
That indirection works better because it pushes the model away from literal illustration and toward the visual language of the design system.
Each image renders at 1152 × 768 pixels, with guidance scale 3.5 and 28 inference steps. If the result fails or is unusable, the pipeline retries up to three times. That limit is part of the strategy. Without it, a single bad prompt can quietly push costs past acceptable levels.
The output PNG is converted to WebP with Sharp for size efficiency.
THE PREVIEW PROBLEM
This is where I spent the most engineering time.
When a draft is ready for review, I need to see exactly what the published article will look like. Not a markdown preview. Not a close approximation. The actual page, with the real CSS, layout, and hero treatment.
If the reviewed version differs from what goes live, the approval step becomes theater.
So the pipeline runs through a build sequence. The draft is copied into the posts directory, its status is switched to published, the Astro site rebuilds with --base /3001, and the result is served on a preview port behind an Nginx proxy.
That base path flag took an embarrassing amount of debugging. Without it, CSS and JavaScript references break because the proxy rewrites the URL structure. An earlier version used serve -s in SPA mode, which quietly returned index.html for missing paths. The article looked as if it loaded correctly, but it was often rendering the wrong content.
Once the preview is live, the pipeline sends a Telegram notification to my phone with the preview link and two buttons: Approve or Reject.
That is the entire review interface.
An approval listener runs as a PM2 daemon and polls the Telegram API every 30 seconds for button presses.
WHAT HAPPENS WHEN I TAP “APPROVE”
Approval triggers a chain of actions. The draft moves into the posts directory, frontmatter is updated with published status and timestamp, the site rebuilds, and the result deploys.
The tricky part was concurrency. The admin dashboard can also trigger publishing, and two publish attempts against the same article can corrupt the build.
The fix is a lockfile at /tmp/vibe-publish-{slug}.lock.
The entire state model still lives in markdown frontmatter. There is no database and no external service to maintain. In practice, grep and git log do a surprising amount of monitoring work.
THE REAL BOTTLENECK
The pipeline can research, write, illustrate, and stage an article in under four minutes. My fastest review-to-publish cycle was about ninety seconds.
But the system does not ship at machine speed. It ships at human speed.
The generation layer can produce daily. Whether anything goes live depends on when I sit down, read the draft, check the sources, and decide it is ready. Some weeks that means several articles. Other weeks, none.
That is not a limitation. It is the design.
That constraint shaped the whole system. The preview has to be exact because I cannot spend review time second-guessing rendering. Telegram approval is one tap because every extra step adds friction between me and the decision. The pipeline does not auto-publish on a schedule, even though it easily could.
The human review step is what makes the rest of the system worth building.
Building the generator took a weekend.
Building the verification layer that protects human judgment needed real time, iteration, and plenty of trial and error.
That ratio says a lot about where the real engineering lives.
This is Part 2 of a 5-part series on building The AI Signal. Next up: the Night Council — what happens when three AI agents debate your blog’s strategy.
Christian Scherling is a designer and developer at cerridan | design e.U., building AI-assisted tools and wondering how far automation can go before it stops being useful.