The Reader Is the AI

A developer I've read for years shipped something this week: a modern, AI-native RSS reader. It's genuinely nice — a couple hundred curated sources, eighteen thousand articles, a clever in-app assistant that reads the article you're looking at and answers questions about it. Keyboard shortcuts, the works. A real product, built over months on top of Claude Code and Codex, with a backend, an account system, a sync layer, the lot.

I'd built the same thing months ago. Except mine isn't an app.

Mine is a 640-line Python script that writes a Markdown file, plus a prompt that turns my AI assistant into the reader. No backend. No database. No account. No UI. And sitting here comparing the two, I don't think I cut corners. I think I found the floor — the actual minimum the problem requires once you stop assuming the answer has to be an application.

That gap is worth pulling apart, because it's not really about RSS. It's about a whole category of software that's quietly becoming obsolete.

The same problem, inverted

Here's the orthodox way to build a reader, and it's what every product on the market does — Reeder, Feedly, NetNewsWire, and now the AI-native ones too. The app is the product. It owns a UI you render, a database you run, a sync layer you maintain, an account system you secure. And then, recently, you bolt an AI assistant onto the side as a feature — a panel the user summons to ask about whatever's on screen.

Look at where the engineering goes. Ninety-five percent of it is the container: the shell, the sync, the auth, the billing, the cross-device state. Maybe five percent is the actual reading. The intelligence is a guest in someone else's house.

Now here's the inversion. What if the intelligence is the house?

Four layers. The first three are a machine you can read end-to-end in ten minutes. The fourth is a mind you already keep on call.

My system has four layers, and only one of them is something you run:

1. Ingest. A script pulls the feeds — Hacker News, Reddit, GitHub, a few crypto-dev forums — using nothing but the Python standard library. Each source is one function that returns a list of dictionaries. There's no framework to learn because there's no framework.

2. Signal. The script keeps a single JSON file remembering every item it has ever seen and the peak score it reached. On each run it tags items: new, re-igniting (score doubled), simmering (up a quarter), or — if a story is known and flat — it silently drops it. That's the only cleverness the fetcher has. It doesn't summarize or rank. It answers exactly one question per item: is this worth your attention today?

3. Store. One plain-Markdown file per day. That's the whole database. I can grep six months of tech news in a second, diff it in git, read it in any editor, paste it into anything. There is no proprietary format and nothing, ever, to migrate to.

4. Read. This is where the AI takes over — and this is the part that has no equivalent in the app. A small Claude Code skill tells my assistant: here's today's file, filter it to what I care about, go read the sources, and talk it through with me.

The fetcher is deliberately, aggressively dumb. All the judgment lives in the model. I keep the script boring precisely so it never breaks, and I put everything that requires intelligence in the one component that gets smarter on its own every few months without me touching it.

The move the app can't make

There's one difference that turns this from a cute minimalism story into an actual capability gap, and it runs the opposite direction from what you'd expect.

The in-app assistant — the impressive one, in the polished product — can only reason over what's already in its database. It's reading a frozen index. Ask it about an article and it answers from the stored copy.

My assistant reads the source live. When something in the morning's file looks interesting, it fetches the actual page, right then, mid-conversation, and reasons over the real thing — not a snapshot taken at crawl time, not a summary baked into a row three days ago. If a Reddit thread is the story, it pulls the thread. If a release note matters, it reads the release note. The "reader" isn't a precomputed artifact sitting in a table. It's a live act, performed fresh every time I ask.

The app spent enormous effort building a database so the AI would have something to read. I skipped the database and pointed the AI at the open internet, which is where the articles already live.

The honest counterpoint

I want to be fair, because the builder of that polished reader is sharp and he said the true thing himself. His point, roughly: vibe-coding a small offline tool for yourself is easy now, even when the underlying tech is deep — the AI handles it. But the moment you need a network service, a database, an account system, a production deployment, security, and you're shipping to thousands of strangers — the bar is still high. The app is hard, and it's hard for real reasons.

He's right. And that's exactly the line that decides which side of the inversion you belong on.

If you're serving thousands of people who don't control their own machines, you need the container. The accounts, the hosted database, the sync, the billing — that scaffolding is the product, because coordinating many strangers is the actual problem you're solving.

But if the user is one person who controls their own machine — you — then every piece of that scaffolding is pure cost with no payoff. You're not coordinating strangers. You're reading the news. The app, for that user, was never the point. It was just the only way we knew how to deliver a capability, back when capabilities had to come wrapped in applications.

They don't anymore. That's the whole shift.

What's actually dying

Step back from RSS and the pattern gets larger than one reader.

For decades, "software" meant: take a capability, wrap it in an application so a human can reach it. The wrapper — windows, menus, settings screens, sync, accounts — was never the value. It was the delivery mechanism for the value. We just couldn't separate the two, so we paid for the whole bundle and called the bundle the product.

CLI-driven AI separates them. The capability — "read the tech world and tell me what matters" — no longer needs a custom wrapper, because the wrapper already exists on my machine: it's the assistant I already talk to. So the capability collapses down to its two irreducible parts. A boring script that gathers raw material. A prompt that tells a general intelligence what to do with it. The application in the middle — the part that used to be the product — just evaporates.

This is why I've started to believe a large class of single-user apps is on borrowed time. Not the hard multi-tenant systems; those earn their complexity. The small ones. The utility you'd have downloaded and paid five or fifty dollars for, that does one focused thing for one person. That whole shelf is turning into scripts and prompts. The reading was always the point. The app was always scaffolding. Now you can take the scaffolding down and the building still stands — because the building was never the app. It was you, and a thing that reads to you.

Takeaways

If you build, or you're deciding what to build:

1. Ask what's scaffolding and what's capability. The UI, the sync, the account system — are they the value, or just how the value used to get delivered? For a single user, it's almost always the latter.
2. Keep the dumb parts dumb. A boring script that never breaks, holding all the judgment in a model that improves on its own, beats a clever app that rots. Put intelligence where it compounds.
3. Plain text is the universal interface. No database, no lock-in, no migration. grep is your search and git is your history. You will never regret choosing a format you can read with your eyes.
4. Point the AI at the live source, not a frozen copy. The freshest read beats the best-indexed snapshot. Don't build a warehouse for data that already has a home on the open web.
5. Multi-tenant earns its complexity; single-user doesn't. Know which one you're building before you reach for a backend. If the answer is "just me," the answer is probably a script and a prompt.

The builder I admire shipped a beautiful app, and for what he's doing — a curated reader for thousands of subscribers — the app is the right call. I shipped 640 lines and a prompt, and for what I'm doing — reading the morning to myself — the app would have been a cage.

Same problem. Opposite floor. The difference is just where you decide the reading happens — inside an application you maintain, or inside the mind you already keep on call.

I open-sourced mine. It's called Kame Island, after the little house where Master Roshi sits and reads his newspaper. The joke is that you don't sit and read anymore. The turtle hermit does it for you now.

---

— Code & Rob · 1984