Nokia Design Archive (2025) | Build or Be Replaced
Today: Nokia Design Archive (2025) | Toyota is taking the Corolla electric | Show HN: Whiteboard (YC W26) – An open-source IDE for thoughtful software design Episode date: 2026-09-25.
Download MP3 →
Build or Replaced
Today: Nokia Design Archive (2025) | Toyota is taking the Corolla electric | Show HN: Whiteboard (YC W26) – An open-source IDE for thoughtful software design Episode date: 2026-09-25.
Download MP3 →ERIK: Everybody's trying to get out from under somebody else's infrastructure today. Google wants compute in orbit, the Dutch government wants off Microsoft. Nobody wants to be the tenant anymore. JOSH: It's Friday, September 25th. 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 defaulting to whatever's loudest. [pause] JOSH: Alright, quick headlines. ScanBrief pulled 83 items overnight across 56 sources, so we've got options. First one — Nokia just opened its full design archive going back decades. What's actually useful about digging through old phone designs? ERIK: Constraints. A keypad and a battery that had to last a week forced real design discipline. Now every phone's a slab of glass and the design problem is basically solved, so there's nothing left to be clever about. JOSH: Next — Toyota's finally putting the Corolla on an EV platform. ERIK: Late on purpose. The Corolla's their highest-volume car worldwide. You don't experiment on your best seller. You prove the platform on the Prius, the bZ, whatever, then you electrify the thing that can't afford to fail. JOSH: Last one — there's a dataset floating around of every Street View coverage gap on Earth, down to the block. [beat] ERIK: That one's underrated. Somebody had to stitch together capture dates, camera generations, and coverage holes across a couple hundred countries into something queryable. That's the unglamorous half of any AI pipeline — the indexing — and nobody notices it until it's missing. [pause] JOSH: Let's go deeper. Google announced Project Suncatcher — putting ML infrastructure in space. When I first read that I thought it was a joke. ERIK: It's not, and it's not as crazy as it sounds. Solar in orbit doesn't have night, doesn't have clouds, doesn't have a grid interconnect queue. If you're Google and your bottleneck is power for training clusters, orbit starts looking like just another data center site — an expensive one, but power-unlimited. JOSH: But you can't exactly send a tech out to swap a bad GPU up there. ERIK: Right, that's the real story. It's not the launch cost, it's the maintenance model. Every system I run assumes I can SSH in and fix it, or PrimeBus catches the failure and self-heals it. You lose that entirely in orbit. Whatever they put up there has to be fault-tolerant in a way nothing on the ground has to be, because there's no truck roll. JOSH: Does that change how you think about redundancy in your own stuff? ERIK: It's the same principle at a different scale. I've got 154 services running on the prod server right now, and I don't watch most of them directly — I watch PrimeBus. 140 distinct projects emit telemetry into it. If something on Bill's Mac or in the Echo lab goes sideways, I find out from an event, not from staring at a terminal. Google's just doing that same idea where the failure domain is a satellite instead of a container. JOSH: That's wild that the underlying logic is the same whether it's your home lab or something Google's launching into orbit. ERIK: Distance doesn't change the architecture. It just raises the cost of being wrong about it. [pause] JOSH: Okay, second one — the Dutch government is building an alternative to Microsoft based on NixOS. ERIK: Good. More of this, please. NixOS gives you a fully declarative, reproducible system config — you can rebuild the exact same environment from a file, byte for byte. For a government that just got spooked about depending on one American vendor for its entire desktop and email stack, that's not a nice-to-have, that's the whole point. JOSH: Why does reproducibility matter that much for something like a government migration? ERIK: Because the alternative is tribal knowledge. Somebody clicks through a GUI for three years, nobody documents it, and the system only exists in one guy's head. Nix forces you to write down every dependency as code. If that guy leaves, the config doesn't leave with him. JOSH: You basically run your whole lab that way already, don't you? ERIK: That's the whole idea behind PrimeBus. Everything's declared, everything emits an event, nothing lives in my head only. The auto-merger's run 2,295 attempts since June — 1,507 merged clean, 788 blocked by Gandalf, zero escalated to me. That's not a 65% success rate story, that's a story about 788 times the guardrail did its job instead of shipping something broken to prod while I was asleep. JOSH: Wait, zero escalated? None of those 788 needed you personally? ERIK: Not one. That's the entire point of building it this way — Gandalf catches it, blocks the merge, and either fixes it or reports it without waking me up. The Dutch government's chasing the same outcome at a completely different scale — don't let one vendor, or one person, be a single point of failure for the whole system. [pause] JOSH: Third one, and this ties into your tip — Opus 5.5 is apparently really good at explainer videos. ERIK: This is the one people get wrong constantly. They pick one model and use it for everything — code, writing, video, whatever — because switching feels like extra work. That's backwards. Different models are just better at different jobs, the same way I wouldn't run a real-time chat backend through the same pipeline I use for batch scoring 83 news items overnight. JOSH: So what's actually different about a model that's good at explainer content versus one that's good at, say, writing code? ERIK: Pacing and narrative structure versus logical precision. Explainer video generation needs a model that understands how a human absorbs information over time — when to slow down, when to cut. Code generation needs a model that's ruthless about correctness and doesn't care about pacing at all. JOSH: You run more than one model day to day, right? ERIK: Three Claude instances across the fleet, plus Hermes running local on the M3 for anything I don't want leaving the house — that's qwen3-coder, about 70 tokens a second. I don't send a HumanDesignApp state-machine bug to the same place I'd send a script for this show. Wrong tool for the job wastes more time than the switch ever costs you. [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 your favorite model for every task. Before you prompt, ask what the job actually needs — reasoning depth, speed, pacing, cost. If it's a quick classification pass, use something fast and cheap. If it's architecture or a multi-step failure you're debugging, use the model built for depth. I've got that decision built right into PrimeRouter — it picks the backend based on the job, not on habit. You can do the same thing by hand: just ask "what does this task actually need" before you ask "which model do I always reach for." That's your tip. Use it. 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.