Build or Replaced
Today: Using AI to write better code more slowly | Taking a walk may lead to more creativity than sitting, study finds (2014) | Ferrari Luce Episode date: 2026-05-26.
Download MP3 →JOSH: It's Tuesday, May 26. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: Slow AI coding is winning, open source just dodged a legal mess, and Norway is training a language model on two petabytes like it's a normal Tuesday. JOSH: Stick around — Erik's got an AI pro tip at the end about making agents slow down before they touch production. [pause] JOSH: First headline. There's a piece making the rounds called "Using AI to write better code more slowly." That sounds backwards, right? ERIK: Backwards if you're using AI like autocomplete on caffeine. Correct if you're using it like an engineering team. The best AI code isn't fast code. It's code that got reviewed, tested, argued with, and forced through guardrails. [beat] JOSH: Next one. California is moving to exempt Linux from an age-verification law after open-source backlash. ERIK: Good. Operating systems are not nightclub bouncers. If lawmakers make every open-source maintainer responsible for user identity checks, they don't get safer software. They get fewer maintainers. [beat] JOSH: Third headline. Motorola phones reportedly started hijacking the Amazon app to insert affiliate codes. ERIK: That's the kind of thing that makes users feel like the device works for somebody else. If true, it's not a cute monetization trick. It's supply-chain trust taking a hit in your pocket. [pause] JOSH: Let's start with the slow AI coding story. Isn't the whole promise that AI makes developers faster? ERIK: Faster at typing, yes. Faster at shipping good systems, only if you build the process around it. That's the part people keep missing. [beat] ERIK: Everybody wants the demo where Claude writes the whole feature in thirty seconds. Looks great on a screen recording. Then you run it against a real repo with weird tests, stale docs, migrations, feature flags, and some function named finalFinalHandler because somebody had a bad week in 2021. JOSH: That's painfully specific. ERIK: It's real life. AI is very good at generating plausible code. Plausible is not the bar. Production is the bar. [beat] ERIK: The slow approach means you don't ask the model to sprint straight to a pull request. You ask it to inspect the repo. Explain the current pattern. Identify risks. Propose the smallest patch. Write tests. Run tests. Then you have another model or another agent review it like it owes you money. JOSH: So the speed comes from the system, not the first answer. ERIK: Exactly. PrimeBus processed 3142 automation events across 11 projects today. That's not one big magic prompt. That's little events, little checks, little decisions. The boring stuff is where the speed lives. [beat] JOSH: How does that look in your actual workflow? ERIK: PrimeBus watches telemetry. A test fails, a warning fires, a service emits a bad state, whatever. That event lands on NATS. An agent picks it up, opens the repo, builds context, proposes a fix, and Gandalf reviews it before it gets near production. JOSH: Gandalf is the gatekeeper? ERIK: Yep. Name fits. You shall not pass, but with logs. [beat] ERIK: Overnight, 11 code changes were automatically reviewed by Gandalf and merged to production. That's the part people like. But the more important stat is the auto-merger history. Since April 17, it has run 3748 attempts: 912 merged, 2824 blocked by Gandalf, 12 escalated to me. That's a 24.3% merge rate, and the rest were caught by guardrails, not failures. JOSH: Wait, really? The blocked ones are the win? ERIK: Duuude, yes. That's the whole game. A dumb auto-merge system brags about how much it merged. A serious one brags about what it refused to merge. [pause] JOSH: That feels different from how people talk about AI coding tools. ERIK: Because most people are measuring keystrokes. Wrong metric. Measure avoided incidents. Measure test coverage added. Measure bad patches blocked. Measure how often you wake up to a clean system instead of a smoking Slack channel. [beat] ERIK: Slow AI coding is like network automation with change windows. I spent years with Cisco NSO and real network state. You don't blast config because the template rendered. You dry run. You diff. You validate. You check service intent. Same thing with AI code. JOSH: So AI agents need change control. ERIK: They need change control, telemetry, and consequences. If the agent breaks a test, it should see that. If it fixes the wrong thing, it should get blocked. If it keeps proposing junk, route it to a different model or escalate to a human. [beat] JOSH: Does that make AI less useful for smaller teams? ERIK: No, it makes it more useful. Small teams need guardrails more, not less. One person with Claude and a decent review loop can do real work. One person with Claude and no process can create a landfill with TypeScript in it. [pause] JOSH: Let's move to California and Linux. Why did that story hit so hard? ERIK: Because it shows what happens when policy treats software like a vending machine. Put a rule in, get safety out. That's not how open source works. [beat] ERIK: The Digital Age Assurance Act created concern that open-source operating systems could get dragged into age-verification obligations. Linux isn't a single company shipping one locked product. It's kernels, distros, maintainers, package mirrors, desktop environments, volunteers, companies, weird edge devices, and someone's router in a closet. JOSH: So who would even be responsible? ERIK: Exactly. That's the problem. If the answer is "everybody," the real answer is "the people with lawyers survive and everybody else backs away." [beat] JOSH: Why should builders care if they're not working on Linux? ERIK: Because this is bigger than Linux. It's about whether laws understand where responsibility actually sits in a stack. If you run a website with user accounts, fine, you can talk about age checks. If you maintain a package manager, a kernel module, or a bootable ISO, that's different. JOSH: That line matters. ERIK: Huge. Infrastructure layers are not application layers. Network engineers know this. You don't ask BGP to enforce your HR policy. [beat] JOSH: That's a good sentence. ERIK: It's true. BGP has enough problems. [pause] JOSH: How does this connect to your systems? ERIK: ScanBrief scored 49 items across 54 sources today, and this is exactly why I built it. A story like this looks like policy news, but for builders it's a dependency risk story. If your platform depends on open-source maintainers, laws that make maintaining painful become your problem. [beat] ERIK: Same with the Echo and Neo lab. I run my systems close to the metal. Services, agents, message bus, deployment checks, all of it. If regulations start treating base infrastructure like consumer apps, small builders get squeezed first. JOSH: Not Big Tech? ERIK: Big Tech hires a compliance department. The maintainer of a small distro gets a migraine and stops publishing releases. That's the damage. [beat] JOSH: So California backing off is a good sign? ERIK: It's a good correction. Credit where it's due. They heard the backlash and moved to clarify. But builders should pay attention. The next version of this debate will show up somewhere else with different words. JOSH: What should teams do now? ERIK: Map your dependencies. Know what open-source projects you're actually relying on. Not the top ten packages in your package file. The real chain. Build systems, container images, base OS, CI actions, Terraform providers, NPM packages, Python wheels. That boring inventory becomes very interesting when policy or licensing shifts. [pause] JOSH: Third deep dive. Norway's National Library is training a Norwegian-language model using two petabytes of Huawei flash storage. What's your read? ERIK: Sovereign AI is becoming real infrastructure. Not a press release. Actual storage, actual data, actual models for a language and culture that the big general models may not serve well. [beat] JOSH: Why does the language-specific part matter? ERIK: Because language is not just words. It's law, idiom, history, names, local references, documents, archives. A model trained mostly on English internet sludge will answer in Norwegian, but that doesn't mean it understands Norway well. JOSH: Translation isn't the same thing. ERIK: Right. Translation is surface area. Domain knowledge is underneath. If a national library has digitized cultural material, legal texts, newspapers, books, and historical records, that's a serious corpus. You can build something useful for citizens, researchers, schools, and government. [beat] JOSH: The Huawei storage part jumped out too. ERIK: It should. Two petabytes of flash storage is not a hobby build. That's capital, power, cooling, procurement, support contracts, and politics. The vendor choice matters because AI infrastructure is now strategic infrastructure. JOSH: Like cloud regions used to be? ERIK: Similar, but more sensitive. Cloud regions hold workloads. AI systems absorb data and produce decisions, summaries, recommendations, search results, maybe policy drafts. Whoever owns the stack has influence. [pause] JOSH: Does every country need its own model? ERIK: Not every country needs to train a giant frontier model from scratch. That's expensive and probably dumb for most. But countries do need control over important language data, evaluation sets, and deployment rules. They need models that know local context and can run where the data is allowed to live. [beat] JOSH: How would a company apply that idea at smaller size? ERIK: Build a company-specific model layer. Doesn't mean train a huge model. Start with retrieval. Put your runbooks, tickets, configs, postmortems, code docs, contracts, and architecture notes somewhere the model can search. Then test it against questions your team actually asks. JOSH: So enterprise sovereign AI, but smaller. ERIK: Exactly. Your company has a language too. Acronyms, service names, weird tribal knowledge, "don't touch router seven on Fridays" type stuff. General models don't know that unless you give it to them. [beat] ERIK: HumanDesignApp has its own state machine and conversation patterns. PrimeDistro has lead data, preview-site generation, postcard status, all that. I don't need a generic chatbot pretending it knows those systems. I need agents that can pull the right local context, take the right action, and leave an audit trail. JOSH: That's more boring than the AI hype. ERIK: Good. Boring survives contact with production. [pause] JOSH: What about the security side of training on national archives or company docs? ERIK: That's where people need to stop being casual. Data access before model access. If the model can retrieve it, someone has to be allowed to see it. Permissions need to follow the document, not the enthusiasm of the demo. [beat] JOSH: That sounds like a place where teams mess up. ERIK: All the time. They dump a folder into a vector database and call it AI search. Then the intern asks a question and gets salary data, credentials, or customer notes. Congrats, you built a breach with embeddings. JOSH: Dry, but fair. ERIK: The fix isn't complicated. Classify sources. Keep tenants separate. Log retrievals. Redact secrets before indexing. Use service accounts with scoped access. Make the model prove where the answer came from. [beat] JOSH: And if they don't? ERIK: Then they'll learn why "the user is visibly frustrated" was also on ScanBrief today. [pause] JOSH: Quick bridge before the sponsor. The Motorola affiliate-code story feels like part of the same trust problem. ERIK: It is. Devices, operating systems, models, browsers, app stores, agents. The question is always the same: who does this thing serve? If the answer is not the user, the user eventually notices. [beat] JOSH: Especially when Amazon links start getting rewritten. ERIK: Yeah. People will tolerate ads. They won't tolerate feeling tricked by their own phone. [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: Make your agent write a failure memo before it writes code. [beat] JOSH: A failure memo? ERIK: Yep. Before Claude touches the file, prompt it like this: "List the three most likely ways this change breaks production. For each one, name the test, log, metric, or manual check that would catch it. Then make the smallest patch that keeps those risks contained." [beat] ERIK: That one prompt changes the behavior. The model stops acting like a code printer and starts acting like an engineer with a pager. It thinks about blast radius. It looks for existing tests. It names what good looks like before it edits. JOSH: That's usable today. ERIK: Put it in your agent template. Put it before every risky change. If the model can't name how the change could fail, it doesn't understand the change yet. That's your tip. Use it. [pause] JOSH: We also drop daily market picks and automation tips on YouTube — search Build or Be Replaced. [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.