Build or Replaced
Today: Keychron announces first open-source firmware for gaming mice | A.I. companies are recruiting electricians and carpenters by the thousands | Kimi K3-256k Episode date: 2026-07-30.
Download MP3 →JOSH: It's Thursday, July 30. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: AI is out of the browser and into the walls now. JOSH: Stick around — Erik's got an AI pro tip at the end about making agents ask better follow-up questions. JOSH: [pause] JOSH: First headline. Indeed says data center job postings have more than doubled in two years. What's the real signal? ERIK: The AI boom needs electricians, installers, maintenance techs, and construction crews. About a quarter of data center openings are installation and maintenance now, and those jobs are paying a serious premium. JOSH: Second headline. Keychron has an open-source gaming mouse firmware project on GitHub, built on Zephyr RTOS. Why should anyone outside keyboard nerd land care? ERIK: Firmware is trust. If your input device is closed, programmable, wireless, and sitting on every engineer's desk, you should care what code is running in it. JOSH: Third headline. Kimi Code is pushing Kimi K3 and k3-256k, with the 256k version pitched as the everyday coding model. Is long context becoming normal? ERIK: Yeah. The interesting part isn't bragging about a giant context window. It's routing work to the right model before you burn money for no reason. JOSH: [pause] JOSH: The data center story feels like the most grounded AI headline of the week. ERIK: It is. Everybody wanted AI to be a pure software story. Clean margins. Cloud APIs. Little demo videos. Then the bill showed up, and the bill had copper, conduit, cooling, substations, permits, fiber, generators, concrete, steel, and a bunch of people in hard hats making the magic box turn on. JOSH: That's a much less glamorous version. ERIK: Correct. Also more honest. A model is software. A cluster is a factory. The factory needs power coming in, heat going out, network between racks, and people who can install everything without turning expensive hardware into a space heater with lawyers attached. JOSH: Wait, really? ERIK: Duuude, yes. GPUs are heat with math attached. That isn't an insult. That's the whole engineering problem. You don't win by saying “we have more GPUs.” You win by keeping them fed, cooled, patched, scheduled, monitored, and useful. JOSH: Indeed had some numbers on this, right? ERIK: Yeah. Their Hiring Lab said data center job postings more than doubled over two years. They also said data center-related postings are now six in every thousand U.S. job postings, up from two per thousand in May 2023. That's not a vibe. That's labor demand showing up in the job market. JOSH: And not just software jobs. ERIK: Exactly. About a quarter of those openings are installation and maintenance. Indeed also found hourly installation workers at data centers can see a 42 percent pay bump compared with non-data-center work. Ten bucks more an hour is not a philosophical debate. That's a market signal. JOSH: What does that mean for builders listening to this? ERIK: It means stop treating infrastructure like a cloud-shaped mystery. If you're building AI products, you need to understand the layer under your prompt. Power. Network. Storage. Queueing. Change control. Logs. Alert routing. If one dependency falls over, your agent doesn't care how clever your prompt was. JOSH: That's the network automation guy talking. ERIK: Absolutely. Cisco NSO taught me this years ago. The device doesn't care about your intent. It cares about state. Terraform doesn't care about your meeting notes. Kubernetes doesn't care that the demo is tomorrow. NATS doesn't care that your investor likes the dashboard. Systems run on facts. JOSH: How does that show up in your own setup? ERIK: PrimeBus is built around that idea. Events first. Systems publish what happened. Agents subscribe. If something throws an error, the event doesn't vanish into a log file nobody reads. It becomes work. That work gets reviewed, tested, and only then does it touch anything important. JOSH: So the AI part is downstream of good plumbing. ERIK: Yes. And I mean plumbing in every sense. Message bus plumbing. Network plumbing. Physical plumbing. Cooling loops. Cable trays. Runbooks. The boring parts are where uptime lives. JOSH: That makes the job market story less surprising. ERIK: It should. AI isn't removing physical work. It's creating a premium on physical work that connects to compute. Electricians, HVAC techs, fiber crews, controls people, data center operators. Those people are closer to the AI economy than half the people writing threads about it. JOSH: That's a little harsh. ERIK: Fair. But accurate. If your whole AI plan depends on someone else building a data center, someone else getting power, someone else keeping the network alive, and someone else absorbing the outage, you don't have a plan. You have a dependency chain wearing a hoodie. JOSH: [beat] JOSH: Where should a small builder start with that? ERIK: Map dependencies. Literally write them down. API provider. Model provider. database. queue. storage. auth. DNS. email. billing. Then ask what happens when each one fails. If the answer is “I wake up and panic,” that's your backlog. JOSH: That's not flashy. ERIK: Good. Flashy is usually expensive. ScanBrief works because the pieces are boring on purpose. Fetch feeds. score items. dedupe. summarize. publish. If one source gets weird, it shouldn't poison the whole brief. If one model call fails, the pipeline shouldn't curl up on the floor. JOSH: [pause] JOSH: Second deep dive. Keychron and open firmware. Why is a mouse firmware repo worth podcast time? ERIK: Because endpoint trust starts lower than people think. Everyone worries about browsers, extensions, SaaS apps, and OAuth grants. That's valid. But the keyboard and mouse are input devices with firmware, wireless stacks, update paths, macros, memory, and sometimes cloud software hanging around the edges. JOSH: That's mildly uncomfortable. ERIK: It should be. The Keychron GitHub repo for ZGM says open source gaming mouse firmware built on Zephyr RTOS. Low latency, customization, extensible driver model. That's interesting because Zephyr is a real embedded operating system. This isn't a toy config file. JOSH: Why does open source help here? ERIK: It lets people inspect behavior. Build from source. Review update mechanisms. Check what the device can do. Closed firmware means you get marketing copy and vibes. Open firmware means somebody can actually read the code and find the weird stuff. JOSH: Is this mainly a security story? ERIK: Security and ownership. If a device sits between your hands and your systems, it matters. Engineers type secrets. Operators paste commands. Admins unlock consoles. A programmable input device is part of the control plane, whether people admit it or not. JOSH: That's a strong take. ERIK: It is because I've seen how boring devices become incident paths. Network gear, badge readers, KVMs, serial consoles, random USB adapters. The stuff nobody wants to inventory becomes the stuff nobody patches. JOSH: How would you handle that in a real environment? ERIK: First, inventory it. Not “we probably use these models.” Actual inventory. Vendor, firmware version, connection type, update path. Second, separate trusted admin workstations from general machines. Third, don't let random peripheral software run with broad permissions because someone wanted RGB. JOSH: The RGB got called out. ERIK: It knows what it did. JOSH: How does this compare to network automation? ERIK: Same pattern. Cisco NSO gives you model-driven control over network state. You don't want mystery state. You want declared state, drift detection, audit trails, and rollback. Firmware should be treated the same way. Known version. known source. controlled update. monitored behavior. JOSH: Does open firmware solve all that? ERIK: No. Open doesn't mean safe. It means inspectable. There's a difference. Bad code can be open. Abandoned code can be open. But with closed firmware, you're stuck trusting the vendor completely. With open firmware, you at least have the option to verify. JOSH: That's the key distinction. ERIK: Exactly. Trust is not a feeling. It's a process. Source code, reproducible builds, signed releases, permissions, monitoring, and a way to roll back when someone ships a bad update at 4:57 on a Friday. JOSH: Very specific. ERIK: That's because Friday releases are how you find out who respects production. JOSH: [beat] JOSH: Where does AI fit into firmware work? ERIK: AI is good at reading boring code at speed. Give Claude a firmware repo and ask it to map input handling, USB descriptors, wireless behavior, update logic, and persistence. Then ask it where a malicious change would hide. That's useful. JOSH: Would you let an agent patch firmware? ERIK: In a lab, yes. In production, not without hard gates. Same rule I use with PrimeBus. Agents can propose. Tests can run. Humans or policy gates decide what crosses into places where mistakes are expensive. JOSH: That's the guardrail theme again. ERIK: Always. Automation without guardrails is just faster chaos. The point is not to let AI touch everything. The point is to make the right work happen automatically, with enough checks that you don't spend your morning explaining why the mouse fleet is now a malware distribution system. JOSH: [pause] JOSH: Third deep dive. Kimi K3 and k3-256k. What's actually new here? ERIK: Kimi's own docs list K3 as the flagship model with up to a one million token context window. The k3-256k variant is positioned for everyday Q&A, code completion, routine feature work, and small-file edits. They also say K3 consumes about twice the quota of k3-256k. JOSH: So the cheaper long-context version is the story? ERIK: The story is routing. People keep arguing about one best model. That's the wrong frame. You need a model router. Small job, cheap model. Sensitive job, local model if it can handle it. Hard reasoning, stronger model. Codebase surgery, use the tool that actually performs in your repo. JOSH: How would that work in practice? ERIK: Every task gets metadata. Task type. risk level. privacy level. max cost. expected output format. Then the router picks a model. The output goes through validators. JSON schema if it's structured. tests if it's code. policy checks if it can touch production. If it fails, retry or escalate. JOSH: That's more like normal engineering. ERIK: Because it is. Model selection is architecture now. It's not taste. It's not fandom. Claude might be best for a certain coding workflow. Kimi might be fine for long context reading. A local model might be right for classification. The system should choose based on evidence. JOSH: What's the trap with long context? ERIK: People think more context means more understanding. It doesn't. It means more text is available. The model still has to attend to the right parts, preserve intent, follow constraints, and not invent a bridge between unrelated files. JOSH: So big context can still fail quietly. ERIK: Very quietly. That's the dangerous part. It sounds confident because it saw the files. But “saw” doesn't mean “understood.” I want retrieval, summaries, tests, and checkpoints. For long sessions, I want compacted state that says what changed, what matters, and what is still unknown. JOSH: That sounds like your pro tip already. ERIK: We'll get there. But yes, this is daily builder stuff. In the PAS website-pipeline, I don't want an agent reading the whole world every time it edits a contact form. I want the relevant files, the current task, the style rules, and a test. Anything else is theater with tokens. JOSH: What about ScanBrief? ERIK: ScanBrief is a natural model-routing problem. News items come in from feeds. Some need dedupe. Some need summarizing. Some need scoring. Some need a stronger judgment call because the headline is noisy or the source is thin. Same pipeline, different model needs. JOSH: So cheaper models don't replace frontier models. ERIK: They reduce waste. Big difference. A cheap model that handles the boring 70 percent makes the expensive model more valuable because you're using it where it matters. That's how builders survive API bills. JOSH: What should people test before switching models? ERIK: Run your real workload. Not a cute prompt. Your actual queue. Measure latency. cost. malformed output. tool call mistakes. missed instructions. bad edits. Then compare it against your current model. If the cheaper model saves money but breaks downstream systems, it isn't cheaper. JOSH: That's the spreadsheet again. ERIK: The spreadsheet comes for everybody. JOSH: [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 JOSH: [pause] JOSH: Alright, what's the AI pro tip today? ERIK: Make your agent ask one forced follow-up question before it acts on unclear work. Not ten questions. One. The best one. JOSH: What does that look like? ERIK: Add this to your agent prompt: “If the task has more than one reasonable interpretation, ask the single question that most reduces the chance of a bad edit. If the task is clear, proceed.” That's it. JOSH: Why only one? ERIK: Because agents can hide behind questions. You don't want a nervous assistant. You want a builder with judgment. One question catches the dangerous ambiguity without turning every task into a committee meeting. JOSH: Give me an example. ERIK: If I say, “fix auth,” the agent should ask whether I mean login failures, token refresh, permissions, or the UI flow. If I say, “change the button text from Save to Publish,” it should just do it. That difference matters. JOSH: Where do you put that rule? ERIK: In the system prompt or the repo instruction file. Then log every question. If the same question appears twice, improve the docs or the task template. Don't just answer it forever. Turn confusion into better instructions. JOSH: That's useful today. ERIK: That's your tip. Use it. JOSH: Track your freedom score and net worth with the Freedom Blueprint app — free download, link in the show notes. JOSH: [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. JOSH: [pause] ERIK: Build or be replaced. JOSH: If you want these signals in your inbox every morning, scanbrief.dev. See you tomorrow.