Delta’s Biscoff cookies were supposed to be temporary | Build or Be Replaced
Today: Delta’s Biscoff cookies were supposed to be temporary | What I self-host | Celebrating 70 Years of Fortran Episode date: 2026-10-16.
Download MP3 →
Build or Replaced
Today: Delta’s Biscoff cookies were supposed to be temporary | What I self-host | Celebrating 70 Years of Fortran Episode date: 2026-10-16.
Download MP3 →ERIK: It's Friday, October 16th. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Erik, here with Josh. JOSH: Erik, what's today's theme? ERIK: Models keep getting bigger and the internet keeps getting scraped harder. Two unrelated stories that are actually the same story. JOSH: Stick around — Erik's got an AI pro tip at the end about when a huge model is actually the wrong tool for the job. [pause] JOSH: Alright, headlines. First up — Delta's Biscoff cookies were supposed to be temporary. Turns out "temporary" airline snacks never die. ERIK: Nothing is more permanent than a "limited time" decision nobody owns. That's every legacy cron job I've ever inherited. JOSH: Next — somebody's been messing with a guy's Sonarr instance off torrent sites. Like, actively sabotaging it. ERIK: If your self-hosted stuff is reachable and you're not watching the logs, you don't own a server anymore, you own a target. [beat] JOSH: And this one's wild — the BIPM is killing leap seconds. No more adding a second to UTC to keep up with the Earth slowing down. ERIK: Forty years of "just add a second" scripts about to break in ways nobody's tested. That's a timestamp bug waiting to happen in production systems everywhere. [pause] JOSH: Okay, let's go deeper on a couple of these. First one — this Muse Spark Open model. 816 billion parameters, but only 42 billion active? ERIK: That's mixture-of-experts. You've got a huge model, but for any given token it only wakes up a slice of it. So it's got the knowledge of something massive while the actual compute per token looks a lot smaller. JOSH: And the headline was it runs locally. On a desktop? ERIK: On two Mac Studios with the new M5 Ultra chips, chained together. That's the part that got my attention. A year ago that's a model you'd need a rack of H100s for. Now it's two consumer boxes on a desk. [beat] JOSH: Does that change anything for you? You're not running Mac Studios in the lab. ERIK: It changes the ceiling, not my setup. I've got Bill, my M3 Mac, doing GPU work already — iOS builds, that kind of thing. The direction matters more than the specific box. A million-token context window, agentic coding, and it's weights-are-public — that's the combination I watch for. JOSH: Why agentic specifically? ERIK: Because that's what PrimeBus actually needs. PrimeBus is my self-healing pipeline — it catches a test failure, spins up a fix attempt, tries to merge it. That loop lives or dies on whether the model can hold a long task without losing the plot. A long context window isn't a spec sheet number to me, it's whether an agent can read a whole repo and still remember what it was doing an hour in. JOSH: Has PrimeBus been busy? ERIK: 2,295 merge attempts since June. 1,507 got merged. 788 got blocked by Gandalf, my review layer. JOSH: Zero escalated to you? ERIK: Zero. That's the number I actually care about. People hear "788 blocked" and think failure rate. No — that's 788 times the guardrail did its job instead of me waking up to a broken prod server. The system is supposed to catch most of its own mistakes. That's 65.7% merging clean and the rest getting caught before it matters. JOSH: What happens to the 788? Do they just vanish? ERIK: No, they sit there as data. Every blocked merge tells me something — a test that's too brittle, a diff that got too big, a model that drifted off task. I go back through the fix guides when a pattern repeats three or four times instead of once. It's not a failure log, it's a tuning log. [pause] JOSH: Alright, second deep dive. Meta's changing its commercial terms to allow scraping news sites for AI and ad products. ERIK: This is the one that should make every publisher nervous, and honestly every builder like me pay attention too. When the biggest platform on earth says "we can scrape your content for our models," that's not a legal footnote, that's a shift in who owns the value of information. JOSH: Wait, really — they're just putting that in the terms, out in the open? ERIK: That's the part people are missing. It's not a leaked internal memo, it's a published policy change. Which means legal already cleared it and they're betting most publishers won't push back hard enough to matter. That's the real signal — not that scraping happens, everybody scrapes, it's that they're comfortable saying so. JOSH: How does that hit you directly? You're not a news publisher. ERIK: I run ScanBrief. It pulls from 56 sources, scores everything, ranks it, and ships a brief every morning. Today it scored 113 items with an average relevance score of 52. The entire business model is "someone already did the scraping and summarizing work so you don't have to." If every big platform starts doing that natively, baked into the product you already use, the whole category of "news brief" tools has to get sharper or get replaced. JOSH: So what's your move? ERIK: Don't compete on volume, compete on signal. Anybody can scrape. The hard part is scoring what actually matters to a specific person instead of just surfacing what's popular. That's the only moat left once scraping becomes table stakes for everyone. JOSH: Does that mean you're changing anything about how ScanBrief scores stuff? ERIK: Not the scoring model, but it pushes me to lean harder into personalization instead of just a ranked list everybody sees the same way. If Meta's brief looks the same for a hundred million people, mine should look different for every subscriber. Right now it's two subscribers, so there's room to actually tune that per person instead of pretending I'm running at scale. [beat] JOSH: Last one — "What I Self-Host." Front page of Hacker News basically every week in some form. ERIK: And it should be. I've got 139 services running on my production server right now, 140 projects total have shipped telemetry through PrimeBus at some point. Self-hosting isn't a hobby for me, it's the whole operation. JOSH: What's the actual argument for someone who's never done it? Why not just pay for the SaaS? ERIK: Control and cost, in that order. When something breaks at 2 AM, I'm not opening a support ticket and waiting. I've got Homer on Morpheus running monitoring, and the Bobs — my fleet of Claude agents — picking up events off the bus and acting on them before I'm even awake. Twelve agents total in the fleet right now, Claude and GPT both, watching different pieces. JOSH: That sounds like a lot to maintain solo. ERIK: It would be, if I did it the dumb way — logging into every box by hand. I don't. Everything emits events onto PrimeBus, and the agents subscribe to what they care about. You put one thing on a bus each week instead of building ten point solutions, and in six months you've got a system that mostly runs itself. JOSH: PrimeRestorer's part of that too, right? ERIK: That's my backup orchestrator — databases, full system snapshots, offsite to S3. Self-hosting without a backup story is just gambling with extra steps. People get excited about the control part and skip the boring part, and the boring part is the one that saves you when a drive dies on a Tuesday. JOSH: Has PrimeRestorer actually saved you, or is it just insurance you've never had to use? ERIK: Both, honestly. Most weeks it's just insurance. But I've had a service corrupt its own SQLite file mid-write, and instead of rebuilding from scratch I pulled the last good snapshot and PrimeDash showed it green again in under ten minutes. That's the whole pitch for self-hosting in one line — own the failure mode instead of waiting on someone else's status page. [pause] ERIK: This episode is sponsored by Prime Automation Solutions. If you're still doing it manually, we automate it. Also, special on a website — $250. primeautomationsolutions.com [pause] JOSH: Alright, what's the AI pro tip today? ERIK: Stop reaching for the biggest model by default. A 800-billion-parameter mixture-of-experts model is great for open-ended reasoning, but if your task is narrow — classify this ticket, extract this field, format this log line — a smaller model wins every time on latency and cost, and it's usually just as accurate. JOSH: How do you decide which to use? ERIK: I think about it as a chain, not a single choice. PrimeRouter is my gateway for exactly this — it looks at the task, checks what's actually available, and walks a priority list of backends instead of hardcoding one model everywhere. Simple tasks go to something small and fast. Anything that needs deep reasoning or has to hold a long context gets escalated. The mistake people make is picking one model and forcing every job through it because it's the one they're used to. JOSH: So bigger isn't always better. ERIK: Bigger is a tool, not a default. Match the model to the job, not the hype cycle. That's your tip. Use it. [beat] JOSH: Binge all five episodes this weekend plus our YouTube shorts — links at buildorbereplaced.dev. [pause] JOSH: One more thing — we started a Discord for builders. If you're shipping AI, automation, or anything that makes a human obsolete — come hang out. Link at buildorbereplaced.dev. ERIK: Post what you built. We'll post what we're building. Real wins, real builds, no fluff. [pause] ERIK: Build or be replaced. JOSH: If you want these signals in your inbox every morning, scanbrief.dev. See you tomorrow.