Build or Replaced
Today: Passkeys are a trap | Total Annihilation, rebuilt for modern computers | The gap in shared understanding of LLM capability is widening Episode date: 2026-10-12.
Download MP3 →1,607 words — within the 1,500–2,200 band. Here's the final script: ERIK: Monday means the fleet caught up on everything that happened over the weekend. PrimeBus ran 2,295 auto-merge attempts since June — this morning it's sitting at 1,507 merged and 788 blocked by Gandalf. Nothing escalated to me. JOSH: It's Monday, October 12. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. JOSH: Stick around — Erik's got an AI pro tip at the end about picking the right model for the job instead of just reaching for the biggest one. [pause] JOSH: Okay, headlines. First up — "Passkeys are a trap." That's a bold headline. ERIK: It's not wrong, either. Passkeys solve phishing, but they tie you to a vendor's cloud. Lose the ecosystem, lose the keys. Great security model, lousy portability story. JOSH: So what do you actually do about it? ERIK: You pair passkeys with a hardware key you control, not just the vendor's cloud backup. If the vendor has a bad day, you're not locked out of your own accounts. [beat] JOSH: Next — NYC's "Click to Cancel" rule just went into effect. ERIK: If a business lets you sign up online, they now have to let you cancel online. Same number of clicks either way. It's the FTC rule finally landing at the state level, and every subscription business just got a very short todo list. JOSH: Think other states follow? ERIK: They will. This is how federal rules spread when enforcement stalls at the top — states pick it up one at a time, and by next year it's just the norm everywhere. [beat] JOSH: And — "Fingerprints are the new cookies." Browser fingerprinting replacing cookie tracking. ERIK: Cookies got regulated so hard that tracking just moved to something harder to block. Your device's fonts, GPU, screen size — that's the new identifier. Incognito mode barely helps. JOSH: Is there anything that actually blocks it? ERIK: Not much. Browser vendors are starting to randomize some of those signals, but it's an arms race, and the trackers are currently winning. [pause] JOSH: Let's go deeper. ScanBrief scored 70 items across 56 sources this morning, average relevance 52.8, and one headline stood out to you. ERIK: "The gap in shared understanding of LLM capability is widening." That one's been bugging me all weekend because I live in that gap every day. JOSH: What do you mean, live in it? ERIK: PrimeRouter is my LLM gateway — it sits in front of every model call across the fleet and does priority-tier routing with multi-provider failover. Claude, Gemini, local Ollama, whatever's available. And the gap isn't about which model is smartest. It's that most people still think of these models as one thing — "the AI" — when the actual capability curve between a frontier model and a quantized local model is enormous. JOSH: How does that play out day to day? ERIK: I've got agents across the Bobaverse fleet — Neo, Homer, Bill, Echo, Gandalf — some Claude, some GPT. Each one's doing a different job, and the routing decision for "which model handles this" matters more than people realize. Code review needs a model that can actually hold a diff in its head. A status summary doesn't. If you route everything to the same model because that's the one you know, you're either overpaying or under-delivering. I've got role profiles in PrimeRouter — basically a job description per model — and the profile for the review chain looks nothing like the profile for a one-line summarization task. A model that's great at writing prose is not automatically great at catching a bug in a merge pipeline, and treating them the same is where most teams waste their budget. JOSH: Does that ever bite you — guessing wrong on which lane a task needs? ERIK: Sure, early on. I had a code review job routed to a lightweight model to save cost, and it missed an edge case a frontier model would have caught. Cheap lane, expensive mistake. That's when the role profiles got strict about what's allowed to touch the merge pipeline. JOSH: Is that the mistake most people make — treating every task the same? ERIK: That's exactly it. The gap isn't "AI is overhyped" or "AI is underhyped." It's that the people making buying decisions haven't caught up to how specialized this has gotten. And it's not static — I'll shift a lane from one provider to another the moment I see a cost spike or a failover pattern in the logs, because the right answer today might not be the right answer next month. [pause] JOSH: The one that really got my attention was "Zod 4.6.6 compromised by malware?" Zod is everywhere in the JavaScript world. ERIK: Yeah, that one's a gut-punch story because it's a supply chain attack, and those are the ones that get past normal code review. Nobody's reading the diff on a dependency update. You just trust the version bump. JOSH: So how does a system like yours catch something like that? ERIK: This is exactly why PrimeBus exists. Every code change in my pipeline — human or agent-written — goes through an event bus with auto-review before it can merge. That 788-blocked number from this morning isn't failure, that's the guardrail doing its job. Something looked wrong, it got stopped, nobody had to notice at 2 AM. Dependency bumps flow through the exact same gate before anything gets promoted — there's no fast lane for "it's just a version number." JOSH: Would you ever just block dependency updates entirely until someone looks at them? ERIK: That's basically what the gate does. Nothing merges on vibes — it merges because the review step actually passed, and a flagged dependency sits right next to a flagged line of code. Same queue, same scrutiny. JOSH: But a compromised package isn't something you wrote — it's something you pulled in. Does the pipeline actually treat that differently? ERIK: No, and that's the point. The lesson from a story like Zod is "never let a dependency bump skip review just because it looks routine." The attacks that work are the boring-looking ones. If your pipeline treats a version bump as low-risk, that's the hole. My email-reactor service handles client website change requests automatically, and if a bad package landed in that path unreviewed, it's not just my code, it's touching client infrastructure. Small diffs, real review, every time. That's the whole philosophy, and it's why I'd rather eat a few false positives in that 788 number than let one real one through. [beat] JOSH: One more — "Postgres isn't slow, your storage is." That feels like a very specific complaint. ERIK: It's a good one because it's true and nobody wants to hear it. People blame the database engine when the actual bottleneck is EBS or whatever network-attached disk they're running on. Postgres on bad storage looks slow. Postgres on NVMe looks completely different. JOSH: Is that something you've dealt with running your own backups? ERIK: PrimeRestorer handles backup orchestration across databases, system state, and offsite to S3 — and the first time a restore job ran slow, my instinct was to blame the backup logic. It wasn't. It was disk contention on the box doing the restore. I moved the restore target to faster local storage before I ever touched S3, and the runtime dropped — same database, same backup, different disk. Same lesson as the Postgres story — profile the actual layer before you blame the software sitting on top of it. Everybody wants to rewrite the query. Almost nobody wants to check what disk it's landing on. JOSH: Any rule of thumb for catching that before it becomes a 2 AM problem? ERIK: Benchmark the disk before you ever point a database at it. If a restore or a query runs slow, check IOPS and latency first, not the query plan. Ninety percent of the time the fix is a storage change, not a schema change. [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 defaulting to the biggest model for every task. Before you fire off a prompt, ask what the task actually needs — reasoning depth, context window, or just speed. A quick classification or a one-line summary does not need a frontier model; a smaller, cheaper model nails it just as well and costs a fraction as much. Save the expensive model for the task where getting it wrong actually costs you something — a code review, an architecture call, a customer-facing response. Build that routing decision into your workflow once, and you stop re-deciding it every single time. ERIK: Here's the test I actually use — if I can describe the task in one sentence and a human intern could do it correctly without thinking hard, it goes to the cheap lane. If it needs judgment, context across multiple files, or there's real cost to being wrong, it goes to the expensive one. JOSH: So it's not about the best model, it's about the right model. ERIK: Every time. That's your tip. Use it. [beat] ERIK: That tip is straight out of The Autonomous Engineer — my book on building systems that run themselves. Grab it on Amazon. [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.