The AI Reading Workflow That Lets Me Process 50 Articles a Day

Let me define “process” before the title gets me in trouble, because I do not read 50 articles a day and neither does anyone else claiming to. Processing means every one of the ~50 articles that enters my queue daily gets a decision — read deeply, skim, or discard — based on an AI summary rather than a headline. Reading deeply still means reading deeply, with my own eyes, slowly. The AI’s job is triage: it helps me decide what to read, it doesn’t read for me. That reframing is the entire workflow, and it’s worth more than any individual tool in it.

Here’s the pipeline, the exact prompts, and the math — plus the section where I argue against my own system.

Stage one: capture everything, judge nothing

Triage only works if everything flows into one place. My capture layer:

• RSS via NetNewsWire (free, native Mac app) for ~70 feeds — blogs, engineering newsletters via Kill the Newsletter (which converts email newsletters into RSS feeds), and a couple of Czech tech sites.
• Read-later for strays: anything from Slack, Mastodon, or conversations goes into a read-later queue via a share-sheet shortcut. Reader-mode extraction matters here — you want clean article text, not nav bars and cookie banners. The reader-cli/Readability-style extraction tools, or simply Safari Reader → share as text, all work; I use a small shortcut that grabs the Reader version of the current Safari page and saves it as Markdown to ~/Reading/inbox/.

The rule at this stage: zero judgment. Capturing costs two seconds; deciding costs attention. Don’t mix them. By morning there are typically 40–60 items in the queue — pocket math says that’s unreadable, which is why most reading systems die. Mine survives because of stage two.

Stage two: local AI triage — the 20-minute pass

Every morning a script walks the inbox and produces a triage digest. The stack is Ollama plus Qwen2.5 14B on my Mac Studio (an 8B model on a lighter Mac does this fine — summarization is not a frontier-intelligence task). Here is the actual prompt template, verbatim, the one file doing the heavy lifting:

You are a reading triage assistant. For the article below, output
exactly this format:

SUMMARY: 3 sentences. What is actually claimed or shown, not the topic.
NOVELTY: 1 sentence. What's new here vs. common knowledge on this topic?
DEPTH: one of [data/original-research | experienced-practitioner |
       aggregation | opinion | promotional]
VERDICT: one of [READ — genuinely novel or deep
                 SKIM — one useful idea, findable in 2 minutes
                 SKIP — you already know this]
REASON: 1 sentence justifying the verdict.

Be harsh. Most articles are SKIM or SKIP. An article earns READ only
if it contains original data, original experience, or an argument
that would survive the deletion of its examples.

ARTICLE:
{text}

The driver script is ten lines:

for f in ~/Reading/inbox/*.md; do
  echo "## $(basename "$f")"
  cat ~/Reading/triage-prompt.txt "$f" | ollama run qwen2.5:14b
  echo
done > ~/Reading/digest-$(date +%F).md

It runs while I make breakfast — about 8–12 seconds per article on the 14B, so a 50-article queue takes 8–10 minutes of machine time and zero of mine. Then I read the digest. That’s the 20 minutes: 50 verdicts, each summary taking 15–25 seconds of human reading. The DEPTH field earns its place — “aggregation” and “promotional” are auto-skips, and the model classifies those with embarrassing reliability, because listicles and content marketing have a texture models smell instantly.

The same model handles my Czech sources and outputs the digest in English, which quietly removes the small friction tax I used to pay switching languages mid-triage.

Stage three: the 50/day math, honestly itemized

On a typical day, the funnel looks like this:

• ~50 in, ~40 resolved by digest alone (~20 min): SKIPs discarded without guilt, plus READ/SKIM labels assigned. The crucial mental shift: a SKIP isn’t unread — it’s processed. I know what it said and decided it wasn’t worth more.
• ~8 skimmed (~15–20 min total): opened, read the intro, jumped to the section the summary flagged, grabbed the one idea, closed.
• ~2 read deeply (30–60 min): full attention, slow, with highlights. These are the articles the system exists to find.

Total: roughly 70–95 minutes a day, of which more than half is real reading of the best 2–4% of my queue. Before this system I spent about the same time reading whatever happened to be at the top, fully finishing maybe three random articles and feeling vaguely behind on forty. Same time budget, radically better allocation. That’s the honest claim: not more reading — better-aimed reading.

Highlights from the deep reads get one more AI pass at the end of the week: I paste them into the model with “Group these highlights by theme and phrase each theme as a question I seem to be circling.” That synthesis step is what turns reading into notes instead of a feeling.

The contrarian section: what AI summaries destroy

Now the part most workflow posts skip. AI summarization is lossy compression, and the loss is not evenly distributed — it falls heaviest on exactly the writing that’s worth the most.

A summary preserves claims and discards experience. But great writing doesn’t work by claims; it works by walking you through a sequence of thoughts until the conclusion becomes yours. Summarize a sharp essay and you get its thesis — true, transferable, and inert. You can repeat it; you don’t believe it the way you would have after twenty minutes inside the author’s head. The summary of a great essay and the summary of a mediocre take on the same topic are often nearly identical. The difference between them was never the thesis. It was the texture, the specific examples, the half-paragraph where the author admits doubt — everything the compression throws away first.

There’s a second-order risk too: optimize your intake for what survives summarization and you drift toward content that is only its information — news, benchmarks, announcements — and away from writing that changes how you think. After a few months I noticed my READ pile skewing toward data-dense posts and against essays, so I added a manual override: certain authors bypass triage entirely and go straight to the deep-read pile, summary unseen. Everyone running this workflow should keep such a list. If a writer has earned your attention, don’t make them re-audition through a 14B model every week.

Start smaller than I did

If you build one piece of this, build the triage prompt. Install Ollama (brew install ollama, ollama pull qwen2.5:14b — or the 8B on a 16 GB machine), save the template above, and pipe tomorrow’s five open tabs through it before reading any of them. You’ll get the core experience in ten minutes: the strange, slightly deflating clarity of seeing five headlines reduced to two SKIPs, two SKIMs, and one READ — and noticing the READ wasn’t the tab you’d have opened first.

The full system — RSS consolidation, the inbox folder, the morning script, the weekly synthesis — took me about two hours to assemble and has run with minor tweaks for eight months. Fifty articles a day flow through it. Two get the thing no model can give them: an actual reader.