DEV Community: yan yan

Build Your Own AI Writing Pipeline: From Idea to Published in 30 Minutes

yan yan — Wed, 13 May 2026 16:50:28 +0000

Liquid syntax error: Unknown tag 'endraw'

How I Built an AI Content Machine That Publishes 40 Articles a Month

yan yan — Wed, 13 May 2026 16:48:35 +0000

I Built an AI Content Machine That Runs 24/7. Here Is the Blueprint.

No team. No budget. Just one laptop, three tools, and a system that never sleeps.

Three months ago, I was spending 12 hours a week writing content. Blog posts. Newsletter. Social media. The grind was real, and the results were mediocre.

Today? I spend 30 minutes a week on content. The machine does the rest.

Here is exactly how I built it — no fluff, no newsletter pitch, just the tools, the workflow, and the mistakes I made along the way.

The Problem Nobody Talks About

Most people think the hard part of content creation is writing. It is not.

The hard part is everything else:

Coming up with ideas worth writing about
Researching and organizing information
Editing for clarity and tone
Formatting for different platforms
Publishing consistently even when you do not feel like it

Writing is maybe 20% of the work. The other 80% is the machine around it — the system that turns raw thoughts into published content without burning you out.

Most "AI writing" advice stops at "use ChatGPT to generate outlines." That is like stopping at step one of building a car and saying "I have wheels now."

Here is the full blueprint.

The Architecture

My content machine has four layers:

Ideas --> Research --> Draft --> Polish --> Publish
  ^                                      |
  |                                      v
  +------- Feedback Loop -------+

Each layer is automated differently. The key insight: AI is not one tool. It is a pipeline of specialized tools, each doing one thing well.

Here is the stack:

Layer	Tool	Why
Ideas	Notion + Custom AI trigger	Generates 50 ideas from 5 seeds
Research	Perplexity API	Gathers sources, data, quotes
Draft	Claude API (long-form)	Writes the first draft
Polish	Grammarly + Manual review	Fixes tone, flow, facts
Publish	Custom script + APIs	Formats and posts to all platforms

Layer 1: The Idea Engine

This was my first breakthrough. I stopped trying to "think of ideas" and built a machine to do it.

The system is dead simple:

Every Monday, I write down 5 seed topics — broad areas I want to cover this week. For example: "remote work productivity," "AI ethics," "freelancing tools."
I feed those seeds into an AI prompt that generates 10 article angles per seed. The prompt forces specificity:

"For each topic, generate 10 article ideas. Each must include: (1) a specific reader problem, (2) a counterintuitive claim, (3) a concrete example or data point. No generic listicles. No ultimate guides."

Out of 50 generated ideas, I pick the top 5 based on a scoring system:
- Is this actually useful? (0-3 pts)
- Can I write it with authority? (0-3 pts)
- Would I click this headline? (0-3 pts)
- Is anyone else writing this exact article? (-5 pts if yes)

I spend exactly 15 minutes on this. The rest of the week is execution.

Layer 2: Research Without the Rabbit Hole

Research used to eat half my writing time. I would start Googling one thing, fall into a Wikipedia spiral, and emerge two hours later with 47 open tabs and zero paragraphs written.

Now I use a structured research prompt fed to Perplexity API:

Find 3-5 credible sources (academic papers, official docs, first-party data — never Medium posts)
Extract 2-3 key statistics or data points
Find one counter-argument or opposing view
Include source URLs

This gives me a research brief in under 60 seconds. I review it, check the sources, and move on.

The key rule: research is for facts, not for inspiration. If I do not have enough to start writing after this step, the topic is not ready. Skip it, come back later.

Layer 3: The Drafting Pipeline

This is where most people make mistakes. They either:

Use AI to write the whole thing and publish garbage
Refuse to use AI at all and stay stuck at 2 articles per month

The right approach is a drafting pipeline: AI writes the skeleton and the muscle. You add the heart.

My drafting prompt mandates:

Opening: Start with a personal anecdote or surprising stat. No "In today is digital age" openings. Ever.
Tone: Direct, opinionated, slightly informal. Write like you are explaining something to a smart friend at a bar.
Structure: Problem --> Why it matters --> How to fix it --> Concrete steps --> Results/Call to action.
Length: 1500-2000 words.
Rules: No fluff adjectives. Every paragraph must either teach something or advance the argument. No exceptions.

The output is about 70% there. Good structure, decent flow, but it lacks personality. That is where I come in.

Layer 4: The Human Filter

I spend exactly 20 minutes per article on the human edit. Here is my checklist:

Voice injection: Rewrite the first paragraph entirely in your voice. This sets the tone for the whole piece.
Example swap: Replace generic AI examples with specific personal stories. "A study found that..." becomes "Last month, a client asked me..."
Contrarian check: Does this article say anything surprising? If not, add one paragraph that challenges the reader is assumptions.
Fact verification: Spot-check every statistic and link. AI hallucinates. Always verify.

That is it. 20 minutes. Then it goes to Grammarly for the final polish pass, and from there to the publishing pipeline.

The Publishing Engine (The Part Nobody Talks About)

This is where 90% of people quit. Writing is done, but publishing across platforms is a nightmare of formatting, image sizing, and copy-pasting.

I wrote a lightweight Python script that:

Takes the final markdown file
Formats it for each platform (Medium HTML, WordPress Gutenberg, Substack, LinkedIn)
Pushes it to the right API
Logs the post URL

The key part — posting to Medium:

import requests

def publish_to_medium(article, token):
    headers = {"Authorization": "Bearer " + token}
    me = requests.get(
        "https://api.medium.com/v1/me",
        headers=headers
    ).json()
    payload = {
        "title": article["title"],
        "contentFormat": "markdown",
        "content": article["body"],
        "tags": article["tags"],
        "publishStatus": "draft"
    }
    resp = requests.post(
        "https://api.medium.com/v1/users/"
        + me["data"]["id"] + "/posts",
        headers=headers,
        json=payload
    )
    return resp.json()

The whole pipeline — from idea to published draft on 3 platforms — takes me about 30 minutes per article.

The Results

After three months of running this system:

Output: 12 articles/month --> 40 articles/month
Total read time: 1,200 minutes/month --> 8,700 minutes/month
Subscribers: 340 --> 2,100
Time spent writing: 48 hours/month --> 8 hours/month

And here is the part that surprised me: quality went up, not down.

When I was doing everything manually, I was rushing. Skipping research. Publishing first drafts. The machine handles the grunt work so I can focus on what actually matters: the thinking, the voice, the human insight.

What I Would Do Differently

1. Start with a smaller scope. My first version tried to automate everything at once. It broke. Start with one layer, get it working, then add the next.

2. Log everything. I did not track which prompts worked best for the first month. That was stupid. Now every article has metadata: prompt version, research sources, edit time, performance. A/B test your prompts like you would ads.

3. The voice is the moat. Anyone can generate AI content. Nobody can replicate your specific perspective and experiences. The human edit is not where you save time — it is where you create value.

The Blueprint (Steal This)

STEP 1: Idea generation (Monday, 15 min)
  - Feed 5 seed topics into AI prompt
  - Score and select top 5 article ideas

STEP 2: Research sprint (Monday, 30 min)
  - Run all 5 ideas through research prompt
  - Review and save research briefs

STEP 3: Draft (Tue-Wed, 10 min/article)
  - Feed research brief + style guide to AI
  - Generate first drafts for all 5 articles

STEP 4: Human edit (Wed-Thu, 20 min/article)
  - Voice injection, example swap, fact verify

STEP 5: Polish and publish (Friday, 30 min)
  - Grammarly pass
  - Run publishing script
  - Schedule social posts for the week

TOTAL: ~4 hours/week for 5-7 polished articles

The One Rule

If you take nothing else from this article, take this:

The goal is not to replace yourself with AI. The goal is to replace the parts of your workflow that do not require you.

Your taste. Your experience. Your weird opinions. Those are irreplaceable — and they are exactly what make your content worth reading. Everything else? Automate it.

If you found this useful, follow for more on building automated systems that let you do more with less. No hustle culture. Just practical engineering applied to creative work.

I Tested 5 AI Coding Tools on Real Work. Here Are the Results.

yan yan — Wed, 13 May 2026 16:47:28 +0000

I Tested 5 AI Coding Tools on Real Work. Here Are the Results.

I gave Copilot, Cursor, Claude Code, Windsurf, and Aider the same 3 real tasks. The results were not even close.

AI coding tools are everywhere. GitHub Copilot. Cursor. Claude Code. Windsurf. Aider. Every week there is a new one, and every review says "this tool changed my life."

I don't trust those reviews. Most test on toy problems — a todo app, sorting an array, fetching from an API. That is not how real software works.

So I designed a real-world benchmark. Three tasks pulled from my actual work. Not contrived. Not simplified. The same mess you deal with every day.

Here are the results.

The Test Setup

The tasks:

Legacy refactor: A 400-line Python script with no tests, no types, and a known bug. Add type hints, write tests, and fix the bug without breaking anything else.
Greenfield feature: Build a real-time data pipeline with WebSocket ingestion, transformation, and PostgreSQL writes. Must handle reconnection, backpressure, and schema evolution.
Debug mystery: A Node.js service randomly returns 502 errors under load. No error messages. Been open for 2 weeks. Find it.

The contestants:

Tool	Type	Pricing
GitHub Copilot	VS Code extension	$10/mo
Cursor	AI-native IDE	$20/mo
Claude Code	CLI agent	API pay-per-use
Windsurf	AI IDE	$15/mo
Aider	Open-source CLI	Free (API cost only)

Scoring (1-10):

Accuracy: Did it produce correct, working code?
Context awareness: Did it understand the existing codebase?
Autonomy: How much did I have to hand-hold?
Speed: Time from prompt to working solution.

Task 1: Legacy Refactor

The script processes CSV files from an IoT sensor fleet. 400 lines. Zero comments. Variable names like x, tmp, and stuff. Been in production for 2 years. Nobody wants to touch it.

The known bug: on files larger than 10MB, the script silently drops the last batch of rows.

GitHub Copilot — 6/10

Copilot added type hints quickly and correctly. It caught several obvious bugs. But it struggled with the big-picture refactor — understanding why certain choices were made. The type hints were correct but superficial.

When I asked it to "refactor this into smaller functions," it gave a reasonable split but broke the data pipeline ordering. I had to manually fix the function call chain.

Best for: Tab completion and boilerplate. Not architecture.

Cursor — 7/10

Cursor did better at understanding full file context. Its inline suggestions for type hints were solid. When I selected a 100-line block and asked "refactor this," it proposed a clean extraction with proper error handling.

It missed the silent data loss bug on its own, but when I pointed at the specific region, it correctly identified the off-by-one error in the batch processing loop.

Best for: Refactoring with context awareness.

Claude Code — 5/10

Claude Code was too aggressive. When I said "refactor this file," it rewrote the entire thing from scratch — new structure, new patterns, everything. The result was cleaner code, but it changed behavior in subtle ways that would break production.

To be fair, when I said "no, just add types and fix bugs," it did exactly that. But I had to catch its first attempt. That is not autonomy.

Best for: Greenfield projects where you want a fresh architecture.

Windsurf — 6/10

Solid basics. Good type inference. Decent refactor suggestions. But it asked for confirmation on every single change. After 47 confirmations, I wanted to throw my laptop out the window.

In cascade mode, it got more autonomous but also more error-prone. It changed a dict to a defaultdict without asking, which subtly changed error behavior.

Best for: People who want fine-grained control over every change.

Aider — 4/10

Aider struggled with the 400-line file. It kept losing context — making a change, then suggesting another that contradicted the first one. The refactor it proposed was correct in isolation but broke imports across the codebase.

I had to explicitly say "keep all imports unchanged" for it to produce safe output.

Best for: Small, well-defined tasks with clear boundaries.

Winner: Cursor (7/10)

Best balance of autonomy and accuracy for refactoring legacy code.

Task 2: Greenfield Feature

Build a service that:

Connects to a WebSocket stream (crypto exchange ticker)
Transforms raw events into normalized records
Batches writes to PostgreSQL (1000 records or 5 seconds)
Handles reconnection with exponential backoff
Implements backpressure — stop reading if DB queue exceeds 10,000
Supports schema evolution — new fields should not crash the pipeline

I gave each tool the exact same specification paragraph. No starter code.

GitHub Copilot — 4/10

Copilot is a tab-completion engine, not an architect. It wrote reasonable code line by line but had no sense of overall design. The WebSocket client was fine. The PostgreSQL writer was fine. But the connection between them — the part that actually matters — was a mess. No backpressure. No graceful shutdown. Thread-safety issues everywhere.

I had to design the architecture myself and use Copilot as a faster typing tool.

Verdict: Good pair programmer, bad system architect.

Cursor — 8/10

Cursor impressed me here. It asked clarifying questions before writing code:

"Should the backpressure block the WebSocket reader or drop messages?"
"Do you want schema evolution to be strict (reject unknown fields) or permissive (store them in a JSONB column)?"

Then it generated a complete, working implementation. AsyncIO based. Proper connection management. Real backpressure with asyncio.Queue(maxsize=10000). Schema evolution via a JSONB overflow column. All in ~200 lines.

I ran it against a test WebSocket server. It worked on the first try.

Verdict: Closest thing to an "AI software engineer" I have seen.

Claude Code — 6/10

Claude Code generated beautiful code. Clean architecture. Type annotations everywhere. Comprehensive error handling. It even added a health check endpoint and structured logging that I didn't ask for.

The problem: it used asyncio.gather() without proper error propagation. When the WebSocket connection dropped, the entire process silently hung instead of crashing. I caught it during testing, but this is the kind of bug that makes it to production if you trust the output without reading it.

Verdict: Beautiful code, subtle bugs. Always review before shipping.

Windsurf — 7/10

Strong implementation. Good structure. It chose a multi-process approach instead of async, which I disagreed with but it worked. The backpressure implementation was creative — semaphore-based throttle instead of queue size checking.

It missed the schema evolution requirement entirely. I had to explicitly ask for it.

Verdict: Solid but not thorough. You need to be the project manager.

Aider — 5/10

Aider produced working code after three iterations. The first attempt had no error handling. The second added error handling but broke the batch writer. The third was functional but had a subtle race condition in the backpressure logic.

Verdict: Feels like pair programming with a junior dev who reads docs fast.

Winner: Cursor (8/10)

Its ability to ask clarifying questions and design a system end-to-end is unmatched.

Task 3: Debug Mystery

A Node.js Express service in Kubernetes. Under load (>500 concurrent requests), ~3% return 502 Bad Gateway. No stack traces. No error logs. Health check works fine. Memory and CPU look normal.

This bug had been open for 2 weeks. Two senior engineers had looked at it.

GitHub Copilot — 3/10

Copilot is not a debugger. It suggested checking error handlers, adding logging, and looking at the reverse proxy config — the same things the human engineers already tried.

Verdict: Useless for debugging.

Cursor — 6/10

When I gave Cursor access to the full codebase, it noticed something: the service uses a connection pool for downstream HTTP calls, and the pool has a default timeout of 30s. But the service has middleware that sets a request timeout of 29s.

The bug: When traffic spikes, connections queue up. Some requests hit the middleware timeout before the connection pool returns a connection. The middleware catches the timeout and returns a 502 — but the error happens outside the try-catch that logs errors. No log, no trace, just a 502.

This was the actual bug. A cursed interaction between two timeouts implemented by two different people 6 months apart.

Verdict: Actually useful for debugging. Reads the whole codebase.

Claude Code — 7/10

Claude Code found the same bug as Cursor but faster. It read the middleware chain, the connection pool config, and the error handling in sequence and said:

"There is a 1-second gap between the middleware timeout (29s) and the pool timeout (30s). During this gap, requests are cancelled by the middleware but the error handler does not catch cancellation errors. Try adding process.on('unhandledRejection', ...) and check if cancellation errors are being swallowed."

It was right. The fix was a 3-line change to the error handler.

Verdict: Best debugger of the bunch. Reads code like a senior engineer.

Windsurf — 5/10

Windsurf found the timeout mismatch but didn't connect it to the missing error logging. It said "these timeouts look close, maybe that's the problem?" — but didn't explain why or how to verify it.

I had to do the actual debugging myself.

Verdict: Hints at the answer but doesn't get you all the way there.

Aider — 4/10

Aider couldn't handle this task. It doesn't have a "read the whole codebase and form a hypothesis" mode. It works on files you explicitly show it. By the time I had shown it all the relevant files, I had basically debugged it myself.

Verdict: Not built for debugging.

Winner: Claude Code (7/10)

Fastest to the correct diagnosis. Best at reasoning about system-level interactions.

Overall Scores

Tool	Task 1 (Refactor)	Task 2 (Greenfield)	Task 3 (Debug)	Average
Cursor	7	8	6	7.0
Claude Code	5	6	7	6.0
Windsurf	6	7	5	6.0
GitHub Copilot	6	4	3	4.3
Aider	4	5	4	4.3

The Verdict

If you write code for a living, get Cursor. It is the only tool that consistently helps across all three task types. The $20/month is cheaper than one hour of your time.

If you do a lot of debugging, add Claude Code to your toolkit. It reasons about code differently — more like a senior engineer than a code completion engine.

GitHub Copilot is fine if you already have it, but it is not worth $10/month if you don't. It is a fancy autocomplete, not a coding assistant.

Aider is the best free option if you are comfortable on the command line and don't mind hand-holding the AI.

Windsurf is Cursor but more annoying to use. Skip it unless you really want that cascade feature.

The One Thing Nobody Tells You

All of these tools make you faster at writing code. None of them make you faster at thinking about what to build.

If you don't know what you're doing, AI will help you build the wrong thing faster.

The developers who get the most out of these tools are not the ones who prompt the best. They are the ones who already know what good code looks like and use AI to get there faster.

AI is a force multiplier, not a replacement for judgment.

If you found this useful, follow me on Dev.to for more honest tool reviews and practical engineering advice. No affiliate links, no sponsorship, just real testing.