Tech FAQ

I only ever used the app for one thing: seeing what the 10 to 15 channels I subscribe to had posted, newest first. Dropping the app as part of degoogling meant losing that. I never touched comments, recommendations, or Shorts, so rebuilding only the subscription feed got me the part I used without the rest of the app I didn't.

No. Every YouTube channel publishes a public RSS feed at feeds/videos.xml listing its recent uploads as Atom XML. The Worker reads that feed directly and parses it with fast-xml-parser, so there is no API key, no quota, and no Google project to manage.

Yes. The feed is built entirely from each channel's public RSS feed, which anyone can read without signing in, so there is no Google account, no login, and no subscription list stored on Google's side. You keep your own list of channels instead.

You add a channel by URL or @handle. The Worker scrapes the channel page to resolve that input to a stable channel ID, which never changes even if the handle does, then fetches the RSS feed for that ID. Resolved channels are saved so the resolution step only runs once per channel.

Two independent checks. A title heuristic flags anything tagged #shorts, and a per-video redirect probe confirms whether a video is a Short, because Shorts and full videos resolve differently. Only full videos make it into the feed.

Not until you press play. Thumbnails are static, and clicking one loads the video inline through YouTube's nocookie IFrame player, so no tracking cookies are set until playback starts. On iOS the player autostarts muted with a tap-for-sound overlay, because Apple blocks one-tap sound on the web.

Channels you add at runtime persist in Cloudflare KV. The merged, sorted feed is edge-cached with the Cache API for 15 minutes, and all channel feeds are fetched in parallel with per-channel timeouts, so a slow or dead channel cannot stall or break the page.

GitHub Pages has no access logs, a hard cap on file size, no control over response headers without a Cloudflare Worker in front, and no place to run anything dynamic alongside the static site. Moving to a self-hosted box adds operational responsibility but unlocks all of those, plus puts the site's data in a jurisdiction I chose.

Cost, transparency, and jurisdiction. A Hetzner CPX21 in Nuremberg has more than enough capacity for a Hugo blog plus supporting services, costs a fraction of equivalent compute on AWS or DigitalOcean, runs on contracted renewable energy, and is operated by a German company under EU law. The tradeoff is fewer managed services, which I wanted anyway.

Cloudflare R2 EU jurisdiction keeps the data in EU data centers under stricter handling rules. R2 also has zero egress fees, an S3-compatible API, built-in integration with the existing Cloudflare Workers, and an image-resizing pipeline I'd already built. Cloudflare is still US-headquartered, so this is a partial sovereignty win, not a complete one.

Partially. R2 EU jurisdiction guarantees data is stored and processed inside EU data centers and applies stricter handling rules, but Cloudflare remains a US-headquartered company subject to the CLOUD Act, so a US court could in principle compel disclosure. For posts and images that tradeoff was acceptable. For newsletter subscriber lists I moved off third-party services entirely onto a self-hosted Listmonk instance.

Cloudflare's CDN, Workers, cache rules, and rate limiting make the site fast everywhere and keep brute-force probes away from self-hosted admin panels. Replacing that layer with a European alternative would be a significant downgrade in capability. Resend handles SPF, DKIM, DMARC, and reputation management for outbound mail. European alternatives exist; ones I trust for newsletter deliverability do not.

Higher than a managed service, lower than people assume. The box runs Caddy for TLS and reverse proxy, Postgres for the supporting services, SQLite for analytics, restic for nightly encrypted backups to R2 EU, and templated systemd alerts that email on any failed unit. Backups have monthly integrity checks. Most ongoing work is reading log digests and applying OS updates.

Nightly restic snapshots to a Cloudflare R2 EU bucket, encrypted with a passphrase stored in two places. Monthly partial-read integrity checks verify the archive is restorable. A full restore drill onto a clean parallel box was the hard gate before flipping DNS, and that drill is now part of the runbook.

Karpathy frames three eras of software. Software 1.0 is humans writing explicit code. Software 2.0 is humans curating datasets and training neural networks, where the weights are the program. Software 3.0 is humans writing prompts, where the LLM is the interpreter and the context window is the program. The unit of programming shifts from a function to a paragraph.

Karpathy points to December 2024 as the inflection point. Before then, agentic tools were 'kind of helpful' but required constant correction. Over the December break, the latest models crossed a line where Karpathy stopped correcting them and started trusting the system. He flagged this on the record, warning that anyone whose mental model of AI was set by ChatGPT was already a generation stale.

Vibe coding raises the floor: it lets non-engineers build software they could not build before. Agentic engineering raises the ceiling: it lets professional engineers preserve the existing quality bar while moving much faster. Karpathy thinks the productivity gap for the best users now exceeds the old 10x engineer benchmark by a wide margin.

Frontier labs train models with reinforcement learning, which requires verifiable rewards. Verifiable domains attract environments and signal, so they get the steepest gains. Everything outside the verifiable distribution stays jagged. Karpathy's takeaway for founders is that building a verifiable environment in your domain is real leverage. For workers, the more useful question than 'is my job safe' is 'is my job verifiable.'

As agents do more execution, the bottleneck moves into the human's head. You still have to know what is worth building, why, and how to direct the work. Your value sits upstream of execution. Karpathy keeps building knowledge bases out of his own reading because the constraint of the next decade is less about compute than about how fast humans can deepen comprehension to keep directing systems that out-execute them.

Karpathy built MenuGen as a full-stack app: photo a restaurant menu, OCR it, generate dish images, render a new menu. Then he saw the Software 3.0 version: hand the photo to Gemini, say 'use NanoBanana to overlay the dishes,' and a single model call returns the rendered menu. The lesson is that a lot of what gets built today is scaffolding around a capability the model could perform end-to-end. Before writing the next CRUD app, ask whether the model is the app.