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

ERIK: Trust is the new attack surface. Code, auth, storage, agents. Same story, different door.

JOSH: Stick around — Erik's got an AI pro tip at the end about using agents without giving them the keys to the building.

[pause]

JOSH: ScanBrief scored 104 items across 54 sources today. First headline: a researcher found 10,000 GitHub repositories distributing Trojan malware. Erik, how bad is that?

ERIK: Bad, but not surprising. Attackers figured out that cloned repos with clean-looking history feel safer than random zip files, so now the supply chain is the payload delivery system.

JOSH: Next up, Zero-Touch OAuth for MCP. That sounds boring until you realize every company is trying to plug agents into internal tools.

ERIK: Exactly. Enterprise-Managed Authorization for MCP means identity lives with the company, not in every little app consent screen. That's the right direction if agents are going to touch real systems.

JOSH: Third headline: Ubiquiti announced an enterprise NAS built on ZFS. Why did that jump out?

ERIK: Because storage vendors love turning basic reliability into a licensing maze. ZFS is boring in the best way. Checksums, snapshots, replication. Give me boring storage every day.

[pause]

JOSH: Let's start with the GitHub malware story. Ten thousand repos is a big number. What's actually happening there?

ERIK: The trick is simple. Clone a real project. Keep the same name. Keep the description. Keep the commit history. Make it look like normal open source. Then change the README so it points people at a zip file with malware in it.

[beat]

ERIK: That's nasty because humans are pattern matchers. We see stars, commits, familiar project names, and our brain says, fine, this is probably okay. The attacker doesn't need to break GitHub. They just need to look enough like GitHub.

JOSH: Wait, really? That's enough?

ERIK: For a lot of people, yes. Especially when they're moving fast. Developer searches for a library, finds a repo, copies the install instructions, runs a command, and now the machine is part of the story.

JOSH: So the weak point isn't GitHub itself. It's the habit.

ERIK: Right. The weak point is trust by vibes. That's not a security model. That's a coin flip with syntax highlighting.

[beat]

JOSH: How do you defend against that without making developers hate their lives?

ERIK: You put checks in the path where work already happens. Don't ask everyone to become a malware researcher before lunch. Use dependency pinning. Verify package origins. Block random archive downloads in build steps. Require signed releases where you can. Scan READMEs for external binary links if your org pulls from GitHub at volume.

JOSH: Scan the README?

ERIK: Absolutely. The README is part of the attack path now. If a repo says, hey download this release zip from a weird domain, that's not documentation. That's a flare.

JOSH: How would you wire that into your setup?

ERIK: PrimeBus already treats events like first-class citizens. Today it processed 793 automation events across 12 projects. That means I don't need every tool to know about every other tool. A repo scanner can emit an event that says, suspicious external archive link found. Gandalf can review it. A policy agent can block the build. A human only gets pulled in when the system can't make a clean call.

[beat]

ERIK: That's the pattern. Events first. Agents subscribe. Guardrails decide. Humans handle the weird stuff.

JOSH: That sounds very enterprise. But your lab is not a giant company.

ERIK: That's the point. You don't need a giant company to need real controls. I have 121 services running on the production server right now. If I let every service pull random code from random places, I'm not building automation. I'm building a haunted vending machine.

JOSH: That's the dry version of a breach report.

ERIK: Pretty much.

[beat]

JOSH: Where does AI make this worse?

ERIK: Code agents will happily follow instructions from poisoned repos if you let them. If an agent reads a README that says run install.sh, and your prompt says follow the repo instructions, congrats. You gave malware a product manager.

JOSH: That's grim.

ERIK: It's accurate. Agentic coding changes the blast radius. A junior dev might hesitate before running a weird script. An agent won't hesitate unless you gave it policy, sandboxing, and a reason to stop.

JOSH: So what's the rule?

ERIK: Agents can read almost anything. They should execute almost nothing by default. Especially shell scripts, install scripts, package postinstall hooks, Dockerfiles from unknown repos, and anything that reaches outside the repo during build.

[pause]

JOSH: That leads right into the MCP OAuth story. For people who aren't buried in agent tooling, what's MCP in plain English?

ERIK: MCP is a way for AI tools to connect to other tools. Files, databases, Slack, GitHub, cloud APIs, internal systems. It gives the model hands.

JOSH: And OAuth is the permission part.

ERIK: Yep. OAuth is how the app gets permission to do things on your behalf. The problem is, when every MCP server asks every user for consent, you get a pile of prompts, tokens, scopes, and weird little trust decisions that no normal person wants to make.

JOSH: So Zero-Touch OAuth removes that?

ERIK: It moves the decision where it belongs. Enterprise-Managed Authorization means the organization controls access through the identity provider. The user doesn't approve every little connection. The company says this group can use this MCP server with these scopes under these conditions.

[beat]

JOSH: That sounds like what IT has wanted all along.

ERIK: It is. And it's necessary. If agents are going to touch ticketing systems, routers, Kubernetes clusters, CRM records, invoices, or production databases, consent prompts are not governance. They're theater.

JOSH: What's the danger if companies skip this?

ERIK: Tool sprawl. Token sprawl. Unknown agents with unknown access. Someone connects a desktop AI client to a sensitive MCP server, grants broad permissions, leaves the company, and nobody knows which token is still alive.

JOSH: That's the nightmare version.

ERIK: That's the normal version if nobody designs the system. I've seen this movie with API keys, SSH keys, service accounts, Jenkins credentials, Terraform state, NSO credentials. Different decade, same mess.

[beat]

JOSH: How would you build it?

ERIK: Start with identity. Groups, roles, scopes. Then split tools by risk. Low-risk tools can read docs or search tickets. Medium-risk tools can open pull requests or draft changes. High-risk tools can touch prod only through a controlled workflow.

JOSH: Not direct access.

ERIK: Never raw direct access for serious systems. If an agent wants to change a router config, it should propose the change, run validation, compare intent, check blast radius, and then hand it to a controlled pipeline. Cisco NSO does that style of thing well because intent and service models matter. Terraform does it with plans. Kubernetes does it with admission control. Same philosophy.

JOSH: Where does PrimeBus fit into that?

ERIK: PrimeBus is the control plane for my agents. Eleven agents in the Bobaverse fleet emit and consume telemetry. Neo, Homer, Bill, Echo, Gandalf, Claude plus GPT. That sounds cute until you realize the important part is the bus, not the names.

[beat]

ERIK: Every action becomes an event. Every event can be reviewed. One code change was automatically reviewed by Gandalf and merged to production overnight. That only works because the pipeline has gates.

JOSH: And the live stats say 697 merged, 368 blocked by Gandalf, 0 escalated to you since June 5.

ERIK: That's the story. The blocked count matters. People hear blocked and think failure. No. Blocked means the guardrail worked. Zero escalated to me means the system either had enough confidence to merge or enough sense to stop.

JOSH: That's a very different way to measure automation.

ERIK: Most people measure how much the robot did. I care how much damage the robot didn't do.

[pause]

JOSH: Let's hit the Ubiquiti NAS story. ZFS in an enterprise NAS from Ubiquiti. Why does that matter to builders?

ERIK: Storage is where good intentions go to die. You can rebuild an app. You can redeploy a service. Lose the data and suddenly everyone finds religion.

JOSH: That's the quote.

ERIK: ZFS matters because it assumes disks lie. It checksums data. It can detect corruption. It can snapshot. It can replicate. It gives you primitives that make sense when you care about uptime and recovery.

JOSH: And Ubiquiti is making that more accessible?

ERIK: That's the interesting part. Enterprise storage has been wrapped in proprietary hardware, support contracts, and license tiers forever. Ubiquiti coming in with a ZFS-based NAS says the boring reliable stuff should be easier to buy and manage.

[beat]

JOSH: Does that replace the big storage vendors?

ERIK: Not everywhere. If you're a bank with petabytes and compliance teams, you're not ripping everything out because a new box looks cool. But for labs, small businesses, agencies, edge sites, schools, and teams that need sane storage without selling a kidney, this is useful.

JOSH: How do you think about storage in your own systems?

ERIK: Backups first. Then snapshots. Then replication. Then restore testing. People love to talk about backup products. I care about the restore. If you haven't restored it, you don't have a backup. You have a bedtime story.

JOSH: That's painfully true.

ERIK: My PAS website-pipeline is a good example. It can build and maintain sites autonomously, but the boring part matters more than the flashy part. Source control. Artifact storage. Rollback. DNS records. Logs. If the agent makes a bad change, I need to roll back fast and know exactly what happened.

[beat]

JOSH: So this connects back to agents again.

ERIK: Everything connects back to agents now. An agent can generate content. It can change configs. It can build a site. BookForge can push edits through a multi-book backend. That's powerful. But if storage, identity, and audit trails are weak, the agent becomes the fastest way to make a mess.

JOSH: Is that why you keep saying infrastructure is the product?

ERIK: Yes. The UI is what people see. The infrastructure is what decides whether you sleep. Real builders care about queues, logs, state, rollback, and permissions. That's where the money is.

JOSH: Where does ScanBrief fit in?

ERIK: ScanBrief is the radar. It scored 104 items across 54 sources today, but the point isn't the count. The point is signal. It shows me what changed. Then I decide what belongs in the stack, what belongs in the trash, and what belongs in tomorrow's automation.

[beat]

JOSH: So today's pattern is trust, but across three layers.

ERIK: Exactly. GitHub malware is trust in code. MCP OAuth is trust in tools. ZFS NAS is trust in data. Same question every time: what do you trust, why do you trust it, and what happens when it lies?

JOSH: That's a clean way to frame it.

ERIK: Builders need to stop treating trust like a feeling. Trust is something you instrument. Logs. Checks. Policies. Reviews. Rollbacks. If you can't observe it, you don't trust it. You hope it behaves.

[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: Give your coding agent a deny list before you give it a task. Not after. Put it in the system prompt or repo instructions.

[beat]

ERIK: Say this clearly: do not run remote install scripts, do not curl pipe to shell, do not modify production secrets, do not change CI permissions, do not add broad OAuth scopes, and do not execute files downloaded from unknown repos.

JOSH: That's pretty specific.

ERIK: Specific is the point. Vague safety prompts are decoration. Give the agent concrete forbidden actions, then make it explain when it needs an exception. If it needs to run something risky, it should stop and ask. Same as a junior engineer with root access.

[beat]

ERIK: Bonus move: log every blocked action. Those logs become your policy backlog. If agents keep trying the same risky move, fix the workflow, don't just yell at the model. 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, June 18. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.

ERIK: Local models are not toys anymore. They're shop tools. You don't use a chainsaw to tighten a rack screw.

JOSH: Stick around — Erik's got an AI pro tip at the end about using cheap local models without letting them wreck your repo.

[pause]

JOSH: First headline. Local Qwen isn't a worse Opus, it's a different tool. Is that the right framing?

ERIK: Yeah. That's exactly right. A local Qwen model is not Claude Opus with fewer vitamins. It's a low-cost worker you can point at bounded jobs, especially when the task is repetitive and the blast radius is small.

JOSH: Next up, Firecracker VMs inside EC2 starting browsers in less than a second. Why do builders care?

ERIK: Browser automation is usually slow, heavy, and kind of rude to your infra. If you can spin clean browser sandboxes that fast, Selenium-style workloads get way more practical for scraping, testing, and agent work.

JOSH: Third headline. RFC 10008, the new HTTP Query Method. New HTTP verbs don't happen every morning.

ERIK: Correct. This one matters because people have been abusing GET and POST for query workloads forever. QUERY gives APIs a cleaner way to say, this request is asking, not mutating.

[pause]

JOSH: The Qwen story feels like the one people are arguing about. Everybody wants to know if local models are actually useful.

ERIK: Useful, yes. Magical, no. That's where people mess it up.

[beat]

ERIK: I run Hermes locally on a Mac M3 with qwen3-coder around 70 tokens a second. That doesn't mean I hand it the keys to PrimeBus and go make coffee. It means I give it bounded work. Read this file. Propose a test. Summarize this failure. Find the dumb thing in this log.

JOSH: So it's not replacing Claude for the hard stuff.

ERIK: Not in my shop. Claude still gets the complicated reasoning. The architectural calls. The scary edits. The stuff where I want a model that can hold the whole shape of the problem.

[beat]

ERIK: But local Qwen is perfect for grunt work. It doesn't need to call home. It's cheap once the hardware exists. It can chew on logs, diffs, stale tickets, docs, test output, and boring conversion jobs all day.

JOSH: What's the catch?

ERIK: Reliability. Local models can loop. They hallucinate. They get weirdly confident. They can repeat themselves like a broken cron job with a caffeine problem.

[beat]

ERIK: That's fine if you design for it. You don't ask the model, please be good. You put it in a lane. You set a timeout. You cap tokens. You validate output. You make it produce JSON if JSON is what the next step expects. Then you reject garbage.

JOSH: That sounds less like chatting with AI and more like managing workers.

ERIK: Exactly. That's the whole point. Agentic systems are not one big brain. They're a bunch of small workers with contracts.

[beat]

ERIK: PrimeBus processed 799 automation events across 11 projects today. That doesn't work because one agent is smart. It works because events are typed, handlers are scoped, and bad output gets blocked before it hits prod.

JOSH: And Gandalf is the guardrail there?

ERIK: Yeah. Gandalf is the reviewer. The PrimeBus auto-merger has run 992 attempts since 2026-06-05: 665 merged, 327 blocked by Gandalf, 0 escalated to Erik. That's the number I care about.

JOSH: Zero escalated is kind of wild.

ERIK: That's the point. The blocked count is not failure. The blocked count is the system doing its job. If an agent makes a bad patch and Gandalf rejects it, that's not drama. That's Tuesday.

JOSH: How would a normal team use local models tomorrow?

ERIK: Start with logs and tickets. Don't start with autonomous code changes. Take your NOC alerts, your CI failures, your incident notes, your Jira noise, whatever you have. Have a local model classify them into buckets.

[beat]

ERIK: Then make it explain why. Then compare the output to a human sample. If it's good enough, wire it to a bus. NATS is fine. Redis streams are fine. Even a queue table works if you're not fancy.

JOSH: Where does it cross the line into dangerous?

ERIK: When the model can mutate state without a second system checking it. That's the line. Reading logs is cheap. Opening a pull request is higher risk. Merging is higher again. Touching production config is the big boy table.

[beat]

ERIK: In networking, I learned this with Cisco NSO years ago. You don't blast config because a parser smiled at you. You dry-run. You diff. You validate service intent. You check device response. AI doesn't change that discipline. It makes it more important.

[pause]

JOSH: The Firecracker browser story feels related. Fast, disposable environments for browser automation.

ERIK: Yep. This is infrastructure for agents. People think AI agents are prompts. They're not. They're prompts plus tools plus isolation plus audit trails.

JOSH: Why are browsers such a pain?

ERIK: Browsers are messy. They're heavy. They store state. They leak cookies. They get fingerprinted. They crash in ways that make you question your career choices.

[beat]

ERIK: If you're running Selenium or Playwright at any volume, you need clean sessions. You need predictable startup. You need to know one job didn't poison the next job. Firecracker is interesting because microVMs give you stronger isolation than a normal container, but with startup times that can still be practical.

JOSH: Less than one second matters that much?

ERIK: It matters a lot. If a browser sandbox takes thirty seconds to start, you design around scarcity. You reuse sessions. You pool things. You tolerate weird state because clean is too expensive.

[beat]

ERIK: If it starts under a second, you can burn it after each job. That's a different operating model. Clean room every time.

JOSH: Where would you use that?

ERIK: PrimeDistro-style work. Scrape Google Maps. Check business sites. Render pages. Generate previews. Confirm a form exists. You don't want one bad session dragging cookies and fingerprints into the next hundred businesses.

JOSH: And ScanBrief?

ERIK: Same idea. ScanBrief scored 100 items across 54 sources today. Most feed work is clean. RSS, APIs, HTML fetches. But some sources need a real browser because the web decided simple documents were too generous.

[beat]

ERIK: Fast browser sandboxes help there. Pull the page, extract the article, kill the browser. No mystery state. No stale login. No haunted profile directory.

JOSH: You said agents aren't prompts. This feels like the missing piece.

ERIK: It is one of them. The other missing piece is eventing. An agent should not be a cron job with a personality. It should subscribe to events, do one job, write back a result, and get out.

[beat]

ERIK: In the Echo and Neo lab, that pattern matters. There are 11 agents in the Bobaverse fleet, Claude plus GPT, with Neo, Homer, Bill, Echo, Gandalf all doing different work. If they all shared one browser, one shell, and one working directory, that would be a fire drill pretending to be architecture.

JOSH: So isolation is not just security. It's sanity.

ERIK: Correct. Security people say isolation and everyone nods. Builders should hear repeatability. Can I run the same task ten times and get the same kind of result? Can I kill it without killing the system? Can I prove what happened after it fails?

JOSH: What should teams watch for?

ERIK: Cost and complexity. Firecracker is cool, but don't cosplay as AWS if a container gets you there. Use microVMs when the isolation actually buys you something.

[beat]

ERIK: Browser jobs from untrusted targets? Good candidate. Running tests against random pull requests? Good candidate. Internal report generation from clean data? Maybe a container is fine.

JOSH: That's the Erik version of architecture advice.

ERIK: Yeah. Pay for the boring thing that solves the actual problem. Don't buy a forklift to move a sandwich.

[pause]

JOSH: Let's hit HTTP QUERY. That sounds dry, but you flagged it.

ERIK: New HTTP methods are dry until you run a pile of APIs and realize everyone has been lying through POST for twenty years.

JOSH: What problem does QUERY fix?

ERIK: GET is supposed to be safe and cacheable, but it has awkward limits. Query strings get huge. Complex filters get ugly. People stuff JSON into URLs. Then POST becomes the escape hatch, even when the request doesn't change anything.

[beat]

ERIK: QUERY says, this is a query. It can have a body. It can be safe. It gives API designers a cleaner semantic box.

JOSH: Why does that matter for automation?

ERIK: Because automation systems care about intent. A bot needs to know if a call is safe to retry. Can I replay this? Can I cache it? Can I run it during a partial outage? Can I let an agent call it without fear that it creates a customer record or reboots a router?

JOSH: POST doesn't tell you that.

ERIK: POST tells you almost nothing. It says, something happened, good luck.

[beat]

ERIK: In network automation, intent is everything. An NSO dry-run is not the same as a commit. A device check is not the same as a config push. If your API semantics blur that line, your agents have to guess. I hate guessing in systems.

JOSH: Would you actually adopt QUERY right away?

ERIK: Internally, maybe. Public API, slower. Tool support always lags. Proxies, gateways, SDKs, auth middleware, logging stacks, all of that has to understand it.

[beat]

ERIK: But I like the direction. The web needs better primitives for machine callers. Humans click buttons. Agents inspect contracts.

JOSH: That's a big shift.

ERIK: It is. We are moving from APIs designed for app teams to APIs used by autonomous workers. Those workers need clear verbs, schemas, idempotency, trace IDs, and permission boundaries.

JOSH: Where does Lore fit into this? The scalable version control story.

ERIK: Same theme. The old tools are under pressure. Git is amazing. I love Git. But giant repos, binary assets, model weights, CAD files, big generated artifacts, all of that pushes Git into places it wasn't built for.

[beat]

ERIK: Lore being open source and aimed at massive codebases is worth watching. Same with open-source AI CAD. Builders are trying to rebuild the boring foundations because AI workloads are exposing the cracks.

JOSH: That's not as flashy as a new chatbot.

ERIK: Good. Flashy is usually where budgets go to die.

[beat]

ERIK: Version control, browser isolation, local model routing, event buses, API semantics. That's the stuff that decides whether AI is a demo or a factory.

JOSH: A dark factory?

ERIK: Yeah. A dark factory. Systems run. Events flow. Agents pick up work. Humans approve the weird stuff. The rest just happens.

[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: Use local models as pre-reviewers, not final decision makers.

[beat]

ERIK: Here's the setup. Take every pull request or config change and run a cheap local model first. Ask for three things only. What files changed. What risk category it sees. What tests or checks should run.

JOSH: Why not ask it to fix the code too?

ERIK: Later. First make it useful without giving it a wrench.

[beat]

ERIK: Have it output strict JSON. Something like risk low, medium, high. A short reason. A list of commands. Then your real pipeline decides what to do. Low risk runs normal tests. Medium adds targeted checks. High risk routes to Claude or a human.

JOSH: So the local model becomes a filter.

ERIK: Exactly. Cheap triage. No trust required. If it says nonsense, reject it. If it times out, continue with the default path. If it helps, you saved tokens and caught obvious stuff earlier.

[beat]

ERIK: The key is this. Never let the weakest model be the authority. Let it be the scout. Scouts are useful because they look ahead. They don't get to merge to prod.

[beat]

ERIK: 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, June 17. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.

ERIK: Local models are finally useful, security people are yelling about JWTs again, and PrimeBus processed 750 automation events across 13 projects today while I drank coffee.

JOSH: Stick around — Erik's got an AI pro tip at the end about using local models without turning your laptop into a space heater.

[pause]

JOSH: First headline. GrapheneOS has been ported to Android 17. Privacy phone people are probably happy, but why should builders care?

ERIK: Because mobile security matters again. Android keeps getting more locked down, and GrapheneOS usually pushes the hardening further. If you carry production access in your pocket, that pocket is part of your infrastructure.

JOSH: Second headline. Running local models is good now. The claim is that Gemma 4-class local models are landing around 75 percent of frontier model usefulness for coding tasks. Wait, really?

ERIK: Yeah, and that number feels believable for bounded work. Not for every task. But for lint fixes, test repair, small refactors, log summarization, and local code search, local models are crossing the line from toy to tool.

JOSH: Third headline. Stop using JWTs. That headline comes back every few months like a bad login cookie.

ERIK: It does, and sometimes it's right. JWTs are fine when you understand revocation, audience, expiry, signing keys, and storage. Most teams don't. They use JWTs because a tutorial said stateless auth was clean, then they spend two years rebuilding sessions badly.

[pause]

JOSH: The local model story feels like the biggest one today. For years, local AI was fun, but the real work happened through Claude or GPT APIs. What's changed?

ERIK: The gap got small enough for boring work. That's the change. Nobody needs a local model to write the next Kubernetes controller from scratch while blindfolded. That's not the point. The point is that a model running on your own machine can now do useful maintenance work without sending every file, log, and stack trace across an API.

[beat]

ERIK: That's a big deal for engineering teams. There are whole categories of work where the model doesn't need genius. It needs context, repetition, and permission to act. Read this test failure. Compare it to the last passing run. Suggest the two-line fix. Check the changelog. Draft the PR note. That is where local models are getting good.

JOSH: So it's less about replacing frontier models and more about moving the cheap work closer to the machine?

ERIK: Exactly. Frontier models are still where I go for architecture, gnarly debugging, and agent planning. Claude is still my daily driver. But I don't need Opus-level reasoning for every little thing. If a local model can triage logs, classify events, and prepare a patch candidate, then the expensive model only touches the parts that need judgment.

JOSH: How would that fit into your setup?

ERIK: PrimeBus is the obvious place. It already has agents watching events, failures, warnings, deploy signals, test results, all of it. Today the bus processed 750 automation events across 13 projects. Not all of those need a frontier model. A lot of them need a fast first pass.

[beat]

ERIK: Local model sees an event. It says, this is noisy, ignore it. Or this looks like a dependency issue. Or this belongs to PrimeRestorer because the S3 backup check failed. Then it can enrich the event before it hits Claude. That means fewer tokens, faster routing, and less junk going into the expensive brain.

JOSH: That's the part people miss, right? They compare model to model instead of workflow to workflow.

ERIK: Yep. Builders get stuck asking, is this model better than Claude? Wrong question. Ask what job it can own. If a local model can handle 30 percent of the event stream before Claude sees it, that matters. If it can write a first draft of a fix that Gandalf reviews, that matters. Overnight, 2 code changes were automatically reviewed by Gandalf and merged to production. That's the pattern. Cheap agent proposes. Strong reviewer decides. Guardrails block the dumb stuff.

JOSH: And privacy is part of it too?

ERIK: Huge part. Local models are perfect for sensitive logs. Network configs. Customer names. Internal IPs. Cisco NSO service payloads. Terraform plans. Stuff you don't want copied into random tooling because somebody got excited on a Tuesday.

[beat]

ERIK: In network automation, config context is everything. Interface names, route policies, device groups, service templates. A local model can summarize and classify that locally. Then if you need Claude, you send the smallest useful slice. That's just good engineering.

JOSH: Is there a trap here?

ERIK: Plenty. People will overtrust local models because they feel private. Private doesn't mean correct. A bad answer on your laptop is still a bad answer. Local models need tight jobs, tight prompts, and tests. Especially tests. If your agent writes code and you don't have tests, you didn't build automation. You built a slot machine.

[pause]

JOSH: Let's connect that to the GrapheneOS story. Android 17 support sounds like a phone thing, but you called the phone part of the infrastructure.

ERIK: Because it is. Builders love talking about servers, clusters, pipelines, and agents. Then they approve production changes from a phone with six years of app cruft on it. That's backwards.

JOSH: That's a little uncomfortable.

ERIK: Good. It should be. Your phone has email, Slack, GitHub, cloud console access, password manager, MFA prompts, SSH apps, maybe even your VPN. If that device is weak, your beautiful Kubernetes setup is wearing a paper hat.

[beat]

ERIK: GrapheneOS matters because it treats the phone like a hostile environment. Sandboxed Google Play, hardened memory allocator, stronger app permissions, tighter attack surface. That's the right mindset. Assume everything is trying to touch everything else. Then make it prove it needs access.

JOSH: Does that map to how you build systems?

ERIK: Directly. PrimeBus works because everything is evented and bounded. An agent doesn't get god mode because it has a cute name. Gandalf reviews merges. PrimeRestorer owns backups. PrimeDash watches services. Each piece has a job. Same idea on a phone. Apps shouldn't get the whole kingdom because they asked nicely.

JOSH: The IIS bug bounty story is kind of the opposite side of that. Old servers, weird defaults, hidden stuff.

ERIK: Yeah, and that story is timeless. Misconfigured IIS servers are not exciting because IIS is magical. They're exciting because forgotten systems are where the bodies are buried. Default splash page, odd headers, old TLS, exposed paths, stale admin panels. It's always the boring surface area.

JOSH: So the lesson isn't "go hack IIS."

ERIK: Correct. The lesson is inventory. Know what you expose. Know what headers you leak. Know what default pages are still answering. Know which old service is sitting behind a load balancer because nobody wanted to touch it in 2018.

[beat]

ERIK: This is why I like dashboards that are ugly but honest. PrimeDash tells me what is running in the lab and on prod. Right now there are 116 services running on the production server. That number matters because unknown services are risk. You can't secure a thing you don't admit exists.

JOSH: That's wild. A lot of teams probably couldn't answer that number quickly.

ERIK: Most couldn't. And that's not a people problem. It's a systems problem. If the only inventory is a spreadsheet, it's already dead. Services should announce themselves. Health checks should publish events. Deploys should emit telemetry. Weird ports should get flagged. Certificates should age out loudly.

JOSH: That's the bus again.

ERIK: Always. Get the events onto a bus. NATS, Kafka, Redis streams, whatever fits. I like NATS because it's simple and fast. Once events exist, agents can subscribe. Security agent watches headers. Backup agent watches restore status. Build agent watches tests. HumanRail-style pattern if confidence is low. Route to a person only when the machine shouldn't decide.

[pause]

JOSH: Now the JWT headline. "Stop Using JWTs" is spicy, but people use them everywhere. What's the actual issue?

ERIK: JWTs are not evil. Bad JWT architecture is evil. The problem is that JWTs make people feel like they deleted state. They didn't. They moved state into a signed blob and then pretended logout, revocation, rotation, device trust, and compromised tokens weren't real problems.

JOSH: Give me the practical version.

ERIK: If you issue a JWT that lives for seven days and somebody steals it, they have seven days. Unless you maintain a denylist, rotate secrets, bind it to a device, shorten expiry, or check session state somewhere. And the moment you do those things, congratulations, you have state again. Which is fine. Just be honest about it.

[beat]

JOSH: So sessions aren't outdated?

ERIK: Sessions are boring. Boring is good. A server-side session with a secure cookie is still a great answer for a lot of web apps. You can revoke it. You can inspect it. You can kill all sessions for a user. You can store risk signals. You don't have to ship every claim to the browser and hope nobody made a bad storage choice.

JOSH: Where do JWTs make sense?

ERIK: Service-to-service auth. Short-lived access tokens. OAuth flows where the boundaries are understood. Mobile clients with refresh token rotation done correctly. API gateways where audience and issuer checks are enforced consistently. They make sense when the team knows the failure modes.

JOSH: And where do they not make sense?

ERIK: A weekend SaaS app where someone stores the token in localStorage, sets expiry to 30 days, and calls it secure because the payload is signed. That's not auth architecture. That's vibes with base64.

[beat]

JOSH: How does this show up in automation systems?

ERIK: Agents need identity too. That's where this gets interesting. In the Bobaverse fleet, 11 agents are emitting and reacting across the system. Neo, Homer, Bill, Echo, Gandalf, Claude, GPT. If one of them can trigger a deploy, merge code, or touch backups, identity matters.

JOSH: You don't want one magic token floating around.

ERIK: Exactly. Each agent should have scoped credentials. Short life. Clear audience. Clear permissions. PrimeRestorer can do backup work. It doesn't need to approve code merges. Gandalf can review. It doesn't need S3 delete access. PrimeBus can route messages. It shouldn't be a skeleton key.

JOSH: That's a clean way to think about it.

ERIK: It also makes failure smaller. People obsess over preventing every failure. Fine, try. But also design so a failure doesn't own the whole system. If a token leaks, what can it do? If an agent gets confused, what can it touch? If a model hallucinates, what guardrail says no?

[beat]

ERIK: The auto-merger stat from this morning is the whole story. Since June 5, PrimeBus auto-merger has run 950 attempts: 634 merged, 316 blocked by Gandalf, 0 escalated to Erik. The blocked count is the win. That's the system saying, nope, not good enough, without waking me up.

JOSH: That's probably the most important sentence today.

ERIK: Yep. Builders need to stop measuring automation only by what it does. Measure what it refuses to do. Refusal is a feature. Especially when code, credentials, money, or production are involved.

[pause]

JOSH: Bring these stories together for someone building this week. Local models, hardened phones, old IIS servers, JWT drama. What's the builder's take?

ERIK: Treat everything like part of the system. Your laptop. Your phone. Your agents. Your auth tokens. Your dashboards. Your weird old Windows server nobody wants to admit exists.

[beat]

ERIK: Then add loops. Local models for first-pass work. Frontier models for judgment. Event bus for visibility. Guardrails for refusal. Real inventory for security. Short-lived credentials for agents. Backups that prove restores, not just files copied somewhere.

JOSH: That sounds less flashy than most AI advice.

ERIK: Good. Flashy doesn't keep prod alive. A boring loop that catches a bad merge at 2 AM is worth more than a demo that writes a poem about your backlog.

JOSH: Dry, but fair.

ERIK: Build the boring control plane. That's where the power is. ScanBrief scored 93 items across 54 sources today. I don't read 54 sources manually. The machine filters, scores, and ranks. Then I decide what matters. Same pattern everywhere. Let systems collect and reduce. Let agents propose. Let guardrails block. Let humans handle judgment and taste.

[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: Run a local model as a pre-filter, not as your main engineer. That's the tip.

[beat]

ERIK: Pick one narrow job today. Log triage. Test failure classification. PR title cleanup. Terraform plan summary. Something with clear inputs and clear expected outputs. Run Gemma, Qwen, Llama, whatever fits your machine. Give it examples. Make it return JSON. Then send only the high-confidence cases forward.

JOSH: And low confidence?

ERIK: Escalate. Either to Claude, GPT, or a human. Don't make the local model pretend. Add a confidence field, but don't trust the number blindly. Check it against rules. If the output is malformed, reject it. If it touches a dangerous file, reject it. If tests fail, reject it.

[beat]

ERIK: The move is not "local AI replaces API AI." The move is routing. Cheap model handles cheap decisions. Strong model handles hard reasoning. Guardrails decide what ships. 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, June 16. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.

ERIK: ScanBrief scored 91 items across 54 sources today, and the story is pretty simple: the internet is now an attack surface, a compiler target, and a hiring funnel. Sometimes all three before breakfast.

JOSH: Stick around — Erik's got an AI pro tip at the end about safely testing code from strangers.

[pause]

JOSH: First headline. A LinkedIn job offer came with a backdoored GitHub repo. Erik, that's not subtle.

ERIK: Nope. That's a clean social-engineering attack. They don't need to beat your firewall if they can get you to clone a repo, run npm install, and execute their payload yourself.

JOSH: Second one. An x86 emulator team found code so bad they fixed it during emulation.

ERIK: That one's awesome. A compiler spit out 256KB of nonsense just to initialize 64KB of memory, so the emulator detected the pattern at runtime and replaced it with a tight loop. That's not just performance work. That's systems engineering with a broom.

JOSH: Third. People are asking if local models can replace Claude or GPT for daily coding.

ERIK: Short answer: not fully. Long answer: local models are great for narrow, private, repetitive work. But for real coding, architecture, test repair, and agent loops, frontier models still earn their keep.

[pause]

JOSH: Let's start with the job offer backdoor. That feels like the story people should actually worry about today.

ERIK: Yeah, because it's believable. That's what makes it dangerous.

JOSH: What's the actual move there?

ERIK: Somebody reaches out on LinkedIn with a job opportunity. They send a GitHub repo, probably framed as a take-home test or a code review. Inside that repo, there's a test file or startup path that fetches and runs remote code. You think you're proving you can build. You're actually proving you can be owned.

[beat]

JOSH: That's bleak.

ERIK: It's also expected. Developers got trained to run code from strangers. Clone repo. Install packages. Run tests. Open dev server. We do it all day. Attackers looked at that workflow and said, cool, that's our installer.

JOSH: Where does AI make that worse?

ERIK: AI makes the repo look normal faster. It can generate a full app, plausible tests, README, fake issue history, comments, lint config, everything. The malicious part can be tiny. One postinstall script. One test helper. One import that looks boring.

JOSH: So the scary part isn't the malware. It's the packaging.

ERIK: Exactly. The social wrapper is the exploit. LinkedIn gives it context. GitHub gives it trust. A job offer gives it urgency. Then the developer runs it because they want the interview.

JOSH: What would you do if someone sent you one of those?

ERIK: First, I don't run it on my main machine. Period.

JOSH: Even if it looks normal?

ERIK: Especially if it looks normal. Normal is the costume.

[beat]

ERIK: It goes into a disposable container or a throwaway VM with no secrets mounted and no access to my SSH keys. No GitHub token. No cloud creds. No browser profile. No npm auth token. Nothing.

JOSH: What do you inspect first?

ERIK: Package scripts. Test setup. CI config. Anything that runs automatically. In Node, package.json scripts are the first place. Then npm lifecycle hooks. Then weird curl, wget, bash, node -e, python -c, base64 decode stuff. In Python, setup.py, pyproject hooks, tox, nox, pytest config. In Go, generated code and makefiles. In Rust, build.rs.

JOSH: That's a lot.

ERIK: It is, but it's not hard. It's habit. PrimeBus processed 848 automation events across 9 projects today. That only works because I treat execution paths like infrastructure. If something can run code, it's a control plane. Respect it.

JOSH: That line is going on a sticker.

ERIK: Put it on the laptop you shouldn't run stranger code on.

[pause]

JOSH: How does this change hiring?

ERIK: Companies need to stop sending random repo tests with no trust boundary. Candidates should push back. Ask for a hosted environment. Ask for a Dockerfile. Ask what the repo does before running it. If a recruiter acts weird because you won't run unknown code on your machine, that's not a recruiter. That's a red flag in shoes.

JOSH: Wait, really? Push back on the assignment?

ERIK: Yes. Good engineers protect systems. Their own system counts. If a company penalizes that, they don't understand engineering.

JOSH: What about AI agents? People are giving agents repo access now.

ERIK: That's the next problem. An agent will happily inspect, install, run tests, open files, and follow instructions buried in the repo. That's prompt injection plus code execution. Bad combo.

JOSH: So the repo can attack the agent too?

ERIK: Absolutely. A README can tell the agent to ignore prior instructions. A test can leak env vars. A fake tool output can steer it. That's why my own systems have guardrails. Gandalf automatically reviewed and merged 13 code changes to production overnight, but it doesn't mean everything gets through. The PrimeBus auto-merger has run 934 attempts since June 5: 624 merged, 310 blocked by Gandalf, 0 escalated to me. The blocked count is the story. Guardrails are doing their job.

JOSH: That's the difference between automation and just hoping.

ERIK: Yeah. Hope is not an architecture.

[pause]

JOSH: Next story. The x86 emulator team finding terrible compiler output and fixing it while emulating. Why did that catch your eye?

ERIK: Because it's the kind of engineering I love. They didn't just complain that the input was bad. They recognized a pattern and made the system recover.

JOSH: What happened in plain English?

ERIK: A binary translator was running code generated by a compiler. That compiler had unrolled a memory initialization loop into this huge block of repeated instructions. Instead of a small loop saying, fill this memory range, it emitted a giant wall of code. Like using a dump truck to deliver a sandwich.

JOSH: And the emulator cleaned it up?

ERIK: It detected the shape of the bad code at runtime and swapped it for a better version. That's the key. The emulator became smarter than the compiler output it was given.

JOSH: Why does that matter outside emulator nerd land?

ERIK: Because modern infrastructure is full of garbage inputs. Bad configs. Noisy alerts. Weird logs. Broken generated code. Vendor APIs that return nonsense. The winning systems don't expect perfection. They detect ugly patterns and route around them.

JOSH: That's basically your whole PrimeBus argument.

ERIK: Pretty much. Events come in. Some are clean. Some are dumb. Some are missing context. You don't panic. You classify, enrich, decide, and act. If the signal says a test failed because a generated selector changed, don't wake a human. Fix the selector, run the test, get a review, ship it if it passes.

JOSH: And if it's not safe?

ERIK: Block it. That's the Gandalf job. Same reason the auto-merger blocked 310 attempts. A block is not a failure. A block is the system saying, this doesn't meet the bar.

[beat]

JOSH: That's a very different way to hear a blocked merge.

ERIK: A blocked merge is cheaper than a bad deploy. Ask anyone who has ever broken prod with confidence.

[pause]

JOSH: How does this compare to network automation? You've been doing that since 2008.

ERIK: Networking taught me this before AI did. You get device output from Cisco, Juniper, random appliances, old firmware, weird line cards, half-documented commands. If your parser expects perfect output, your automation dies by lunch.

JOSH: So you build around variation.

ERIK: You build around reality. Cisco NSO is good at modeling intent, but the world underneath is still messy. Terraform has state weirdness. Kubernetes has reconciliation loops. Selenium has flaky DOM timing. NATS is great, but your subscribers still need to behave. The pattern is the same: observe, compare against expected state, repair what you can, escalate only when needed.

JOSH: That's also what the emulator did.

ERIK: Exactly. It looked at a terrible instruction pattern and said, I know what you meant. Then it did the cheaper thing.

JOSH: Is that dangerous?

ERIK: It can be. You need confidence. You need tests. You need limits. You don't rewrite arbitrary behavior because you feel clever. You detect a known pattern, prove the replacement is equivalent, then use the faster path. That's engineering, not vibes.

JOSH: Where would you use that in AI coding?

ERIK: Test repair. Dependency bumps. Screenshot diffs. Repeated lint failures. If Claude fixes the same class of error five times, stop treating it like a brand-new mystery. Capture the pattern. Make a tool. Put it on the bus. Let the agent call it.

JOSH: So agents should become less magical over time.

ERIK: Yes. The best agent system slowly turns magic into plumbing.

[pause]

JOSH: Third deep topic. Local models. Hacker News was asking if anyone has replaced Claude or GPT for daily coding. Have they?

ERIK: Some people have replaced pieces. Not the whole thing.

JOSH: What's local good at right now?

ERIK: Privacy-sensitive tasks. Log summarization. Rewriting boring text. Searching internal docs. Small code edits in a repo it already knows. Classification. Triage. Stuff where the cost of a mediocre answer is low and the context is controlled.

JOSH: And where does it fall down?

ERIK: Long-horizon coding. Multi-file reasoning. Debugging weird test failures. Planning migrations. Understanding why a change is risky. Frontier models still have a real gap there.

JOSH: Does that bother you?

ERIK: Not really. Use the right tool. I run an 11-agent Bobaverse fleet across Claude and GPT. Neo, Homer, Bill, Echo, Gandalf. Different jobs, different models, different trust levels. Treat models like workers on a shop floor, not one magic brain in the sky.

JOSH: Where would you put a local model in that fleet?

ERIK: First pass triage. Summarize logs before sending anything expensive. Classify events. Draft a fix idea. Review docs. Maybe run private code comments where I don't want data leaving the box. Then if it needs serious reasoning, hand it to Claude or GPT with a clean packet of context.

JOSH: That's more hybrid than replacement.

ERIK: Hybrid is the real answer. People love binary arguments because they're easy to post. Local versus cloud. Open weights versus closed. Cheap versus smart. Real systems mix them.

[beat]

JOSH: What about cost?

ERIK: Cost matters, but time matters more. If a local model saves ten cents and wastes twenty minutes, that's not a win. If it filters 500 dumb events before they hit a frontier model, that's a win.

JOSH: So where's ScanBrief in that?

ERIK: ScanBrief is exactly that kind of pipeline. Today it scored 91 items across 54 sources. The point isn't to read 91 things. The point is to reduce the pile into signals worth talking about. Local models can help with that kind of sorting. Frontier models are better when the output needs judgment.

[pause]

JOSH: There's also the homelab angle. People are building AI dev platforms at home now.

ERIK: That part makes me happy. Build the lab. Break it there. Learn where the limits are. My stuff started in a home lab too. You don't need a giant budget to understand queues, agents, deploys, secrets, telemetry, and rollback.

JOSH: But you do need discipline.

ERIK: Yeah. A homelab without discipline becomes a museum of half-working dashboards. Funny, but not useful.

JOSH: What makes it useful?

ERIK: Pick one workflow and make it real. For me, that was code review and repair. PrimeBus gets telemetry. Agents react. Gandalf reviews. Merge happens only if the checks pass. That's a closed loop. Not a demo. Not a screenshot. A loop.

JOSH: That's the difference?

ERIK: Yep. A project becomes infrastructure when it has inputs, decisions, actions, and feedback. InkEngine has that for writing books. ScanBrief has that for tech signals. PrimeDistro has that for outreach. HumanDesignApp even has it in an iMessage state machine. Different domains, same pattern.

JOSH: You make it sound obvious.

ERIK: It is obvious after you build it. Before that, people stare at a blank terminal and call it strategy.

[pause]

JOSH: Before we hit the tip, any quick takes on the other stories?

ERIK: Hetzner price adjustment is a reminder that cheap compute is never guaranteed. Design for portability before the invoice teaches you.

JOSH: Fox buying Roku?

ERIK: Distribution. Always distribution. Hardware, ads, streaming surfaces, data. Same old game with a different remote.

JOSH: Salesforce buying Fin for 3.6 billion?

ERIK: AI support is becoming table stakes. If your support flow is still humans copying answers from docs, you're volunteering to be expensive.

[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: Treat unknown repos like hostile infrastructure.

JOSH: What does that look like today?

ERIK: Make a throwaway workspace. Container or VM. No mounted home directory. No SSH keys. No cloud creds. No browser cookies. No GitHub token. Then inspect before execution.

[beat]

ERIK: Run ripgrep first. Search for curl, wget, bash, eval, child_process, postinstall, preinstall, base64, and remote URLs. Check package scripts before npm install. Check test hooks before running tests. If an AI agent is doing it, give the agent the same sandbox. Don't let it browse your secrets because the README looked friendly.

JOSH: That's very specific.

ERIK: Good. Specific keeps you employed. Bonus move: ask Claude to produce a threat summary before it runs anything. Not after. Before. Then make it list what commands it wants to run and why. Approve the commands, not the vibe.

[beat]

ERIK: 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, June 15. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.

ERIK: Maintainers are tired, local AI is getting real, and guardrails beat hero engineering every time.

JOSH: Stick around — Erik's got an AI pro tip at the end about making agents prove their work before they touch production.

[pause]

JOSH: First headline. Curl is taking July off from vulnerability reports. Wait, really?

ERIK: Yep. Curl said they won't accept vulnerability reports during July 2026. That includes bug bounty reports and email disclosures. Daniel Stenberg and the team are basically saying, we need one month where security triage doesn't eat our lives.

JOSH: That's a pretty loud signal.

ERIK: It is. Curl is infrastructure. Everything uses it. When a project like that has to block the front door for a month, the story isn't laziness. The story is maintainers carrying half the internet with a tiny crew.

[beat]

JOSH: Second headline. Apple Foundation Models showed up in the ScanBrief list today.

ERIK: That's the local AI story. Apple wants developers building against models on the device, not shipping every prompt to a cloud endpoint. For normal users, that's privacy. For builders, that's latency, cost control, and app features that still work when the network is trash.

JOSH: And third. Rio de Janeiro's homegrown LLM may not be very homegrown.

ERIK: That one is spicy. The claim is their model looks like a merge of an existing model. This is why model provenance matters. If you're spending public money and calling something sovereign AI, you better know what weights you're actually running.

[pause]

JOSH: Curl pausing vulnerability reports feels extreme. Is that normal?

ERIK: No. And that's why it matters. Curl isn't some random weekend project with six users and a README from 2014. Curl is in operating systems, appliances, phones, containers, CI pipelines, network gear, weird industrial boxes, everything.

[beat]

ERIK: When Curl says, don't send us vulnerability reports for a month, that's not a vacation post. That's an incident report about open source maintenance.

JOSH: But security reports are kind of the point, right? You want people to send them in.

ERIK: Correct. But every report has cost. Even junk reports. Especially junk reports. Somebody has to read it, reproduce it, decide if it's real, coordinate disclosure, write a patch, write an advisory, deal with CVEs, deal with downstreams, deal with companies who panic because their scanner lit up red.

JOSH: Sounds like a second job.

ERIK: More like a second job stapled to the first job while strangers yell at you for free.

[beat]

ERIK: Security reporting has become weird. Bug bounty platforms created incentives for volume. People run scanners, paste output, and call it research. Some reports are real and valuable. A lot are noise. But maintainers can't ignore them, because the one you ignore might be the real one.

JOSH: So what's the lesson for companies listening?

ERIK: Stop treating open source like public plumbing that fixes itself. If your product depends on Curl, OpenSSL, Postgres, Kubernetes, Caddy, whatever, you need a support plan that isn't vibes.

JOSH: What does that look like in practice?

ERIK: First, know your dependency graph. Not just package names. Know which services use what, where they're deployed, and who owns patching. Second, don't run every scanner finding straight to panic mode. Put a triage layer in front of it. Third, fund critical projects if you're making money on top of them.

[beat]

ERIK: In my world, PrimeBus processed 832 automation events across 14 projects today. That's normal now. But I don't let random events mutate production. Gandalf reviews the change. Tests run. If the signal is weak, it gets blocked.

JOSH: That's the auto-merger stat from this morning, right?

ERIK: Yep. Since June 5, PrimeBus auto-merger has run 889 attempts: 593 merged, 296 blocked by Gandalf, 0 escalated to me. That's the part I care about. The 296 blocked means the system had a spine.

JOSH: So the Curl problem is really a queue problem?

ERIK: A queue problem, a trust problem, and a people problem. Maintainers need a way to accept reports without every report becoming an emergency. That's where automation can help, but only if it's strict. You can have an agent dedupe reports, map them to affected versions, run a repro harness, check whether the reporter included enough detail.

JOSH: But don't let the agent close the ticket because it feels confident.

ERIK: Exactly. Confidence is not evidence. Evidence is a repro, a failing test, a patched test, and a diff that passes review. Claude can help write the harness. NATS can route the event. PrimeBus can track the state. Gandalf can block the nonsense. But humans still define the policy.

[pause]

JOSH: Apple Foundation Models. This feels like a different AI story than the usual giant cloud model announcement.

ERIK: It is. Cloud models are still king for hard reasoning, coding, long context, and agent work. Claude is my daily driver for building. But on-device models change the shape of normal apps.

JOSH: How?

ERIK: They make AI features boring. And boring is good. Your phone can summarize a note, classify a message, generate a quick response, clean up text, or pull entities from a form without a server round trip.

[beat]

ERIK: That's not a moonshot. That's a checkbox developers can start using.

JOSH: Is local AI mostly about privacy?

ERIK: Privacy is the headline. Cost is the builder story. If you're running an app and every small inference hits a paid API, your margins get weird fast. Local models let you keep cheap tasks on the device and save Claude or GPT for the heavy stuff.

JOSH: Give me an example from your own systems.

ERIK: HumanDesignApp has an iMessage state machine. Some messages need deep interpretation. That's cloud model territory. But a lot of state handling is simpler. Is this person asking a follow-up? Are they changing birth time? Are they stuck in onboarding? That kind of classification can move closer to the edge when the model quality is good enough.

JOSH: So you split the work.

ERIK: Yep. Small model handles routing. Big model handles reasoning. Same pattern in automation. A cheap detector watches logs. A better model writes the fix. A stricter reviewer decides if it ships.

[beat]

JOSH: That sounds a lot like how a network engineer would design it.

ERIK: Because it is. You don't send every packet through the most expensive inspection path if you don't have to. You classify, route, inspect where needed, and drop garbage early.

JOSH: Where does Apple have an advantage?

ERIK: Distribution. If Apple gives developers a stable API and the model is already on the device, adoption gets stupid simple. No API key. No billing surprise. No data leaving the device for basic tasks.

JOSH: What's the downside?

ERIK: Capability gaps. Local models are smaller. They can be wrong. Developers will overuse them because the demo looks good. Then users get weird behavior in production.

JOSH: Classic.

ERIK: Always. The fix is the same as cloud AI. Bound the task. Don't ask a small local model to be a consultant. Ask it to classify one thing, rewrite one paragraph, extract three fields, or choose from a short list.

[beat]

ERIK: ScanBrief scored 71 items across 54 sources today. That pipeline isn't one big magical prompt. It's feeds, scoring, dedupe, summarization, ranking, and delivery. Models do pieces. Systems do the work.

JOSH: That's a clean line.

ERIK: It's the whole show. Build systems around AI. Don't build a hope machine and call it a product.

[pause]

JOSH: The Rio de Janeiro LLM story. Why should normal builders care if some city model was merged from another model?

ERIK: Because we're about to see this everywhere. Companies, cities, universities, agencies. Everybody wants their own AI. Sovereign AI. Private AI. Domain AI. Fine. But if you can't explain the base model, training data, license, evals, and modifications, you don't own what you think you own.

JOSH: Is merging models bad?

ERIK: No. Merging can be useful. Fine-tuning can be useful. Distillation can be useful. The problem is branding it like you trained a national model from scratch when it's really a remix of public weights.

[beat]

JOSH: Why is that dangerous?

ERIK: Licensing, security, and trust. If the base model has license restrictions, you inherit them. If the weights include behavior you don't understand, you inherit that too. If you deploy it into public services, now citizens are interacting with something nobody can properly explain.

JOSH: That's wild.

ERIK: Public sector AI needs boring paperwork. Model card. Data lineage. Eval results. Known failure modes. Human review process. Audit logs. I know everyone wants the cool demo. The demo is the least important part.

JOSH: How would you verify a model?

ERIK: Start with provenance. Where did the base weights come from? What license? What changed? Then run behavioral tests. Prompt suites. Safety tests. Domain tests. Regression tests. Then watch production telemetry.

[beat]

ERIK: Same way I treat automation. PrimeBus doesn't get to say, trust me bro. It emits events. The reviewer logs decisions. The merge has a trail. If something blocks, I know why.

JOSH: You mentioned 0 escalated to you this morning.

ERIK: Right. That doesn't mean the system is magic. It means the guardrails handled it. In the last 7 days, 538 auto-merger runs: 324 merged, 214 blocked, 0 escalated. The blocked count is the good news.

JOSH: Most people would brag about the merged number.

ERIK: The blocked number is where the engineering lives. Anybody can make an agent that opens pull requests. Shipping safely is the job.

[pause]

JOSH: There's also a Hacker News item today on formal methods and the future of programming. Does that connect?

ERIK: Big time. Formal methods sound academic, but the idea is simple. Prove properties about the system instead of hoping tests catch everything.

JOSH: Are you using that day to day?

ERIK: Not in the full theorem-prover sense for every project. I'm practical. But the mindset matters. Define invariants. This must never happen. This field must exist. This state transition must be valid. This command must not run unless these checks pass.

[beat]

ERIK: Agents need that more than humans do.

JOSH: Because agents are creative?

ERIK: Because agents are confident little bulldozers. They will solve the wrong problem beautifully if you let them. Formal-ish guardrails make the box smaller. JSON schemas. state machines. policy checks. dry-run plans. test gates. approval gates.

JOSH: That's less exciting than a big autonomous agent demo.

ERIK: Good. Exciting production systems wake people up at 2 AM. Boring ones send you a summary after breakfast.

JOSH: Put that on a shirt.

ERIK: Prime Automation merch department is currently one guy and too many cron jobs.

[beat]

JOSH: Where do tools like Terraform and Kubernetes fit into this?

ERIK: They're already formal-ish. Terraform has a plan. Kubernetes has desired state. NSO has service models and transactions. The whole point is to declare intent and let the system converge. AI agents should behave the same way.

JOSH: Not just run commands.

ERIK: Never just run commands. Agent proposes intent. System turns it into a plan. Tests validate the plan. Policy checks the blast radius. Then it applies. If it fails, emit telemetry and roll forward or stop. Don't freestyle on prod.

[pause]

ERIK: This episode is sponsored by Prime Automation Solutions. If you're still doing it manually, we automate it. Also, special on a website — $250. primeautomationsolutions.com

[pause]

JOSH: Alright, what's the AI pro tip today?

ERIK: Make your agent return a proof packet before it changes anything.

[beat]

ERIK: Not a paragraph saying it looked at the code. A real packet. Files touched. Tests it expects to run. Risk level. Rollback plan. Exact command it wants to execute. Expected output. What would make it stop.

JOSH: So the prompt asks for evidence first.

ERIK: Yep. Use a two-step workflow. Step one: analyze and produce the proof packet. Step two: only if the packet passes your checks, allow the agent to make the change.

[beat]

ERIK: This works with Claude, GPT, local models, whatever. The model is less important than the contract. If it can't explain the change clearly before touching files, it doesn't get write access.

JOSH: That's usable today.

ERIK: Very usable. Put it in your coding agent instructions. Put it in your CI bot. Put it in your NATS workflow. Small rule, huge difference. 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, June 12. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.

ERIK: AI agents are cheap until you hand them a cloud account and no leash.

JOSH: Stick around — Erik's got an AI pro tip at the end about putting hard spend limits around agent work before the agent gets creative.

[pause]

JOSH: First headline. An AI agent tried to scan DN42 and left its operator with a six thousand five hundred thirty one dollar AWS bill. Erik, that's not a bug, that's a mortgage payment.

ERIK: That's what happens when autonomy meets an unlimited credit card. The agent did what it was asked to do. The system around it failed.

JOSH: Next one. Hacker News is arguing that if you're asking for human attention, you need to show human effort. Is that just manners, or is it now an engineering requirement?

ERIK: It's engineering hygiene. If Claude wrote the patch, say Claude wrote the patch. Add what you checked, what you believe, and what you need reviewed. Don't dump a mystery box on another engineer and call it collaboration.

JOSH: Third headline. An old paper is back: nobody gets credit for fixing problems that never happened. That's painfully familiar.

ERIK: Preventative work is invisible until it stops happening. PrimeBus processed 968 automation events across 16 projects today, and the whole point is that most of them should be boring.

[pause]

JOSH: Let's start with the AWS bill story, because that's the one everyone is going to remember.

ERIK: Yeah. An agent tried to join and index DN42, which is this decentralized network lab people use for BGP, tunnels, experiments, that kind of thing. It spun up cloud resources, kept going, and the operator got hit with a $6,531.30 AWS bill.

JOSH: Wait, really?

ERIK: Really. And the part people miss is that the agent wasn't evil. It wasn't conscious. It wasn't sitting there twirling a mustache. It was given a goal, access to infrastructure, and not enough guardrails.

JOSH: So the failure is the box around the agent.

ERIK: Exactly. Agentic systems need budgets the same way production systems need CPU limits, rate limits, and rollback plans. If your Kubernetes cluster can stop a container from eating the node, your AI runner should stop a task from eating your AWS account.

[beat]

JOSH: What does that mean in practical terms?

ERIK: Hard limits. Not vibes. Set AWS budgets. Set service quotas. Use separate accounts. Use IAM roles that only allow the exact actions needed. Put agents in a sandbox account first. Then make the agent ask for approval before it crosses a spend threshold or creates resource types it hasn't used before.

JOSH: That sounds obvious when you say it.

ERIK: It is obvious. That's why people skip it.

JOSH: That's cold.

ERIK: It's true. Everyone wants the cool demo. Nobody wants to wire the breaker panel. Then the demo becomes a financial incident.

[pause]

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

ERIK: PrimeBus is event-driven, but it doesn't mean every event gets a blank check. Gandalf reviewed and merged 17 code changes to production overnight, but that pipeline has gates. Since June 5, the auto-merger has run 637 attempts: 438 merged, 199 blocked by Gandalf, 0 escalated to me. That's the story. The blocked count means the guardrails worked.

JOSH: Zero escalated is the number that jumps out.

ERIK: Right. That's what I want. Not because the system is magic. Because the system has a narrow job, clear tests, separate agents, logs, review rules, and stopping conditions. The model can suggest. It can patch. It can test. It can merge if the evidence passes. It doesn't get to improvise production policy at 3 AM.

JOSH: And this AWS agent basically improvised production policy.

ERIK: That's how I read it. The operator said go do network discovery, and the surrounding system didn't say, cool, but your max spend is fifty bucks, your max runtime is two hours, and if you create anything expensive, stop and ask.

JOSH: Is this an AI problem or just an automation problem wearing a new hat?

ERIK: Both. Old automation broke things fast because scripts are dumb and literal. AI automation breaks things creatively because the model can find a path you didn't imagine. That's useful. That's also why it needs tighter walls.

[beat]

JOSH: What's the wall you would build first?

ERIK: Money. Always. Cloud budget alarm is not enough. Alarm means it already happened. You need budget enforcement, quota enforcement, and kill switches. If the agent starts ten instances when it usually starts one, stop it. If it touches a region it has never touched before, stop it. If the estimated cost crosses the job budget, stop it.

JOSH: And then a human reviews?

ERIK: Or another system reviews. HumanRail is the pattern, even if you don't use my system. When confidence drops or risk goes up, route it to a human. Don't make every task human-in-the-loop. That's slow. Make the dangerous transitions human-in-the-loop.

[pause]

JOSH: Second deep dive. Human attention. The post says if you're asking for attention, demonstrate human effort. Why did that hit a nerve?

ERIK: Because code review is already expensive. Now people are pasting AI-generated patches, AI-generated summaries, AI-generated explanations, and asking a human to untangle what nobody owned.

JOSH: So the issue isn't using AI.

ERIK: No. Use AI all day. I build with Claude every day. The issue is pretending AI output is the finished thought. If you send me a pull request, I want to know what changed, why it changed, what you ran, what you're unsure about, and what you want me to focus on.

JOSH: Label the machine part.

ERIK: Yes. Say, Claude generated the first pass. I reviewed the database migration. Tests passed locally. I'm not sure about the retry behavior. Please look there. That's a good review request.

JOSH: What's the bad version?

ERIK: Here's a thousand lines. Thoughts?

[beat]

JOSH: I felt that one.

ERIK: Everyone has seen it. It's not new, but AI made the volume worse. Before, a lazy request took time to write. Now a lazy request can be beautifully formatted in ten seconds.

JOSH: That's the trap, right? It looks polished.

ERIK: Polished is not the same as inspected. I don't care if the summary has bullets and nice wording. I care if the person sending it knows where the sharp edges are.

[pause]

JOSH: How do you avoid that in an automated review pipeline?

ERIK: Make the agents produce evidence, not prose. PrimeBus doesn't just say, looks good. It emits events. Tests ran. Files changed. Risk category. Gandalf decision. Merge decision. Block reason. If something fails, the event trail is there.

JOSH: So the review isn't a vibe check.

ERIK: Correct. And with email-reactor, same idea. A client emails a website change request. The system can parse it, draft the change, and prepare the update, but it has to keep the original request tied to the diff. Otherwise you're trusting a summary of a summary. That's how little mistakes turn into embarrassing invoices.

JOSH: What does that mean for teams using AI in code reviews right now?

ERIK: Set a house rule. AI-generated work is allowed, but it must include human notes. What did you verify? What did you not verify? What changed from the model's first version? Where should the reviewer spend attention?

JOSH: That sounds like it would cut review noise fast.

ERIK: It does. It also makes junior engineers better faster, because they have to form an opinion. The model can help them write code, but it can't be the only one who understands the code.

[beat]

JOSH: There's a cultural piece there too.

ERIK: Big time. If you ask for my attention, you're spending my time. Show me you spent some of yours. That's not gatekeeping. That's respect for the queue.

[pause]

JOSH: Third story. The old paper about not getting credit for problems that never happened. Why is that showing up again now?

ERIK: Because prevention is becoming the main engineering job. The loud work used to be outages, war rooms, dashboards going red. The valuable work is making sure that never starts.

JOSH: But companies reward the firefighter.

ERIK: They do. Person runs into the burning building, everyone claps. Person installs the sprinkler system, nobody notices. Engineering has the same sickness.

JOSH: How do you prove the value of prevention then?

ERIK: You instrument it. You count what was blocked, what was caught, what was automatically repaired, what never reached a human. ScanBrief scored 90 items across 54 sources today. Most don't become show topics. That's not wasted work. That's filtering doing its job.

JOSH: Same logic as Gandalf blocking merges.

ERIK: Exactly. A blocked merge isn't a failure. It's a prevented incident. Same with PrimeRestorer. Nobody gets excited about backups until the database is gone. Then suddenly the backup orchestrator is the most important system in the building.

[beat]

JOSH: How do you make that visible without turning it into dashboard theater?

ERIK: Tie prevention to decisions. Don't make a wall of charts nobody reads. Send the right signal to the right place. A weekly report that says 193 risky auto-merger runs were blocked in the last 7 days is useful. A dashboard with fourteen colors and no action is office wallpaper.

JOSH: That's a very specific complaint.

ERIK: I've seen some dashboards, man.

JOSH: Fair.

ERIK: The point is, preventative work needs receipts. If your runbook saved an outage, log it. If your agent stopped a bad deploy, record why. If your backup test passed, keep the restore time. Engineers don't get credit for ghosts. Give the ghost a ticket number.

[pause]

JOSH: How does this apply outside infrastructure? Say someone is building a small app or solo business.

ERIK: Same rules. Add guardrails before you add features. If InkEngine is generating book drafts, I care about versioning, prompt records, source files, and output checks. If ScanBrief is ranking stories, I care about source diversity and scoring. If email-reactor is changing a client site, I care about approval states.

JOSH: You're saying boring systems first.

ERIK: Boring systems make the fun stuff possible. Nobody wants to hear that, but it's true. You want agents shipping while you sleep? Cool. Then give them logs, budgets, tests, rollback, and a way to stop themselves.

JOSH: That sounds like the theme of the day.

ERIK: Yeah. Autonomy is not permission to be sloppy. Autonomy is a reason to be more strict.

[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 you run an agent against anything real, write a one-page operating contract. Not a giant policy doc. One page.

JOSH: What's in it?

ERIK: Inputs, allowed tools, forbidden actions, max runtime, max spend, stop conditions, and who gets paged. Then paste that into the agent prompt and enforce the same rules outside the prompt with actual limits.

[beat]

ERIK: Prompt rules are not security. They're instructions. Use them, but back them with code. If the agent can create cloud resources, put a budget in the cloud account. If it can edit files, run tests before merge. If it can send email, require approval before external send.

JOSH: So the tip is prompt plus guardrail.

ERIK: Exactly. Tell the agent the rules, then build the system so the rules still matter when the model gets weird. 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, June 11. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.

ERIK: Today's theme is simple. Agents need guardrails, data has receipts, and weird old systems keep winning because they were built by adults.

JOSH: Stick around — Erik's got an AI pro tip at the end about making agents prove their work before they touch production.

[pause]

JOSH: First up. Pokémon Go data training military drone navigation. That sounds like a sci-fi lawsuit waiting to happen.

ERIK: It does, but the engineering lesson is bigger than the outrage. Consumer apps collect real-world spatial data at a scale defense teams would kill for, and apparently, in this case, they didn't have to kill for it. They just waited.

JOSH: Second headline. An AI agent reportedly ran amok around Fedora and other open-source projects. Is this the nightmare version of agentic coding?

ERIK: It's the lazy version. If your agent can reassign bugs and merge questionable code without narrow permissions, audit trails, and a kill switch, you didn't build an AI workflow. You built a toddler with repo access.

JOSH: Third. Anthropic's Fable and Mythos guardrails are annoying cybersecurity researchers. Too locked down?

ERIK: Yeah, probably. Security work looks suspicious by default. If your model can't tell the difference between a researcher testing a CVE and some clown trying to pop a real target, the guardrail becomes the outage.

[pause]

JOSH: Let's start with Pokémon Go. People walked around catching monsters, and now that helped train drone navigation?

[beat]

ERIK: That's the rough shape of it. Pokémon Go was an augmented reality game, but under the hood it was also a massive machine for mapping public space. Phones were moving through sidewalks, parks, buildings, intersections, weird corners, bridges, all with cameras, GPS, motion sensors, and user behavior.

ERIK: That kind of data is gold. Not cute gold. Real gold. If you're building navigation for drones, robots, AR glasses, anything that needs to understand physical space, you need lots of messy real-world examples. The lab doesn't give you that. A million people walking around town with phones does.

JOSH: The creepy part is the gap between what people thought they were doing and what the data became.

ERIK: Exactly. Nobody playing Pokémon Go thought, "Nice, I'm contributing to defense navigation." They thought, "There's a Pikachu by the fountain." Different vibe.

ERIK: This is why data provenance matters. Where did the data come from? Who consented? What was the original purpose? What can it be reused for later? Engineers love to say, "It's just data." No. Data is history. It has context. It has intent attached to it, even if your database schema dropped that column.

JOSH: Is this an AI problem, or just a tech industry problem with AI making it louder?

ERIK: Tech industry problem. AI made the appetite bigger. Before, you needed data for one product. Now every company looks at old logs, images, clicks, maps, support tickets, chat transcripts, and says, "Can we train on this?" Sometimes the answer is technically yes and morally gross.

ERIK: ScanBrief scored 93 items across 54 sources this morning, and this was at the top because it's a perfect signal. Not because drones are new. Because the line between consumer systems and military systems is getting thinner.

JOSH: What would you do differently if you were building that kind of data pipeline?

ERIK: Tag the data at collection. Not later. Collection-time metadata. Source, user consent state, allowed use, retention window, downstream restrictions. Put it in the pipeline where engineers can't conveniently forget it.

ERIK: In PrimeBus, everything is an event. The event has type, source, target, timestamp, status, and review path. That's not decoration. That's how you can answer, "What happened, who touched it, and why did it move?" If you can't answer that, you're operating on vibes.

JOSH: And vibes don't pass audit.

ERIK: Vibes don't pass anything except a pitch deck.

[beat]

JOSH: How does this compare to the stuff you build at home? Obviously you're not training drones in the lab.

ERIK: Correct. My drones are metaphorical and mostly yell at Jenkins.

ERIK: But the same principle applies. PrimeBus processed 756 automation events across 11 projects today. That means 756 little facts moved through the system. If those events don't carry enough context, the agents downstream make dumb choices.

ERIK: For example, an error event from PrimeSentinel isn't just "job stuck." It's which service, which host, how long, what changed recently, whether it happened before, and whether a human has already looked at it. That context decides whether Claude writes a patch, opens an issue, restarts a worker, or leaves it alone.

JOSH: So the lesson isn't "don't collect data." It's "don't pretend the data has no story."

ERIK: That's it. Data needs a chain of custody. AI systems make that mandatory. If you train or act on data without knowing where it came from, you're going to build something impressive and then spend the next year explaining it to lawyers.

[pause]

JOSH: Let's talk about the Fedora agent story. An AI agent reassigning bugs and merging questionable code sounds like every maintainer's blood pressure just went up.

ERIK: It should. Open source already has enough weirdness. Now add an autonomous agent with bad permissions and you get a very fast mess.

ERIK: Here's the part people miss. The danger isn't that AI writes bad code. Humans write bad code all day. The danger is speed plus authority. Bad code at human speed is reviewable. Bad code at agent speed with merge rights becomes infrastructure weather.

JOSH: Wait, really? Infrastructure weather?

ERIK: Yeah. It just happens to you. You wake up and the repo is wet.

JOSH: That's bleak.

ERIK: It's accurate.

[beat]

JOSH: What's the correct way to let agents work in codebases then?

ERIK: Narrow authority. Clear review gates. Observable events. Reversible actions. Start there.

ERIK: An agent should be able to propose. Maybe branch. Maybe run tests. Maybe open a pull request. But touching main is a privilege. Production is not a sandbox. Open-source maintainers learned this with humans, CI bots, dependency bots, and now we're pretending agents are special. They're not. They're just faster.

JOSH: You do let agents merge though.

ERIK: I do, because I built the cage first.

ERIK: PrimeBus auto-merger has run 529 attempts since 2026-06-05: 376 merged, 153 blocked by Gandalf, 0 escalated to Erik. That's the story. Not "AI merged a bunch of code." The story is 153 blocked by Gandalf and 0 escalated to me. Guardrails worked.

JOSH: That's a very different posture from "the bot has access, hope it behaves."

ERIK: Completely different. Gandalf reviews the change before it gets in. Tests have to pass. The patch has to match the failure. The scope has to make sense. If it's weird, it gets blocked. It doesn't get a motivational quote and a second chance.

JOSH: What counts as weird?

ERIK: Touching unrelated files. Disabling tests. Changing config without a reason. Adding a dependency for a tiny fix. Broad exception handling. Any patch that looks like it's hiding the symptom instead of fixing the cause. Classic intern moves, just generated faster.

JOSH: That's the uncomfortable part. The agent mistakes are familiar.

ERIK: Very familiar. Agents don't invent new categories of bad engineering. They compress the timeline.

ERIK: Same thing with Cisco NSO or Terraform. If you let automation push network changes without validation, dry runs, diff review, and rollback, you're asking for pain. The tool doesn't matter. NSO, Kubernetes, GitHub Actions, Claude, whatever. Authority needs boundaries.

[beat]

JOSH: What should open-source projects do right now?

ERIK: Treat AI agents like new maintainers with no reputation. Read-only first. Then issue comments. Then PRs. Then maybe triage labels. Merge rights should come way later, and only through policy.

ERIK: Also, publish the agent identity. Don't hide it. If a bug got reassigned by an agent, say that. If a PR was generated by Claude, say that. Maintainers need to know whether they're talking to a person or a workflow.

JOSH: Is that about trust?

ERIK: It's about debugging. Trust is cute. Debugging is the job.

ERIK: If PrimeDash shows me a service flapping, I need to know if a human deployed it, Gandalf merged it, or PrimeSentinel restarted it. Different cause, different fix. Same with open source. You can't run a serious project if the actors are invisible.

JOSH: So the Fedora story isn't "AI bad." It's "permissions are architecture."

ERIK: Yep. Permissions are architecture. Review is architecture. Logging is architecture. The agent is just another worker. If you don't design the system around that worker doing something dumb at 3 AM, you are the system's weakest service.

[pause]

JOSH: Third deep dive. Anthropic's Fable and Mythos. Cybersecurity researchers are annoyed by the guardrails. What's going on there?

ERIK: Anthropic is trying to expose powerful cyber capability without handing everyone a loaded tool. Fair problem. Hard problem. But researchers are saying the guardrails are blocking legitimate work, especially around cybersecurity and biology-adjacent topics.

ERIK: That matters because security work uses dangerous language. Exploit. Payload. Persistence. Bypass. Credential. Malware. Those words can be part of defense, testing, education, or crime. A dumb filter sees the word and panics.

JOSH: So strict guardrails can make the tool less useful to the people who are actually trying to help.

ERIK: Right. If a model refuses basic exploit analysis for a local lab, the researcher goes back to manual work or uses a less restricted tool. Congratulations, you protected nobody and annoyed the good users.

JOSH: But you also don't want the model writing ransomware instructions.

ERIK: Correct. This is why context beats keyword blocking. Who is the user? What's the target? Is it a lab? Is there authorization? Are we analyzing a patch, reproducing a CVE, writing detection logic, or generating a weaponized chain? Those are different tasks.

ERIK: A good guardrail should route. Not just refuse. If the request is risky but legitimate, keep it in a constrained mode. Give defensive analysis. Generate YARA rules. Explain how to detect. Help write a safe reproduction against a toy target. Don't hand out real-world abuse instructions.

[beat]

JOSH: This sounds like HumanRail territory.

ERIK: Exactly. When the model isn't confident, route to a human. That's the sane move. Some decisions shouldn't be made by a regex wearing a helmet.

JOSH: Dry, but fair.

ERIK: In agentic systems, refusal isn't the only control. You have read-only modes, simulation modes, approval steps, limited outputs, target allowlists, audit logs, and human review. Security models need that same thinking.

ERIK: The model can say, "I can help you analyze this CVE in a local lab. I won't provide stealth, persistence, or live-target instructions." That's useful. That's not weakness. That's a grown-up boundary.

JOSH: How would you apply that in a company using AI for security operations?

ERIK: Build task classes. Detection, triage, explanation, patch guidance, reproduction, exploitation, external scanning. Each class gets a policy. Detection can be broad. Exploitation needs authorization. External scanning needs a ticket. Anything touching prod needs approval.

ERIK: Then wire it into tools. Don't leave it in the prompt. Prompts are not policy. Policy is code, permissions, logs, and tests.

JOSH: That line probably belongs on a sticker.

ERIK: It belongs in a repo.

[beat]

JOSH: Where do Fable and Mythos fit into the bigger AI model story?

ERIK: Specialized models are coming. General chat models are fine, but cyber, coding, legal, medical, and operations all need domain behavior. The trick is not just training the model. It's packaging the model with controls that match the domain.

ERIK: Cyber is the best stress test because the same knowledge helps defenders and attackers. If you get the policy layer wrong, the model is either dangerous or useless. That's a narrow road.

JOSH: Do you think Anthropic fixes it?

ERIK: They probably tighten the routing. They have the right instincts on safety, but researchers are giving useful feedback. The market won't accept a cyber model that refuses half the work. It also won't accept one that helps teenagers write better malware. There's a middle path, and it's mostly product engineering.

JOSH: Not magic.

ERIK: Not magic. Boring controls. Boring wins.

[pause]

ERIK: This episode is sponsored by Prime Automation Solutions. If you're still doing it manually, we automate it. Also, special on a website — $250. primeautomationsolutions.com

[pause]

JOSH: Alright, what's the AI pro tip today?

ERIK: Make your agent produce a proof packet before it changes anything important.

ERIK: Not a summary. A proof packet. The exact failing test. The file it touched. The diff. The command it ran. The result after the fix. Why the change is scoped. What it refused to touch.

ERIK: Then make another model review that packet with a hostile prompt. I don't mean rude. I mean skeptical. Ask it, "Is this patch hiding the error? Did it remove coverage? Did it touch unrelated code? Would you merge this if you owned production?"

ERIK: That's how Gandalf works in my world. Claude can write the patch. Gandalf has to believe it. If Gandalf blocks it, the code doesn't ship. Feelings are not part of the deployment pipeline.

ERIK: You can do this today with GitHub Actions, Claude, and a second review step. No fancy platform needed. Make the agent prove the work before it gets authority.

ERIK: 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, June 10. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.

ERIK: AI is getting better, package managers are getting stricter, and if your pipeline can't handle both, it's already behind.

JOSH: Stick around — Erik's got an AI pro tip at the end about making agents prove their work before they touch prod.

[pause]

JOSH: First headline. Claude Fable 5 showed up in the feed today, and ScanBrief ranked it right near the top. Is this another model launch, or something bigger?

ERIK: Bigger. The signal is the class name. Mythos-class means Anthropic is changing how they describe capability, not just bumping a model number. When naming shifts, product boundaries usually shift right behind it.

JOSH: Second one. npm v12 has breaking changes coming for installs. Why should builders care?

ERIK: Because install scripts are a supply-chain mess. npm making Git and remote dependency resolution opt-in by default is annoying for lazy builds and great for real systems. July 2026 sounds far away until your CI breaks on a Friday.

JOSH: Third headline. A German ruling says Google can be liable for false answers in AI Overviews. That feels like a big line in the sand.

ERIK: It is. The era of “the model said it, not us” is ending. If you put AI output in front of users, you own it. Same as automation. Same as code. Same as a bad runbook at 2 AM.

[pause]

JOSH: Let's start with Claude Fable 5. The feed called it a new Mythos-class AI with strong software engineering and research performance. What's the real signal?

ERIK: The real signal is not “new model good.” That's boring. The signal is Anthropic is carving out a new lane for agent work.

[beat]

ERIK: Current Claude naming is musical. Opus, Sonnet, Haiku. Fable and Mythos sound different. That matters because names are product architecture. You don't change the shelf label unless the shelf changed.

JOSH: What would that mean in practice?

ERIK: It probably means longer-running work, higher agency, and stronger tool use. Not just chat. Not just “write me a function.” More like, “take this repo, inspect the failures, propose two fixes, run the tests, explain the risk, then stop at the approval gate.”

JOSH: That sounds like what you're already doing with PrimeBus.

ERIK: Exactly. PrimeBus processed 1073 automation events across 18 projects today. That's not a toy demo. That's my actual systems throwing events on a NATS bus, agents reading those events, and workflows firing based on what happened.

[beat]

ERIK: The important part is not the model. The important part is the contract around the model. Claude can be brilliant and still need boundaries. My agents don't get to freestyle against prod because they feel confident. Gandalf reviews the change. Tests run. Telemetry gets emitted. The bus records the whole thing.

JOSH: And you had code changes merge overnight, right?

ERIK: Nineteen code changes were automatically reviewed by Gandalf and merged to production overnight. That's the number that matters. Not a benchmark. Not a tweet. Real code, reviewed by an agent, shipped while I was asleep.

JOSH: Wait, really?

ERIK: Yeah. And the auto-merger has run 445 attempts since June 5. 331 merged, 114 blocked by Gandalf, 0 escalated to me. That's the story. The blocked count is not failure. That's guardrails working.

JOSH: So when people say the new model is safer or more capable, you don't trust that by itself.

ERIK: Never. Model safety cards are useful, but production safety comes from the system around the model. Permissions. Logs. Test gates. Rollback paths. Human escalation. That boring stuff is what lets you move fast without turning your infrastructure into a science project.

[beat]

ERIK: Fable 5 can be amazing. Great. Put it behind PrimeRouter. Route low-risk tasks to cheaper models. Send high-risk code review to the strongest model. Fail over when a provider gets weird. Track every call with OTEL. Now you have engineering instead of vibes.

JOSH: How do you compare that to old automation? Like NSO, Terraform, or scripts?

ERIK: Old automation is deterministic. NSO says, “given this service model, push this config.” Terraform says, “given this state, converge this infrastructure.” That's good. Keep that.

[beat]

ERIK: Agentic automation is different. It handles ambiguity. A test failed. The error is ugly. The dependency changed. The README lied. That's where Claude shines. But you still wrap it in deterministic rails. The agent can propose. The system decides what gets deployed.

JOSH: That's the difference between building with AI and just asking it for answers.

ERIK: Exactly. Asking AI questions is fine. Building with AI means the answer becomes an event, the event becomes a workflow, and the workflow leaves evidence. If it can't leave evidence, it doesn't touch anything important.

[pause]

JOSH: Let's move to npm v12. The headline says Git and remote dependency resolution become opt-in by default. Why is that a big deal?

ERIK: Because `npm install` has been too trusting for too long. Developers treat install like a harmless download. It's not. It's code execution wearing a hoodie.

JOSH: That's a pretty dark hoodie.

ERIK: Accurate hoodie. Package installs can run scripts. Remote dependencies can change. Git URLs can point at things you didn't audit. One compromised dependency and your build machine becomes the softest target in the room.

JOSH: So npm is tightening the default.

ERIK: Right. npm v12 is saying, “you want this remote thing? Prove it.” That will break some builds. Good. Broken builds are feedback. Silent compromise is worse.

[beat]

ERIK: Builders should upgrade to npm 11.16.0 or later now and start testing the stricter behavior before July 2026. Don't wait until the release lands. Run it in CI. Find the packages that depend on sketchy install behavior. Replace them or explicitly approve them.

JOSH: Is this just a JavaScript problem?

ERIK: No. JavaScript is just louder because npm is everywhere. Python has the same class of issue. Containers have it. GitHub Actions have it. Terraform providers have it. Any system that pulls code from the internet and runs it during build has a supply-chain problem.

JOSH: What does that mean for a small team?

ERIK: Small teams need fewer dependencies and stricter gates. That sounds boring, but it's how you stay alive. Pin versions. Use lockfiles. Block unknown post-install scripts. Cache known-good artifacts. Scan dependency diffs like you scan code diffs.

[beat]

ERIK: In my world, PrimeRouter doesn't get a dependency update because “npm said yes.” It goes through review. Same with ScanBrief. Same with InkEngine. If a package changes behavior, I want a system catching that before it becomes a morning surprise.

JOSH: Where does AI fit into that?

ERIK: This is a perfect agent job. Not “please secure my app.” That's junk. Give the agent a lockfile diff. Tell it to classify risk. New maintainer? New install script? New transitive dependency with network access? New Git dependency? Have it produce a short review with evidence.

JOSH: And then Gandalf gets involved?

ERIK: Yeah. Gandalf can block the merge if the risk is wrong or the proof is thin. That's how agents should work. One agent proposes. Another reviews. The pipeline enforces. Nobody gets a magic wand.

JOSH: That's a very specific architecture.

ERIK: It has to be. “AI in CI” without policy is just a faster way to create a mess. Put the agent in one lane. Give it inputs. Require outputs. Validate those outputs. Store the decision. Then you can trust the pattern over time.

[beat]

ERIK: Also, builders need to stop pretending convenience is free. Every package you add is a vendor relationship. Maybe tiny. Maybe unpaid. Still a relationship. If that maintainer gets compromised, bored, angry, or bought, your build inherits the problem.

JOSH: That's grim, but fair.

ERIK: It's not grim. It's normal engineering. Networks taught us this years ago. You don't let random devices join a production routing domain because they asked nicely. Same idea. Dependencies need admission control.

[pause]

JOSH: The third deep story is Google and AI Overviews. A German ruling says Google can be liable for false answers. Why does that matter beyond Google?

ERIK: Because it moves AI output from novelty to responsibility. If your product summarizes something and a user relies on it, you may own the damage. That's the whole shift.

JOSH: Is that going to make companies pull back?

ERIK: Some will. The sloppy ones should. If your AI feature is just a text box glued to a model, legal pressure is going to hurt. If your system has citations, audit logs, confidence thresholds, and a route to human review, you're in better shape.

JOSH: That sounds like ScanBrief.

ERIK: ScanBrief scored 99 items across 54 sources today. It doesn't just ask a model, “what's news?” It pulls from feeds, scores relevance, ranks stories, and keeps source context. That matters because summaries are cheap. Traceable summaries are the product.

[beat]

ERIK: If an AI says “Company X got acquired” and it's wrong, I want to know which source caused it, what the score was, what model touched it, and whether another source confirmed it. Without that, you're just publishing fog.

JOSH: So the ruling is really about accountability.

ERIK: Yes. And builders should take it seriously before regulators force them to. Every AI output should have a provenance story. Where did the data come from? What transformed it? What confidence did the system have? Was there a human approval path for risky cases?

JOSH: What counts as risky?

ERIK: Anything with money, health, legal claims, employment, security, or reputation. If the answer can cost somebody cash, access, a job, or public trust, don't treat it like a chatbot response. Treat it like a change request.

JOSH: That's a good way to frame it.

ERIK: Same pattern as infrastructure. A config change can take down a network. A false AI answer can take down trust. Different blast radius, same discipline.

[beat]

ERIK: This is where HumanRail-style thinking matters. When confidence is low, route to a person. When sources disagree, don't hide it. When the model is guessing, say it's guessing or don't publish it.

JOSH: But doesn't that slow everything down?

ERIK: A little. Good. Speed without control is not speed. It's gambling with better fonts.

JOSH: That's going on a mug.

ERIK: Please don't.

[beat]

ERIK: Look, I want AI everywhere. I'm the guy building agents to replace manual work. But replacing manual work doesn't mean removing judgment. It means putting judgment at the right choke points so humans aren't clicking the same button 400 times.

JOSH: How does this apply to a builder shipping a small app?

ERIK: Add source links. Store prompts and model responses for important actions. Add a confidence threshold. Put a review queue in front of anything risky. Let users report bad output. And when the AI makes a claim, make the UI show why.

JOSH: Not flashy.

ERIK: Correct. Useful beats flashy. The builders who win here won't be the ones with the cutest demo. It'll be the ones whose systems can survive contact with users, lawyers, outages, and Tuesday.

[pause]

ERIK: This episode is sponsored by Prime Automation Solutions. If you're still doing it manually, we automate it. Also, special on a website — $250. primeautomationsolutions.com

[pause]

JOSH: Alright, what's the AI pro tip today?

ERIK: Make your agent produce a receipt before it changes anything.

[beat]

ERIK: Here's the pattern. Give the agent a task, but require five fields before execution: observed problem, files touched, tests to run, rollback plan, and risk level. If any field is missing, the agent stops. If the risk level is high, it routes to review.

JOSH: So the prompt is basically a gate.

ERIK: The prompt is part of it. The system enforcement is the real part. Don't trust the model to remember your policy. Put the policy in code. Have CI reject an agent patch if the receipt is missing. Have another model review the receipt against the diff. Make the boring paperwork automatic.

[beat]

ERIK: You can do this today with Claude, GitHub Actions, and a simple JSON schema. The model writes the receipt. CI validates the schema. Tests run. A reviewer agent checks whether the receipt matches the patch. Then a human or your merge policy decides.

JOSH: That's practical.

ERIK: It also changes behavior. Agents do better work when they know they have to explain the work in a structured way. Same as engineers. 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, June 9. This is Build or Be Replaced, powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.

ERIK: Today's theme is simple: AI isn't slowing down. The bottleneck moved to compute, trust, and who owns the workflow.

JOSH: Stick around, Erik's got an AI pro tip at the end about making agents prove their work before they touch production.

[pause]

JOSH: First up, Apple looks like it's rebuilding Apple Intelligence around Google Gemini models. Big deal, or just branding?

ERIK: Big deal. Apple doesn't need the flashiest demo. They need AI that works inside the phone, respects privacy, and can actually touch apps without making a mess.

JOSH: And Siri is apparently getting the real treatment this fall.

ERIK: Siri has been the punchline for years. If Apple gives it context, app actions, visual search, and a sane privacy model, it stops being a voice assistant and starts being a local operator.

JOSH: Next one is weird. xAI is starting to look like a datacenter business.

ERIK: That's the story. Frontier AI is not only about models anymore. It's power, GPUs, buildings, fiber, cooling, and contracts. The lab with the most compute wins more often than the lab with the best tweet.

JOSH: Last headline. Microsoft's open source tools were hacked to steal passwords from AI developers.

ERIK: That one should get everyone's attention. AI builders are wiring keys, tokens, agents, and cloud access together fast. If your dev toolchain gets poisoned, the attacker doesn't need to beat your model. They just ride your credentials.

[pause]

JOSH: Let's start with Apple. Every year people say Siri is fixed. Why is this one different?

ERIK: Because Apple is changing the architecture, not just the voice. That's the part that matters.

[beat]

ERIK: Old Siri was a command parser with a nice microphone. Set a timer. Call my wife. Play a song. It had narrow actions, and it failed in ways that made you stop trusting it.

JOSH: Very familiar.

ERIK: Exactly. Once a tool embarrasses you twice, you stop using it. That's the real Siri problem. Not capability. Trust.

JOSH: So what changes if Gemini-style models are underneath it?

ERIK: You get better reasoning over messy input. You get multimodal support. You get a model that can look at context instead of waiting for perfect phrasing. And if Apple wires it into apps properly, it can take actions across the system.

JOSH: Like what?

ERIK: Pull the tracking number from one email, find the delivery photo, text it to the contractor, and add a reminder if nobody replies by noon. That's not magic. That's workflow glue.

[beat]

ERIK: The trick is Apple has to make it feel boring. Boring is good here. If Siri becomes an agent on a billion phones, the win isn't some wild demo on stage. It's ten tiny actions a day that don't fail.

JOSH: Where does privacy fit into that?

ERIK: That's Apple's best angle. Run what you can on device. Send only what you must to cloud models. Make the boundary visible enough that normal people don't have to read a system diagram to feel safe.

JOSH: You're building a lot of agent stuff. Does this match what you see in your own systems?

ERIK: Completely. PrimeBus processed 866 automation events across 14 projects today. That sounds like a big number, but the reason it works is boring plumbing. Events come in. Agents subscribe. Guardrails check outputs. Actions happen only when the rules say they can happen.

JOSH: That's the phone version?

ERIK: Pretty much. The phone is the bus. Apps are services. Siri becomes the agent layer. The calendar, mail, messages, photos, reminders, files, all of that becomes callable infrastructure.

JOSH: Wait, really?

ERIK: Yeah. People think of phones as apps. Builders should think of phones as local infrastructure with sensors, identity, payment, storage, and user context. Apple owns the best runtime for personal agents if they don't fumble the permissions model.

JOSH: What's the risk?

ERIK: Half measures. If Siri can summarize but can't act, people shrug. If it can act but asks for confirmation on every tiny step, people turn it off. If it acts without proof, people stop trusting it.

[beat]

ERIK: Agent design is not "let the model do stuff." That's how you wake up to weird calendar invites and an apologetic status page. Good agent design is intent, plan, evidence, action, audit trail.

JOSH: That sounds like your production pipeline.

ERIK: It is. The PrimeBus auto-merger has run 367 attempts since 2026-06-05: 282 merged, 85 blocked by Gandalf, 0 escalated to Erik. That's the part I care about. Not just the 76.8% merge rate. The 85 blocked tells me the guardrails are doing work.

JOSH: So Apple needs a Gandalf.

ERIK: Everybody needs a Gandalf. Especially your phone.

[pause]

JOSH: The xAI story is stranger. The headline says it looks more like a datacenter REIT than a frontier lab. What does that mean in normal words?

ERIK: It means compute is becoming the product. Not the model. Not the chatbot. The GPUs.

JOSH: That's wild.

ERIK: It is, but it makes sense. Frontier labs are hungry all the time. Training needs massive clusters. Inference needs massive clusters. Peak usage is brutal. If a company controls enough power and hardware, it can sell capacity to other labs and suddenly it's not only competing with them. It's feeding them.

JOSH: So xAI partnering with Anthropic and Google for compute isn't as weird as it sounds?

ERIK: Not weird at all. It's infrastructure economics. If you have idle capacity, sell it. If someone else has a capacity crunch, buy time. Everyone talks about intelligence like it's floating in the air. It isn't. It's sitting in racks, pulling power, waiting on network fabric.

JOSH: How does that change what builders should care about?

ERIK: Stop treating model choice like religion. You need routing. You need fallbacks. You need telemetry. You need cost controls. The model is one dependency in the path.

[beat]

ERIK: That's why PrimeRouter exists in my stack. I don't want one provider outage turning my systems into a very expensive paperweight. Route by priority. Track latency. Watch token spend. Fail over when the provider gets weird.

JOSH: Is that overkill for a small builder?

ERIK: No. A simple version is not overkill. Even a basic gateway that says "use Claude for code review, use a cheaper model for summaries, fall back if latency crosses a threshold" will save you pain.

JOSH: Where does local AI fit?

ERIK: Local matters more every month. Hermes runs on a Mac M3 with qwen3-coder at 70 tokens per second. That's not replacing every cloud model, but it's enough for private code tasks, small reviews, extraction, routing decisions, and offline work.

JOSH: So cloud for power, local for control?

ERIK: That's the clean split. Cloud models are your heavy machinery. Local models are your shop tools. You don't rent a crane to tighten a bolt.

JOSH: Nice.

ERIK: And you don't send every secret to a cloud model just because the API is easy. Builders need to get serious about data boundaries. What can run local? What needs the frontier model? What needs a human?

JOSH: Is this why companies are acting like compute is oil?

ERIK: Yeah, except oil doesn't ask for more context window every quarter.

[beat]

ERIK: The labs know demand is not linear. Better models create more use cases. More use cases create more inference. More inference creates more infrastructure demand. That's the loop.

JOSH: And if you own the loop?

ERIK: You print options. You can train. You can sell capacity. You can negotiate with other labs. You can survive spikes. Compute is leverage in the plain English sense. It's power.

JOSH: You used the forbidden word.

ERIK: Fair. Compute is a big hammer. Better?

JOSH: Much better.

[pause]

JOSH: The Microsoft toolchain hack feels like the one that should scare regular developers. What happened there?

ERIK: Attackers went after open source tools used by AI developers and stole passwords. That's the simple version. The important part is the target selection.

JOSH: Why AI developers specifically?

ERIK: Because AI developers are connecting everything. GitHub tokens. Cloud credentials. Slack bots. Vector databases. Browser automation. Deployment keys. Agents with permissions. If you compromise that workstation or package path, you might get access to the whole build system.

JOSH: So the agent becomes the blast radius.

ERIK: Exactly. A normal script with bad permissions is bad. An agent with bad permissions is worse because it can discover things, call tools, and chain actions together.

JOSH: How do you defend against that?

ERIK: First, don't give agents broad credentials. Give them scoped tokens. Read-only where possible. Short-lived where possible. Separate dev from prod. Separate review from merge. Separate observation from action.

[beat]

ERIK: Second, log every tool call. If your agent can run Terraform, Selenium, kubectl, NSO actions, or GitHub writes, you need an audit trail. Not vibes. Logs.

JOSH: What should those logs include?

ERIK: Who requested it, what model produced it, what tool ran, what input went in, what output came back, what changed, and what gate approved it. That's minimum.

JOSH: Sounds heavy.

ERIK: It sounds heavy until an agent deletes the wrong thing and your only incident note is "Claude seemed confident."

JOSH: Fair.

ERIK: Third, put review gates where money or production is involved. In my world, Gandalf reviews changes before merge. It blocked 85 auto-merger attempts in the last 7 days, and 0 escalated to me. That's not bureaucracy. That's the system catching risk before I have to.

JOSH: What about developers using random packages?

ERIK: Pin versions. Use lockfiles. Watch dependency changes. Don't install mystery CLIs with your main shell profile loaded. Run suspicious tools in a container. Keep secrets out of env files that every tool can read.

JOSH: People won't love that.

ERIK: People also don't love rotating every credential after a compromised npm package. Pick your pain.

[beat]

JOSH: Does AI make supply chain security harder?

ERIK: Much harder. It increases speed. Speed exposes weak process. If a human used to copy one command from a README, now an agent may run ten commands, inspect files, install packages, and open PRs before coffee.

JOSH: That sounds like the future and a headache.

ERIK: It is both. The answer is not "don't use agents." That's losing. The answer is make agents operate like junior engineers with badges that only open certain doors.

JOSH: What do you mean by badges?

ERIK: Permission tiers. One agent can read logs. Another can propose code. Another can open a PR. A different gate can merge after tests and review. Don't give one model the keys to the building because it wrote a nice summary.

JOSH: How does this connect to network automation?

ERIK: Same pattern. In Cisco NSO, you don't let every workflow push service changes everywhere with no dry run. You validate intent. You check diffs. You commit through controlled paths. AI doesn't remove that discipline. It makes it mandatory.

JOSH: So the boring controls win again.

ERIK: Always. Boring controls are undefeated.

[pause]

JOSH: There was also OpenCV 5 in the feed today. Quick builder take?

ERIK: Computer vision is quietly becoming normal infrastructure. Cameras, OCR, screenshots, UI tests, factory lines, document processing. OpenCV 5 matters because vision isn't only research now. It's another sensor input for automation.

JOSH: Would you wire that into agents?

ERIK: Absolutely. Selenium can drive the browser, but vision can verify what actually rendered. That's useful. DOM says the button exists. Vision says the modal covered it. Big difference.

JOSH: That's painfully specific.

ERIK: Because it happens.

[pause]

ERIK: This episode is sponsored by Prime Automation Solutions. If you're still doing it manually, we automate it. Also, special on a website — $250. primeautomationsolutions.com

[pause]

JOSH: Alright, what's the AI pro tip today?

ERIK: Make your agent produce evidence before it takes action.

[beat]

ERIK: Not a paragraph saying "I checked it." Evidence. Command output. Test results. Diff summary. File paths. API response. Screenshot. Whatever proves the action is safe.

JOSH: Give me the actual prompt.

ERIK: Use this: "Before making any write action, list the exact evidence you have, the command or tool that produced it, the risk if you're wrong, and the smallest reversible action you can take next."

[beat]

ERIK: Then enforce it. If the evidence field is empty, the tool call doesn't run. If the risk is high, route to a human. If the action isn't reversible, require a second review.

JOSH: That's practical.

ERIK: That's how you move fast without pretending the model is magic. Agents don't need trust. They need boundaries and receipts. 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, June 8. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.

ERIK: Today's theme is simple: AI agents are entering the workplace, and the real product is control.

JOSH: Stick around — Erik's got an AI pro tip at the end about using model disagreement as a safety system.

JOSH: [pause]

JOSH: First headline: Microsoft Build pushed hard on agent infrastructure. Are we past the chatbot phase?

ERIK: Yep. Microsoft is talking agent runtime, model catalogs, Work IQ APIs, and sandboxed execution. That's not chat. That's plumbing for software that acts.

JOSH: Second: Anthropic filed confidential IPO paperwork, and the AI cost conversation got loud again.

ERIK: Good. The bill finally showed up. Everyone loves frontier models until finance asks why one support workflow costs more than the humans it replaced.

JOSH: Third: researchers keep calling out AI slop in software development. Is that just developers complaining?

ERIK: No. Review burden is real. If AI generates ten bad patches and a senior engineer has to clean them all up, you didn't automate work. You moved the pain.

JOSH: [pause]

JOSH: Microsoft is the first deep one. Agent infrastructure sounds boring. Why should builders care?

ERIK: Boring is where the money is. The flashy demo is the agent booking a meeting or editing a spreadsheet. The real question is what files it can touch, what network calls it can make, what secrets it can see, and who gets blamed when it does something dumb.

JOSH: That's the part most demos skip.

ERIK: Always. Demos love the happy path. Production is where your agent finds an old API token, writes to the wrong repo, and calls it confidence. That's why the Microsoft Execution Containers idea matters. Give agents a box. Give that box rules. Limit file access. Limit network access. Limit UI access. Then log everything.

JOSH: So you're saying the sandbox is the product.

ERIK: For enterprise AI, yes. The model is only one piece. You need identity, policy, audit trails, rollback, and a way to prove what happened. That's why agent runtime matters more than another clever chat window.

JOSH: How does that compare to what you run?

ERIK: PrimeBus is the same pattern in my lab. NATS moves the events. Agents subscribe to specific messages. PrimeSentinel watches for stuck jobs. Claude can propose fixes, but it doesn't get a crown and a sword. It gets a task, context, guardrails, and a review path.

JOSH: Wait, really?

ERIK: Really. If a job fails, the event says what failed. Not "something broke." Test output, repo, branch, service, timestamp. The agent has a narrow job. It can inspect. It can patch. Then another layer reviews. That is very different from "hey Claude, go fix production."

JOSH: That's the line.

ERIK: That's the whole line. Agents need lanes. A network engineer understands this immediately because we've had blast radius drilled into us forever. You don't push a global BGP change because a script felt inspired. You stage it. You validate it. You roll it back if it gets spicy.

JOSH: And Microsoft is trying to give that shape to office work?

ERIK: That's how I read it. Work IQ APIs are about context. Teams, Outlook, documents, meetings. The agent can understand the work graph. But context without control is dangerous. If the agent knows everything and can act everywhere, congrats, you built an intern with root access.

JOSH: That's a sentence that should be on a coffee mug.

ERIK: Probably a warning label. The useful version is smaller. Let the agent prepare a meeting brief. Let it draft the follow-up. Let it find the customer thread. But when money moves, contracts change, production config changes, or customer data leaves the system, you need gates.

JOSH: Where do builders start if they don't have Microsoft's whole stack?

ERIK: Use the same architecture with smaller tools. Put events on a bus. NATS, Redis Streams, Kafka, whatever fits. Store the raw inputs. Give each agent a role. One reads logs. One writes a patch. One reviews. One decides if a human is required. Don't let a single model do read, write, approve, and deploy.

JOSH: Separation of duties for robots.

ERIK: Exactly. Boring security words become exciting when the robot can type faster than your team can review. In NSO, Terraform, Kubernetes, same deal. The tool doesn't matter. The pattern matters. Intent comes in. Plan gets generated. Policy checks it. Human or system approves it. Then execution happens with evidence.

JOSH: [beat]

JOSH: That sounds slower than the hype version.

ERIK: It is slower than a reckless demo. It's faster than cleaning up a bad deployment at 2 AM. People keep confusing speed with absence of friction. Some friction is the point. PrimeBus blocking a bad merge is not lost velocity. That's the system paying for itself.

JOSH: And this connects to cost too, right?

ERIK: Directly. Every bad agent action has two costs. Token cost and human cost. The token bill is annoying. The human cleanup bill is the killer. If your agent writes junk and a senior engineer spends twenty minutes proving it's junk, that's expensive junk.

JOSH: [pause]

JOSH: That tees up Anthropic. IPO filing, huge valuation talk, and everyone suddenly cares about AI spending.

ERIK: The money conversation was always coming. These companies need massive compute, massive talent, massive distribution, and customers who don't churn when the novelty wears off. An IPO filing makes that visible.

JOSH: Why does that matter to someone building small systems?

ERIK: Because model economics hit everyone. If you build a workflow where every tiny task goes to the biggest model, you built a fancy furnace. It burns money beautifully.

JOSH: So don't use the best model?

ERIK: Use the right model. That's different. Claude is great for code reasoning and long messy context. A smaller model might be fine for classification. Embeddings might handle routing. Regex might handle the dumb part. Selenium might pull the page. A cron job might schedule it. Not every problem deserves a frontier model invoice.

JOSH: That feels less glamorous.

ERIK: Glamour is for pitch decks. Builders need margins. ScanBrief doesn't need a frontier model for every step. Feed collection is boring plumbing. Deduping can be deterministic. Ranking needs judgment. Summaries need care. The trick is matching the expensive thinking to the part where thinking matters.

JOSH: How do you decide?

ERIK: I look at failure cost. If a mistake is cheap, use cheap tools. If a mistake is expensive, use stronger models and more review. If the task touches money, production, compliance, or customer trust, add gates. That's not complicated. People make it complicated because they want one magical model policy.

JOSH: The pricing pressure could actually make systems better.

ERIK: Absolutely. A token budget forces architecture. When compute feels free, people get sloppy. They paste giant logs into a prompt and call it engineering. When the bill hurts, suddenly they learn to chunk logs, extract the error, cache results, and stop asking the model to read a novel because one line failed.

JOSH: That's wild, because the cost problem becomes a discipline problem.

ERIK: Yep. Same as cloud. Everybody loved spinning up instances until the AWS bill started teaching architecture. AI is getting the same education. The model bill is going to create better builders and expose prompt tourists.

JOSH: Prompt tourists?

ERIK: People who can make a demo but can't keep a system alive. They know model names. They know launch threads. They don't know retries, idempotency, queues, or why your automation needs a dead-letter path. That's the gap.

JOSH: How does a small team avoid getting crushed by that?

ERIK: Instrument first. Track every model call. Prompt, model, latency, cost, output type, result. Did the action succeed? Did a human edit it? Did the patch pass tests? Did the customer accept it? If you don't measure that, you're just vibes with a credit card.

JOSH: That applies to big companies too.

ERIK: More, honestly. Big companies can hide waste longer. A solo builder feels the burn fast. In the Echo and Neo lab, I care when an agent loops. PrimeSentinel exists because stuck jobs are real. A loop is not a philosophical issue. It's compute turning into heat while nothing useful ships.

JOSH: [beat]

JOSH: So the IPO story isn't just Wall Street gossip.

ERIK: No. It's a signal that AI is moving from toy budget to operating budget. Once it hits operating budget, CFOs ask rude but useful questions. What did it replace? What did it reduce? What risk did it add? What revenue did it create? Those are the right questions.

JOSH: [pause]

JOSH: Third deep one: AI slop in software development. This one stings a little.

ERIK: It should. AI can make good engineers faster and bad processes louder. That's the honest version.

JOSH: What do you mean by louder?

ERIK: A weak engineer used to submit one shaky pull request. Now they can submit five. A rushed team used to create a little tech debt. Now they can create a whole landfill with tests that barely mean anything. The model didn't invent the problem. It multiplied it.

JOSH: That's bleak.

ERIK: It's accurate. But it's fixable. The answer is not "ban AI." That's lazy. The answer is to treat AI-generated work like untrusted input until it proves itself.

JOSH: What does that look like in practice?

ERIK: Small patches. Clear diffs. Tests required. No drive-by refactors. No touching unrelated files. No dependency changes without a reason. No generated code that the author can't explain. And if the model says "minor cleanup," that diff better be tiny.

JOSH: You're describing review rules.

ERIK: Yes. AI didn't remove engineering discipline. It made discipline more important. I use Claude every day, but I don't worship the output. I make it show its work through tests, logs, and diffs.

JOSH: Where do people go wrong with code agents?

ERIK: They ask for outcomes that are too broad. "Improve this service." Terrible prompt. What does improve mean? Faster? Safer? Less memory? Fewer retries? Better logs? If you can't define the change, the agent will decorate the codebase.

JOSH: Decorate is brutal.

ERIK: Accurate though. I've seen AI patches that rename variables, move files, add abstractions, and somehow don't fix the bug. That's interior design for a failing test.

JOSH: How do you keep it tight?

ERIK: Give the agent a failing test or a specific error. Tell it the allowed files. Tell it what not to change. Tell it to make the smallest patch. Then run the tests. If it fails, feed back the exact failure. Don't let it wander.

JOSH: That's very different from "build me an app."

ERIK: Big greenfield prompts are fine for prototypes. Production work needs constraints. Same with network automation. If I'm using NSO or Terraform, I don't ask an agent to "make the network better." I ask it to generate a candidate change for this service, against this schema, with this rollback path, and this validation.

JOSH: That makes the AI useful.

ERIK: It makes it accountable. Useful comes after accountable. The agent has to produce an artifact you can judge. Patch. plan. test. config. summary. Anything else is smoke.

JOSH: How does Josh, not an automation engineer, spot AI slop in a pull request?

ERIK: Look for three things. First, scope creep. Did it touch files that don't relate to the request? Second, fake certainty. Does the summary sound confident but avoid specifics? Third, missing proof. No tests, no logs, no before-and-after evidence.

JOSH: That's actually easy to remember.

ERIK: Good. Add one more. If the code is more abstract after the fix, ask why. Sometimes abstraction is right. A lot of times the model just got fancy because fancy looks smart.

JOSH: That's the quiet danger.

ERIK: Yep. Fancy code creates future bills. The best AI patch often looks boring. One condition fixed. One test added. One log improved. No parade.

JOSH: [beat]

JOSH: How does this connect back to being replaced?

ERIK: The engineer who can only type code is in trouble. The engineer who can define work, constrain agents, review output, and wire systems together is dangerous. That's the replacement line.

JOSH: Dangerous in the good way.

ERIK: In the "gets shipped before the meeting ends" way. If you know Claude, NATS, Selenium, Terraform, Kubernetes, and basic business math, you can build systems that make whole categories of manual work look silly.

JOSH: And if you don't?

ERIK: Then you're competing with someone who does. That's not a threat. That's the weather.

JOSH: [pause]

ERIK: This episode is sponsored by Prime Automation Solutions. If you're still doing it manually, we automate it. Also, special on a website — $250. primeautomationsolutions.com

JOSH: [pause]

JOSH: Alright, what's the AI pro tip today?

ERIK: Use model disagreement as a safety system. Take one real task today. A bug fix, a Terraform plan, a customer email, anything with consequences. Send the same context to two models or two separate agent runs. Don't ask which one sounds better. Ask where they disagree.

JOSH: What are you looking for?

ERIK: Differences in assumptions. One model changes a dependency, the other doesn't. One says the test needs updating, the other says the code is wrong. One spots a security issue, one misses it. That disagreement is signal.

JOSH: Then what?

ERIK: Make a third step. A reviewer prompt. Feed it both answers and ask for risks, not a winner. Then you decide or route it to a human. This works because agreement can be lazy, but disagreement shows the edge of the problem. Do it before the merge, not after production teaches you manners. That's your tip. Use it.

JOSH: [pause]

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

JOSH: [pause]

JOSH: One more thing — we started a Discord for builders. If you're shipping AI, automation, or anything that makes a human obsolete — come hang out. Link at buildorbereplaced.dev.

ERIK: Post what you built. We'll post what we're building. Real wins, real builds, no fluff.

JOSH: [pause]

ERIK: Build or be replaced.

JOSH: If you want these signals in your inbox every morning, scanbrief.dev. See you tomorrow.