Build or Replaced
Today: Fujitsu launches made-in-Japan next-generation CPU FUJITSU-MONAKA | Why I didn’t sign the Fields medallists’ letter | Wax motor Episode date: 2026-09-18.
Download MP3 →1518 words — within the 1,500–2,200 range and comfortably clear of the floor. The script is finalized. ERIK: Trust is the whole game right now. Who do you let write code, who do you let read code, who do you let touch prod. JOSH: That's a heavy way to start a Friday. ERIK: It's a heavy week. Every story on today's list is really the same story wearing a different hat. [pause] JOSH: It's Friday, September 18th. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: And today's the day we talk about what happens when you give something access it hasn't earned yet. JOSH: Stick around — Erik's got an AI pro tip at the end about deciding when a model earns write access. [pause] JOSH: Let's get into it. Fujitsu just launched a new CPU, made entirely in Japan. Domestic chip, no outsourcing. Why's that a story right now? ERIK: Supply chain paranoia. Every country wants a chip they don't have to ask permission for. Fujitsu's betting there's a market for "built here, no exceptions." JOSH: Next one's straight out of today's theme — a coding agent startup just confirmed one of their autonomous merge agents pushed a broken PR into a customer's production branch. No human reviewed it. ERIK: Same failure every time. You give a model write access, you skip the review step because it's slower, and eventually "slower" turns out to be the thing that would've saved you. [beat] JOSH: Last headline — "the scourge of x86 emulation." Sounds like a complaint post. ERIK: It is one, and it's fair. Every ARM transition — Apple, now the Windows laptops — you're running x86 code through a translator and eating a performance tax nobody advertises on the box. [pause] JOSH: Okay, let's slow down on a few of these. First one — there's a story about a heap overflow and an SSO misconfiguration that got someone into OpenAI's internal repos. Walk me through that. ERIK: Two separate mistakes stacked on top of each other, which is how every real breach happens. Heap overflow gets you code execution somewhere you shouldn't have it. SSO misconfiguration means once you're in, the identity layer doesn't actually stop you from moving sideways. JOSH: And that combination got them into actual source code? ERIK: Internal repos, yeah. That's the part that should worry people more than it does. Everyone's scared of the model leaking a secret in a chat response. Nobody's watching the boring stuff — a login provider set up wrong, a memory bug in some internal tool nobody's audited since it shipped. [beat] JOSH: What actually changes at a place like OpenAI after something like that? Or does it just turn into a blog post and everyone moves on? ERIK: The pattern's always the same three moves. Rotate every credential that touched the affected system, not just the ones you can prove got used. Add a second identity check on anything that reaches source control, so SSO alone stops being enough. And run a retroactive audit on every internal tool that's been sitting untouched for a year or more, because that's exactly where a bug like this hides for years before anyone finds it. None of that's exciting. It's also the only part that actually works. JOSH: Does that change how you think about your own setup? You've got Gandalf reviewing everything before it merges. ERIK: It's exactly why Gandalf exists. Every PR gets reviewed before it touches prod, and I don't let one agent both write the code and approve the code. PrimeBus has run 2,295 auto-merge attempts since June — 1,507 went through, 788 got blocked. Zero of those got escalated to me because they needed a human, they got blocked because the guardrail did its job. JOSH: Wait, 788 blocked and that's a good number? ERIK: That's the whole point. People see a block count and think failure rate. It's not. It's the review catching something before it became the OpenAI story. I'd rather see 788 blocks than one heap overflow in something I shipped at 2 AM. [pause] JOSH: Next one — Bonsai 2, this 27B model that got compressed down to under 6 gigs. What's actually happening there? ERIK: Ternary weights. Instead of storing each weight as a 16-bit float, you store it as basically three states — negative, zero, positive — with a scaling factor layered on top. You take a 27 billion parameter model built on Qwen3.8 and it fits in 5.9 gigs at under 2 bits per weight. JOSH: And it still performs? ERIK: 98.2 percent of the original benchmark score. That's the number that matters. Compression that costs you accuracy isn't compression, it's just a worse model with better marketing. [beat] JOSH: Does something like that change what you can run locally versus what has to go to the cloud? ERIK: Completely. That's the whole calculation behind PrimeRouter — it's the gateway that decides where every call goes. Right now cloud lanes are dark by default, gated behind explicit approval, capped, logged. A model like Bonsai shrinking that much means more of that decision tree can stay local without giving anything up. You don't spend cloud money to summarize a log file when a 6-gig model on the box next to you gets 98 percent of the way there for free. JOSH: So it's not just "smaller model," it's "smaller model that changes your routing logic." ERIK: Exactly the shift. Every time compression gets meaningfully better, the line between "has to be cloud" and "can stay local" moves. You want your infrastructure able to take advantage of that the day it drops, not six months later after you finally get around to testing it. [pause] JOSH: Last deep dive — there's a language called Bend that claims to block AI mistakes through proof, not just testing. What does that even mean? ERIK: The type system doubles as a proof checker. You define laws — rules the code has to respect — and the compiler won't let generated code violate them. It's not "run the tests and hope," it's "the code literally cannot compile if it breaks the rule you defined." JOSH: That sounds like it's built for exactly the problem we just talked about — an agent writing code nobody double-checked. ERIK: That's the whole reason it caught my eye. Right now my safety net is process — Gandalf reviews it, tests run, a human's in the loop if something's ambiguous. Bend's argument is you push some of that verification into the language itself, so the mistake is unrepresentable instead of just unlikely. JOSH: Give me a real example. Where would you actually use that instead of just trusting your review pipeline? ERIK: Take PrimeTrader. It watches 109 tickers and fires alerts off price movement. If I had a law that said never submit an order size larger than the account's defined cap, I don't want that enforced by a test somebody remembered to write — I want the compiler to refuse to build the thing at all if that rule's violated. Same idea for email-reactor handling client change requests. Define the law once, never send outside the approved domain list, and it's not a runtime check that can get skipped under load. It's baked into whether the code exists in the first place. JOSH: Would you actually use something like that? ERIK: Not replacing what I've got — on top of it. ScanBrief pulled 91 items across 56 sources this morning, average relevance score sitting around 52.6, and email-reactor is out there handling client change requests without me touching it. Every one of those is an agent making a decision without me watching in real time. Anything that makes "the wrong decision literally can't compile" instead of "the wrong decision gets caught downstream" — that's worth a real look. [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: If you're letting an agent open pull requests, give it a second identity for the review step. Don't let the same session that wrote the diff also approve it. In Claude Code that's as simple as spinning up a fresh session with no memory of the conversation, and handing it only the diff — not the reasoning that produced it. A session that doesn't remember writing something can't rubber-stamp it out of loyalty. That's the same principle behind Gandalf on my end — separate the write path from the approve path, every single time, no exceptions, no "it's a small change so skip it." That's your tip. Use it. [pause] 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.