Build or Replaced
Today: .name Termination | The largest electric aircraft just flew [video] | Any Human Ever – One life, drawn at random from all who have ever lived Episode date: 2026-09-04.
Download MP3 →JOSH: It's Friday, September 4. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: Today is about control. Domains, model speed, GPS drift. Same lesson every time: if your system trusts reality without checking it, reality will eventually embarrass you. JOSH: Stick around — Erik's got an AI pro tip at the end about making agents prove their work before they touch production. JOSH: [pause] JOSH: First up, the dot-name mess. ICANN approved Verisign's proposal to retire third-level dot-name domains. Why should builders care? ERIK: Because people built on a namespace they thought was permanent. Personal sites, old email routes, login callbacks, little services nobody remembers until they break. JOSH: Next, Cerebras is serving Qwen 3.8 27B at around 1500 tokens per second. Is that just benchmark theater? ERIK: No. That's agent fuel. Fast inference changes what you can afford to verify, retry, and inspect. JOSH: And GPS glitched across the U.S. by as much as 33 feet. That sounds small until it isn't. ERIK: Thirty-three feet is nothing if you're walking to lunch. It's a lot if automation thinks that coordinate is truth. JOSH: [pause] JOSH: Let's start with dot-name. This sounds niche, but people got loud about it. What happened? ERIK: Verisign asked to retire the third-level namespace under dot-name. Domains like first.last.name. ICANN approved it. Now a whole category of names people used for identity can go away. JOSH: Wait, really? A registry can just end that? ERIK: Registry contracts make the internet feel boring until they don't. Everybody thinks DNS is bedrock. It's not. It's a contract stack, policy stack, billing stack, and somebody else's operational decision. JOSH: That's uncomfortable. ERIK: It should be. People tied email addresses, personal pages, old resumes, sign-in flows, and weird side projects to those names. Some of that stuff is probably abandoned. Some of it is probably still quietly doing work. JOSH: So this is bigger than one domain extension. ERIK: Exactly. The domain is just the visible part. Same thing happens with cloud accounts, package registries, Git providers, API vendors, payment processors, model endpoints. Builders treat those as neutral ground. They're not neutral. They're vendors with knobs. JOSH: What's the practical move? Nobody's running their own internet. ERIK: You don't have to run the internet. You have to know where your kill switches are. Own the top-level domain you care about. Keep DNS simple. Export zone files. Use separate registrar accounts for real business domains. Don't put the only recovery email on the same domain you're trying to recover. JOSH: That last one feels like it came from pain. ERIK: That's not pain. That's Tuesday. JOSH: [beat] ERIK: Also, stop making cute nested names the center of your architecture. If your customer identity is tied to bob.project.region.example.whatever, you're going to hate your life when one layer moves. JOSH: What's better? ERIK: Treat the domain like a pointer. The identity should live in your database, your signing keys, your customer record, your content store. The domain gets people there today. If it changes, the system is wounded, not dead. JOSH: How does that show up in your own systems? ERIK: ScanBrief is built around that assumption. Feeds disappear. HTML changes. Sites rate-limit. Some source decides today is the day they want to return garbage. Fine. The pipeline scores, dedupes, checks freshness, and keeps moving. JOSH: So you're not trusting one source. ERIK: Never. One source is an opinion. Multiple sources plus scoring is a signal. ScanBrief is a daily brief, not a shrine to one RSS feed. JOSH: And PrimeBus? ERIK: PrimeBus is the same pattern inside my own infrastructure. Every project can emit events, but the bus doesn't blindly trust them. Payloads get validated. Bad events get parked. Agents subscribe to what they understand. JOSH: That sounds boring. ERIK: That's why it works. JOSH: [beat] ERIK: Everybody wants the cool agent demo where Claude fixes code while you drink coffee. Nobody wants to talk about schemas, retries, dead-letter queues, and audit trails. But that boring stuff is what keeps an agent from turning one bad event into a production incident. JOSH: So dot-name is really a story about hidden ownership. ERIK: Yep. Ask one question: who can revoke the thing my system depends on? If the answer is somebody else, build a fallback. Doesn't mean don't use the tool. It means don't pretend the tool is gravity. JOSH: [pause] JOSH: Next story. Cerebras serving Qwen 3.8 27B at around 1500 tokens per second. Why does that matter outside AI Twitter? ERIK: Because latency is architecture. People obsess over which model is smartest. Fine, that matters. But in real systems, speed changes the design. JOSH: How? ERIK: Agents are loops. Read state, make a plan, call a tool, inspect output, write a patch, run tests, review the diff, decide what to do next. If each model call takes twenty seconds, you build timid workflows. If calls come back fast, you can afford more checks. JOSH: Speed buys caution? ERIK: Exactly. That's the part people miss. Fast models don't just make chat feel snappy. They let you add verification without making the system unusable. JOSH: Give me an example. ERIK: In PrimeBus, I don't want one Claude session deciding everything. I want one agent to propose a fix, another to review the diff, another to look at test output, and a guardrail layer to say no if the evidence isn't good enough. JOSH: That's more expensive though. ERIK: With slow inference, yes. With fast inference, it becomes normal plumbing. You don't ask whether logging is worth it on a server. You just do it because flying blind is stupid. JOSH: That's a very Erik answer. ERIK: Good. Put it on a mug. JOSH: [beat] JOSH: Does a smaller fast model beat a larger slower model? ERIK: Sometimes, absolutely. If the job is narrow and the feedback loop is strong, a fast model can win. Code review summaries, JSON repair, routing decisions, test triage, extraction, ranking. You don't need a giant model for every turn. JOSH: But for hard reasoning? ERIK: Use the heavy model where it earns its keep. Architecture decisions, nasty bugs, ambiguous requirements, security reviews. But don't send every tiny classification job to the most expensive brain in the room. That's how people build slow, expensive systems and then blame AI. JOSH: How do you decide? ERIK: I route by risk. Low-risk, structured tasks go to cheaper or faster models. Medium-risk tasks get a stronger model plus validation. High-risk tasks get multiple passes, tests, and human approval if needed. JOSH: That's basically a network design mindset. ERIK: It is. Same as routing traffic. Not every packet needs the same path. Not every event needs the same model. If you understand queues, backpressure, retries, and blast radius, agent design makes way more sense. JOSH: Where do tools like NATS fit here? ERIK: NATS is great because it makes events boring. PrimeBus uses that event-bus style. A failure isn't a dramatic thing. It's a message. A review request is a message. A deploy check is a message. Agents come and go, but the bus gives the system memory and movement. JOSH: What does that mean for someone building today? ERIK: Stop building one giant prompt that does everything. Break the work into small jobs. Use fast models for the boring checks. Use strong models for judgment. Store the outputs. Compare them. Make the system prove why it should continue. JOSH: That's the theme again. ERIK: Yep. Trust is earned at every step. If your agent says tests passed, I want the command output. If it says the diff is safe, I want the files changed and the reason. If it says deploy, I want the gate that allowed it. JOSH: And if it can't prove it? ERIK: Then it doesn't ship. Pretty simple. JOSH: [pause] JOSH: Third story. GPS drifted across parts of the U.S. by as much as 33 feet. Why does that hit your radar? ERIK: Because automation loves coordinates. Humans see a map and use judgment. Machines see numbers and act. JOSH: Thirty-three feet still sounds small. ERIK: Depends on the system. For turn-by-turn driving, maybe it's annoying. For drones, asset maps, telecom field work, fleet routing, geofencing, timing systems, or anything using location as a trigger, thirty-three feet can matter a lot. JOSH: What's the networking angle? ERIK: Timing. GPS isn't just maps. Networks use precise timing. Finance uses timing. Cellular systems use timing. Power systems use timing. When people hear GPS, they think blue dot. Engineers hear clock. JOSH: That's wild. ERIK: Yeah. GPS is one of those invisible dependencies. Same as DNS. Same as NTP. Same as certificates. Nobody cares until the thing that always works suddenly doesn't. JOSH: What should builders do with that? ERIK: Don't let one sensor be the source of truth. If location matters, cross-check it. GPS plus Wi-Fi. GPS plus known site inventory. GPS plus last-good coordinate. GPS plus human confirmation for risky actions. JOSH: That sounds like more friction. ERIK: Good friction. Bad friction is making a user click twelve screens because the app is badly designed. Good friction is stopping automation from doing something dumb because the input smells wrong. JOSH: How would that look in one of your projects? ERIK: HumanDesignApp has an iMessage state machine. Totally different domain, but same principle. The app doesn't just assume one message means the user intent is clean. It tracks state. It knows where the conversation is. It asks for the missing piece when the next action would be risky or wrong. JOSH: So even chat flows need guardrails. ERIK: Especially chat flows. People type weird stuff. Models infer weird stuff. State machines keep everybody honest. JOSH: And the website pipeline? ERIK: PAS website-pipeline is another one. If an agent changes a site, I don't want vibes. I want a diff, screenshot checks, build output, and a rollback path. A pretty homepage doesn't matter if the form is broken and nobody can pay you. JOSH: That's the agency brain talking. ERIK: That's the money brain talking. Same thing. JOSH: [beat] JOSH: It feels like all three stories point to the same rule. ERIK: They do. Verify the layer beneath you. DNS can move. Models can hallucinate. GPS can drift. APIs can change. Feeds can rot. If your system assumes the world is stable, you didn't build a system. You built a wish. JOSH: That's harsh. ERIK: It's cheaper than learning it in production. JOSH: What's the minimum version for a solo builder? ERIK: Three things. First, write down the dependencies that can kill you. Domain, auth, database, model provider, payment processor, email. Second, add one check for each. Expiration monitor, health check, backup export, test transaction, synthetic login. Third, make alerts actionable. If an alert doesn't tell you what to do, it's just a tiny anxiety machine. JOSH: That's painfully accurate. ERIK: Alert fatigue is self-inflicted a lot of the time. Have you implemented runbooks today? If no, start there. If yes, make the runbook executable. Put events on a bus. Let agents subscribe. Let humans approve the risky stuff. JOSH: That's the dark factory idea. ERIK: Yep. Quiet systems doing useful work while you're asleep. Not magic. Just runbooks, events, tests, and enough paranoia to survive vendors being vendors. 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 produce evidence before it takes action. Not a summary. Evidence. JOSH: What counts as evidence? ERIK: For code, it means changed files, test command, test output, and why the diff fixes the issue. For infrastructure, it means the target devices, intended config, pre-checks, post-checks, and rollback. For content, it means source links, extraction notes, and the exact claim being made. JOSH: And where do you put that? ERIK: Put it in the workflow. Don't ask politely in the prompt and hope the model behaves. Make evidence a required field. If the field is empty, the next step doesn't run. JOSH: So the agent can't charm its way past the gate. ERIK: Exactly. Models are very good at sounding done. Your job is to make done mean something. JSON schema helps. Tool outputs help. Tests help. A second reviewer helps. But the key is simple: no proof, no action. JOSH: What's one version people can use today? ERIK: Add a final checklist to any agent that writes or changes anything. Required fields: what changed, why it changed, how it was verified, what could break, and how to undo it. Then make your script reject the run if any field is blank. JOSH: That's pretty direct. ERIK: Direct works. That's your tip. Use it. JOSH: Binge all five episodes this weekend plus our YouTube shorts — links at buildorbereplaced.dev. 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.