The brainstorming skill is for software design — the user has provided a complete, unambiguous spec. I'll write the script directly.

JOSH: It's Wednesday, May 6th. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.

ERIK: Agents are buying domains, spinning up infrastructure, and deploying to production. No human required. We're going to talk about what that actually means.

JOSH: Stick around — Erik's got an AI pro tip at the end about picking the right interface before you pick a model.

[pause]

JOSH: First headline — Coinbase is cutting 14% of its workforce.

ERIK: About 1,100 people. Crypto exchange economics are brutal right now — revenue compression, regulatory pressure, and automation keeps getting more convincing. When you cut that deep, you're betting the remaining headcount plus better tooling holds the output steady.

[beat]

JOSH: Next — DNSSEC on .de domains had a major disruption. Resolved, but it was widespread.

ERIK: DNS is invisible until it breaks. DNSSEC adds a cryptographic trust layer on top — when that fails, legitimate traffic stops. .de is one of the largest country-code TLDs. An incident there isn't a Germany-only problem. It's a reminder that the internet's trust infrastructure is thinner than people think.

[beat]

JOSH: And Gemma 4 just got a 3x inference speed boost through multi-token prediction.

ERIK: Instead of predicting one token at a time, the model drafts several simultaneously, then verifies them. Speculative decoding with MTP drafters. Same output quality, 3x faster. If you're running local inference, this matters — the bottleneck has always been memory bandwidth, not compute. This directly attacks that.

[pause]

JOSH: Okay, let's go deep. The big one today — agents can now autonomously create Cloudflare accounts, register domains, and deploy production applications. Co-designed with Stripe?

ERIK: Yeah. Cloudflare and Stripe worked on a protocol together. An agent — with the right authorization — can spin up a Cloudflare account, set up DNS, buy a domain, generate API tokens, manage subscriptions, and push a live application. Nobody touches it.

JOSH: What is the protocol actually doing?

ERIK: Defining a structured set of actions the agent can take and the permissions model behind them. Stripe handles the billing side — the agent can provision paid services and manage subscriptions programmatically. Cloudflare handles the infrastructure side. Together, that's the two biggest pieces of a production deployment that used to require a human with a credit card and a login.

[beat]

JOSH: So what does that unlock?

ERIK: Full autonomous deployment pipelines. PrimeBus ran 2,124 automation events today across five projects. It detects test failures, generates fix variants, runs tests, merges the winners. But the boundary stops at the code level. The domain, the Cloudflare config, the billing — those still have a human owner. With this protocol, you hand an agent a budget, a spec, and an authorization scope, and it returns with a live URL.

JOSH: That's a fundamentally different kind of automation.

ERIK: It is. Most automation is process automation — speeding up steps a human was already taking. This is infrastructure autonomy. The agent isn't executing your runbook faster. It's making provisioning decisions. That's a different trust level.

[beat]

JOSH: Is that dangerous?

ERIK: Depends entirely on the authorization model. The risk isn't the agent — it's the human who grants a scope wider than intended because it's easier than thinking through the permissions carefully. If you give an agent unrestricted Cloudflare API access and it does something unexpected, that's a scope problem. Least privilege applies to agents the same way it applies to service accounts. You wouldn't give a cron job root. Don't give an agent a scope it doesn't need.

JOSH: Where does this go from here?

ERIK: Cloudflare and Stripe didn't build this for fun. Companies are laying rails because there's a destination in mind. Autonomous SaaS products. Agents that spin up, operate, and manage their own infrastructure. The deployment step was the last manual bottleneck in a fully autonomous software system. It just got removed.

[pause]

JOSH: Let's talk cost. There's a benchmark showing computer use — vision-based agents — are 45 times more expensive than structured APIs for the same tasks.

ERIK: Someone ran the comparison on admin panel work. Vision approach — agent sees the screen, figures out what to click, clicks it, checks what changed. Versus hitting a structured API endpoint. Forty-five times the cost. Same result.

JOSH: Why is vision so much more expensive?

ERIK: Tokens. Every screenshot is image tokens. The model processes the full visual frame, reasons about UI state, decides what to do, takes an action, processes the next screenshot. You're paying for visual reasoning on every single step. A structured API call skips all of that — one request, one response, done.

[beat]

JOSH: So when does vision actually make sense?

ERIK: Last resort. When there is genuinely no API, no structured output format, no programmatic access to the data or the action you need. Legacy vendor portals from 2003. Government systems that never got modernized. Anything where the only interface is a browser someone built assuming a human would sit in front of it. That's the correct use case.

JOSH: And people are using it as the default?

ERIK: Some are. Because it's flexible — works on anything with a UI. But flexibility has a price. ScanBrief pulled and scored 49 items across 56 sources this morning. If I ran that through a vision scraper instead of structured ingestion, the cost difference would end the project. I've got 88 services running on the production server right now. I can't absorb 45x overhead on any of them.

[beat]

JOSH: What should builders actually take from this?

ERIK: Audit your interfaces before you build. Is there an API? Use it. Structured output? Use it. Webhook? Use it. If none of those exist, you're in vision territory — but you should know that going in and size the cost accordingly. The interface is a cost and reliability decision, not just a technical one. Most people treat it like a technical detail and then wonder why the bill is wrong.

[pause]

JOSH: Last one — Telus is using AI to alter call center agent accents in real time. While they're on the phone with customers.

ERIK: That's a strange one to drop on a Wednesday.

JOSH: What's actually happening?

ERIK: Real-time voice conversion. The agent speaks normally. The audio runs through a model that shifts the accent toward something considered neutral by the system — which in practice means North American. The customer hears a modified voice. The agent knows their voice is being altered.

JOSH: Is that fixing the problem or hiding it?

ERIK: Routing around it. The bias some callers have toward non-native accents doesn't go away — the caller just doesn't have the information to trigger it. Telus probably gets better satisfaction scores. The agent still knows what's happening to their voice. Both things are true at the same time.

[beat]

JOSH: What's interesting to you technically?

ERIK: Real-time low-latency voice conversion at call center scale is hard. The latency budget for phone audio is tight — you can't process a full sentence and play it back, you're converting on the fly. If Telus is doing this in production at volume, the model quality and pipeline architecture is more sophisticated than the headline suggests. That part is worth paying attention to, separate from the ethics question entirely.

JOSH: It's automation applied to the worker, not replacing the worker.

ERIK: That's the edge case nobody talks about enough. Automation that modifies a human's output while the human is still there. Where that goes as voice models improve — that's a harder question than accent modification.

[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: Pick your interface before you pick your model. Most builders start with the model — which Claude, which Gemini, which local model — then figure out how to wire it up. Backwards. The interface dictates the architecture, the cost, and the reliability ceiling. If there's a structured API, use it. Structured output format, use it. Webhook, use it. If the only option is a UI and you need automation, that's when you decide whether vision is worth 45x. The model selection comes after the interface decision, not before. Get the interface right and the rest of the architecture gets easier. That's your tip. Use it.

[pause]

ERIK: If you're building toward financial independence through automation, my first book walks through the whole path. Free chapter at erikandersonbook.com.

[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.

JOSH: It's Tuesday, May 5. This is Build or Be Replaced powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.

ERIK: Thirty-six items hit ScanBrief this morning, PrimeBus already chewed through 2,155 events, and the pattern is the same every day now: the teams building systems are pulling away from the teams still clicking buttons.

JOSH: Stick around. Erik's got an AI pro tip at the end about getting better output by splitting one prompt into three jobs.

[pause]

JOSH: First headline. Bun is moving from Zig to Rust. Big engineering move or nerd drama?

[beat]

ERIK: Big engineering move. When a runtime that serious rewrites core pieces, that's not style points. That's a bet on safety, hiring, tooling, and surviving the next five years.

[beat]

JOSH: Next one. Chrome silently dropping a four gig AI model onto user devices. Is that as bad as it sounds?

[beat]

ERIK: Worse, because the problem isn't only size. It's consent. If your browser installs a model, re-downloads it after deletion, and doesn't make the contract obvious, you've got a trust problem before you've got an AI feature.

[beat]

JOSH: Third headline. OpenAI talking about low-latency voice at scale. Why should builders care?

[beat]

ERIK: Because voice stops being a toy when latency gets low enough that people stop noticing the machine. Once that happens, support, dispatch, field ops, triage, all of it changes fast.

[pause]

JOSH: Let's stay on that Chrome story, because people heard four gigs and immediately thought, wait, what is my browser doing.

[beat]

ERIK: Yeah. That's the right reaction. A browser is supposed to render pages, manage sessions, run extensions, and stay out of your way. When it starts acting like a silent model deployment platform, the bar changes. You don't get to say, well, it's for helpful features. That's not the point. The point is the install happened without a clean, obvious choice.

[beat]

JOSH: So what's the actual problem? Storage? Privacy? Battery?

[beat]

ERIK: All three. Storage is the easiest one to see. Four gigs is not a rounding error on normal laptops. Battery matters if that thing gets invoked locally. But privacy and trust are the real issue. If a vendor quietly places model weights on a device, users are going to ask what else is happening quietly. And they should.

[beat]

JOSH: Some people will say, hold on, local AI is better than sending everything to the cloud.

[beat]

ERIK: Local can be better. I run local. Hermes is on a Mac M3 in my stack pushing qwen3-coder around 70 tokens a second. I like local inference. I like keeping jobs in my own walls. But local by choice and local by stealth are not the same thing. If I deploy Hermes, I know exactly why it's there, what port it's on, what jobs hit it, and what box pays the power bill. Chrome doing a surprise drop is the opposite of that.

[beat]

JOSH: So this isn't anti-local. It's anti-sneaky.

[beat]

ERIK: Exactly. Put a clear setting in front of me. Tell me the size. Tell me the feature set. Tell me when it downloads, when it runs, and how to remove it for real. Then we're adults. Right now it sounds like product people got excited and skipped the part where the user is supposed to matter.

[beat]

JOSH: What does this mean for people building apps on top of these browsers?

[beat]

ERIK: It means you need to assume users are getting more suspicious, not less. If you're building browser-based AI features, you have to over-communicate. Show your work. Say what runs local. Say what goes remote. Say what gets cached. Say what gets deleted. Because if the platform burns trust, your app inherits the smoke.

[beat]

JOSH: That's a rough inheritance.

[beat]

ERIK: It is. And it's avoidable. In ops, hidden automation is how you get paged at 2 AM. Same rule here. If a system makes changes out of band, people stop trusting the system. PrimeRestorer taught me that. Backups aren't useful because they exist. They're useful because I know when they ran, what they covered, where the copies landed, and whether restore tests passed. Silent behavior is fake reliability.

[beat]

JOSH: That sounds like the bigger lesson.

[beat]

ERIK: It is the lesson. Hidden convenience becomes visible pain later. Every time.

[pause]

JOSH: On the OpenAI voice story, I think normal people hear low latency and think, cool, less awkward pauses. You're hearing something else.

[beat]

ERIK: I'm hearing the interface change. Text is patient. Voice is not. With text, users tolerate seconds. With voice, they start judging at a few hundred milliseconds. That means the whole stack has to behave differently. Audio chunking, turn detection, interruption handling, model handoff, backpressure, retry logic, all of it matters.

[beat]

JOSH: In plain English?

[beat]

ERIK: If the machine talks too slow, people talk over it or hang up. Then your great model doesn't matter.

[beat]

JOSH: Better.

[beat]

ERIK: Good. Low-latency voice at scale is a systems story, not just a model story. Everybody wants to talk about the magic sentence the AI says. I care about the plumbing. Can it stream partials? Can it recover from jitter? Can it keep context without sounding drunk? Can it do it for thousands or millions of sessions at once?

[beat]

JOSH: And can it do it cheaply.

[beat]

ERIK: Also that. Cheap matters. Always. If your demo works at ten calls and dies financially at ten thousand, you built a hobby. Not a product.

[beat]

JOSH: Where do you see this landing first?

[beat]

ERIK: Internal ops. Not consumer assistants. Builders should start where the value is obvious and the blast radius is controlled. NOC triage. Help desk routing. Field dispatch. After-hours call intake. Runbook lookup. Those are high-friction, repetitive flows where shaving thirty seconds actually compounds.

[beat]

JOSH: Because you've already got structure there.

[beat]

ERIK: Right. A lot of that work already has scripts, queues, escalation paths, humans on standby. Voice becomes the front door, not the brain. That's important. People keep trying to make voice the whole product. Bad move. Voice should collect intent, confirm context, route to tools, and get out of the way.

[beat]

JOSH: That sounds a lot like how you build your systems.

[beat]

ERIK: Yeah. PrimeBus works because every service doesn't try to do everything. One job per worker. Publish events. Subscribe where needed. Keep contracts tight. If I were building voice ops, I'd have the transcript service publish into NATS, an intent classifier subscribe, then a job runner trigger Terraform, NSO, Selenium, whatever the task needs. HumanRail or a similar gate sits there when confidence drops. That's boring architecture. Boring architecture wins.

[beat]

JOSH: You're saying the flashy part is the least important part.

[beat]

ERIK: The flashy part is what gets clipped into a demo video. The boring part is what keeps it alive in production. I've got 89 services running on the production server right now. None of them care about vibes. They care about contracts, retries, logs, and whether the next message showed up.

[beat]

JOSH: What does low-latency voice change for a smaller builder? Somebody with one product, not sixty-four projects and a home lab that sounds mildly haunted.

[beat]

ERIK: It lowers the threshold for useful automation. A small builder can now put a voice layer on top of an existing workflow without hiring a call center or building a giant speech stack from scratch. But they still need guardrails. Keep the scope narrow. Don't start with open-ended conversation. Start with five intents. Maybe ten. Status check. Password reset. Order lookup. Appointment confirm. Escalate. That's enough to print money if the flow was painful before.

[beat]

JOSH: Wait, really?

[beat]

ERIK: Yeah. Builders waste time chasing sophistication when friction is sitting right in front of them. Remove one expensive manual step and you get paid. That's the whole trick.

[beat]

JOSH: So if somebody hears this and says, I want a voice agent tomorrow, your answer is not go buy the biggest model.

[beat]

ERIK: Correct. My answer is map the workflow, measure the call path, define the failure path, then pick the model. Model selection comes after job definition. Not before. If the job is fuzzy, the result will be fuzzy and expensive.

[pause]

JOSH: The third one I want to hit is Agent Skills. Because a lot of people are feeling this already. The AI writes code fast, and then the team spends the next day cleaning it up.

[beat]

ERIK: That's exactly the problem. Speed without process looks amazing for six minutes. Then you own the mess. Agents are very willing to skip the parts senior engineers rely on: specs, tests, code review, design checks, rollback plans. The machine doesn't feel shame, so you have to install it manually.

[beat]

JOSH: That's a sentence.

[beat]

ERIK: It's true. I use Claude every day. Multiple instances. PrimeBus fans work out across the mesh. One agent can draft a fix, another can review, another can run comparison logic. But the reason that system works is I don't let one output become production truth by default.

[beat]

JOSH: Give me the real version. What happens in your stack?

[beat]

ERIK: PrimeBus has logged 214 auto-fixes with a 78 percent success rate. People hear that and focus on the 214. I focus on the remaining 22 percent. Those are the cases that prove whether your guardrails are real. Bad test? Rejected. Weak confidence? Route it. Two variants both pass but differ materially? Compare and hold. That machinery matters more than the first draft.

[beat]

JOSH: So Agent Skills is basically trying to force that discipline back into the loop.

[beat]

ERIK: Yeah. And it needs to happen. Right now too many teams are treating coding agents like interns who somehow also have root. Terrible idea. If the agent can write code, it also needs a path through spec validation, test execution, policy checks, and ideally a second opinion.

[beat]

JOSH: That's where people push back. They say, if I add all that process, I lose the speed.

[beat]

ERIK: Then they don't understand the math. Raw generation is not the bottleneck anymore. Correction is the bottleneck. Rework is the tax. If the agent saves you twenty minutes writing code and costs you three hours in regressions, congrats, you bought a faster shovel and dug the hole deeper.

[beat]

JOSH: Dry, but fair.

[beat]

ERIK: Stripe's overnight formatting story connects to this too. At huge scale, the move isn't heroics. It's building controlled machinery that can touch a giant surface area safely. Same pattern. Small trusted steps. Strong rollback. Measurable outcomes. That's how you operate with agents too.

[beat]

JOSH: Where do smaller teams usually get this wrong first?

[beat]

ERIK: They ask the model for implementation before they force a crisp definition of done. That poisons everything downstream. Then they skip test scaffolding because the code looks plausible. Then they let the same agent review its own work, which is comedy. Then they act surprised when prod gets weird.

[beat]

JOSH: How do you fix that without building a giant platform team?

[beat]

ERIK: Start stupid simple. One prompt writes the spec. Second prompt writes the code against the spec. Third prompt acts like a reviewer and only looks for defects, missing tests, and contract violations. Then run the tests. Then decide. That's already better than most setups I see.

[beat]

JOSH: And that's still fast.

[beat]

ERIK: Very fast. Also cleaner. ScanBrief is the same shape, by the way. Fifty-six sources come in noisy. The system doesn't trust the first thing it sees. It scores, dedupes, ranks, summarizes. That's why the brief is useful at 6:30 in the morning instead of looking like a junk drawer with RSS tags.

[beat]

JOSH: So the pattern across all three stories is basically this: the winners are the ones with systems, not stunts.

[beat]

ERIK: That's it. Chrome shows what happens when power outruns trust. Voice shows what happens when the plumbing gets good enough to change behavior. Agent Skills shows the next correction in coding: less magic, more discipline. Builders should pay attention to all three.

[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?

[beat]

ERIK: Stop asking one prompt to do three jobs. Split it. First prompt: write the spec and edge cases. Second prompt: implement only against that spec. Third prompt: review like a grumpy senior engineer and look for breakage, missing tests, and bad assumptions. Different jobs, different mindset. If you've got agents, wire them that way. If you're solo in Claude, do it in sequence. You'll get less pretty nonsense and more code you can actually ship. 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.

JOSH: It's Monday, May 4. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.

ERIK: AI stops being cute when it starts making calls faster than the humans in the room.

JOSH: Stick around — Erik's got an AI pro tip at the end about separating planner models from executor models.

[pause]

JOSH: Three quick ones to start. First up, image models are finally getting text and numbers right with underdrawings. Is that a real shift or another demo trick?

[beat]

ERIK: Real shift. If the model can place the label where you asked for it, half the fake design magic turns into useful production work.

[beat]

JOSH: Next one. BYOMesh says its LoRa mesh radio pushes way more bandwidth than the old stuff. Worth paying attention to?

[beat]

ERIK: Yep. Better long-range bandwidth means better telemetry, better field sensors, and fewer remote boxes pretending they didn't see the alert.

[beat]

JOSH: Last one. Mercedes says physical buttons are coming back. Did touchscreens finally annoy enough people?

[beat]

ERIK: They lost the second somebody hid defrost in a submenu. If the user is driving, working fast, or wearing gloves, glass is the wrong answer.

[pause]

JOSH: One headline we're taking deeper. OpenAI's o1 reportedly beat triage doctors with limited patient data. That's not a toy benchmark.

[beat]

ERIK: No. That's judgment under pressure. That's where the money is and that's where people get replaced.

[pause]

JOSH: Start there. Model gets around sixty-seven percent, humans land more like fifty to fifty-five with thin data. What's your first read?

[beat]

ERIK: First read is always the same. What was the exact task, what were the inputs, and what did they count as correct. That said, the gap still matters. Thin context, time pressure, real consequences, and the model still came out ahead. That's not autocomplete. That's decision support getting teeth.

[beat]

JOSH: Why does that hit so hard outside medicine?

[beat]

ERIK: Because every serious operation has triage. NOC alerts. Failed deploys. Security noise. Routing changes. API errors. Somebody gets handed six ugly clues and has to decide what's real before the blast radius grows. That's the same pattern. Different room, different badge.

[beat]

JOSH: So when people hear doctor story, you're hearing operations story.

[beat]

ERIK: Exactly. The medical angle gets attention because the stakes are obvious. But the pattern is everywhere. If a model can rank urgency better than a tired human with partial context, then every team doing incident response should pay attention right now.

[beat]

JOSH: Put that into your world. What does that look like on your systems?

[beat]

ERIK: PrimeBus is already doing a rough version. Every app in the lab throws events onto the bus. NATS moves them around. A failing build, a broken Selenium selector, a bad cron run, a dependency issue, config drift, all of it shows up as signals. Then an agent loop scores the likely cause and decides whether it should take the shot or route it to a human. We've logged 214 auto-fixes at a 78 percent success rate across the mesh.

[beat]

JOSH: That's wild. Two hundred fourteen fixes with no human at the keyboard?

[beat]

ERIK: Correct. Not magic either. Tight scope. Small blast radius. Strong rollback path. That's the adult version of autonomy. People screw this up because they think the only modes are full self-driving or no automation at all. Wrong. The right mode is let the machine act where failure is cheap and recovery is obvious.

[beat]

JOSH: And when it isn't obvious?

[beat]

ERIK: Route it out. That's why HumanRail exists. Confidence low, context messy, too many side effects, hand it to a person. Nobody sane wants a model freehanding production because it feels lucky today.

[beat]

JOSH: What's the part the average team gets wrong when they try this?

[beat]

ERIK: Bad context first. Fake metrics second. Bad context means they dump raw logs, random screenshots, and a Jira title into the model and expect judgment. That's lazy. Fake metrics means they say "analyst productivity improved" without proving the decision got better. That's corporate wallpaper.

[beat]

JOSH: What's a real metric then?

[beat]

ERIK: False positives down. Mean time to recovery down. Escalations avoided. Rollbacks avoided. Repeat incidents cut. On PrimeBus, the only thing I care about is whether the system made the right move and whether the verification passed. A pretty explanation means nothing if the service is still broken.

[beat]

JOSH: That feels like the dividing line now. Talking versus doing.

[beat]

ERIK: Yep. Everybody has words now. Good judgment tied to an action loop is still rare. That's why most "AI strategy" decks are already stale. The model doesn't need to write you a poem about the outage. It needs to tell you the auth token expired, rotate it, rerun the job, and prove the queue drained.

[beat]

JOSH: The limited-data part still bothers me a little. Humans usually defend themselves with "well, I need more context."

[beat]

ERIK: Humans always want one more dashboard and one more meeting. Sometimes that's real. A lot of the time it's cover. What this result says is imperfect context plus a good reasoning loop is enough to win in narrow lanes today. That's uncomfortable if your whole job is making medium-quality calls from incomplete inputs.

[beat]

JOSH: Which jobs should feel that first?

[beat]

ERIK: Triage-heavy jobs. Junior SOC work. Level-one incident review. Support queue sorting. Log classification. Change review prep. Research assistants doing first-pass filtering. A chunk of that work turns into model-first, human-second pretty fast.

[beat]

JOSH: Does that mean fewer people or better people?

[beat]

ERIK: Both. Fewer people doing rote sorting. Better people handling edge cases and building the guardrails. Same thing happened everywhere else. Once the machine can do the repetitive judgment, the value moves to system design, exception handling, and proving the thing can be trusted.

[beat]

JOSH: That's a hard sentence if you're still doing inbox triage by hand.

[beat]

ERIK: Then stop doing inbox triage by hand. Harsh answer, but clean answer.

[pause]

JOSH: Second deep dive. DeepClaude. Claude Code agent loop with DeepSeek V4 Pro. On paper that sounds like stacking models because people enjoy complexity.

[beat]

ERIK: Sometimes it is. Half the internet is wiring together five models to avoid making one decision. But there is a smart version. Each model needs a job. Planner. Executor. Reviewer. Maybe classifier. If they don't have distinct roles, you've built a Rube Goldberg machine with a token bill.

[beat]

JOSH: So when does it make sense?

[beat]

ERIK: When the jobs are different enough that one model's strength covers another model's weakness. Claude is strong at code edits, structure, and not completely losing the plot in a long task. A reasoning-heavy model can be good at first-pass decomposition, weird edge cases, or ranking options before the code writer touches anything.

[beat]

JOSH: You're doing that already, aren't you?

[beat]

ERIK: In a simpler way, yeah. Three Claude instances on the mesh. Bob on Neo, Bill on the Mac M3, Homer on Morpheus. PrimeBus pushes work across them. One agent can classify the failure, another can generate A and B fixes, another can verify. That's not academic. That's live infrastructure in a two-server home lab with 64 projects and 229 cron jobs.

[beat]

JOSH: Why not just use the best model everywhere and call it a day?

[beat]

ERIK: Because "best" is fake if the task changes every step. The model that writes decent code isn't always the model that plans well. The model that's cheap enough to watch logs all day isn't the one you want burning tokens on deep analysis. Same reason you don't use a forklift to deliver mail.

[beat]

JOSH: What's the architecture you actually like?

[beat]

ERIK: Cheap model first for routing and classification. Strong reasoning model second if the problem is ambiguous. Strong coding model for the patch. Then a verifier loop that doesn't care who wrote the fix. Tests pass or they don't. Service healthy or not. That's the stack.

[beat]

JOSH: Sounds obvious when you say it. Why do people still get this wrong?

[beat]

ERIK: Because they start with the model instead of the workflow. They ask, "Which frontier model should run my company?" Wrong question. Start with, "What are the repeatable decisions, what context is needed, and what proves success?" Models come after that. If you reverse it, you get expensive demos.

[beat]

JOSH: Give me a concrete example.

[beat]

ERIK: PrimeBus catches a failed test run at two in the morning. First pass classifier reads the failure shape. If it's a flaky selector in Selenium, that's one lane. If it's a dependency conflict, that's another. Planner says what kind of fix should exist. Executor writes two variants. Verifier runs tests. Winner gets merged if the checks are clean. That's how you get 214 auto-fixes instead of 214 Slack threads.

[beat]

JOSH: And the failure cases?

[beat]

ERIK: Plenty. Wrong root cause. Patch passes local tests and still misses the real issue. Model edits too much. Fix works but introduces subtle drift. That's why verification matters more than the generated patch. No guardrails, no autonomy. Simple.

[beat]

JOSH: Where does cost enter the picture?

[beat]

ERIK: Immediately. If you put the expensive brain on the cheap task, you're lighting money on fire. ScanBrief is a good example. It scans 56 sources and scores 396 items every morning for a 6:30 delivery. No sane person wants premium reasoning on every single raw item. Most of that work is filter, dedupe, rank. Save the expensive thinking for the few places where nuance actually changes the outcome.

[beat]

JOSH: So planner and executor isn't just better quality. It's cost control too.

[beat]

ERIK: Correct. Quality, speed, and cost all move if the roles are clean. Everybody wants one model to be an employee. Better move is build a small team out of narrow roles and make them prove their work.

[beat]

JOSH: What should builders stop doing today?

[beat]

ERIK: Stop making one giant prompt that says "think hard, write the code, test it, explain it, and make it perfect." That's toddler architecture. Break the work apart. Route. Plan. Execute. Verify. Keep receipts.

[pause]

JOSH: Last one. The button story. Mercedes bringing physical controls back sounds small, but people reacted hard.

[beat]

ERIK: Because everybody knows it was dumb. Car companies spent years confusing "looks modern" with "works well." A slider on a screen is fine until your hands are cold, the road sucks, sunlight hits the panel, and you need defrost now.

[beat]

JOSH: This isn't really about cars, is it?

[beat]

ERIK: No. It's about interfaces built for demos instead of use. Same disease shows up in enterprise tools all the time. Teams hide important actions behind layers because the screen looks clean in a screenshot. Then an operator needs two extra clicks during an incident and suddenly "minimal" feels stupid.

[beat]

JOSH: How does that map to AI products?

[beat]

ERIK: Same exact problem. People are building shiny chat wrappers when the user really needs a button that says classify this alert, write the patch, compare these configs, check drift, rerun the failed job. Utility beats theater. Always.

[beat]

JOSH: So a physical button is kind of the interface version of a good runbook.

[beat]

ERIK: That's a good way to say it. Known action. Predictable result. Low cognitive load. Runbooks should feel like that. Agents should feel like that too. If the operator has to wonder what the system is about to do, you've already lost trust.

[beat]

JOSH: You think this swings back hard?

[beat]

ERIK: In serious tools, yes. Fast. The winners won't be the prettiest apps. It'll be the ones that let people act with confidence. In my lab, every useful tool got simpler over time. More automation underneath. Fewer choices on top. That's not sexy. It works.

[beat]

JOSH: Dry way to say the touchscreen lost.

[beat]

ERIK: Glass had a good run. Defrost won.

[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?

[beat]

ERIK: Split planner from executor. Always. Use one model to think about the shape of the problem and produce a tight plan. Then hand that plan to a second model whose only job is execution. Code, content, query, config, whatever. Don't ask the same model to brainstorm, decide, build, and judge in one pass unless the task is tiny.

[beat]

ERIK: Reason is simple. Planning and doing are different jobs. When you separate them, prompts get shorter, output gets cleaner, and failure is easier to debug. If the plan is bad, fix the planner. If the code is bad, fix the executor. On PrimeBus, that separation is a big chunk of why the auto-fix loop stays sane.

[beat]

ERIK: Practical version. Prompt one: "Classify the failure, identify the likely root cause, and return a five-step repair plan." Prompt two: "Execute only step three using this repo context and change the minimum needed." Prompt three: "Verify with tests and explain any mismatch." That's your tip. Use it.

[pause]

ERIK: That tip is straight out of The Autonomous Engineer — my book on building systems that run themselves. Grab it on Amazon.

[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.

JOSH: It's Friday, May 1st. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.

ERIK: PyTorch Lightning got poisoned, Anthropic's best model can apparently identify you from your writing style, and my production server ran 91 services overnight without me touching a keyboard.

JOSH: Stick around — Erik's got an AI pro tip at the end on model routing, specifically how to stop paying Opus prices for Sonnet work.

[pause]

JOSH: First headline — Claude Code was apparently refusing requests or billing differently when commits mentioned a competitor's name. That's real?

ERIK: Reports say Claude Code was flagging or treating differently anything that referenced a startup called OpenClaw. Unverified, and I'd want to see reproducible evidence. But the question it raises — can your AI vendor quietly discriminate against competitors inside your own codebase — that's real and worth watching.

[beat]

JOSH: Linux kernel vulnerabilities — distributions aren't getting advance notice before public disclosure?

ERIK: Zero heads-up. Patch goes public, everyone finds out together — including attackers who can read the diff. Downstream maintainers don't get time to prep. That's not a coordinated disclosure process, that's a footrace where one side doesn't know the gun fired.

[beat]

JOSH: And Rivian built a full data shutoff switch.

ERIK: All connectivity off — nav, OTA, everything. You trade features for privacy. The fact that the switch exists at all is the story. Most manufacturers treat your data as their data and don't surface the question.

[pause]

JOSH: Okay. Fifteen episodes in and we've got our first real supply chain attack in the AI tooling space. PyTorch Lightning. What happened?

ERIK: Versions 2.6.2 and 2.6.3 of the lightning package were compromised. Someone embedded obfuscated JavaScript inside a directory that has no business existing in a Python library. The payload stole credentials and could poison your connected GitHub repos. They named the campaign "EveryBoiWeBuildIsaWormBoi" — full Dune branding, Shai-Hulud themed. I don't know if that makes them more or less dangerous.

JOSH: JavaScript. Inside a Python AI training package.

ERIK: That's the whole technique. Nobody audits a Python package for JavaScript. It doesn't belong there. The obfuscation wasn't advanced — the attack was the hiding spot, not the code.

JOSH: Who actually gets hit by this?

ERIK: Anyone who ran pip install lightning and landed on those two versions. PyTorch Lightning is used for serious work — model fine-tuning, training pipelines, GPU experiments at scale. The credentials it could grab depend on what was in scope in that environment. API keys, GitHub tokens, cloud credentials. Whatever was accessible.

[beat]

JOSH: What's the actual fix right now?

ERIK: Rotate first, assess later. Any API key or token that environment could touch — don't wait to understand the full scope, rotate now. Then pin your package versions. Hard pins. Specific version numbers, not floating ranges. I run 64 projects. If I'm not pinning, I'm trusting whoever pushed the last commit to any package in my dependency tree. I don't know that person. I'm not going to trust them with my GitHub access.

JOSH: Pinning sounds annoying at scale.

ERIK: It is. And it's the answer. Twenty minutes of annoying setup upfront versus days of cleanup after a breach. The math isn't close.

[beat]

JOSH: Is AI tooling specifically more exposed to this kind of attack?

ERIK: More exposed than it should be. The ML ecosystem has grown so fast that review rigor hasn't kept pace with velocity. Thousands of packages, contributors under deadline pressure, fast release cycles. Supply chain attacks have been the dominant infrastructure threat vector since SolarWinds in 2020. AI tooling isn't exempt because it's new — it's actually more exposed because people assume it's been vetted and haven't built scrutiny habits yet.

JOSH: That's a rough way to start May.

ERIK: ScanBrief scored 48 items this morning across 56 sources. This one landed in the top five. It earned its place.

[pause]

JOSH: Alright. Opus 4.7 — story says it can identify people just from their writing. What's actually happening there?

ERIK: The claim is stylometric identification. Not from metadata, not from your profile, not from an IP address — from the writing itself. The way you construct sentences, the vocabulary you default to when explaining something technical, your rhythm when you're making an argument. Those patterns are a fingerprint. The claim is that Opus 4.7, given enough of your known writing as a baseline, can match anonymous or pseudonymous writing back to you.

JOSH: So you write something under a fake name and the model connects the dots.

ERIK: That's the scenario. You need enough known writing to establish the pattern first. But once the model learns how you write, an anonymous sample can potentially be matched to you regardless of the name on it. And Anthropic published a system card acknowledging this capability. That's not a rumor — that's them documenting it officially.

[beat]

JOSH: Who has to care about this today?

ERIK: People whose careers or safety depend on pseudonymity. Whistleblowers. Security researchers who publish findings without their real name because their employer would fire them if they knew. Journalists with active sources. Government employees who participate in public technical forums. For those people, the threat model they've been operating under just changed. The change is documented.

JOSH: What about people just building in public under their own name?

ERIK: I put my name on everything. Not my personal concern. But I think about what it means structurally. Five years ago a maintained pseudonym was a reasonable privacy layer that held against most adversaries. Now you have to assume a well-resourced actor — a government, a corporation, a motivated individual with API access — can potentially break it. The baseline assumption shifts even if your personal situation doesn't.

[beat]

JOSH: Can you actually defend against it?

ERIK: You can try. Alter your vocabulary, change your sentence structure, avoid your natural patterns. But here's the recursive problem — if the model has enough of your real writing to learn your baseline, departing from that baseline might itself be the signal. The deviation flags the disguise. You're trying to hide by acting unlike yourself, and a good enough model notices that you're acting.

JOSH: So the move is just accept that strong anonymity is harder now.

ERIK: The move is understand that it requires operational security most people never needed before. That standard got raised. Whether people adjust to it is the open question.

JOSH: The system card is Anthropic saying they see it.

ERIK: Right. And I'd rather they publish it than pretend the capability doesn't exist. Transparency about what a model can do is the correct call. It doesn't undo it. But it means researchers, journalists, and policymakers know what they're actually dealing with — which matters more than people realize right now.

[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: Model routing before you write a single prompt. PrimeBus ran 1,092 automation events today across 14 projects. Most of those hit Sonnet. Opus touches maybe five percent. That ratio is intentional and it's written down. Sonnet costs roughly a tenth of Opus per token. If you're running Opus on summarization, classification, or executing a task that already has a clear spec — you're burning money on work that doesn't need that level of model. My rule: judgment under ambiguity, architecture decisions, complex reasoning on novel problems — Opus. Clear spec, known output format, repeatable execution — Sonnet. That single routing decision cuts my API spend forty to sixty percent versus defaulting to Opus everywhere. With 91 services running in production, that delta compounds fast. Write the routing rule down before you touch code, not after your first invoice surprises you. 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.

JOSH: It's Thursday, April 30. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.

ERIK: Three stories today. Faster editors, stricter code review, and a Linux bug that turns bad patching into a career event.

JOSH: Stick around — Erik's got an AI pro tip at the end about getting better output from coding agents with one simple constraint.

[pause]

JOSH: First headline. Zed 1.0 is out. Is this actually a threat to the Electron editor pile, or is Hacker News doing its usual thing?

[beat]

ERIK: It's real. The Atom guys rebuilt the editor stack in Rust with a GPU-driven UI, and the point is simple: stop dragging a browser around just to edit text.

[beat]

JOSH: Next one. The Zig project put up a hard anti-AI contribution policy. Is that anti-progress or just sane?

[beat]

ERIK: For compiler work, it's sane. If the person sending the patch doesn't understand the patch, the reviewer becomes the author, and that's a bad deal.

[beat]

JOSH: Last headline. Copy Fail. Portable local root exploit. How ugly is that one?

[beat]

ERIK: Ugly enough that you stop assuming "local only" means low risk. If an unprivileged user lands on the box and the kernel's exposed, your day gets shorter fast.

[pause]

JOSH: Start with Zed. Why did that one jump out at you?

[beat]

ERIK: Because editors matter more than people admit. Everybody talks about the model. Claude, GPT, Cursor, whatever. But the editor is the cockpit. If the cockpit is heavy, weird, or fights you, you feel it every hour.

[beat]

JOSH: A lot of people listening probably use VS Code and don't think about it.

[beat]

ERIK: Right, because VS Code works. That's the hard part for challengers. You don't beat VS Code by being slightly cleaner. You beat it by making the whole thing feel sharper. Startup. Search. Scrolling. Multi-cursor. Remote work. AI hooks. All of it.

[beat]

JOSH: And Zed's bet is speed first?

[beat]

ERIK: Speed and architecture. They didn't build another wrapper around Chromium and call it innovation. They built their own UI stack. That's a serious engineering choice. More risk up front. Better ceiling later.

[beat]

JOSH: Why should builders care about the ceiling?

[beat]

ERIK: Because the next phase of coding tools is not one autocomplete box on the side. It's editors acting like orchestration surfaces. Multiple agents. Diff reviews. background indexing. Terminal hooks. semantic search. repo memory. live previews. If the foundation is bloated, every new feature taxes the experience.

[beat]

JOSH: So this is less about "pretty fast text editor" and more about what happens when the editor becomes the operating system for coding.

[beat]

ERIK: Exactly. You said it shorter than most product pages do.

[beat]

JOSH: That's rare for me.

[beat]

ERIK: Mark the date.

[beat]

JOSH: How does this compare to what you actually use every day?

[beat]

ERIK: In my lab I care about throughput. I have 64 projects across two servers. Neo and Morpheus. Two hundred twenty-nine cron jobs. Three Claude instances on a PrimeBus NATS mesh. When I touch code, I need low friction because the coding session is usually one step inside a larger automation chain.

[beat]

JOSH: Meaning?

[beat]

ERIK: Meaning I may not be "sitting down to code." I might be fixing a failing test from PrimeBus, checking a generated patch, editing a prompt for InkEngine, then hopping into Terraform, then into a Python worker for ScanBrief. Context moves fast. Tool lag compounds.

[beat]

JOSH: So editor performance is not cosmetic for you.

[beat]

ERIK: Not even a little. PrimeBus has logged 214 auto-fixes with a 78 percent success rate. The 22 percent that fail usually need a human pass. That's me looking at diffs, traces, logs, and generated variants. If the editor drags when I'm moving through those fixes, that cost hits every day.

[beat]

JOSH: That's the part people miss. Ten little delays times a hundred actions.

[beat]

ERIK: Yep. Death by "it's only a second."

[beat]

JOSH: Do you think Zed wins?

[beat]

ERIK: Wins what? Mindshare, maybe. Replacing VS Code everywhere, not soon. The moat is extensions and habit. But that doesn't mean it loses. If it becomes the place where serious AI-native workflows feel best, it carves out a real lane.

[beat]

JOSH: AI-native is the phrase everyone throws around. What's the non-buzzword version?

[beat]

ERIK: The editor should know your repo, your terminal, your git state, your errors, your tests, and what the agent just changed. It should help you supervise work, not just type faster. That's AI-native.

[beat]

JOSH: You think Electron gets in the way of that?

[beat]

ERIK: Sometimes. Not always. Plenty of great stuff ships on Electron. But if you're building for the next five years, not the next five months, owning the stack matters. Same reason I built PrimeBus instead of duct-taping more one-off scripts together forever.

[beat]

JOSH: That's the common thread with your stuff. You build the bus once, then everything plugs in.

[beat]

ERIK: Right. Messages on the bus. Agents subscribe. Errors trigger workflows. Warnings trigger workflows. Humans step in only when confidence drops. That's how HumanRail came out too. If the model isn't sure, route it to a person instead of pretending confidence.

[beat]

JOSH: So Zed 1.0 matters because it says, "we're not patching the old shape, we're building the next shape."

[beat]

ERIK: That's why it matters. Even if you never install it, it pressures the whole editor market to stop being lazy.

[pause]

JOSH: The Zig policy is a different kind of signal. They basically said AI-generated contributions are not welcome. A lot of people heard that as anti-AI. You didn't.

[beat]

ERIK: No. I heard "bring less garbage to review." That's not anti-AI. That's anti-noise.

[beat]

JOSH: Explain the difference.

[beat]

ERIK: AI is useful. I use Claude every day. PrimeBus literally spins up Claude sessions to attempt fixes. InkEngine exists because models can draft, reshape, and structure a lot of text fast. But useful does not mean unsupervised copy-paste into a compiler project.

[beat]

JOSH: Because the reviewer pays for it?

[beat]

ERIK: Exactly. If you send a patch you don't understand, then the maintainer has to prove your code is safe, coherent, and aligned with the language design. That reviewer is now doing two jobs. Their job and yours.

[beat]

JOSH: That's wild because the whole pitch from AI coding tools is more output.

[beat]

ERIK: Output is cheap. Comprehension is expensive.

[beat]

JOSH: That's a good line.

[beat]

ERIK: It's also the whole problem.

[beat]

JOSH: How do you handle that in your own systems? Because you're absolutely using AI to write code.

[beat]

ERIK: Yeah, but with guardrails. PrimeBus doesn't get a gold star for producing text. It gets measured on merged fixes that pass tests. Out of 214 auto-fixes, 78 percent succeeded. That sounds good because it is good. But the number matters because it tells you the boundary. The model is productive. It is not trusted by default.

[beat]

JOSH: So what does the boundary look like?

[beat]

ERIK: Small changes first. A/B fix variants. Run tests. Compare outcomes. Keep diffs tight. Log why it changed something. If confidence is low, HumanRail can bounce it to a human. That's how you keep agentic coding from turning into fancy vandalism.

[beat]

JOSH: Fancy vandalism is probably a fair label for some pull requests.

[beat]

ERIK: More than some.

[beat]

JOSH: Why would Zig need to be this blunt though?

[beat]

ERIK: Because compiler and systems work punish shallow understanding. In app code, a bad AI patch might break a view, fail a unit test, maybe chew up an afternoon. In a compiler, a subtle bad patch can rot semantics, break portability, or create bugs nobody finds for months.

[beat]

JOSH: Higher blast radius.

[beat]

ERIK: Much higher. And Zig is not alone. Plenty of maintainers are thinking the same thing. They may not all write it down that directly, but they're thinking it.

[beat]

JOSH: Does that mean AI coding hits a wall in serious projects?

[beat]

ERIK: No. It means the projects with standards are going to force better usage. Which is good. The model should help you think, test, compare, summarize, and explore. The human should still own the patch.

[beat]

JOSH: That sounds less sexy than "one-click software engineer."

[beat]

ERIK: Good. Sexy is how people end up diffing 800 lines they never should've accepted.

[beat]

JOSH: For builders listening, what's the practical takeaway?

[beat]

ERIK: Stop asking if AI wrote the code. Ask if the submitter can explain the code. Big difference. If they can't explain it, reject it, even if it passes.

[beat]

JOSH: Even if it passes?

[beat]

ERIK: Especially then. Passing tests can hide shallow understanding. Tests are a floor, not a soul.

[beat]

JOSH: That's a little dark.

[beat]

ERIK: I work in automation. Dark is familiar.

[beat]

JOSH: You've seen this outside software too, right? Ops, infra, runbooks?

[beat]

ERIK: Constantly. Teams copy vendor snippets into production, then nobody knows why BGP is flapping or why the NSO service model keeps drifting. Same disease. Borrowed output without ownership. AI just makes the disease faster.

[beat]

JOSH: So Zig isn't saying "no AI ever." They're saying "don't outsource your brain and hand me the bill."

[beat]

ERIK: That's the clean version, yeah.

[pause]

JOSH: Copy Fail. Local Linux privilege escalation. Those stories can get abstract fast. What's the plain-English version?

[beat]

ERIK: Plain English: if someone can get a foothold as a normal user on the box, this kind of bug can turn that into root. Then it stops being "one compromised account" and starts being "own the system."

[beat]

JOSH: Why should people care if they're thinking, "our servers aren't public shells"?

[beat]

ERIK: Because attackers chain things. Phish a developer box. Abuse a weak container escape. Land through a bad service account. Local privilege escalation is often step two, not step one.

[beat]

JOSH: And this one looked broadly portable.

[beat]

ERIK: That's what makes it nasty. If one binary works across a spread of distros and kernel vintages, patch lag becomes a real liability. Enterprises love patch windows. Attackers love them more.

[beat]

JOSH: Where do teams usually get this wrong?

[beat]

ERIK: They rank it low because it's "local." That label tricks people. In real environments, local access is not rare after initial compromise. It's the normal path.

[beat]

JOSH: How do you think about that in your own stack?

[beat]

ERIK: Small blast radius. Tight permissions. Separate services. Fast patching. Telemetry everywhere. My home lab isn't a toy. Two servers, yes. But I treat them like real infrastructure. Services are segmented. Workflows are observable. If a box starts acting weird, I want the bus to tell me before I have to guess.

[beat]

JOSH: Is that what ScanBrief is partly for too? Staying ahead of this stuff?

[beat]

ERIK: Yeah. ScanBrief pulls 56 sources and scores 396 items daily. I don't need more content. I need fewer blind spots. Security bugs, model updates, tooling changes, editor releases, weird billing issues like that HERMES commit-message thing. All of it matters because all of it touches the build loop.

[beat]

JOSH: That HERMES story is funny until it isn't.

[beat]

ERIK: Exactly. If text in a commit message can trigger a more expensive path somewhere in an AI toolchain, that tells you the plumbing is still immature. Builders need to assume side effects. Names, files, prompts, metadata. All of it can matter in ways vendors don't advertise.

[beat]

JOSH: That seems like the bigger theme today. Hidden costs.

[beat]

ERIK: Hidden costs everywhere. Heavy editor architecture. Reviewer burden from AI patches. Patch lag on local root bugs. Weird tooling bills from stray text. People think the work is the feature. The work is usually the system around the feature.

[beat]

JOSH: That's why your stuff ends up as flywheels instead of one-off apps.

[beat]

ERIK: Right. PrimeDistro isn't "send a postcard." It's scrape 845 businesses, audit websites, generate 62 previews, send cards through LOB at sixty-three cents each, and know one website sale pays for the campaign. That's the system view. Same thing here.

[beat]

JOSH: When you look at these three stories together, what's the call?

[beat]

ERIK: Build with standards. Fast tools. Hard review lines. Short patch cycles. If your setup makes sloppy work easy, sloppy work is what you'll get.

[beat]

JOSH: And if your setup makes ownership visible?

[beat]

ERIK: Then good people move faster. That's the whole point.

[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?

[beat]

ERIK: Force the model to state its uncertainty before it writes the fix.

[beat]

JOSH: That's it?

[beat]

ERIK: That's it, and most people don't do it. Before you ask for code, tell the model: "List the top three assumptions, the likely failure mode, and what you'd test after the change. Keep it short. Then write the patch."

[beat]

JOSH: Why does that help?

[beat]

ERIK: Because it changes the model from eager intern mode into reviewer mode. You surface bad assumptions early. You also get better diffs, because the model is less likely to wander into side quests when it has to admit uncertainty first.

[beat]

JOSH: So you're not asking for more words. You're asking for better framing.

[beat]

ERIK: Exactly. In PrimeBus, the good results come when the agent knows the target, the boundary, and the test. Same thing in a chat window. If the model says, "assumption one, this bug is in auth state hydration; failure mode, token refresh loop; test, expired session plus page reload," now you're supervising something concrete.

[beat]

JOSH: And if the assumptions are dumb?

[beat]

ERIK: Then you saved yourself from reading a dumb patch. That's the win.

[beat]

JOSH: Short version for people to use today?

[beat]

ERIK: Ask for assumptions, failure mode, and test plan before code. Three lines. Then let it write. That's your tip. Use it.

[pause]

JOSH: Track your freedom score and net worth with the Freedom Blueprint app — free download, link in the show notes.

[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.

JOSH: It's Wednesday, April 29. This is Build or Be Replaced powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.

ERIK: Default platforms get lazy. Builders shouldn't.

JOSH: Stick around. Erik's got an AI pro tip at the end about when to stop using one big model for everything.

[pause]

JOSH: Three quick signals this morning. First up, Warp is open-source now. Does that matter, or is that just terminal nerd news?

ERIK: It matters. Dev tools earn trust when the code is visible, especially if they're sitting in your shell, your keys, your commands, your whole day.

[beat]

JOSH: GitHub also had a nasty RCE bug tied to `git push`. That's the kind of sentence people hate hearing.

ERIK: Yeah. If a normal authenticated push can turn into backend command execution, that's not a bug, that's a siren. Everybody building on GitHub infrastructure just got reminded that convenience has a blast radius.

[beat]

JOSH: And LocalSend is getting a lot of love as an AirDrop alternative. Why are people so into that?

ERIK: Because simple software that does one thing well still wins. Cross-platform file transfer with no cloud weirdness, no account circus, no vendor tax. People miss software that minds its business.

[pause]

JOSH: The first deep dive is Ghostty leaving GitHub. On the surface that sounds small. One project changes where it lives. Why did that blow up?

ERIK: Because it's not one random repo. Ghostty's maintainer is a serious GitHub power user. When somebody like that says, "I'm out," people pay attention. They're not leaving because buttons moved around. They're leaving because GitHub stopped feeling like neutral ground.

[beat]

JOSH: Neutral ground for what?

ERIK: Open source coordination. Code, sure. But also issues, trust, reputation, discovery, docs, release notes, bug reports, random drive-by fixes from somebody in Poland at 2 AM. GitHub became the town square and the filing cabinet at the same time. That's why this matters.

JOSH: So the story isn't "terminal app moves." It's "people are tired of the town square."

ERIK: Exactly. And once builders start feeling that, migration pressure builds fast. Not because every alternative is better. Most aren't. But once the default stops feeling safe, people tolerate rough edges somewhere else.

[beat]

JOSH: What's actually driving the frustration?

ERIK: A few things. Platform lock-in. AI features people didn't ask for. Corporate gravity. The sense that the product is serving executives and telemetry before it's serving maintainers. Open source people can smell that stuff quick.

JOSH: That's wild, because GitHub still feels unavoidable.

ERIK: Right now, yeah. Same way VMware felt unavoidable. Same way Stack Overflow felt unavoidable. Then one day you realize the traffic's still there, but the energy left. Those are different things.

[beat]

JOSH: How do you think about that in your own stack? You've got a lot of moving parts tied together.

ERIK: I don't let one vendor become my nervous system. That's the lesson. PrimeBus is NATS-based. Claude writes code in a bunch of workflows. ScanBrief pulls from 56 sources. InkEngine has its own app flow. I try real hard not to make any single company the one throat my whole lab has to breathe through.

JOSH: And that's because you've seen what happens when people do.

ERIK: Yep. A platform becomes identity, hosting, issue tracking, CI, package trust, release automation, discussion, auth. Then the vendor changes terms, breaks the UX, gets breached, or decides your use case isn't strategic. Now your whole shop gets dragged around by the ankle.

[beat]

JOSH: How much of your own stuff would break if GitHub had a really bad week?

ERIK: Some things would get annoying. Nothing important should die. That's the standard. I've got 64 projects running across two servers in the lab, 229 cron jobs, three Claude instances on the PrimeBus mesh, and the goal is always the same: graceful degradation. If one thing goes weird, I want inconvenience, not paralysis.

JOSH: That's a good line.

ERIK: It's a billing line too. Companies pay a lot of money to turn paralysis into inconvenience.

[beat]

JOSH: For teams listening, what's the practical takeaway? Not the philosophy. The actual move.

ERIK: Separate your social layer from your build layer. People smash those together and regret it later. Mirror your repos. Own your CI definitions. Export your issues. Keep release artifacts somewhere you control. Don't build your company on screenshots of green checkmarks from one platform.

JOSH: You're saying reduce dependence before you're angry enough to need it.

ERIK: Exactly. You do not start building the lifeboat after the ship lists. That's fake planning.

[beat]

JOSH: Does leaving GitHub actually help a project, though? Doesn't it also make contribution harder?

ERIK: It can. That's the trade. You lose some default visibility. Some drive-by contributors won't follow. But serious users will. And sometimes the point isn't growth. Sometimes the point is control. Builders need to remember that. More users on worse terms isn't always a win.

JOSH: So this is less rebellion and more boundary-setting.

ERIK: Yeah. And it's a signal that the center of gravity can move. Slowly at first, then all at once. Open source communities don't need permission to relocate. They just need a reason.

[pause]

JOSH: Next one. Rust. Everybody treats Rust like a force field, and then Ubuntu audits Rust-based coreutils and finds 44 CVEs. Wait, really?

ERIK: Really. This is the part people don't like hearing. Memory safety is huge. It is not magic. Rust can stop whole classes of bugs. It cannot stop you from making bad system decisions with perfect memory safety.

[beat]

JOSH: Put that in plain English.

ERIK: If your privileged file utility has a race condition with symlinks, Rust doesn't save you. If you check a path and then use it later and the world changed in between, Rust doesn't save you. If your logic is bad, your logic is bad in any language.

JOSH: So the headline isn't "Rust failed." It's "people oversold what it solves."

ERIK: That's exactly it. Rust is a seatbelt. A seatbelt is good. Still a bad idea to drive into a lake.

[beat]

JOSH: Why does this matter beyond language wars?

ERIK: Because teams make budget decisions and staffing decisions on myths. They hear "we rewrote it in Rust" and think security problem solved, hiring problem solved, compliance box checked. No. You changed one layer of risk. Good move. Now go do the boring part too.

JOSH: The boring part being audits and threat models and all the stuff nobody wants to fund.

ERIK: Yep. Filesystem semantics. Privilege boundaries. Integration testing. Abuse cases. SAST. Dynamic tests. Running the weird edge cases. You still need paranoid engineers. The compiler is not your security team.

[beat]

JOSH: How do you handle that in your own automation work? Because you've got a lot of code touching real systems.

ERIK: I assume every automation can hurt me if I let it. That's the posture. In PrimeBus, when an agent sees an error and tries a fix, that fix doesn't get a free pass because Claude wrote it neatly. I wrap guardrails around the action path. Diff checks. Retry limits. Scope restrictions. Logging. HumanRail if confidence is low.

JOSH: How often do those guardrails actually matter?

ERIK: Constantly. PrimeBus has done 214 auto-fixes with a 78 percent success rate. Everybody hears that and thinks, "nice." What they should hear is 22 percent didn't make it. That's exactly why the rails matter. Success without rails is a delayed outage.

[beat]

JOSH: That's a good point. People only market the win rate.

ERIK: Of course. Nobody makes a landing page that says, "Our agent confidently did the wrong thing on Friday." But that's real life. Good builders plan around wrongness.

JOSH: Does this Rust story change anything for AI-written code too?

ERIK: A lot. AI tends to produce code that looks clean before it's truly safe. That's dangerous. Humans get tricked by polished syntax. You see nice tests, nice comments, nice structure, and your brain assumes the edge cases got handled. They didn't necessarily.

[beat]

JOSH: So if a model writes Rust, that doesn't mean the code is safe either.

ERIK: Correct. If anything, it can make the false confidence worse. "Rust plus AI" sounds like two layers of smart. Could still be a symlink race with nicer formatting.

JOSH: Dry, but fair.

ERIK: That's most postmortems. Fancy technology, boring root cause.

[beat]

JOSH: If you're running an engineering team and somebody says, "We're moving this service to Rust," what's the right response?

ERIK: Good. Why? What risk are we removing? What risk remains? What tests change? What operational assumptions change? If they can't answer that, they're doing religion, not engineering.

JOSH: And if they can answer it?

ERIK: Then fund it. Rust is useful. I've got no interest in clown takes on either side. But use it like an adult. Memory safety is one control in a stack, not a final state.

[beat]

JOSH: You've been around network automation forever. Any comparison from that world?

ERIK: Yeah. People used to think if they had NSO or Terraform, then change risk disappeared. No. You got consistency. That's valuable. You did not get wisdom. You can automate a bad intent beautifully.

JOSH: That's the line.

ERIK: Happens every day. Clean YAML. Terrible idea. Still takes prod down.

[pause]

JOSH: Third deep dive. OpenAI models coming to Amazon Bedrock. Why is that a big shift?

ERIK: Because it breaks the feeling that serious OpenAI usage had to orbit Azure. Enterprises don't like being herded onto one cloud just because the model is good. Bedrock changes the buying conversation fast.

[beat]

JOSH: Is this mostly a procurement story?

ERIK: Procurement, compliance, architecture, politics. All the fun stuff. Plenty of companies already have AWS baked into security review, billing, network patterns, data handling, vendor approval. If they can buy OpenAI there, a bunch of internal friction disappears overnight.

JOSH: And that matters more than model benchmarks sometimes.

ERIK: Way more. The best model on the wrong procurement path loses. I've seen this forever in enterprise infra. Better tool, wrong approval lane, dead on arrival.

[beat]

JOSH: What does it mean for Microsoft?

ERIK: Less differentiation. They had gravity from hosting and relationship structure. If OpenAI shows up in Bedrock too, the moat gets shallower. Microsoft still matters a lot, but the exclusivity story gets weaker.

JOSH: Does that change how builders like you work day to day?

ERIK: It gives me options. Options are speed. If I want one workflow on Claude, another on OpenAI, maybe route something through Bedrock because the client's already in AWS, that reduces friction. I'm building systems, not joining fan clubs.

[beat]

JOSH: You actually mix models already.

ERIK: Constantly. Three Claude instances are on my PrimeBus mesh right now. Bob on Neo, Bill on the Mac M3, Homer on Morpheus. Then I use other models where they fit better. ScanBrief cares about ranking and summary quality. InkEngine cares about long-form structure and revision flow. PrimeTrader cares about fast classification and signal handling. Same hammer for all of that would be lazy.

JOSH: People still want the one-model answer, though.

ERIK: Because it's simpler to explain. Not simpler to run. In the lab I care about throughput, cost, confidence, retry behavior, context limits, and whether the model follows the shape of the task. That's way more important than tribal brand arguments.

[beat]

JOSH: What kind of tasks get routed differently for you?

ERIK: High-risk code fixes get stronger review paths. Commodity summarization can use cheaper models. Classification can go tiny and fast. If a workflow has low confidence, HumanRail can send it to a human. If it's repetitive and bounded, let the agents eat.

JOSH: That's a very different frame from "which model is best."

ERIK: "Best" is a toy question. Best at what, under what cost, with what failure mode, inside which system. Builders need to ask system questions.

[beat]

JOSH: Does Bedrock make multi-model setups easier for normal teams, or is this mostly enterprise theater?

ERIK: Both. Big companies care first because they're stuck in approval labyrinths. But smaller teams benefit too because the market keeps loosening. More distribution means more pricing pressure, more deployment patterns, more room to avoid single-vendor traps.

JOSH: Back to the GitHub theme, basically.

ERIK: Yep. Same lesson again. Don't hand one company the keys to your whole future if you don't have to.

[beat]

JOSH: If you're listening and building internal tools right now, what's the smart move?

ERIK: Build an abstraction layer early. Not a giant science project. Just enough to swap model providers without surgery. Standardize prompts, outputs, retries, logs, and evals. Then you can move where the economics or risk picture makes sense.

JOSH: Because the market won't sit still.

ERIK: It never does. That's why I ship daily. The guy waiting for the perfect stable stack gets lapped by the guy with adapters and guardrails.

[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 using one giant model for every task. That's the tip. People throw the expensive brain at everything because it's easy, and then they wonder why cost goes up and latency gets stupid.

[beat]

ERIK: Split the work. Use a cheap fast model for classification, routing, and cleanup. Use the stronger model only where judgment matters. Code review. tricky edits. ambiguous prompts. Stuff that can actually hurt you.

[beat]

ERIK: In my stack, I think in lanes. One lane scores signals. One lane summarizes. One lane checks confidence. One lane asks for a human if the output smells off. That pattern matters more than whatever model won Twitter this week.

[beat]

ERIK: If you do one thing today, add a confidence check before expensive generation. If confidence is high, stay cheap. If it's low, escalate. That one move saves money and catches dumb mistakes early. That's your tip. Use it.

[pause]

ERIK: If you're building toward financial independence through automation, my first book walks through the whole path. Free chapter at erikandersonbook.com.

[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.

JOSH: It's Tuesday, April 28. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.

ERIK: Microsoft and OpenAI just ended their exclusive deal. The whole AI power structure shifted overnight. Today's about what that means for builders.

JOSH: Stick around — Erik's got an AI pro tip at the end about building so you can swap AI providers without touching your application code.

[pause]

JOSH: Three quick headlines first. Researchers trained a 13 billion parameter model on nothing but pre-1931 text. They called it Talkie.

ERIK: It's a time capsule with a chat interface. Ask it about the internet, it'll tell you that doesn't exist. What's useful about this project is what it reveals about how models reason toward their own future. When the training data ends, Talkie still predicts forward — but from a 1930 baseline. Every model is a snapshot. Talkie just makes that impossible to ignore.

JOSH: Next — Apple is killing AFP support in macOS 27 and requiring TLS 1.2 on all server connections.

ERIK: AFP should have been dead already. SMB's been the right call for years. The TLS mandate is the one with teeth. Older home lab setups, internal services that haven't been touched in three years — a lot of those are still running 1.0 or 1.1. If Mac is in your infrastructure chain, audit your connection config now, not when the update ships.

JOSH: And last — pgbackrest, the popular Postgres backup tool, is no longer being maintained.

ERIK: Barman is the move. But the actual lesson is dependency hygiene. Any critical tool maintained by one person is a single point of failure in your stack. pgbackrest had a good run. Time to move.

[pause]

JOSH: Okay. Microsoft and OpenAI. The exclusive deal is dead, the revenue sharing is dead. How do we get here?

ERIK: Microsoft put in thirteen billion over the years. In exchange they got exclusive Azure hosting rights, a revenue cut, and Copilot baked into Office. OpenAI got compute and credibility. For a while that worked. But OpenAI has been trying to close compute deals with other providers — Oracle, Amazon, others — and the exclusivity kept blocking it. Now that's gone.

JOSH: Who blinked first?

ERIK: Probably OpenAI. They've been moving toward independence for two years. The Altman saga, the for-profit restructuring — they want to operate like a company, not a Microsoft division. Cutting the exclusivity and revenue share is that move made official.

JOSH: So Microsoft loses here?

ERIK: Not exactly. The enterprise install base isn't going anywhere. Copilot is in Word, Excel, Teams — hundreds of millions of users. Microsoft didn't bet the company on OpenAI. They bet part of it and got years of AI credibility in return. But the moat is smaller now. If GPT-5 runs on AWS just as well as Azure, the "you need Microsoft to get the best AI" pitch doesn't hold anymore.

[beat]

JOSH: What does this mean for someone building on these platforms right now?

ERIK: More competition, which is good for pricing. But it's also a reminder that no provider is stable infrastructure — they're all companies making business decisions. That's why routing matters. PrimeBus has had a model routing layer since day one. Every API call goes through the orchestrator. The orchestrator decides which model handles it. Right now I've got three Claude instances on the mesh — Neo, Bill, Homer. But the routing logic doesn't care what's underneath. If Anthropic has an outage or changes pricing, I update the routing config. Nothing in the application changes.

JOSH: How long did that take to build?

ERIK: Fifty lines of Python, a config file. A couple hours. Most builders skip it because it feels like extra work on day one. Then their provider changes terms and they're in a bad spot.

JOSH: And that's exactly what's happening right now.

ERIK: It's been happening. This Microsoft-OpenAI split is just the loudest version. Copilot's billing change today is the same story — provider decides the cost model doesn't work, terms change overnight. If you built assuming the terms were permanent, you're scrambling. Build like the terms will change. Because they will.

[pause]

JOSH: The Mercor breach. 40,000 AI contractors, 4 terabytes stolen. What makes this one different from a standard data breach?

ERIK: Two things. The data type — voice biometrics. Actual audio recordings of people's voices. And those recordings were paired with government-issued ID scans in the same dataset. That combination has never leaked at this scale before.

JOSH: Why does the pairing matter so much?

ERIK: Voice cloning by itself is already a nuisance. You can generate a convincing synthetic voice from a short clip. That's been true for a while. But you don't know whose voice it is. You can't target anyone specific. When you add verified identity to the audio, you know exactly who the voice belongs to. You can build a targeted attack. You call their bank. You call their employer. You get into phone-based verification systems that use voice as a factor. That's a completely different threat class.

JOSH: Is voice auth still being used at scale?

ERIK: More than it should be. Financial services, call centers, some government systems. And the pitch was always "only you have your voice." Now 40,000 people's voices are sitting in a leaked archive, attached to ID documents that confirm who each voice belongs to. That's a ten-year tail. Someone will use that data in 2031. The person won't know why their account got hit.

JOSH: What should someone do if they think they're in this breach?

ERIK: Audit every service that uses voice as an auth factor and swap it out. TOTP, hardware keys — anything but voice. Voice authentication was always the weakest second factor. This closes the argument. And don't sign up for any voice-biometric-as-payment systems. That trend needs to stop.

[beat]

JOSH: You work on identity in your own AI pipelines. Does this change anything for you?

ERIK: It reinforces something I've been thinking about with HumanRail. HumanRail routes AI decisions to a human when the model isn't confident enough to act. The whole premise is that the human in the loop is trustworthy — that they are who they say they are. These breaches are stacking up. Biometrics, identity scans, voice samples — all compromised at scale now. Verifying real humans in AI workflows is going to get harder, and the stakes are going up as these systems make real decisions. The next version of the routing logic has to account for that.

[pause]

JOSH: GitHub Copilot is moving to usage-based billing. What happened?

ERIK: Cursor happened. When Copilot launched, ten dollars a month made sense — it was autocomplete. People did a few tab-completions, called it a day. Now AI coding tools are running agentic sessions. Multi-file edits, long code generation runs that burn through tokens. The cost per heavy user shot up. Usage-based billing shifts that cost to the people who are actually consuming it.

JOSH: Is that fair?

ERIK: From GitHub's perspective, rational. From a builder's perspective, the predictability is gone. If you're shipping hard and running agentic sessions all day, you don't want to be thinking about compute costs per task. You want the flat rate.

JOSH: Would you pay for Copilot at the new rate?

ERIK: No. PrimeBus, ScanBrief, InkEngine — it's all direct Claude API with my own routing layer. That's where I live. Writing "The Autonomous Engineer" — 55,000 words in two days using InkEngine — that's not how Copilot works. But I'm an edge case. For someone who wants clean IDE integration without building any infrastructure, Copilot is still a reasonable tool. Just know what your actual usage looks like before you opt in. Some teams are going to get a very unpleasant invoice.

JOSH: Who should be most worried?

ERIK: Enterprise teams that issued Copilot licenses to 50 engineers and haven't looked at the bill since. That conversation is coming.

[beat]

ERIK: The real story is that coding assistants are commoditizing fast. The margin is collapsing. Usage-based is GitHub trying to capture value at the top of the curve before the race to zero finishes. Every month these tools get cheaper and more capable. Flat-rate pricing doesn't hold in that environment.

[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: Build a routing layer. One function that sits between your application and the model. You pass in the task type and the payload, the function decides which provider and which model handles it. Cheap fast tasks go to a smaller model. Complex reasoning goes to Opus. If a provider goes down or changes terms, you update the routing config — not your application. Nothing downstream breaks. I built this into PrimeBus in week one. In the past month I've had three separate API disruptions. None of them hit production because the router kept running. It is fifty lines of Python and one config file. You can write it this afternoon. 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.

The brainstorming skill doesn't apply here — the user provided a complete, prescriptive spec with all creative decisions already made. Proceeding directly to execution.

JOSH: It's Monday, April 27. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.

ERIK: An AI agent deleted a production database this week. Then it confessed. We need to talk about that.

JOSH: Stick around — Erik's got an AI pro tip at the end about the one thing most people skip before giving agents database access.

[pause]

JOSH: Three quick headlines to start. First — someone bought Friendster for thirty thousand dollars.

ERIK: For context, Friendster had 115 million users before Facebook ate it. The buyer is treating it as a brand play with nostalgia equity baked in. Thirty grand is cheap if any of that converts. Probably nothing. Could be smart.

[beat]

JOSH: Next — a runner just broke the two-hour marathon barrier in an actual competitive race.

ERIK: Sabastian Sawe. 1:59:30 in a sanctioned event. Kiptum held the record. Now he doesn't. Not a controlled lab setup — a real race. Worth noting.

[beat]

JOSH: And researchers turned up a 2006 Windows malware sample called Fast16 that used an embedded Lua scripting engine. Five years before Stuxnet.

ERIK: Stuxnet got the headlines because it hit a nuclear facility. But the technique — embedding a scripting VM inside malware so you can swap payloads without recompiling — that was already solved in 2006. Someone was running surgical sabotage tools before most people knew what an APT was.

[pause]

JOSH: OK, let's go deep on the one that actually keeps builders up at night. An AI agent deleted a company's entire production database. And then it apparently logged what looked like a confession. What actually happened here?

ERIK: The full post-mortem hasn't dropped, but the shape of the failure is familiar. Agent gets broad database access. Agent runs what it thinks is a cleanup task. Wrong environment. Everything gone. And the confession — that's just the agent writing its action log the way it was designed to. "I executed DROP TABLE on the following..." It looks dramatic. It's really just good logging on a catastrophic mistake.

JOSH: So it wasn't rogue. It was obedient.

ERIK: That's exactly it. The model did what it was told. Nobody was precise enough about what they were telling it. There's a category of mistake that isn't a model failure — it's an architecture failure. This is one of them.

JOSH: How do you guard against it in your setup?

ERIK: Three layers. First, every Claude session in my stack gets environment context injected at startup. The first thing any agent knows is whether it's running on prod, dev, or staging. Not as a suggestion in the prompt — hard context in the system header.

[beat]

ERIK: Second, destructive operations are not in the default permission set for any of my agents. Delete, drop, overwrite, send — those require explicit escalation. The agent can't decide on its own that it's confident enough to proceed.

JOSH: And the third layer?

ERIK: HumanRail. It's a system I built for exactly this. When an agent hits a decision threshold — anything irreversible, anything touching prod state — it pauses and files a review request. I approve or deny. The agent waits. There's no timeout that lets it proceed anyway.

JOSH: Doesn't that slow things down?

ERIK: About 22% of my auto-fix attempts get routed through human review before execution. The other 78% run clean. PrimeBus has 214 total auto-fixes at a 78% success rate. None of them have dropped a production table. The slowdown is the point. Fast is great until it's catastrophic.

[beat]

JOSH: That's a very different philosophy than move fast.

ERIK: Moving fast with irreversible operations is moving reckless. My lab has 64 projects running 229 cron jobs. If I hadn't built these guardrails in early, something would have gone wrong months ago. Probably spectacularly.

JOSH: The agent story becoming your story.

ERIK: Right. The difference is the guardrails were already there.

[pause]

JOSH: Second deep dive — SWE-bench Verified. This has been the standard for measuring AI coding ability. And now it's being retired as a frontier measurement. What happened?

ERIK: Saturation. Models got too good at it. When you can't reliably tell Claude from GPT-4o from Gemini on a benchmark, the benchmark stopped doing its job. The test ceiling is lower than the models' actual capability.

JOSH: Is that a good thing? Like, coding is solved?

ERIK: Not even close. SWE-bench tests a narrow slice — fix this isolated GitHub issue, patch this function given this context. Real engineering is holding a 300K-line codebase in context, making architectural tradeoffs, debugging something that only happens under load on specific hardware. No benchmark comes close to measuring that.

JOSH: So what do builders actually do with this?

ERIK: Stop outsourcing your evaluation to published benchmarks. What I care about is which model ships working code in my pipeline, on my codebase, with my context window constraints. That's the only benchmark that matters to me.

JOSH: How do you actually run that?

ERIK: PrimeBus A/B tests fix variants on every auto-fix attempt. It generates two approaches, runs both through the test suite, merges the winner. That's real evaluation. The model that produces working code in production wins. Not the one with the better paper number.

JOSH: You built your own benchmark.

ERIK: It's just outcomes. Every engineer should be doing this. Pick a task your team does repeatedly, run multiple models against it, measure results. More useful than any leaderboard.

[pause]

JOSH: There's a third story that ties all this together — "AI should elevate your thinking, not replace it." That seems obvious, but I don't think it is.

ERIK: The argument is that the real risk isn't AI taking your job. It's AI replacing the thinking that makes you good at your job. You use it to write the code, you stop understanding the code. You use it to design the system, you stop being able to defend the design. The skill atrophies quietly.

JOSH: Is that actually happening?

ERIK: Yes. I watch it in how people build with AI now. They paste the output, ship it, don't read it. Works fine until 2 AM when something breaks and they have no mental model for why. My setup has a discipline baked in — I read every generated file before it merges. Not because I distrust the models. Because I need to stay current with what's in my own codebase.

JOSH: You built a system that forces you to stay sharp.

ERIK: It's a weekly diff review. Thirty minutes. Every time I skip it, I'm slower to debug the next issue. The models are fast. I need to be fast enough to supervise them. That requires staying in the code.

[beat]

JOSH: And if you stop being able to supervise them?

ERIK: Then you're not an engineer. You're someone who runs prompts and hopes. The builders who come out ahead on the other side of this are the ones using AI as a multiplier on their own judgment — not as a substitute for it.

[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: Before any agent touches a real system, write down every action it needs to take. That list is its maximum permission set. Anything not on that list — denied by default. Most people give agents broad access and rely on the prompt to constrain behavior. That's not a guardrail. That's a suggestion. The permission layer is infrastructure, and you have to build it like infrastructure. Read operations — default allowed. Write operations — require explicit scope. Destructive operations — require a human gate. No exceptions. Doesn't matter how confident the model sounds, doesn't matter how clean the test run was. If an action would be catastrophic with the wrong target, a human approves it first. That's how you run 64 projects without losing a database.

[beat]

ERIK: That's your tip. Use it.

[pause]

ERIK: That tip is straight out of The Autonomous Engineer — my book on building systems that run themselves. Grab it on Amazon.

[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.

JOSH: It's Friday, April 24. This is Build or Be Replaced powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.

ERIK: Three stories today. One is useful, one is dangerous, and one is people confusing rumor with product.

JOSH: Stick around — Erik's got an AI pro tip at the end about getting better results by splitting thinking from doing.

[pause]

JOSH: First headline. DeepSeek v4 says it can drop into OpenAI and Anthropic workflows without a rewrite. Real story or marketing line?

ERIK: Real enough to matter. If your SDK calls keep working and the model swap is mostly config, teams test faster, and faster testing means cheaper model churn.

[beat]

JOSH: Next one. Anthropic had to address Claude Code quality reports. What happened?

ERIK: They had three separate issues, fixed them by April 20, reset limits, and tuned defaults. Translation: if your agent felt weird this week, it probably wasn't your prompt, it was the stack.

[beat]

JOSH: Third headline. Bitwarden CLI got pulled into a Checkmarx supply chain mess. Why should builders care?

ERIK: Because everybody trusts the security tool in the pipeline until the security tool becomes the threat. One poisoned dependency can turn your CI into a delivery truck for malware.

[pause]

JOSH: And the ones we’re not going deep on?

ERIK: GPT-5.5 is rumor bait until there’s an actual release. Meta cutting 10 percent tells you big tech is still trimming for margin while pretending it’s strategy. Ubuntu 26.04 looks solid, especially TPM-backed disk encryption, but that’s a weekend migration story, not a morning panic story.

[pause]

JOSH: Start with DeepSeek. Why did that one jump out to you?

ERIK: Because compatibility wins. Always. Nobody wakes up excited to rewrite every wrapper, every retry handler, every tool call, every model selector just to test one new model. If DeepSeek v4 can sit behind an OpenAI-style or Anthropic-style interface and behave close enough, builders will try it by lunch.

[beat]

JOSH: Close enough is doing a lot of work there.

ERIK: It is. API compatibility is not behavior compatibility. Big difference. You can match the endpoint, the auth pattern, the SDK shape, and still break workflows because the model thinks differently, formats differently, calls tools differently, or times out in different places.

[beat]

JOSH: So why are people excited?

ERIK: Because switching cost is where experiments go to die. In my lab I’ve got 64 projects running across two servers, neo and morpheus. I’m not rebuilding every pipeline because a model company says their vibes are better. I want a swap layer. PrimeBus pushes messages around the mesh, my agents subscribe, and I can change the model behind a service without detonating the rest of the system.

[beat]

JOSH: That’s how you keep shipping daily?

ERIK: Exactly. Loose coupling. Boring plumbing. Everybody wants the magical agent. Nobody wants to talk about the adapter layer that keeps the magical agent from setting the house on fire.

[beat]

JOSH: What does DeepSeek changing old model names tell you?

ERIK: It tells you they’re consolidating around modes instead of brands. Non-thinking and thinking modes under one family is cleaner operationally. Also dangerous if you’re sloppy. A lot of teams hard-code model names all over the place. Then the vendor renames one thing and half the scripts start throwing errors at 2:13 a.m.

[beat]

JOSH: You’ve seen that in the wild?

ERIK: Constantly. Different vendors, same movie. One of the reasons PrimeBus exists is to stop model naming from leaking into every corner of the system. My apps post intent. Summarize this. Classify this. Generate fix candidates. Review diff. The service that fulfills that intent chooses the model. Then if I want Claude for code review and another model for headline scoring, I change one service, not 19 apps.

[beat]

JOSH: What’s the practical takeaway for a small team?

ERIK: Stop binding business logic directly to a model string. Put a policy layer in front of it. Even if it’s a dumb JSON config on day one. `task_type: code_fix -> preferred_model: claude`, `task_type: short_summary -> preferred_model: cheaper_model`. That one move saves you later.

[beat]

JOSH: And if someone wants to try DeepSeek v4 this afternoon?

ERIK: Do it in a contained path. Pick one workflow. Something measurable. Don’t say, “we’re migrating the whole company.” That’s how grown adults create outages. Take one task like support ticket classification or first-pass summarization. Run the same 100 inputs across your current model and DeepSeek. Compare latency, token cost, formatting consistency, and how often a human has to fix the output.

[beat]

JOSH: Real numbers matter there.

ERIK: Always. In ScanBrief I score 396 items daily from 56 sources and deliver the brief at 6:30 a.m. If a model saves me money but misses the format window, it failed. If it’s brilliant but inconsistent with structured output, it failed. If it needs hand-holding every few calls, it failed. Cheap wrong answers are still expensive because now a human is doing cleanup.

[pause]

JOSH: Where does this land for people who feel the model market changes every five minutes?

ERIK: That feeling is correct. Vendors are sprinting. Your job is not loyalty. Your job is optionality. Build the lane change before you need the lane change.

[pause]

JOSH: Anthropic next. There were quality reports around Claude Code, the Agent SDK, and Cowork. For people who felt that but couldn’t prove it, what happened?

ERIK: The useful part is they acknowledged separate issues instead of one vague “we had an incident.” That matters. Different layers can fail at the same time. UI freezes, degraded code quality, weird behavior under high reasoning effort. They fixed the issues by April 20 and reset usage limits. That’s the operational story.

[beat]

JOSH: What’s the engineering story?

ERIK: Agentic systems are sensitive to defaults. People underestimate that. Change the default reasoning effort on a coding agent and you change latency, cost, completion behavior, tool usage, even whether the human thinks the model is “smart” or “broken.” Sometimes the model is fine and the orchestration is the problem. Sometimes the orchestration is fine and the default turned every task into a philosophical essay.

[beat]

JOSH: Wait, really?

ERIK: Really. I’ve watched agents go from useful to annoying because they started overthinking a file rename. Nobody asked for a dissertation on a test fixture. We asked for a patch.

[beat]

JOSH: How do you guard against that in your own setup?

ERIK: By separating roles. PrimeBus routes work based on task type. One Claude instance is better at code generation. Another is better at review. Another handles triage. Bob, Bill, Homer. Three Claude instances on the mesh. Same family, different jobs. If one starts acting strange, I can isolate the lane instead of wondering why the whole lab feels haunted.

[beat]

JOSH: That sounds like overkill for most people.

ERIK: It sounds like overkill until your single-agent setup quietly burns three hours and 400,000 tokens trying to solve the wrong problem. Then suddenly a little structure sounds very reasonable.

[beat]

JOSH: What do you mean by isolate the lane?

ERIK: Example. PrimeBus has 214 auto-fixes so far with a 78 percent success rate. Those are not random miracles. The system sees a failure, classifies it, generates A/B fix variants, runs tests, and only merges the winner. If code quality drops, I can inspect where. Was the diagnosis bad? Was the patch bad? Did the reviewer get too lenient? Did high-effort reasoning make it slower and not better? You want observability around the agent, not faith.

[beat]

JOSH: So when users said Claude Code felt off, you don’t treat that like whining.

ERIK: No. I treat it like a production report. Users notice degradation before dashboards do. Not always accurately, but fast. If ten builders say “it got weird,” pay attention. They live in the tool all day. They know the feel of it.

[beat]

JOSH: What should teams change after seeing this?

ERIK: Three things. First, pin important settings. Don’t let a vendor default decide your whole week. Second, log request class, model, effort level, latency, and outcome so you can compare before and after a provider change. Third, keep a fallback model path for critical work. If your coding agent goes sideways during a release, “we’ll wait for the vendor to sort it out” is not a plan.

[beat]

JOSH: That fallback path can be another provider?

ERIK: Yep. Or another mode. Or even another prompt strategy with the same provider. I don’t care what religion somebody has around models. What matters is whether work keeps moving.

[beat]

JOSH: Any good example from your systems?

ERIK: ScanBrief is simple on purpose. Gather. Dedup. Score. Summarize. Publish. If one summarizer degrades, I can still ship because the upstream pipeline is clean and the downstream formatting is rigid. Same with InkEngine. Writing a 55,000-word book in two days sounds flashy. What actually matters is checkpointing, chapter segmentation, review passes, and keeping the model from drifting off into fake confidence. Structure beats hype.

[pause]

JOSH: Last deep dive. Bitwarden CLI in a supply chain campaign. This one feels ugly.

ERIK: It is ugly. Supply chain attacks are ugly because they exploit trust, and trust is the whole point of the toolchain. People install a CLI like Bitwarden because it’s supposed to make secrets handling safer. Then a compromised dependency path or poisoned image turns that trust into exposure.

[beat]

JOSH: Break that down for the audience that doesn’t live in CI pipelines.

ERIK: Your build process pulls tools, containers, packages, extensions, scanners. You assume they’re clean because they’re common, or security-branded, or came from a source you used last month. An attacker only needs one path into that chain. Once they’re in, they don’t need to smash the front door. They ride your automation. Quietly.

[beat]

JOSH: Why does this keep happening?

ERIK: Because modern software factories are giant graphs of borrowed code and borrowed infrastructure. Fast teams automate everything, which is good. Fast teams also trust too much by default, which is bad. Same knife. Different direction.

[beat]

JOSH: What’s the first fix?

ERIK: Reduce blind trust. Pin versions. Verify signatures where possible. Mirror critical dependencies. Restrict outbound network access in CI. Don’t let every build container talk to the whole internet like it’s on vacation.

[beat]

JOSH: That sounds expensive.

ERIK: Less expensive than incident response. People will spend months building clever agents and zero days hardening the pipeline those agents depend on. That’s backwards. If your code assistant helps you write faster but your build chain is porous, you’ve automated the path to compromise.

[beat]

JOSH: You’ve got dry words for that, I assume.

ERIK: Fancy self-own.

[beat]

JOSH: That’s wild.

ERIK: It is. And it gets worse with AI wrappers because people install random extensions, random model CLIs, random helper scripts, random Docker images from accounts they discovered 14 minutes ago. Then they pipe secrets through them. That’s not experimentation. That’s volunteering.

[beat]

JOSH: What should a small shop actually do today?

ERIK: Inventory the tools in the path from commit to deploy. Not the ones you remember. The actual ones. Every action, every image, every package, every extension. Then rank them by blast radius. Secrets tools, build runners, deployment bots, artifact publishers. Those get the first hardening pass.

[beat]

JOSH: Any examples from your lab?

ERIK: I run 229 cron jobs. That means I’ve got 229 chances to do something dumb on schedule. So I keep secrets scoped tight, isolate jobs, and use guardrails around anything that can mutate state. PrimeTrader watches 109 tickers in three batches every market hour. If that pipeline breaks, I lose alerts. Annoying. If a secrets pipeline breaks, that’s a different category. You separate “inconvenient” from “catastrophic” fast.

[beat]

JOSH: How does HumanRail fit into this?

ERIK: HumanRail exists for exactly this kind of boundary. If confidence is low, or the action is risky, route to a human. People keep trying to remove humans from every step. Wrong target. Remove humans from the boring steps. Keep humans at the high-blast-radius junctions until you’ve earned enough confidence to automate more.

[beat]

JOSH: So the theme across all three stories is not “AI is magic.”

ERIK: Correct. The theme is interfaces matter, defaults matter, and trust boundaries matter. That’s the work. Fancy demos get headlines. Adapters, telemetry, and guardrails keep the business alive.

[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: Split thinking from doing. Don’t ask one model call to research, reason, code, review, and summarize in the same breath. That’s how you get mush. Make stage one produce a plan or a diagnosis. Make stage two execute one narrow task. Make stage three review against a checklist.

[beat]

ERIK: Same model or different models, doesn’t matter. What matters is the contract between stages. In my systems I’ll have one pass classify the failure, another generate two fixes, and a final pass judge the diff and test output. That’s a big reason PrimeBus got to 214 auto-fixes with a 78 percent success rate. The agent isn’t “smarter.” The workflow is cleaner.

[beat]

ERIK: If you’re building today, start small. Take one messy prompt and break it into three messages with explicit outputs. JSON if you can. Then log which stage failed. Once you can see the failure point, you can actually improve 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.

JOSH: It's Thursday, April 23. This is Build or Be Replaced powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.

ERIK: AI is getting cheaper, faster, and less careful. That's great right up until it touches prod.

JOSH: Stick around — Erik's got an AI pro tip at the end about stopping coding agents from rewriting half your repo.

[pause]

JOSH: First headline. Apple patched a bug that let cops pull deleted messages off iPhones. Bad bug, or normal bug?

ERIK: Bad bug. Deleted is supposed to mean deleted, not hanging around in notification cache for a month like old pizza in the office fridge.

[beat]

JOSH: Next one. Somebody said, "I am building a cloud." Crazy ambition or timely move?

ERIK: Timely. AWS, Azure, and GCP all got powerful, then annoying, then expensive. When builders get annoyed long enough, they start replacing the stack.

[beat]

JOSH: Third headline. AI coding tools are over-editing. Everybody's seen that. Why does it matter now?

ERIK: Because over-editing kills trust. If I ask for a one-line fix and the agent hands me 43 changed files, that's not help, that's paperwork.

[pause]

JOSH: Start with the cloud one. A founder says he's building a cloud because current cloud platforms are miserable. What's really underneath that?

ERIK: Simple. The hyperscalers won on capability, then they drifted into complexity taxes. Every year you get more services, more pricing weirdness, more policy layers, more YAML, more IAM edge cases, more "why is this bill four times higher than last month." Builders can take a lot. They hate feeling trapped.

[beat]

JOSH: You think this is more than a rant?

ERIK: Yeah. Not because building a cloud is easy. It's not. It's brutal. Hardware, networking, orchestration, billing, support, compliance, global edge, storage durability, the whole mess. But the demand is real because people want a cloud that feels like buying a tool, not negotiating with a casino.

JOSH: What does that mean for people not building a cloud from scratch?

ERIK: It means the market is tired of complexity theater. If you can offer one narrow thing that works cleanly, people will move. That's been true in networking forever. NSO won teams over because it made ugly device automation less ugly. Kubernetes got adopted because once you survive the learning curve, you can standardize a lot. The same thing can happen at the infrastructure layer if somebody strips away ten layers of nonsense.

[beat]

JOSH: Wait, really? You think teams will leave the big three for "boring but sane"?

ERIK: For the right workload, absolutely. Not all at once. Nobody is lifting a Fortune 500 out of AWS next week. But greenfield workloads, internal tools, batch jobs, AI inference, CI runners, dev environments, storage-heavy apps, sure. If the math is cleaner and the docs don't feel like a hostage note, people will try it.

JOSH: What's the builder angle here?

ERIK: Build smaller than your ego wants. That's the angle. "Cloud" sounds giant. But under it, you're really solving a set of pains. Compute that doesn't surprise people. Object storage without weird retrieval gotchas. Managed Postgres that doesn't fight you. GPU access that doesn't require a blood oath. Pick one.

[beat]

JOSH: That sounds like how you build your own stuff.

ERIK: Exactly. PrimeBus wasn't me trying to build some giant universal platform on day one. It started as a message bus because I got tired of scripts acting like lonely little islands. Now I've got three Claude instances on the mesh, events firing across systems, auto-healing, human fallback, all that. But it started with one pain: things breaking in silence.

JOSH: Put numbers on that.

ERIK: PrimeBus has handled 214 auto-fixes with a 78% success rate. Three Claude instances on the bus. Two servers in the lab. Sixty-four projects. Two hundred twenty-nine cron jobs. That whole setup works because the pieces are opinionated and simple enough to reason about. If I had built some giant "everything platform" first, it would've collapsed under its own ambition.

[beat]

JOSH: So when this founder says he's building a cloud, what's your test for whether it's real?

ERIK: Three things. One, does it remove an actual pain, not just mock AWS on a blog. Two, can a builder understand the product in five minutes. Three, can the bill be predicted by a human without opening a spreadsheet with seven tabs.

JOSH: Low bar, somehow hard to clear.

ERIK: That's because a lot of infra companies build for investors first and operators second. Operators want clarity. If the CPU costs X, say X. If outbound bandwidth costs Y, say Y. If a permission breaks a deploy, tell me exactly which one. Don't make me open a sacrificial goat and read CloudTrail.

[pause]

JOSH: Shift to Apple. They fixed a bug where deleted or disappearing messages could still be extracted. Why should regular people care?

ERIK: Because a lot of people think privacy settings are magic words. They're not. They're code paths. If the code path leaves residue in notification storage, then your disappearing message isn't disappearing. It's just hiding badly.

[beat]

JOSH: For people who don't live in logs and caches, what's the plain English version?

ERIK: You get a message. The phone shows a notification preview. That preview data can stick around even after the app thinks the message is gone. If investigators can access the device and the cache is still there, they can recover stuff you assumed was dead. That's the problem.

JOSH: That's wild.

ERIK: It's also common. Systems leak through side channels all the time. Main database says one thing. Logs say another. Metrics leak timing. Notification services retain copies. Search indexes keep old text. Engineers say "delete," but the architecture says "best effort."

JOSH: Does this change how people should use disappearing messages?

ERIK: It should change how much confidence they place in them. They're useful. They're better than nothing. But if your mental model is "this message self-destructs like a movie prop," that's fiction. Real systems have caches, retries, backups, and weird corners.

[beat]

JOSH: What does this mean for teams building apps?

ERIK: Treat deletion as a system-wide requirement, not a feature toggle in the UI. Map every place the data touches. Primary store. Secondary store. push notification content. local device caches. logs. analytics events. screenshots. exports. backups. If you don't do that, you're shipping false promises.

JOSH: You're saying privacy bugs are architecture bugs.

ERIK: Usually, yes. Same with security. People look for one dramatic exploit. A lot of the real damage comes from ordinary leftovers. Old files in S3. Debug logs with tokens. A Redis key with no expiry. Temporary screenshots sitting in a support bucket. Death by "we meant to clean that up later."

[beat]

JOSH: How do you handle that in your own systems?

ERIK: Two ways. First, I don't collect what I don't need. That cuts your blast radius fast. Second, when data has a short shelf life, I treat expiry like a first-class path. HumanRail is a good example. If a model isn't confident and I route work to a human, I need the right context, but not forever. That's a workflow object, not a family heirloom.

JOSH: Give me a concrete one.

ERIK: ScanBrief pulls 396 items a day from 56 sources. I care about ranking, deduping, summaries, timestamps, source links, and delivery. I do not need random long-term junk hanging around forever just because storage is cheap. Cheap storage creates expensive sloppiness.

JOSH: And for consumers?

ERIK: Update your phone. That's the boring answer and the correct one. Also stop assuming "deleted" means every copy vanished in every layer. It means the vendor hopefully fixed the obvious path this week.

[beat]

JOSH: That's not comforting.

ERIK: Security rarely is. Comfort is what marketing gives you. Engineering gives you threat models.

[pause]

JOSH: Last deep dive. Over-editing in AI coding tools. Everybody complains about it. What are you seeing?

ERIK: I see agents trying to be heroes. That's the disease. You ask for a failing test fix. The model decides the real issue is your architecture, style guide, file layout, naming scheme, and childhood. Then it rewrites half the repo and expects applause.

[beat]

JOSH: Why is that happening?

ERIK: Training pressure and product pressure. Models get rewarded for looking useful. Big diff looks useful if you don't measure pain correctly. But the operator pain is review time, regression risk, and merge conflict debt. The best fix is usually the smallest one that closes the issue cleanly.

JOSH: So a flashy diff is often a bad diff.

ERIK: Most of the time, yeah. In production work, restraint matters. When PrimeBus fires an auto-fix path, I don't want the agent expressing itself. I want it acting like a surgeon with a small blade and a good map.

JOSH: How do you keep that under control?

ERIK: Guardrails. Tight task framing. File scope limits. Diff size expectations. Test gates. And you score the agent on mergeability, not creativity. That's the big one.

[beat]

JOSH: Break that down.

ERIK: If you ask an agent, "Fix the build," that's too wide. It hears permission to renovate. Better prompt is, "Fix the failing test in this file. Do not touch unrelated modules. Keep the patch under 30 lines unless a test proves more is needed. Explain root cause in one sentence." Now it has walls.

JOSH: Does that actually work?

ERIK: Way better than vague prompts. Not perfect. But better. PrimeBus does this with A/B fix variants. When a test fails, it generates candidate repairs, runs validation, and keeps the winner. Two hundred fourteen auto-fixes so far. Seventy-eight percent success rate. Those numbers do not come from giving the model a blank check.

JOSH: That's the thing people miss, right? They want full autonomy with zero guardrails.

ERIK: Yep. Then they act shocked when the model trashes a config file, rewrites imports, and updates comments nobody asked about. Agentic coding is not "send it and pray." It's routing, policy, evaluation, and rollback.

[beat]

JOSH: How does this compare to a human engineer making broad changes?

ERIK: Humans over-edit too. Senior engineers can be just as guilty. You ask for a bug fix, they sneak in a framework opinion. Difference is humans understand team context better and can usually explain the trade. Models often can't tell useful cleanup from ego cleanup.

JOSH: Ego cleanup is a good phrase.

ERIK: Seen a lot of it. "While I was here, I improved everything." No, you increased the surface area of review and made `git blame` look like a crime scene.

JOSH: What does good look like then?

ERIK: Good looks boring. Small patch. Clear intent. Tests pass. No unrelated churn. If a broader refactor is truly needed, separate it. Different commit. Different review. Different conversation.

[beat]

JOSH: And for people using tools like Claude or other agents every day?

ERIK: Make the model earn trust in layers. Start read-only. Then let it propose patches. Then let it patch in a branch. Then maybe let it auto-merge on very narrow categories after it proves itself. That's how I work in the lab. Small blast radius first. Lesson learned, more guardrails, then wider permission. That's why I don't have big disasters. I don't skip the proving ground.

JOSH: You say that a lot. Lab first.

ERIK: Because it works. Neo and Morpheus exist for a reason. Two servers. Cheap compared to prod mistakes. I test the workflow, test the rollback, test the bad prompt, test the weird edge case. Then I trust it more. That's engineering. The people getting burned are often trying to jump straight from demo to autonomy.

JOSH: So the real story isn't "AI over-edits." It's "people gave it too much room."

ERIK: That's a big part of it. The other part is tool design. Editors and coding agents should expose patch previews, intent summaries, file scope controls, and hard stop policies by default. If your tool hides the blast radius, it's helping the wrong user. It should help the reviewer, not just impress the person in the demo clip.

[beat]

JOSH: Does this get better soon?

ERIK: Yeah. Models are improving, but the bigger win will come from better wrappers around them. Better policies. Better evals. Better eventing. Better handoff between agents and humans. Raw model intelligence matters. The workflow around it matters more.

JOSH: That's basically your whole playbook.

ERIK: Pretty much. PrimeBus for event routing. HumanRail for uncertainty. ScanBrief for signal filtering. InkEngine for production workflow. Same pattern every time. Don't ask the model to be magic. Put it in a system and make the system keep score.

[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: Put a hard ceiling on edit scope before the agent writes a single line. Tell it the exact files it can touch, the max diff size, and the acceptance test it has to satisfy. Then make it explain the root cause in one sentence before it generates the patch.

[beat]

ERIK: That one sentence matters. If the model can't explain the bug cleanly, it probably doesn't understand the bug. And if it doesn't understand the bug, it's about to start redecorating your repo.

[beat]

ERIK: In Claude, Codex, whatever you're using, prompt like this: "Only edit these files. Keep changes minimal. Do not refactor unrelated code. If you believe broader changes are required, stop and explain why first." That cuts a lot of nonsense immediately.

[beat]

ERIK: Also split "diagnose" from "patch." First ask for the likely cause and smallest fix. Then ask for the patch. Two steps beats one when you care about precision. That's your tip. Use it.

[pause]

JOSH: Track your freedom score and net worth with the Freedom Blueprint app — free download, link in the show notes.

[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.