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

ERIK: Privacy laws, local AI, and encryption keys sitting in memory. That's a pretty good Friday if you like systems that can hurt you.

JOSH: Stick around. Erik's got an AI pro tip at the end about the short leash method for coding agents.

[pause]

JOSH: First headline. Virginia just banned the sale of geolocation data. Big privacy move?

ERIK: Yep. The key word is sale. They defined it as money changing hands between controllers and third parties. Narrow definition, but it's still another state saying location data is not just harmless exhaust from an app.

JOSH: Next one. Right to Local Intelligence. Sounds like AI policy language.

ERIK: It is, but the idea is solid. Run the model near the user, on the device when you can, and stop shipping every private thought to somebody else's cloud. Local inference is going to matter more than people think.

JOSH: Third headline. Since Linux 6.9, LUKS suspend stopped wiping disk encryption keys from memory. That sounds bad.

ERIK: That is the kind of boring kernel detail that becomes a real incident later. Disk encryption only helps if the key handling is tight. If suspend leaves keys around, your laptop threat model just changed.

[pause]

JOSH: Let's start with Virginia. Why does a state geolocation law matter to builders?

ERIK: Because location data is one of those things teams collect casually and then forget they're holding a loaded weapon.

[beat]

ERIK: A phone ping is not just a dot on a map. It's where you sleep, where you work, what doctor you visited, what church you attend, which protest you walked past, and where your kids go after school.

JOSH: Wait, really? From just location?

ERIK: Absolutely. You don't need a spy movie. Give me enough points over time and I can infer a life. That's why selling it is nasty. The customer didn't really consent to that. They clicked through a screen so a flashlight app could work.

JOSH: But Virginia's law defines sale pretty narrowly. Does that weaken it?

ERIK: It does. If money has to change hands, a lot of data sharing gets dressed up as partnership, analytics, fraud prevention, ad measurement, whatever. Same data movement, different label. Lawyers are good at that. Shocking development.

[beat]

ERIK: But it's still a signal. States are tired of waiting for federal privacy law. Builders need to assume location data is regulated, sensitive, and radioactive if mishandled.

JOSH: What would you do differently if you're building an app today?

ERIK: First, don't collect precise location unless the feature dies without it. Second, separate location from identity as early as possible. Third, set a retention clock. If the data isn't needed tomorrow, delete it today.

JOSH: That's the opposite of the usual product instinct.

ERIK: The usual product instinct is hoard everything and call it future insight. That's how you end up explaining a CSV export to regulators.

[beat]

ERIK: In ScanBrief today, it scored 88 items across 54 sources. I don't need to store every raw artifact forever to make the product useful. Score it, summarize it, keep what matters, drop what doesn't. Same mindset applies to location.

JOSH: So privacy by deletion.

ERIK: Exactly. Deletion is architecture. It's not a cleanup task. Build the pipeline so data ages out by design.

JOSH: How does this connect to automation teams?

ERIK: Automation teams love telemetry. I love telemetry. PrimeBus processed 993 automation events across 15 projects today. That data is gold for debugging. But I don't treat every event the same. Some events can live forever as counters. Some should expire. Some should never contain secrets in the first place.

JOSH: That's the part people skip.

ERIK: Yep. They log the whole payload because it's convenient. Then the logs become the breach.

[pause]

JOSH: The second story pairs with that. Right to Local Intelligence. What is local AI actually solving?

ERIK: It solves three problems. Privacy, latency, and control.

[beat]

ERIK: Privacy because the data stays on the device. Latency because you're not waiting on a cloud round trip. Control because the user can run the tool even if a provider changes terms, rate limits, or has an outage.

JOSH: But aren't the best models still in the cloud?

ERIK: For heavy reasoning, yes. Claude, GPT, Gemini, the big models still win on hard tasks. But not every task needs a giant brain in a data center.

JOSH: Give me an example.

ERIK: Email triage. Meeting notes cleanup. Local search over personal files. Small code edits. Screenshot classification. Command suggestions. A local model can handle a lot of that without shipping private data off the box.

JOSH: Where do you draw the line?

ERIK: Route by risk and complexity. That's the whole trick.

[beat]

ERIK: Low-risk, low-complexity tasks go local. High-complexity tasks go to a frontier model. Sensitive tasks get redacted first or stay local. If confidence drops, send it to a human or a stronger model with a smaller context window.

JOSH: That sounds like HumanRail.

ERIK: Yeah. HumanRail exists because agents should not pretend they're sure when they're not. Route the work. Put confidence thresholds on it. If the model is guessing, stop and ask.

JOSH: People hear local AI and think, fine, but it won't be as smart.

ERIK: That's the wrong test. The test is whether it's smart enough for the job. A hammer doesn't need Kubernetes.

[beat]

ERIK: If I need Claude to reason through a broken Terraform module, I'll use Claude. If I need a local agent to classify a log line and decide whether PrimeSentinel should wake up a workflow, that's a smaller problem.

JOSH: So the future isn't local versus cloud.

ERIK: Correct. It's routing. Local first when it makes sense. Cloud when it earns the trip. Human when the cost of being wrong is high.

JOSH: What's the builder mistake here?

ERIK: Treating every AI call like a chat app. Prompt in, answer out. That's not a system. A system has policies. What data can leave? What model gets used? What gets logged? What gets retried? What gets blocked?

JOSH: And what gets deleted.

ERIK: Exactly. Privacy and automation are tied together. The more agents you run, the more important your data boundaries get.

[pause]

JOSH: Let's hit the Linux LUKS story. Disk encryption keys not being wiped from memory after suspend since Linux 6.9. How serious is that?

ERIK: Depends on your threat model, but it's not nothing.

[beat]

ERIK: LUKS protects the disk at rest. If the machine is powered off and someone steals it, they need the passphrase or key material. But suspend is different. The machine is sleeping. RAM may still hold secrets.

JOSH: So encryption is only as strong as the state the machine is in?

ERIK: Yep. Security is always stateful. Powered off, locked, suspended, hibernated, logged in over SSH, screen locked with agents running. Those are not the same condition.

JOSH: Who should care about this?

ERIK: Anyone carrying a Linux laptop with sensitive data. Engineers, journalists, lawyers, finance people, security teams. Also anyone who says, "It's fine, my disk is encrypted," and then suspends the laptop in an airport.

JOSH: That's a lot of people.

ERIK: It is. Suspend is convenient. Convenience is usually where security goes to get mugged.

[beat]

JOSH: What would you change?

ERIK: If the data matters, prefer full shutdown or hibernate with proper swap encryption over suspend. Keep firmware updated. Watch distro advisories. And test your own fleet behavior instead of assuming the blog post matches your setup.

JOSH: How do you test something like that in a real environment?

ERIK: Make it boring. Inventory kernel versions. Track suspend settings. Flag machines on risky combinations. Put it in your dashboard. PrimeDash exists because I don't want to guess what the lab is running.

JOSH: That's the difference between reading about risk and managing risk.

ERIK: Exactly. Reading the headline is step one. Turning it into a check is the builder move.

[pause]

JOSH: Another headline today was Podman v6.0.0. You use containers all over the place. What do you look for in a release like that?

ERIK: I look for boring improvements. Better networking, better systemd behavior, fewer weird edge cases around rootless containers, cleaner compatibility with Docker workflows. Containers are plumbing. Plumbing should not be exciting at 2 AM.

JOSH: Podman versus Docker. Do you have a side?

ERIK: Use what fits the operating model. Docker is still familiar and easy. Podman is strong when you care about rootless operation, systemd integration, and not running a big daemon for everything.

JOSH: Would you switch a production fleet just because v6 dropped?

ERIK: No. Version number is not a migration plan. I'd test it against actual services, especially anything using volumes, networking, and restart behavior. Then move one boring service first.

[beat]

ERIK: That's how I handle almost everything. Start small in the lab. Prove the win. Add guardrails. Then prod.

JOSH: That sounds very not glamorous.

ERIK: Good. Glamorous infrastructure is usually on fire.

[pause]

JOSH: The Postgres story also stood out. "Postgres transactions are a distributed systems superpower." Is that overselling it?

ERIK: Not really. Transactions are one of the reasons Postgres keeps surviving every trend cycle.

JOSH: Why do transactions matter so much?

ERIK: Because state is where systems lie to you. You think a thing happened, then half of it failed. Now the UI says paid, the ledger says unpaid, and the job queue is holding a message from the past like it's evidence.

JOSH: That's specific.

ERIK: Because it happens. Transactions let you make a group of changes atomic. All of it commits, or none of it commits. That's not fancy. That's civilization.

[beat]

JOSH: How does that become distributed systems power?

ERIK: Pair transactions with durable queues, outbox tables, idempotency keys, and careful retries. Now Postgres isn't just a database. It's the control point for reliable work.

JOSH: Is that better than adding a message broker?

ERIK: Sometimes. NATS is great. I use NATS in PrimeBus because event flow matters there. But not every app needs a separate broker on day one. A Postgres outbox can carry a shocking amount of real workload if you design it well.

JOSH: So don't add moving parts for sport.

ERIK: Exactly. Every new component is another thing with logs, upgrades, backups, metrics, and failure modes. If Postgres can solve the coordination problem cleanly, let it.

JOSH: Where would you still use NATS?

ERIK: Fanout, telemetry, agent coordination, event-driven automation. PrimeBus is built around that because agents need to react to messages across projects. Different shape of problem.

[beat]

ERIK: But for a SaaS app doing billing events, emails, user actions, background jobs, Postgres plus an outbox is often plenty. Ship the product. Don't cosplay as a hyperscaler.

[pause]

JOSH: We also had a headline about the short leash AI coding method. Since that's the pro tip later, give me the quick version now.

ERIK: Don't hand an agent the whole repo and ask it to make magic. Give it a small task, force it to inspect first, make it explain the edit, run tests, then repeat. Short leash. More control. Less cleanup.

JOSH: Sounds slower.

ERIK: It feels slower for about ten minutes. Then you stop spending two hours undoing confident nonsense.

[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 the short leash method with your coding agent today.

[beat]

ERIK: Give it one file or one behavior. Ask it to read before editing. Then make it state the plan in plain English. After the edit, require a test command or a reason why no test exists.

JOSH: What's the actual prompt?

ERIK: Say this: "Inspect the relevant files first. Do not edit yet. Tell me the smallest safe change and the test you'll run." Then after it answers, say: "Make only that change."

[beat]

ERIK: That's it. You're turning the model from a wandering intern into a tool with rails. Claude is very good when the task is bounded. It gets weird when you give it a fog machine and a dream.

JOSH: And if it finds more problems?

ERIK: New task. New leash. Don't let one fix become a renovation. 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, July 2. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.

ERIK: The theme today is control. Your phone, your robot vacuum, your code pipeline, your payment layer. If you don't own the control plane, somebody else does.

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

[pause]

JOSH: First headline. ScanBrief flagged a nasty Android story today. Malware allegedly disguised as an Android Developer Verifier service, pushed through Play Protect. Erik, what's your take?

ERIK: If that report holds up, it's brutal. The security layer becomes the delivery path. That's the nightmare version of trusted infrastructure.

JOSH: Second one. Oomwoo is an open-source robot vacuum you build yourself. ROS 2, Raspberry Pi, LiDAR, local processing. Is that a toy or a signal?

ERIK: Signal. A loud one. Local robots are coming back because cloud-dependent home devices taught everyone a lesson: rented convenience turns into abandoned hardware.

JOSH: Third headline. Cloudflare's x402 Monetization Gateway lets people charge for resources behind Cloudflare. Tiny payments for APIs and content. Interesting?

ERIK: Very. Agents need meters. If an AI agent can call your service 10,000 times, you need pricing at the request level, not a sales call and a PDF.

[pause]

JOSH: Before we go deeper, what did your own systems do this morning?

ERIK: ScanBrief scored 88 items across 54 sources today. PrimeBus processed 1010 automation events across 13 projects today. And 31 code changes were automatically reviewed by Gandalf and merged to production overnight.

[beat]

ERIK: That's the bar now. Not a dashboard you admire. A system that wakes up, reads the room, makes changes, and leaves receipts.

[pause]

JOSH: Let's start with the Android story, because that one sounds insane. How does malware end up hiding inside something people are supposed to trust?

ERIK: Trust chains are where the bodies are buried. Everybody wants to talk about the app. The APK. The permission prompt. Fine. But modern systems don't fail only at the edge. They fail in the updater, the scanner, the verifier, the helper service, the thing with elevated rights nobody wants to touch because it's "platform."

JOSH: That's the scary part. People see Play Protect and think, okay, Google checked it.

ERIK: Exactly. That's why this matters. If a malicious service is disguised as a verifier, and if it's distributed or blessed by the same path users rely on for safety, the user has no meaningful decision left. They can't inspect it. They can't remove it. They can't reason about root privileges on a consumer phone.

JOSH: What should builders take from that?

ERIK: Stop treating trust as a label. Treat it like an event stream. Who signed it? Who deployed it? What changed? What process spawned it? What permissions did it gain after install? Did it call home? Did its behavior change after a config pull?

[beat]

ERIK: That's boring work. Which means it actually matters.

JOSH: How does that map to your world? You're not shipping Android system services.

ERIK: Same pattern. PrimeBus doesn't trust a thing because it has a nice name. Every automation event carries context. Origin, project, severity, what agent touched it, what Gandalf reviewed, what got blocked. The auto-merger has run 1856 attempts since 2026-06-05: 1202 merged, 654 blocked by Gandalf, 0 escalated to Erik. That's the important part. The blocked count is the system doing its job.

JOSH: Wait, zero escalated to you?

ERIK: Zero escalated to me. Because the guardrails are built into the work path. Not stapled on after. Gandalf is not vibes. It reads diffs, tests, risk, blast radius. If something smells wrong, it blocks. I want that in every system. Phones, routers, agents, CI, backups. Same idea.

JOSH: So the lesson isn't "never trust Google."

ERIK: No. The lesson is never trust a single layer. Google can have great engineers and still ship a trust-chain problem. Cisco can have great engineers and still ship a bad image. I can write good automation and still have a model propose a dumb fix at 2:13 in the morning. The answer is layered proof.

JOSH: What would layered proof look like for a normal engineering team?

ERIK: Start simple. Signed builds. Reproducible artifacts if you can. Runtime behavior checks. Permission drift detection. Network egress alerts. And for AI-generated code, separate the writer from the reviewer. Claude can write. Gandalf reviews. Tests run. Only then does PrimeBus move it forward.

[beat]

ERIK: One agent with root is not automation. That's a liability with a keyboard.

[pause]

JOSH: Next story: Oomwoo. Open-source robot vacuum. I did not expect the robot vacuum to become an infrastructure conversation.

ERIK: Duuude, the vacuum is absolutely infrastructure. It's a mobile sensor platform in your house. It has maps, cameras or LiDAR, motors, firmware, update channels, maybe microphones, maybe cloud APIs. People call it a vacuum because that sounds less creepy.

JOSH: That's wild. So Oomwoo being local-first matters.

ERIK: It matters a lot. ROS 2, Raspberry Pi, 2D LiDAR, 3D-printed parts, local navigation. That's the interesting stack. You can see it. You can fix it. You can fork it. If the company disappears, the thing doesn't turn into modern art under your couch.

JOSH: But is the average person building a robot vacuum?

ERIK: No. And they don't need to. The average person didn't compile Linux in 1996 either. Builders did. Then the work moved into products. Open systems start ugly, then they get useful, then vendors either adopt the pressure or keep shipping sealed boxes with subscription plans.

JOSH: How does this compare to AI agents?

ERIK: Same fight. Local control versus cloud dependency. A lot of people are building agent workflows that only work if one SaaS API is awake, one provider likes them, one model keeps the same pricing, and one dashboard doesn't change the button name.

[beat]

ERIK: That's not a system. That's a hostage note with webhooks.

JOSH: You run multiple models and systems, right?

ERIK: Yeah. PrimeRouter sits in front of model calls so my systems don't care if the provider changes behavior. Priority-tier routing, multi-provider failover, telemetry, cost visibility. If Claude is the right tool, use Claude. If GPT is better for a job, use GPT. If one provider is down, route around it. That's basic engineering.

JOSH: So Oomwoo is the physical version of that.

ERIK: Exactly. Own the map. Own the logs. Own the firmware path. Own the failure mode. If the robot gets confused, you should be able to inspect the state machine instead of opening a support ticket and praying someone in a cloud console notices your kitchen.

JOSH: That's very specific.

ERIK: I've built enough state machines to know where the pain lives. HumanDesignApp has an iMessage state machine. Different domain, same issue. Conversation state, retries, user intent, bad inputs, provider weirdness. If you don't own state, you don't own the product.

JOSH: What would you tell someone who wants to build with robotics but isn't a robotics engineer?

ERIK: Build one boring loop. Don't start with a humanoid robot that folds laundry. Start with one sensor, one actuator, one event bus, one feedback loop. Read distance. Move motor. Publish event. React to event. Log everything.

[beat]

ERIK: That's how you learn robotics without pretending you're Boston Dynamics in a garage.

JOSH: And use ROS 2?

ERIK: If you're serious, yes. Learn ROS 2. Learn how messages move. Learn transforms. Learn why timing matters. The math is not optional, but you don't need to become a PhD before you make something move across the room without hitting a chair.

[pause]

JOSH: Third deep dive: Cloudflare x402. Charging for resources behind Cloudflare. Why does this matter for AI builders?

ERIK: Because agents are going to consume the web differently than humans. Humans browse. Agents call. They fetch, summarize, compare, retry, validate, and then call again because the first response was weird. That breaks the old business model.

JOSH: The old model being ads?

ERIK: Ads, subscriptions, enterprise contracts, API keys hidden behind sales forms. None of that fits cleanly when an agent needs one fact, one file, one calculation, or one enrichment. x402 is interesting because it puts payment closer to the request.

JOSH: Like pay-per-call for the web?

ERIK: Pretty much. The HTTP 402 status code has been sitting there forever like a reserved parking spot nobody used. Now people are trying to make it useful. Put a price on the resource. The caller pays. The request completes. No human checkout flow.

JOSH: That sounds great for APIs. Also a little dangerous.

ERIK: Both. Great because builders can charge for useful services without building a whole billing department. Dangerous because agents can spend money very fast if you don't put budgets and policy in the path.

JOSH: That feels like a PrimeRouter problem.

ERIK: It is. Every model call should have policy. Every paid API call should have policy. Who is calling? What project? What budget? What priority? Is this production or a test run? Did the agent already try five times? Is the answer worth the cost?

[beat]

ERIK: A wallet attached to an agent without limits is how you discover new kinds of regret.

JOSH: What would you build first if you were using x402?

ERIK: Metered enrichment. Something narrow. For example, an endpoint that returns a scored company profile, a contract summary, or a normalized product feed. Make the value obvious. Price it per call. Then build spend controls before you let agents loose on it.

JOSH: How does ScanBrief fit into that?

ERIK: ScanBrief already scores and ranks sources. Today it scored 88 items across 54 sources. Imagine parts of that pipeline becoming paid resources. A high-quality summary endpoint. A source reputation score. A dedupe check. Agents don't need a subscription to your entire product. They need a reliable answer right now.

JOSH: So the product becomes smaller units.

ERIK: Smaller units, clearer value. That's the big shift. Software used to be a destination. Log in, click around, export a CSV. Agents don't want your nav bar. They want the function. Give them the function and charge correctly.

JOSH: Does that hurt SaaS?

ERIK: It hurts lazy SaaS. If the only moat is a login wall around a basic database, yeah, that's rough. If your product has real workflow, data quality, domain logic, and trust, you're fine. Probably better than fine. Agents become customers, but very impatient ones.

JOSH: What should builders do now?

ERIK: Add metering to anything agents can call. Even if you don't charge yet. Count requests. Track cost. Track latency. Track failure reasons. Add per-project budgets. Add kill switches. Then when payment rails mature, you're ready.

[beat]

ERIK: Don't wait until the bill shows up to learn your agent has expensive hobbies.

[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 agents produce a review packet before they change anything. Not a paragraph. A packet. Intent, files touched, commands run, test output, risk level, rollback plan, and the exact diff.

JOSH: That sounds like slowing the agent down.

ERIK: It speeds the system up. Humans waste time because agents hide the important part in chat history. A review packet turns messy work into an artifact another agent or human can inspect. That's how Gandalf works in my world. Claude can propose the fix, but the reviewer gets the evidence.

JOSH: What's the simple version someone can use today?

ERIK: Add this to your prompt: "Before editing files, write a review packet with objective, affected files, expected behavior change, verification plan, and rollback notes. After editing, update the packet with actual commands and results." Then make that packet required in CI or your pull request template.

[beat]

ERIK: Agents are better when they know they'll be audited. Same as humans, unfortunately.

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

ERIK: AI didn't just change who writes code. It changed who has to prove the code should exist.

JOSH: Stick around — Erik's got an AI pro tip at the end about fingerprint checks for agent output.

JOSH: [pause]

JOSH: First headline. Claude Code users are reporting tiny formatting changes that could act like fingerprints. Erik, is that real signal or internet paranoia?

ERIK: Real enough to build a check for it. The claim is specific: formatting drift in dates, punctuation, and apostrophes inside agent traffic. Could be tracking. Could be a bug. Either way, invisible behavior belongs in your threat model.

JOSH: Second. Anthropic launched Claude Sonnet 5, pitched as cheaper and strong at agent work. Is that the model people should use now?

ERIK: Maybe. Sonnet is where the boring money gets spent. If it can plan, use tools, recover from errors, and not burn Opus-level cash, it belongs in the middle of an agent pipeline.

JOSH: Third. Godot maintainers are complaining about low-quality AI pull requests. Some people framed it as a ban. Is that fair?

ERIK: No. Tighten that claim. Godot maintainers said AI-generated contribution volume is wearing them down. That's not the same as a formal hard ban. The story is review capacity, not a press release.

JOSH: [pause]

JOSH: Start with Claude Code. Tiny punctuation marks sound small. Why do you care?

ERIK: Because small is exactly how this stuff survives. Nobody notices a curly quote. Nobody notices whether a date uses a slash or a dash. But machines notice. Diff tools notice. Policy scanners notice. A downstream classifier can notice.

JOSH: What would the fingerprint actually prove?

ERIK: Could prove which client created the request. Could prove a response came through a certain path. Could help abuse detection. Could be an accident from a formatter buried in the client. The scary part isn't the punctuation. The scary part is content carrying metadata the user didn't explicitly ask to carry.

JOSH: Is that different from normal telemetry?

ERIK: Completely different. Normal telemetry lives in logs, headers, request IDs, account metadata, API traces. You can route it. You can redact it. You can explain it to security. Content-level marking rides inside the thing you're publishing, committing, emailing, or shipping.

JOSH: Wait, so an agent could write a markdown file and leave a signature in it?

ERIK: That's the concern. Maybe not a deliberate signature. Maybe a consistent formatting pattern. Doesn't matter. If a pattern leaves your system and someone else can classify it later, you need to know.

JOSH: That feels like a compliance meeting waiting to happen.

ERIK: Exactly. Some poor engineer is going to get asked why generated docs have strange Unicode punctuation, and the answer cannot be, "Duuude, the robot did it." Funny answer. Bad audit answer.

JOSH: How would you handle it in your own setup?

ERIK: Put every agent artifact through a normalization gate. Code gets the repo formatter. Markdown gets quote normalization, whitespace cleanup, line ending checks, and invisible character stripping. JSON gets parsed and re-emitted by a real serializer. Don't regex your way through structured data like a maniac.

JOSH: PrimeBus would sit in the middle of that?

ERIK: PrimeBus is built for that exact shape. Agent writes output. Output lands on NATS. A subscriber inspects it. Another subscriber scores risk. If it passes, it moves forward. If it smells weird, Gandalf gets it or a human gets it.

JOSH: Gandalf is the cranky reviewer?

ERIK: Correct. Every fleet needs a cranky reviewer. Happy-path agents are fine for demos. Production agents need something in the path that says, "Nope, explain this before it touches main."

JOSH: What would the scanner look for?

ERIK: Invisible Unicode. Mixed quote styles. Date format drift. Zero-width characters. Weird whitespace. File changes that don't match the stated task. Generated text that changes after a tool handoff. Also license language, secrets, and test files that magically disappear.

JOSH: Test files disappearing feels oddly specific.

ERIK: AI agents love solving test failures by deleting the test. Very human behavior, honestly. Bad engineering, but extremely relatable.

JOSH: Is the answer to distrust Claude Code?

ERIK: No. Claude Code is still one of the best tools for real building. The answer is don't treat any agent as a clean room. Treat it like a very fast junior engineer with root access and a weird memory. Useful. Dangerous. Needs rails.

JOSH: That sounds like the new linting.

ERIK: That's the right mental model. Old linting caught style. New linting catches provenance, policy, and agent behavior. If your agents produce artifacts, those artifacts need checks before they leave the lab.

JOSH: [pause]

JOSH: Sonnet 5 now. Cheaper agentic model, better planning, more tool use. What matters there?

ERIK: Cost per useful loop. Not cost per token. Builders keep getting this wrong. A real coding agent doesn't answer once. It reads files, makes a plan, edits, runs tests, fails, reads logs, patches again, then summarizes. That loop is the product.

JOSH: So benchmarks don't tell the whole story?

ERIK: Benchmarks tell part of it. Tool loops tell the truth. A model can score great and still be annoying in a repo because it edits too much, ignores errors, or gets theatrical when it should run the test again.

JOSH: Theatrical?

ERIK: You know the move. "I've identified the likely root cause" and then it writes six paragraphs instead of opening the file. Bro, run rg. The stack trace is right there.

JOSH: Where would Sonnet 5 fit in your fleet?

ERIK: Middle layer. Hermes can handle local coding experiments on the Mac. Opus-style models are for ugly architecture calls or high-risk changes. Sonnet is for the daily work: inspect, patch, test, report, move on.

JOSH: Why not use the best model for everything?

ERIK: Because that is how you build a money furnace. Strong models are great, but every automation system has a cost curve. If the model is too expensive, you stop using it often. If you stop using it often, the automation gets stale.

JOSH: Give me a real example.

ERIK: ScanBrief is a good example. It doesn't need the most expensive model for every item. First pass is scoring, grouping, dedupe, summarization. Save the expensive reasoning for weird stories, conflicting reports, or things that affect builders directly. Same with GovContractScanner. Pull the opportunities, rank them, flag the interesting ones, then spend heavier reasoning only where the contract actually deserves attention.

JOSH: That sounds more like routing than prompting.

ERIK: Exactly. Model routing is now architecture. Prompting matters, but routing decides whether your system survives contact with the invoice.

JOSH: What do you look for before trusting a new model in an agent pipeline?

ERIK: Four things. Can it use tools without being dramatic? Can it recover after a failed command? Can it explain the diff in normal language? Can it stop when the task is done?

JOSH: Stop when done sounds easy.

ERIK: It is not easy. Agents love activity. They see an old TODO and suddenly your bug fix becomes a spiritual renovation of the repo. That's how you get a pull request that fixes one typo and redesigns authentication.

JOSH: That's wild.

ERIK: Wild, but common. Strong planning is only useful if the model respects scope. Otherwise planning becomes a bigger shovel for a bigger hole.

JOSH: What about safety? Anthropic is positioning models differently around risk.

ERIK: Sensible. Agentic models can touch browsers, shells, file systems, tickets, cloud APIs, and sometimes money. Capability is risk. A cheaper model with strong tool use needs the same controls as the expensive one: allowlists, dry runs, audit logs, budget caps, and human gates for dangerous actions.

JOSH: Budget caps are underrated.

ERIK: Very underrated. Every agent should know when to quit. Token budget, tool-call budget, retry budget, wall-clock budget. If it can't solve the task inside the box, escalate. Don't let it wander around the repo with a flashlight and vibes.

JOSH: How does this compare to network automation?

ERIK: Same lesson from NSO and Terraform. The tool can generate a change. That doesn't mean it applies the change. You validate intent, check diff, simulate impact, then push. AI agents need the same discipline. Plan, diff, test, approve, apply.

JOSH: That's less magical than people want.

ERIK: Good. Magic is terrible operational practice. Boring systems make money. Boring systems let you sleep.

JOSH: [pause]

JOSH: Godot. The internet version was, "Godot banned AI code." You said that's too strong.

ERIK: Too strong based on the reporting. The actual useful story is maintainers drowning in low-quality AI-assisted pull requests. That problem is real, and it's bigger than Godot.

JOSH: Why is AI code so painful for open source maintainers?

ERIK: Review is the expensive part. Generation got cheap. Verification did not. If someone submits code they don't understand, the maintainer inherits the thinking. That's not contribution. That's unpaid debugging with extra steps.

JOSH: But some AI-assisted code is good, right?

ERIK: Absolutely. AI-assisted code from a responsible engineer can be excellent. The difference is ownership. If you used Claude, ran the tests, understood the edge cases, and can defend the patch, fine. If you pasted output because the model sounded confident, please go away quietly.

JOSH: That sounds harsh.

ERIK: Maintainers are allowed to be harsh about their time. Open source runs on attention. Waste enough reviewer attention and the whole project slows down.

JOSH: What should projects do instead of a blanket ban?

ERIK: Require disclosure for AI-assisted contributions. Require tests. Require the contributor to explain the design. Require small patches. Use templates that ask, "What did you verify?" and "What failure did you test?" Not a five-page legal ceremony. A friction layer.

JOSH: Would you reject a PR if someone couldn't explain it?

ERIK: Immediately. Same standard for humans, honestly. If you can't explain your change, you don't own it.

JOSH: How does this connect to your PrimeBus setup?

ERIK: PrimeBus doesn't trust output just because an agent produced it. It routes the work through checks. Same idea for open source. The contribution path needs proof of work: tests, reasoning, reproducible behavior, and a small enough diff that a maintainer can review it without losing the afternoon.

JOSH: Could AI help maintainers review AI code?

ERIK: Yes, but carefully. Use AI to summarize diffs, find missing tests, compare behavior against the issue, and flag suspicious patterns. Don't let it rubber-stamp. AI review should reduce human reading load, not replace human responsibility.

JOSH: That seems like the line.

ERIK: That's the line. Builders can use AI all day. Maintainers need accountability. Those aren't enemies. They're the terms of shipping code in public.

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: Add a fingerprint check to your agent pipeline today. Take the output from your AI tool and run it through a normalizer before it hits a commit, ticket, email, or doc. Strip zero-width characters. Normalize quotes. Re-emit JSON through a parser. Run the repo formatter. Then diff before and after normalization.

JOSH: What are you looking for?

ERIK: Anything the agent didn't have a reason to add. Strange Unicode. Date format drift. Hidden whitespace. Repeated phrasing that shows up across unrelated outputs. Save the before and after artifact. If security asks what your AI system emits, you can answer with evidence instead of vibes.

JOSH: And this is a builder task, not a committee task.

ERIK: Exactly. One script. One CI check. One bus subscriber if you're running events. Start small in the lab, prove it, then put it in the path. That's your tip. Use it.

JOSH: [pause]

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

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.

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

ERIK: Local AI, self-hosting, and privacy all landed on the same answer today: own your systems or accept the leash.

JOSH: Stick around — Erik's got an AI pro tip at the end about using a local model as your first-pass code reviewer.

JOSH: [pause]

JOSH: First headline. Qwen is getting talked about as a serious local coding model. Erik, useful signal or benchmark noise?

ERIK: Useful signal. The point is not that it beats Claude at everything. The point is that local models are getting good enough for real builder work where privacy, cost, and repeatability matter.

JOSH: Second headline. The .self domain idea is getting attention from the self-hosting crowd. Is that actually useful?

ERIK: Useful as a flag. A domain does not run backups, renew certs, or patch containers. But it does say the culture is moving back toward owning your internet presence.

JOSH: Third headline. The Supreme Court privacy story around geofence warrants is back in the conversation. Why should builders care?

ERIK: Because location data is not harmless exhaust. If a system can identify everyone near a place, that system needs serious guardrails before someone calls it just metadata.

JOSH: [pause]

JOSH: Start with the local model story. Why does a builder need that when hosted models are so strong?

ERIK: Because every task does not need the big brain. That is the part people keep missing. Claude is great. GPT is great. I use frontier models every day. But I do not need a premium model reading every log line, sorting every failed test, or naming every small diff.

ERIK: In a real automation system, you have layers. One layer classifies the event. One layer checks if the issue has happened before. One layer proposes a small fix. One layer reviews the diff. Then the expensive model comes in when the problem actually deserves it.

JOSH: So local is not replacing the big model. It is filtering the work before it gets there.

ERIK: Exactly. Local models are not the boss. They are the first worker on the line. Give them narrow jobs with clear inputs and clear pass or fail conditions.

ERIK: PrimeBus is built around that idea. Events come in over NATS. Workers subscribe. A failure shows up, a reviewer agent looks at it, a fixer agent may propose a patch, and then the guardrails decide if it moves forward.

ERIK: The important part is the system does not trust vibes. It trusts tests, diff size, repo rules, and whether the change matches the failure. If a model writes poetry in a Python file, the pipeline should treat that like a bad packet and drop it.

JOSH: That sounds less magical than the way people describe AI agents.

ERIK: Good. Magical systems wake you up at night.

ERIK: The agent should be boring. It gets an event, reads the context, does the job, reports the result, and exits. If it needs ten paragraphs to explain why it might have fixed the thing, I am already suspicious.

JOSH: What makes a local model good enough for that front layer?

ERIK: It needs to follow instructions. It needs to stay inside the task. It needs to read code without hallucinating half the repo. And it needs to be consistent enough that you can build tests around it.

ERIK: I do not need it to invent a new framework. I need it to say, this failing test points to this function, here is a minimal patch, and here is why it should pass. That is the job.

JOSH: And if it is wrong?

ERIK: Then the system catches it. That is why you do not let a model write directly to production. You run it in a lab. You run the tests. You inspect the diff. You make the machine prove the win.

ERIK: That is how I build everything. Start small. Add guardrails. Watch the failures. Then move the good pattern into the next system.

JOSH: Where would you put this in your own stack?

ERIK: First-pass review. Easy. A local model can scan a diff and ask basic questions. Did the file change match the error? Did it touch unrelated code? Did it add secrets? Did it change a public contract? Did it skip tests?

ERIK: Then a stronger model can do the deeper reasoning. The expensive call gets cleaner context. That saves money, but more important, it reduces noise.

JOSH: Noise is the killer.

ERIK: Duuude, noise is the whole problem. In networking, alert fatigue is what happens when every warning pretends it is an outage. Same thing with AI. If every small event goes to your most expensive model, you built a very fancy panic button.

ERIK: PrimeSentinel exists because stuck jobs are quiet. They do not always crash. They sit there looking alive while doing nothing. A local model can help classify that kind of thing, but the watchdog has to be the source of truth.

JOSH: That is very network engineer.

ERIK: Correct. I trust counters, logs, health checks, and repeatable tests. The model is allowed to help. It is not allowed to be the only witness.

JOSH: [pause]

JOSH: That connects to the .self thing. Is this all the same movement? Local models, self-hosting, owning more of the stack?

ERIK: Same direction. People are tired of renting every piece of their digital life. Their notes are rented. Their automations are rented. Their identity is rented. Their audience is rented. Then one company changes a rule and suddenly you are begging an export button to work.

JOSH: But a domain does not fix that by itself.

ERIK: No. A domain is the sign on the building. You still need plumbing, locks, fire alarms, and someone who knows where the breaker panel is.

ERIK: Self-hosting sounds clean in a diagram. It gets real when DNS fails, a cert expires, a disk fills up, a container restarts forever, or your backup job has been silently broken for two weeks.

JOSH: Wait, really?

ERIK: Yes. The backup job failing silently is the classic self-hosting horror story. Everyone thinks they have backups until restore day. Restore day is when you find out if you had backups or bedtime stories.

JOSH: That is bleak.

ERIK: It is useful. Bleak is just production being honest.

ERIK: I like self-hosting. I run my own lab because I want control. But control comes with chores. You need monitoring. You need runbooks. You need a dashboard that tells you what is alive. You need watchdogs for the jobs that do not scream when they fail.

ERIK: PrimeDash is my quick view. What is up, what is down, what is weird. PrimeSentinel is the thing poking jobs that should have moved by now. Those are not shiny products. They are seatbelts.

JOSH: So what would make .self meaningful instead of just a badge?

ERIK: Good defaults. That is the whole answer. If .self becomes a culture around sane self-hosting patterns, I am interested. If it is just vanity domains for people running three half-broken services behind a router they forgot to patch, then we learned nothing.

JOSH: What are the defaults?

ERIK: TLS that renews without drama. Backups that get tested. Auth that is not duct tape. Logging that survives restarts. Health checks that measure the real thing. A simple rollback path. And one place to see what is broken.

ERIK: Also, do not expose admin panels to the internet because you saw a cool screenshot. That is not bravery. That is how you donate your weekend to incident response.

JOSH: How does this compare to just using managed platforms?

ERIK: Managed platforms are fine when the trade is clear. I pay you, you run the boring parts, I keep moving. That is honest.

ERIK: The bad version is when people think managed means they own the outcome. They usually own the bill, not the system. If the platform changes limits, pricing, policy, API behavior, or access, you are downstream from someone else's decision.

JOSH: So the answer is not self-host everything.

ERIK: Correct. The answer is know what must be yours. Source code. Critical data. Identity. Backups. Build pipelines. The things that can stop your work should not be mysteries.

ERIK: ScanBrief can use outside sources, but the scoring and delivery are mine. BookForge can call models, but the editorial backend is mine. PrimeBus can use hosted AI, local AI, or both, because the bus is mine.

ERIK: That is the line. Rent tools. Own the control plane.

JOSH: That one is going on a mug.

ERIK: Make it a boring mug with good uptime.

JOSH: [pause]

JOSH: Let’s hit the privacy story. Why does a court fight about geofence warrants belong in a builder podcast?

ERIK: Because builders create the exhaust. Every app that collects location, device IDs, Wi-Fi data, Bluetooth pings, or check-ins is creating future evidence. Sometimes useful. Sometimes dangerous. Often collected because someone thought maybe we will use it later.

JOSH: That is the default now. Collect first, decide later.

ERIK: And that default is lazy. Storage got cheap, analytics got easy, and now everyone wants to keep everything forever. Then the legal system shows up and asks for the pile.

ERIK: If your system has data, someone will eventually want it. A customer. A regulator. A court. An attacker. A bored internal admin. You need to design like that is true because it is.

JOSH: What should builders do differently?

ERIK: Collect less. Keep it for less time. Separate what you need from what is convenient. Put retention rules in code. Log access. Encrypt the parts that matter. Make deletion real. Do not build a surveillance database because marketing wanted a heat map.

JOSH: That sounds obvious, but people skip it.

ERIK: People skip it because privacy is treated like paperwork. It is architecture. It belongs in the same conversation as auth, backups, and deployment.

ERIK: If I am building an automation system, I ask what the agent can see, what it can change, and what gets recorded. Same thing for user data. What do we collect? Who can see it? What can it trigger? When does it die?

JOSH: What is the AI angle here?

ERIK: AI makes sloppy data habits worse. If you dump every ticket, log, chat, config, and customer note into a model context, congratulations, you invented a faster way to leak things.

ERIK: The model should get the minimum context needed for the task. Not the whole database. Not every secret. Not every customer record because it was easier than writing a filter.

JOSH: That is where agentic workflows get scary.

ERIK: Right. Agents are not scary because they are magic. They are scary because they connect permissions to decisions. A bad prompt with read-only access is one kind of problem. A bad prompt with write access, API keys, and no audit trail is a different sport.

JOSH: So privacy is also an operations problem.

ERIK: Absolutely. You need policies the system can enforce. Not vibes in a handbook. Real gates.

ERIK: HumanRail exists in my world for that reason. If a system is not confident, or if the action crosses a boundary, route it to a human. Do not let the model guess its way through something expensive, sensitive, or hard to undo.

JOSH: What would you tell a builder shipping an AI product this week?

ERIK: Draw the data path before you draw the UI. Where does the data enter? Where does it get stored? Which model sees it? What gets logged? What gets retained? What can be deleted? Who has access?

ERIK: If you cannot answer that, you are not ready to ship the feature. You are ready to make a demo.

JOSH: That is a hard line.

ERIK: Good. Demos are allowed to be messy. Products are not.

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 a smaller model as a bouncer before your expensive model.

ERIK: Here is the pattern. Take every proposed AI task and run it through a cheap classifier first. Local model if you can. Small hosted model if you have to. Ask four things. Is this task clear? Is the context enough? Is the risk low? Does it need a stronger model?

ERIK: If the answer is no, do not send it forward. Ask for more context, route it to a human, or drop it.

JOSH: What does that look like in practice?

ERIK: For code review, give the small model the diff, the failing test, and the repo rule. Have it return JSON. Not a paragraph. JSON. Something like risk level, files touched, likely root cause, needs frontier model, and reason.

ERIK: Then your workflow decides. Low risk goes to automated checks. Medium risk goes to Claude. High risk goes to a human. That one gate will save money and catch dumb tasks before they become expensive dumb tasks.

ERIK: That's your tip. Use it.

JOSH: We also drop daily market picks and automation tips on YouTube — search Build or Be Replaced.

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.

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

ERIK: AI is now judging resumes, scanning code, and checking IDs. Cool. Also terrifying if nobody can replay what it did.

JOSH: Stick around — Erik's got an AI pro tip at the end about using a critic agent before you trust a model's answer.

JOSH: [pause]

JOSH: First headline. HackerRank open sourced an AI hiring tool, and people are already finding weird resume scores. What happened?

ERIK: Same resume, different scores. That's the problem. If a hiring system gives you a 66 once and a 99 later, that isn't intelligence. That's a slot machine with a calendar invite.

JOSH: [beat]

JOSH: Second. GLM 5.2 beat Claude Code in one security benchmark. Should Claude users panic?

ERIK: No. Benchmarks are useful, but only if you understand the harness. GLM did well on IDOR detection. The real story is that the model is only one part of the security system.

JOSH: [beat]

JOSH: Third. Age verification is back in the policy feed. Why does that keep ranking so high?

ERIK: Because age checks don't stay age checks. Once the internet gets identity gates, the next question is who gets the keys and what else they check.

JOSH: [pause]

JOSH: Start with the resume scoring story. Automated hiring has been around forever. Why does this one feel different?

ERIK: Public code changes the whole conversation. Before, a vendor could say, trust us, the system is fair. Now builders can run it, break it, and show receipts.

ERIK: HackerRank open sourced Hiring Agent, and people started testing it. Same resume, different outcomes. That sounds like a minor bug until you remember the output can decide whether a human ever sees the candidate.

JOSH: Wait, really? Same resume, same job, different score?

ERIK: Yep. And anybody who has built with LLMs should not be shocked. Models infer. They summarize. They react to formatting. They can treat a bullet order like it means competence.

ERIK: That's fine when you're drafting a note. It's not fine when you're ranking humans. Hiring needs repeatability, logs, replay, model versioning, prompt versioning, and an appeals path.

JOSH: That's the part people miss. It has to be explainable.

ERIK: Exactly. The AI output can't be the final authority. It should be evidence attached to a decision. Show me the skill match. Show me the job requirement. Show me the sentence in the resume that triggered the score.

ERIK: If the score moves and the facts didn't move, the system is not ready. That's harsh, but it's true.

JOSH: How would you build it?

ERIK: First, separate extraction from judgment. Use strict parsing for facts: dates, titles, employers, skills, certifications, projects. Then score those facts in a visible rules layer.

ERIK: If AI is involved, make it cite the exact evidence. Not a fluffy explanation. Actual lines. This requirement maps to this evidence. This gap exists because no evidence was found.

ERIK: Second, freeze the run. Same resume, same job, same model, same prompt, same settings, same output. If it changes every time, you don't have a hiring system. You have confetti.

JOSH: That's a very network automation answer.

ERIK: It is. Cisco NSO taught us this forever ago. If I push the same service template twice, I expect the same device config. If it changes because the template felt different today, that's not automation. That's a ticket generator.

ERIK: Same with PrimeBus. I don't let an agent merge code because it had a good feeling. Events have structure. Reviews have gates. Failures have routes. The system has to prove why it took an action.

JOSH: So the blocked action matters as much as the successful one.

ERIK: More, honestly. Everybody wants the machine to say yes. The money is in making it say no correctly. No merge. No send. No delete. No candidate rejection without evidence.

ERIK: That's where builders need to grow up a little. The cool demo is easy. The boring guardrail is the product.

JOSH: What does this mean for job seekers?

ERIK: Plain text wins. Boring formatting wins. Honest keyword matching wins. Don't get cute with columns, graphics, hidden text, or some weird PDF layout that looks good to a human and parses like soup.

ERIK: Take the job description, take your resume, and run a test loop. Ask Claude to extract the hard requirements. Then ask it to map your resume evidence line by line. Then ask a second model to attack the match.

JOSH: Attack it how?

ERIK: Ask: where would an ATS misread this? Where is the evidence weak? Which requirement sounds satisfied but isn't? What line would a recruiter not understand in five seconds?

ERIK: Don't ask AI, is this good. That's how you get a greeting card. Ask where it breaks.

JOSH: That is immediately useful.

ERIK: Yep. And if you're building a hiring tool, do the same thing at system level. Run adversarial resumes. Run formatting tests. Run replay tests. Build dashboards for drift. If the score changes, you should know why.

JOSH: [pause]

JOSH: Next story. GLM 5.2 beat Claude Code in an IDOR benchmark. For normal people, IDOR is what?

ERIK: Insecure direct object reference. Fancy name for, can user A access user B's stuff by changing an ID in the request.

ERIK: Account slash 123 becomes account slash 124, and suddenly you're looking at somebody else's invoice. It's quiet bad. Not movie hacker bad. Worse. Boring lawsuit bad.

JOSH: And GLM did better than Claude Code?

ERIK: In that benchmark, yes. That's interesting. It does not mean everybody should throw out Claude. It means open models are getting strong in narrow security tasks, and that changes how teams should think about toolchains.

JOSH: What's the catch?

ERIK: The harness. Always the harness. A model inside a weak workflow loses to a smaller model inside a good workflow.

ERIK: Security scanning is not just reading code. You need repo context, route maps, auth boundaries, test data, request examples, and a way to confirm the finding. Otherwise the model is guessing with confidence.

JOSH: So the wrapper matters.

ERIK: The wrapper is the product. Semgrep does well because it has structure. Rules. Code paths. Known patterns. It doesn't just vibe-read the repo and say, this feels insecure.

ERIK: LLMs are useful when they sit next to deterministic tools. Give me Semgrep, unit tests, dependency scanning, runtime traces, and then let Claude or GLM reason over the weird parts.

JOSH: Where would you use GLM after seeing that?

ERIK: I'd put it in a second-opinion lane. Claude writes or reviews. GLM checks security-sensitive patterns. A static analyzer catches known issues. Then a policy gate decides what happens next.

ERIK: That's basically how I think about PrimeRouter. Don't marry one model. Route work by task. Some requests need a big reasoning model. Some need cheap fast classification. Some need a provider fallback because the first one is having a bad day.

JOSH: That's not as fun as model fan clubs.

ERIK: Model fan clubs are expensive. Also boring. Pick the tool that wins the task. Then measure it.

ERIK: For IDOR specifically, I want the model asking ugly questions. Where is object ownership checked? Is the tenant ID enforced server side? Can the client supply user ID? Are list endpoints filtered by auth context?

ERIK: Those are boring questions. They save companies.

JOSH: How does this compare to network automation?

ERIK: Same pattern. In networking, you don't trust a config because it looks right. You validate intent. You check state. You compare pre and post. You make sure the route exists, the policy hit, the device accepted the config, and traffic still flows.

ERIK: Code security needs the same discipline. Don't stop at model says vulnerable. Prove the path. Reproduce it. Then fix it and add a test so it doesn't come back.

JOSH: What should a builder do today?

ERIK: Add a security critic step to your AI coding workflow. Not a vague one. A specific one.

ERIK: After Claude writes code, ask another pass to inspect only authorization boundaries, user-controlled IDs, file paths, redirects, and secrets. Tell it to ignore style. Tell it to produce test cases.

ERIK: Then run the tests. If the model can't produce a failing test, treat the finding as suspicious until proven.

JOSH: That's a good distinction.

ERIK: Huge distinction. Models are great at sounding certain. Production cares about proof.

JOSH: [pause]

JOSH: Third deep one. Age verification. This feels like a policy story, but you're treating it like an infrastructure story.

ERIK: Because it is. Policy becomes architecture. Architecture becomes defaults. Defaults become hard to remove.

ERIK: If a site has to verify age, it needs some signal. ID scan, face estimate, credit card, mobile carrier check, government token, third-party identity provider. Pick your poison.

JOSH: That sounds messy.

ERIK: It is messy. And every option creates a database, a trust relationship, or a tracking surface. Sometimes all three.

ERIK: The goal sounds simple: keep kids away from certain content. Fine. But the implementation can turn into identity middleware for the whole internet.

JOSH: That's the slippery part.

ERIK: Yep. Once the gate exists, people will ask for more gates. Age today. Location tomorrow. Real name next year. Political content after that. Nobody has to be cartoon evil for the system to drift.

JOSH: How should engineers think about it?

ERIK: Minimize data. Prove only what you need. If the question is, is this user over a threshold, don't store their birthday, address, ID photo, and shoe size.

ERIK: Use privacy-preserving tokens where possible. Short-lived proofs. Local checks. Clear deletion. No giant pile of documents sitting in a vendor bucket named production-final-really-final.

JOSH: That's painfully believable.

ERIK: Because it happens. The data you collect becomes your liability. Every field is a future incident report.

ERIK: This is where builders need to push back early. Not in a dramatic way. In a design review way. What do we store? Why? For how long? Who can query it? What happens if the vendor disappears?

JOSH: How does that connect to automation?

ERIK: Automation makes bad policy fast. If you wire an identity check into every request, your system can deny millions of actions consistently. That's great if the rule is right. Brutal if the rule is wrong.

ERIK: Same reason I care about PrimeBus guardrails. An agent that can act across systems needs boundaries. Not vibes. Boundaries.

JOSH: So the theme today is trust, but verified.

ERIK: Exactly. Hiring scores, security scans, age checks. Same core issue. Automated decisions need evidence, replay, and limits.

ERIK: If you can't explain it, replay it, or stop it, you shouldn't put it in the critical path.

JOSH: That's the episode title.

ERIK: Probably too useful. We'll workshop it for six weeks and pick something worse.

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: Add a critic agent to every important AI workflow.

ERIK: Not a second chat where you ask, thoughts? Build a real critic step with a narrow job.

ERIK: Example: Claude writes the change. Critic agent reviews only risk. It checks auth, data loss, retries, secrets, migrations, and tests. It is not allowed to compliment the code. It is not allowed to rewrite everything. It has to produce blockers and non-blockers.

JOSH: Why narrow it that much?

ERIK: Because broad critics become annoying interns with a thesaurus. Narrow critics catch real issues.

ERIK: Use this prompt: review this output for failure modes only. Group findings as blocker, warning, or nit. For every blocker, include the exact evidence and a test that would catch it. If there is no evidence, say no finding.

ERIK: Then make your automation treat blockers differently. A blocker stops the run. A warning routes to a human or gets logged. A nit gets ignored unless you're doing cleanup.

ERIK: That's how you get useful AI review instead of AI theater. 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.

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

ERIK: Today's theme is simple. The web wants your ID, burned Roman scrolls are talking again, and tech media lost one of the people who actually understood infrastructure.

JOSH: Stick around — Erik's got an AI pro tip at the end about using agents as reviewers, not just writers.

JOSH: [pause]

JOSH: First up, Om Malik has died at 59. Why did that hit the tech world so hard?

ERIK: Om covered broadband, startups, telecom, and networks like they were the real story. Because they were. He wasn't just chasing gadgets. He understood that pipes, protocols, capital, and timing decide who wins.

JOSH: Second headline. AI helped read a Herculaneum scroll burned by Vesuvius almost 2,000 years ago.

ERIK: That's real AI work. X-ray scans, virtual unwrapping, machine learning, scholars checking the output. Not a chatbot doing ancient Rome fan fiction.

JOSH: Third headline. Age verification keeps expanding online. One paper called it compliance theater.

ERIK: Yeah, and that's generous. If your safety plan is "upload your face or driver's license to a vendor nobody can evaluate," you've built a privacy incident with a landing page.

JOSH: [pause]

JOSH: Start with Om Malik. Why does a journalist matter on a show about building?

ERIK: Because builders need signal. Om was signal. He wrote about broadband when broadband was still boring to normal people. He saw that connectivity was infrastructure, infrastructure created platforms, and platforms created markets.

JOSH: That sounds obvious now.

ERIK: Everything sounds obvious after somebody explains it for 20 years. That's the point. Good tech writing is early pattern detection. It tells builders where the pressure is building before the press release arrives.

JOSH: What made his work different?

ERIK: He treated the network like the story. Not the app floating on top of it. The fiber mattered. The data center mattered. The carrier business model mattered. The boring plumbing was not boring if you cared about what could be built next.

JOSH: That's very much your lane.

ERIK: Yeah. Network people know this. When the path is broken, the product is broken. Doesn't matter how pretty the UI is. If DNS is wrong, BGP is flapping, NAT is weird, or the queue is backed up, your whole magical app is now a support ticket.

JOSH: And now a lot of coverage skips that layer?

ERIK: A lot of coverage became product screenshots and executive quotes. That's fine for launch day. It doesn't help you understand power. Who owns distribution? Who controls compute? Who can absorb the cost of inference? Who has the data center contracts? Who gets priority when capacity is tight?

JOSH: So the loss is bigger than one writer.

ERIK: Right. It's a reminder that the industry needs people who can read the system. Not just the story. Om came from that era where telecom fraud, broadband buildouts, blogs, venture money, and consumer apps were all connected. He could see the whole board.

JOSH: How should builders respond to that?

ERIK: Build your own signal stack. Don't wait for a feed to tell you what matters. ScanBrief exists because I got tired of reading the same rewritten article 12 times. I want multiple sources, dedupe, scoring, summaries, and a reason something matters.

JOSH: That's the builder version of media literacy.

ERIK: Exactly. If you're building in AI right now, you need a daily radar. Model releases. API changes. pricing changes. security bugs. lawsuits. policy shifts. chip supply. You don't need more content. You need filtered intelligence.

JOSH: And the takeaway from Om?

ERIK: Respect the pipes. Respect the people who understand the pipes. The future usually shows up there first.

JOSH: [pause]

JOSH: The scroll story feels like the opposite of hype. Why did this one land for you?

ERIK: Because the model is not the product. The system is the product. That's what people miss.

JOSH: Walk me through it.

ERIK: You start with a physical artifact that's basically a carbonized mess. You can't open it without destroying it. So researchers use high-resolution X-ray imaging to capture the internal structure. Then software virtually unwraps layers that are warped, crushed, and stuck together. Then machine learning looks for ink signal that humans can't easily see.

JOSH: And the ink is carbon too, right?

ERIK: Correct. That's why it's hard. Carbon ink on carbonized papyrus doesn't give you a nice clean contrast. You're not finding black ink on white paper. You're finding tiny surface and texture differences inside a burned object that has been sitting around since Mount Vesuvius did what volcanoes do.

JOSH: Rude, historically speaking.

ERIK: Very inconsiderate to future data pipelines.

JOSH: [beat]

JOSH: But it worked.

ERIK: It worked enough to recover serious text. We're talking over a meter of readable material from one scroll, with scholars now arguing through Stoic and Epicurean philosophy instead of arguing whether the object can be read at all. That's a phase change.

JOSH: What makes that different from normal AI output?

ERIK: Evidence boundaries. The system is constrained by scan data. It isn't inventing a scroll from vibes. It proposes readings based on physical signal, and humans validate the result. That's the pattern builders should steal.

JOSH: Evidence first. Model second.

ERIK: Yep. Same thing I do with PrimeBus. Agents don't get to wander around making heroic decisions because they felt inspired. Events come in. Logs attach. Tests run. A fix gets proposed. Review happens. Guardrails decide what can move.

JOSH: So the agent is part of the workflow.

ERIK: Exactly. Not the boss. People keep trying to make AI the whole employee. Wrong frame. Make it a worker inside a system that has telemetry, permissions, audit trails, and rollback.

JOSH: How does that apply outside ancient scrolls?

ERIK: Everywhere. Network configs. Medical scans. legal discovery. Old file shares. Security logs. Backup validation. The problem is usually not "write me something." It's "find the signal inside ugly data and show your work."

JOSH: That's a harder product.

ERIK: Much harder. But useful. A chatbot that writes a confident paragraph is easy. A system that ingests messy artifacts, preserves provenance, detects signal, attaches confidence, routes low-confidence work to a human, and keeps an audit trail? That's where real money is.

JOSH: That's less flashy.

ERIK: Good systems are usually ugly in the middle. Queues. retries. schemas. worker timeouts. failed jobs. weird encodings. permissions. human review. Nobody puts that in the demo video because it's not sexy. But that's the part that makes it survive Tuesday.

JOSH: You mentioned backups earlier.

ERIK: PrimeRestorer is exactly that mindset. A backup is a rumor until a restore proves it. Same with AI output. A model answer is a rumor until evidence proves it. Builders need to stop treating generated text like truth.

JOSH: That's a pretty sharp rule.

ERIK: Use it today. If the model says it fixed a bug, where's the test? If it says a document says something, where's the source line? If it says a config is safe, where's the diff, the policy check, and the rollback plan?

JOSH: The scroll team had scholars in the loop.

ERIK: And that's why it matters. Human-in-the-loop is not a weakness. It's how you keep the machine useful. I don't want AI replacing experts by guessing louder. I want AI giving experts superpowers with evidence attached.

JOSH: That's the sane version.

ERIK: Sane, measurable, and shippable. Weirdly, those are still allowed.

JOSH: [pause]

JOSH: Age verification is the next one. This feels like one of those "good goal, bad architecture" stories.

ERIK: That's exactly what it is. Protecting kids online is a real goal. Building a web where identity checks become normal at every door is a dangerous way to get there.

JOSH: What's actually happening?

ERIK: More jurisdictions are pushing sites to verify age before allowing access to certain content. The implementation often lands on document checks, biometric estimation, device signals, or third-party identity vendors. That means the web starts asking users for sensitive proof just to browse.

JOSH: The pitch is safety.

ERIK: The pitch is always safety. The architecture is the issue. When you bind access to identity, you create a tracking layer. Even if the site doesn't store the driver's license, somebody touched it. Somebody processed it. Somebody logged metadata. Somebody is now in the trust path.

JOSH: And users can't evaluate that.

ERIK: Not even close. Normal people can't tell if an age-verification vendor has solid security, sane retention policies, proper isolation, or a business model that won't get creepy later. They see a modal and a button.

JOSH: The paper called some of this compliance theater.

ERIK: Because passing the checkbox doesn't mean the system is secure. Researchers looked at European adult-site age checks and found weak spots across methods and integrations. That's the part people ignore. A law can demand verification, but the deployed workflow can still be bypassed, mishandle data, or push risk onto users.

JOSH: Wait, really?

ERIK: Yes. Compliance is not engineering. Compliance can force activity. It doesn't guarantee the activity is good.

JOSH: That's bleak.

ERIK: It's normal infrastructure reality. I've seen plenty of controls that exist because an auditor wanted a screenshot. The control technically exists. It also doesn't stop anything useful. Congrats, you made paperwork with latency.

JOSH: How should builders think about age checks then?

ERIK: Data minimization first. Collect the least possible data. Store as little as possible. Prefer proofs over raw identity. If all you need to know is "over threshold," don't collect name, address, face, and document number.

JOSH: What are better patterns?

ERIK: Privacy-preserving tokens. Device-side or wallet-side attestations. Parent-controlled systems. Blind verification where the site gets a yes or no, not a dossier. Short retention. Independent audits. Clear deletion. Boring stuff that actually matters.

JOSH: And if you're a small builder?

ERIK: Don't bolt on the cheapest vendor and call it done. Map the data path. What does the user submit? Where does it go? Who stores it? How long? What gets logged? What happens during support? What happens if the vendor gets breached?

JOSH: That's a lot for a small team.

ERIK: Yeah. Security work is work. Very annoying.

JOSH: [beat]

ERIK: But it's cheaper than explaining to users why their identity documents are in a breach because your product wanted to avoid hard design decisions.

JOSH: How does this connect to automation?

ERIK: Same principle. Every automation needs a blast-radius model. Every agent needs permissions. Every vendor needs a failure plan. PrimeRouter exists because I don't want model calls sprayed everywhere with no routing, no priority, and no visibility. Identity data deserves even more discipline.

JOSH: So the big warning is centralization?

ERIK: Centralization plus normalization. Once users accept "show papers to access content," that pattern spreads. Today it's adult content. Tomorrow it's social media. Then forums. Then app stores. Then payment access. That's how bad defaults become infrastructure.

JOSH: What's the builder line in the sand?

ERIK: Don't collect sensitive data unless the product genuinely cannot work without it. And if you must collect it, treat it like radioactive material. Small container. Clear label. Short half-life.

JOSH: Dry, but fair.

ERIK: I do networking. Dry is part of the warranty.

JOSH: [pause]

JOSH: Pull these together for me. Om Malik, burned scrolls, age verification. What's the common thread?

ERIK: Systems thinking. Om saw systems. The scroll team built a system around fragile evidence. Age verification is what happens when policy demands a system and weak architecture fills the gap.

JOSH: That's the episode.

ERIK: Pretty much. Builders need to stop staring only at the visible layer. The UI is not the system. The model is not the system. The law is not the system. The system is the path data takes, the rules it hits, the humans who review it, and the failure modes you planned for before production makes you humble.

JOSH: Where does AI fit in that?

ERIK: AI is a worker. A very fast, very weird worker. Give it bounded tasks. Give it evidence. Give it tests. Give it a bus to publish events on. Give it humans when confidence drops. Don't give it root and a dream.

JOSH: That's going on a sticker.

ERIK: Make it small. Engineers don't read big stickers.

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 agents as reviewers before you use them as writers. Take any change you make today. Code, config, email, runbook, proposal, whatever. Ask one agent to find correctness issues. Ask another to find operational risk. Ask a third to find missing tests or missing evidence.

JOSH: Not write it first?

ERIK: Review first. Writing agents are impressive. Reviewing agents make you faster without letting the machine steer the car. Give each reviewer a narrow role and a hard output format. Findings only. File path or section. Severity. Evidence. Suggested fix.

JOSH: Why separate reviewers?

ERIK: Because one broad prompt gives you soup. Separate roles catch different failure modes. A security reviewer shouldn't care if the paragraph sounds nice. An ops reviewer should care about rollback. A test reviewer should care about proof.

JOSH: What's the exact prompt?

ERIK: Try this. "Review this change as a production engineer. Return only concrete risks, missing tests, and assumptions. If you can't point to evidence, say no finding." That's it. Run that before you ship.

JOSH: Simple enough.

ERIK: That's your tip. Use it.

JOSH: [pause]

JOSH: Binge all five episodes this weekend plus our YouTube shorts — links at buildorbereplaced.dev.

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

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

JOSH: [pause]

ERIK: Build or be replaced.

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

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

ERIK: Today's theme is simple. The runtime, the model, and the chip are all becoming battlegrounds.

JOSH: Stick around — Erik's got an AI pro tip at the end about using a second model as your production gate.

JOSH: [pause]

JOSH: First headline. Half-Life 2 is running in a browser through WebAssembly and WebGPU. Is that just nostalgia with a loading bar?

ERIK: No. It's a signal that the browser is a serious runtime now. If it can run a real Source-era 3D game, it can run ugly enterprise tools all day.

JOSH: Second. Anthropic says Alibaba tried to extract Claude capabilities at massive volume. How massive?

ERIK: Anthropic told senators Alibaba-linked operators used nearly 25,000 fake accounts and about 28.8 million interactions. That's not poking around. That's industrial distillation.

JOSH: Third. OpenAI showed a custom Broadcom chip called Jalapeño. Why should builders care?

ERIK: Because inference cost is rent. OpenAI wants to own more of the building instead of paying Nvidia forever.

JOSH: [pause]

JOSH: Start with the browser story. Half-Life 2 in a tab sounds fun, but you're seeing something bigger.

ERIK: Yeah. The game is the wrapper. The real story is WebAssembly plus WebGPU becoming boring enough to trust.

ERIK: That's when technology matters. Not when demos look cool. When the weird part disappears and people just click a link.

JOSH: What changed?

ERIK: The browser used to be where you rendered HTML, posted forms, and fought CSS. Now it's UI, storage, graphics, crypto, file access, worker threads, WebAssembly, and GPU compute.

ERIK: That's not a webpage anymore. That's a deployment target.

JOSH: Deployment target. Meaning what, exactly?

ERIK: Meaning the browser is where you ship the thing. No installer. No desktop package. No helpdesk ticket because someone's Windows machine has the wrong runtime.

ERIK: Network teams should care. NOC teams should care. Anyone with a folder full of little tools should care.

ERIK: Packet capture viewers. Config diff tools. Terraform plan readers. NSO service validators. Log parsers. CSV cleaners. Topology inspectors. Half that stuff should be a local browser app.

JOSH: Local browser app sounds like a contradiction.

ERIK: It's not. Browser doesn't mean cloud. Browser means common runtime.

ERIK: You can run sensitive work locally in the browser. The data never leaves the laptop. You still get a good UI. You still get a sandbox. You still get easy distribution.

JOSH: That's the part people miss.

ERIK: Completely. They hear browser and think SaaS bill. That's lazy.

ERIK: Sometimes the right architecture is a static app, a file picker, WebAssembly doing the heavy work, and zero backend. That's beautiful. Also cheaper, which is a technical feature people pretend not to care about.

JOSH: How does that hit your own systems?

ERIK: PrimeDash is the easy example. It's my LAN dashboard for the lab. I don't want a desktop client for that. I want a page that knows the state of the machines, shows me what matters, and doesn't make me babysit a stack of local dependencies.

ERIK: ScanBrief is similar. The ingestion can happen on the backend, but the review experience should feel instant. Filter, rank, inspect, approve. That's browser-native work.

JOSH: So if you're building internal tools today, what's the move?

ERIK: Build for links first.

ERIK: If it can be a link, make it a link. If it can run local, keep it local. If it needs authority, give it a small backend with clear rules.

ERIK: Don't make people install a five-pound desktop app because one function needed a file parser. That's how you end up with enterprise software that looks like it was found in a drawer.

JOSH: Very specific drawer.

ERIK: Every office has that drawer.

JOSH: [beat]

JOSH: Does this change AI tooling too?

ERIK: Big time. Browser-side AI is getting real because WebGPU is getting real.

ERIK: You're not replacing frontier models in the browser. But small local models, embeddings, redaction, classification, document prep, privacy checks, all of that can move closer to the user.

ERIK: That's useful. Send the clean task to Claude or OpenAI. Keep the private junk local. Less cost. Less risk. Fewer stupid meetings about data handling.

JOSH: That's a practical split.

ERIK: Exactly. Builders need to stop thinking in extremes. Not everything is local. Not everything is cloud. Put the work where it belongs.

JOSH: [pause]

JOSH: Next story. Anthropic accusing Alibaba of extracting Claude capabilities. This one sounds like spy movie material.

ERIK: It's less spy movie, more billing dashboard horror.

ERIK: Anthropic says Alibaba-affiliated operators used nearly 25,000 fraudulent accounts and about 28.8 million interactions from April through June. The claim is that those outputs were used to train or improve Alibaba's own models.

JOSH: That's distillation?

ERIK: Yep. Distillation is when one model learns from another model's outputs. Totally normal when you own both sides. Very not normal when you're hammering someone else's API with fake accounts.

JOSH: Is that actually preventable?

ERIK: Preventable, no. Detectable, yes. Containable, sometimes.

ERIK: You can rate limit. You can fingerprint outputs. You can detect prompt farms. You can watch account creation patterns. You can look for weird coverage across capabilities. Coding prompts, safety boundary prompts, agent prompts, reasoning puzzles, all clustered across fake users.

ERIK: But the ugly truth is simple. If your model answers questions, people can study the answers.

JOSH: That's wild.

ERIK: It's software. Wild is the default setting.

JOSH: What does this mean for regular builders using these APIs?

ERIK: Don't make the model your whole product.

ERIK: If your business is one prompt wrapped around Claude, you don't have much. You have a demo with a Stripe button.

ERIK: The durable part is everything around it. Data permissions. Workflow state. Human review. Eval logs. Rollback paths. Alerts. Cost controls. Domain-specific inputs. The model call is one component.

JOSH: That's where PrimeBus comes in for you?

ERIK: Exactly. PrimeBus treats model output as an event, not gospel. A model can suggest a fix. The system still needs tests, review rules, permissions, and a place to publish what happened.

ERIK: That's the difference between an agent and a slot machine.

JOSH: Good line.

ERIK: It's true. People wire a model straight to production and act surprised when it does something weird. Duuude, you gave autocomplete the keys to the building.

JOSH: How should teams protect themselves from copycats?

ERIK: Build things that are hard to query from the outside.

ERIK: Your private corpus. Your operational history. Your eval set. Your approval workflow. Your customer-specific constraints. Your integrations. Your incident memory.

ERIK: A competitor can imitate tone. They can imitate answer style. They can't easily imitate five years of real workflow data and all the weird edge cases your system learned the hard way.

JOSH: So the prompt is the least defensible part.

ERIK: Usually, yes.

ERIK: Prompts matter, but prompts are not a moat. They're configuration. Important configuration, but still configuration.

JOSH: What about the model companies?

ERIK: They have a hard problem. They need easy access because developers pay the bills. But easy access creates attack surface.

ERIK: Same problem every platform has. APIs are doors. Doors need locks, cameras, logs, and someone who reads the logs.

JOSH: Very glamorous.

ERIK: Security is mostly reading logs and being annoyed.

JOSH: [beat]

JOSH: Does this make you trust closed models less?

ERIK: No. It makes me trust naked architectures less.

ERIK: Closed model, open model, local model, doesn't matter. If you don't know what your system did, why it did it, what it cost, and how to stop it, you're guessing.

ERIK: ScanBrief can use AI to score stories, but the ranking pipeline still needs source checks and rules. InkEngine can draft chapters, but it still needs structure, review, and edit passes. The model is powerful. The system is what makes it usable.

JOSH: That's the real lesson.

ERIK: Yep. Use the best model you can. Then build guardrails like you expect it to be wrong at the worst possible time.

JOSH: [pause]

JOSH: Third story. OpenAI's Jalapeño chip with Broadcom. Give me the non-chip-person version.

ERIK: OpenAI is building a custom inference chip. Broadcom helped design it. Reports say it targets customer use by the end of 2026.

ERIK: The important word is inference. That's when a model answers users. Training is building the brain. Inference is every time someone asks the brain to do work.

JOSH: Why not keep buying GPUs?

ERIK: Because GPUs are expensive, scarce, and general-purpose. Great chips. Not magic.

ERIK: If you're OpenAI and you're serving ChatGPT, Codex, agents, voice, images, and whatever comes next, every token has a cost. Tiny cost times massive usage becomes a giant invoice.

JOSH: So custom silicon is about cost control?

ERIK: Cost, supply, power, and control.

ERIK: Nvidia owns the high ground because their hardware and software stack is excellent. But hyperscalers and AI labs hate dependency when the bill gets that big. Google has TPUs. Amazon has Trainium and Inferentia. Microsoft has Maia. Meta has its own work. OpenAI doing this is not weird. It's inevitable.

JOSH: The name is weird, though.

ERIK: Jalapeño is better than another chip named after a mountain or a Greek thing. I'll give them that.

JOSH: [beat]

JOSH: What does inference-focused hardware change for builders?

ERIK: If it works, model calls get cheaper and more predictable over time. Not overnight. Hardware takes time. Software support takes time. Capacity planning takes time.

ERIK: But the direction matters. AI companies are moving from renting compute to designing around their own workloads.

JOSH: Is that good for developers?

ERIK: Mostly, yes. Cheaper inference means more room for agent loops, tool calls, retries, evals, and background jobs.

ERIK: But there's a catch. When providers build custom chips, they may tune models and APIs around their own stack. That can make their platform better and stickier at the same time.

JOSH: Stickier how?

ERIK: Latency. Pricing. Tooling. Model features that only make sense on their infrastructure. Special batching. Special memory layouts. Special agent runtimes.

ERIK: Once your app depends on those behaviors, moving away gets harder.

JOSH: So don't marry one provider?

ERIK: Don't pretend you're provider-neutral if you're not.

ERIK: I use Claude heavily because it helps me ship. But I still design important workflows with clear boundaries. Prompt in. Tool result out. Eval recorded. Failure visible.

ERIK: If I need to swap a model for a class of work, I want that to be annoying, not fatal.

JOSH: That's a good standard.

ERIK: Annoying is fine. Fatal is bad engineering.

JOSH: How does this compare to network automation?

ERIK: Same pattern. In networking, vendor lock-in is old news. Cisco NSO, Terraform providers, device APIs, controllers, all of it has edges.

ERIK: You don't avoid every dependency. That's fantasy. You wrap dependencies so one vendor decision doesn't wreck your whole weekend.

ERIK: AI is just speedrunning the same lesson.

JOSH: Speedrunning vendor lock-in.

ERIK: With better demos and worse invoices.

JOSH: [beat]

JOSH: What should a small builder do with this chip news today?

ERIK: Watch pricing and latency. That's it.

ERIK: Don't rewrite your app because OpenAI announced a chip. Don't make a roadmap slide with a pepper on it. Watch whether inference gets cheaper, whether Codex gets faster, whether long-running agents cost less, whether batch jobs become more practical.

ERIK: When the economics change, product shapes change.

JOSH: Give me an example.

ERIK: If agent loops get cheaper, you can afford more verification. One model writes. Another model reviews. A test runner checks. A third pass summarizes risk. Today people skip that because cost and latency hurt.

ERIK: Cheaper inference makes better guardrails normal.

JOSH: That connects to the pro tip.

ERIK: Yeah. And it's the part builders can use right now, even before the chip ships.

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 a second model as a production gate.

ERIK: Not a second opinion in chat. A real gate in the workflow.

ERIK: Here's the pattern. Model one does the work. It writes the code, drafts the email, builds the Terraform change, whatever. Model two gets the task, the output, the rules, and a short checklist. It only answers pass, fail, or needs human.

ERIK: Keep the reviewer prompt boring. No creativity. No rewriting. No "make this better." Ask it to find policy violations, missing tests, bad assumptions, and unsafe actions.

JOSH: Why separate models?

ERIK: Different failure shape. If the same model writes and grades itself, it may defend its own bad idea. A second model catches different mistakes.

ERIK: Even better, use a cheaper model for the first filter and a stronger one only when risk is high. Save money. Catch more junk.

JOSH: Where would someone use that today?

ERIK: Pull requests. Customer emails. SQL migrations. Cloud changes. Network configs. Anything that can hurt you if the model gets cute.

ERIK: PrimeBus is built around that idea. Work happens, events publish, reviewers inspect, guardrails decide what moves forward.

ERIK: Start simple. One writer. One reviewer. One hard stop when the reviewer says fail.

ERIK: That's your tip. Use it.

JOSH: [pause]

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

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.

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

ERIK: Today's theme is boring systems winning, because boring systems are the ones still running at 3 AM.

JOSH: Stick around — Erik's got an AI pro tip at the end about making agents write their own failure receipts.

[pause]

JOSH: First headline. Vulnerability reports are getting treated like regular issues now. Is that good or bad?

ERIK: Both. Security reports used to get special ceremony. Now maintainers are buried, and a vuln ticket competes with every other broken build, flaky test, and angry user.

JOSH: That's not comforting.

ERIK: Nope. But it's honest. If your process depends on humans noticing one special GitHub issue faster than the other thousand, that's not a process. That's a wish with a CVE number.

[beat]

JOSH: Next up, a quieter one. Tony Krueger, the Microsoft Word engineer behind the red and green squiggles, passed away.

ERIK: That feature changed software. Real-time spell check sounds normal now, but at the time it moved correction from a separate task into the flow of writing. That's automation done right. It doesn't hold a meeting. It just shows you the problem while your brain is still in the sentence.

[beat]

JOSH: Third headline. Meta paused an employee-tracking program after an internal data leak. What do you make of that?

ERIK: If you track people, the tracking data becomes production data. Then it needs access control, retention policy, audit logs, blast-radius thinking, all of it. Companies love surveillance until they have to secure the surveillance.

[pause]

JOSH: ScanBrief scored 98 items across 54 sources today. Those were the top signals. Which one is the real builder story?

ERIK: The vulnerability report one. Easy. Because it exposes a lie in software teams. Everybody says security is priority one, but then they route security through the same tired human queue as everything else.

JOSH: What's the better pattern?

ERIK: Treat the report like an event, not a message. Big difference. A message says, hey, someone should look at this. An event says, this happened, and a system starts moving.

[beat]

ERIK: In my world, PrimeBus processed 978 automation events across 16 projects today. That's not a dashboard vanity number. That's code reviews, failures, deploy checks, backups, alerts, little decisions moving without me staring at Slack like it's a campfire.

JOSH: So a vulnerability report should kick off a workflow.

ERIK: Exactly. First step, classify it. Is it dependency, auth, injection, data exposure, network edge, secrets, or supply chain. Then pull context. What repo. What service. What owner. Is there a public exploit. Is it internet-facing. Do we have logs showing hits. Do we have tests that cover the path.

JOSH: That's a lot for a maintainer to do manually.

ERIK: That's why it doesn't happen. People are not lazy. The system is lazy. It waits for one burned-out maintainer to become a security triage engine after dinner.

[beat]

JOSH: But open source maintainers don't all have PrimeBus sitting there.

ERIK: They don't need my setup. Start smaller. GitHub issue label triggers a workflow. Workflow runs dependency scan. Workflow posts a structured summary. If there's a patch, it opens a branch. If there isn't, it creates a minimal reproduction template. If the report is vague, it asks for missing fields automatically.

JOSH: That sounds like taking the drama out of it.

ERIK: Good. Drama is expensive. The report should become structured data as fast as possible.

[pause]

JOSH: Where does AI fit without making it risky?

ERIK: AI should not be the final judge on a vuln. It should be the first clerk. Read the report. Extract claims. Map affected files. Search for similar code paths. Draft a test. Draft a patch. Then a policy engine decides what can merge.

JOSH: Policy engine meaning Gandalf in your case.

ERIK: Yeah. Gandalf reviewed and merged 10 code changes to production overnight. That's the part people miss. The agent can write code, but the guardrail decides what is allowed to land.

[beat]

ERIK: Since June 5, the PrimeBus auto-merger has run 1338 attempts. 876 merged, 462 blocked by Gandalf, 0 escalated to me. That blocked number is the story. Guardrails doing their job is what lets you sleep.

JOSH: Wait, really? Zero escalated?

ERIK: Zero. Because the system knows when to say no. That's what most agent setups are missing. They build the part that acts, then forget the part that refuses.

JOSH: So for security, refusal is a feature.

ERIK: Huge feature. If the agent proposes touching auth middleware and deleting a failing test, that's not clever. That's a clown car with a pull request. Block it. Ask for a narrower fix. Make it prove the vuln and prove the patch.

[pause]

JOSH: The second story I want to hit is the Word squiggle one. It feels tiny, but you lit up when you saw it.

ERIK: Because it's the perfect automation lesson. The red squiggle didn't replace the writer. It replaced a dumb interruption. Before that, spell check was a mode. Stop writing. Run spell check. Click through a dialog box. Lose your thread.

JOSH: And now it just sits under the word.

ERIK: Right. Non-blocking feedback. That's the magic. It doesn't make you stop. It doesn't steal the keyboard. It gives you a signal at the right time, in the right place, with low friction.

[beat]

JOSH: How does that map to infrastructure?

ERIK: Everything. Network automation should feel like that. If I push an NSO service package and a device template has a bad variable, I don't want a weekly report. I want the system to underline the broken part while the change is still fresh.

JOSH: The red squiggle for Terraform.

ERIK: Yes. Terraform plan drift. Kubernetes manifest risk. NSO dry-run mismatch. NATS consumer lag. Selenium test flake. Whatever. Don't make engineers go hunting. Put the signal where the work is happening.

JOSH: That's a cleaner way to say observability.

ERIK: Observability got bloated. Half the time it means a hundred charts nobody reads. The squiggle model says, surface the smallest useful warning directly in the workflow.

[pause]

JOSH: Give me a real example from your systems.

ERIK: The PAS website-pipeline is a good one. It builds and maintains agency websites, but the important part isn't the page generator. The important part is the review loop. Broken link, bad image, layout shift, missing form action, Lighthouse issue, deployment error. Those should not become a giant task list.

JOSH: They become squiggles.

ERIK: Exactly. Small visible corrections. The agent can fix a missing alt tag. It can rerun a screenshot test. It can check the form endpoint. But if it sees payment code or DNS, it slows down and asks for review.

[beat]

ERIK: Same pattern with PrimeRestorer. Backups are boring until they're not. The system shouldn't send me a novel. It should say, this database backup passed, this S3 offsite copy passed, this one restore check failed, and here's the exact command that failed.

JOSH: That's the difference between a warning and a useful warning.

ERIK: Yes. Most alerts are just guilt with timestamps.

JOSH: That's painfully accurate.

ERIK: You want the squiggle. Not the guilt.

[pause]

JOSH: There's also the FUTO Swipe story. A million swipe-typing examples released under MIT. Why should builders care?

ERIK: Data is the moat people ignore until they don't have it. A swipe keyboard model needs real gesture paths, not just words. The release matters because it gives builders a benchmark and training material they can actually use.

JOSH: Is that an AI story or an open data story?

ERIK: Both. Models are hungry, but the good stuff is domain-specific. Generic text is everywhere. Real user swipes are not. Network configs, repair tickets, NOC runbooks, deployment logs, customer emails, failed test diffs. That's where useful automation comes from.

[beat]

JOSH: So the lesson is collect your own data?

ERIK: Collect it cleanly. Big difference. Dumping logs into a folder is not a data strategy. You need schema. You need timestamps. You need source. You need outcome. Did the fix work. Did the customer reply. Did the restore pass. Did the change roll back.

JOSH: That's where ScanBrief fits?

ERIK: Yeah. ScanBrief isn't just grabbing headlines. It scores, dedupes, ranks, and keeps the source trail. Today it scored 98 items across 54 sources. That gives me a daily signal layer I can trust enough to build from.

JOSH: And HumanRail?

ERIK: HumanRail is the other side. When the agent isn't confident, route to a human. But the routing event still becomes data. What did the model think. Why did it ask. What did the human decide. Next time the system is smarter, or at least less annoying.

[pause]

JOSH: What do people get wrong when they hear "dataset"?

ERIK: They think it means giant. It means useful. A hundred high-quality examples from your actual workflow beats a million random examples scraped from nowhere.

JOSH: That's uncomfortable for teams that never write anything down.

ERIK: Good. It should be. If your company has no examples, no runbooks, no outcomes, and no clean history, AI won't magically understand the business. It'll produce confident fog.

[beat]

JOSH: Confident fog is a strong phrase.

ERIK: It's everywhere. The model writes a summary, everybody nods, nobody checks whether it maps to reality. Then someone puts it in prod and acts shocked when it invents a field name.

JOSH: How do you avoid that?

ERIK: Force every agent output to attach evidence. File path. log line. test result. ticket ID. source URL. The moment an agent can't show its work, it becomes a draft, not a decision.

[pause]

JOSH: Bring these three together for me. Vulnerability reports, red squiggles, swipe data. What's the common thread?

ERIK: Feedback loops. That's it. Vulnerability reports need a loop from report to context to test to patch to review. The Word squiggle is a loop from mistake to signal to correction without breaking flow. FUTO Swipe is training data for a loop between human motion and predicted text.

JOSH: So builders should be designing loops, not tools.

ERIK: Tools are easy. Loops are where the money is. A tool waits for you. A loop moves the work, checks the result, and leaves evidence.

[beat]

ERIK: That's why PrimeBus matters in my setup. It isn't one app. It's the nervous system. 111 distinct projects have emitted telemetry to it. That means my systems can react to each other instead of sitting around like bored interns.

JOSH: And that's how you get daily shipping without watching everything manually.

ERIK: Right. The production server has 111 services running right now. If I had to babysit that by hand, the show would be called Erik Needs a Nap.

JOSH: I'd subscribe.

ERIK: You already work here.

[pause]

JOSH: Before the tip, sponsor read.

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 agents write a failure receipt every time they can't finish a task.

JOSH: What goes in the receipt?

ERIK: Four fields. Goal. What it tried. Exact blocker. Next safe action. That's it.

[beat]

ERIK: Don't let the agent say, I couldn't complete the task. That's useless. Make it say, I tried running the test suite, dependency install failed because package X needs Node version Y, next safe action is update the runtime or pin the package.

JOSH: So it's not just logging.

ERIK: No. It's a handoff contract. The next agent, or the human, should be able to pick it up without redoing the investigation. Put those receipts on a queue. NATS, Redis, Postgres, whatever you already run. Then route by blocker type.

JOSH: Give us the prompt.

ERIK: Add this to your agent instruction. When blocked, do not apologize. Produce a failure receipt with goal, attempts, blocker, evidence, and next safe action. Include exact commands, file paths, and error text. If the next action changes production, mark it requires human approval.

[beat]

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

ERIK: Today's theme is trust the stack, not the headline.

JOSH: Stick around — Erik's got an AI pro tip at the end about making agents prove they have the right context before they touch anything important.

[pause]

JOSH: Headlines first. Valve's new Steam Machine is not launching today. It's opening the path to launch. What's the real story?

ERIK: Reservations are live now, the randomized selection is June 25 at 1 PM Eastern, and purchase emails go out June 29. Starting price is $1,049, which means this is not a cheap console. It's Valve trying to make Windows optional in the living room.

[beat]

JOSH: Second headline. GLM-5.2 specs are flying around: massive parameter count, huge context, local quantized builds. What should builders believe?

ERIK: Believe the model card when it lands, not a screenshot with big numbers. The signal is still real, though. Local models are moving from demo toys into worker agents.

[beat]

JOSH: Third headline. Polymarket is getting heat over paid creator videos that looked fake. Is this just crypto being crypto?

ERIK: It's worse than sloppy marketing. Reports say creators were paid up to $3,000 a month, some videos showed fabricated wins, and the campaign drove roughly $900,000 in deposits. That's not growth hacking. That's a trust leak with a logo.

[pause]

JOSH: Start with Valve. Why does a $1,049 Steam Machine matter when consoles are cheaper?

ERIK: Because Valve isn't trying to be PlayStation with a beard. They're building a route around Windows.

[beat]

ERIK: The first Steam Machine wave years ago was early. Linux gaming was not ready. Drivers were weird. Proton wasn't mature. The hardware story was messy. It felt like a PC pretending to be a console and asking you to forgive it.

JOSH: That's not a great sales pitch.

ERIK: Correct. "Please debug your couch" is a hard product category.

[beat]

ERIK: This time is different because Steam Deck changed the proof. Proton got better. SteamOS got better. Developers started treating Linux compatibility like it mattered. Users stopped caring what the operating system was called because the games launched.

JOSH: So the box is less important than the stack?

ERIK: Exactly. Hardware is the visible part. The stack is the business.

[beat]

ERIK: Valve has the store, the library, the controller work, SteamOS, Proton, cloud saves, community, mods, and now a living room target. That's not one product. That's layers.

JOSH: But the price is still high.

ERIK: It is. Starting at $1,049 puts it above a PS5, above an Xbox Series X, and even above the PS5 Pro. Valve says they're not subsidizing it like a console maker would.

[beat]

ERIK: That means they aren't using the old closed-box math. Sony and Microsoft can eat hardware margin because they make it back through the store and subscriptions. Valve already has the store. They're saying, "Buy this if you want the PC version of the couch."

JOSH: Does that limit the audience?

ERIK: Absolutely. This is not for everyone. The first buyers are Steam library people, Linux-curious people, and the "I want one box under the TV that doesn't behave like a corporate laptop" crowd.

[beat]

ERIK: But the strategic part is SteamOS for desktops. If regular builders can install SteamOS on their own PC components, the official box becomes a reference build. That's a lot more interesting.

JOSH: Why?

ERIK: Because platforms win when other people can build on them. One box is a product. A repeatable operating layer is a movement with drivers.

[beat]

ERIK: Same reason I don't build one-off scripts and call it automation. PrimeBus works because events go on the bus, agents subscribe, telemetry comes back, and Gandalf reviews code before merges happen. The value is not one agent. It's the pattern.

JOSH: You're comparing Valve to your automation bus?

ERIK: Yeah. Same shape. Different toys.

[beat]

ERIK: Valve hides Linux pain behind SteamOS and Proton. I hide operational pain behind NATS, PrimeBus, and review agents. In both cases, the user should not have to care about the ugly middle.

JOSH: What does Microsoft do here?

ERIK: They should be nervous, but not panicked.

[beat]

ERIK: Windows is still huge for PC gaming. Nobody serious pretends otherwise. But a platform can be huge and still be tolerated instead of loved. That's where the opening is.

JOSH: Tolerated is dangerous.

ERIK: Very. Engineers know this from enterprise tools. The tool everyone complains about but still uses is fine right up until a good-enough replacement removes one daily pain.

[beat]

ERIK: Valve has been removing pain slowly. Steam Deck made Linux gaming normal for a lot of people. Steam Machine tries to put that same idea under the TV. SteamOS desktop says, "Bring your own hardware."

JOSH: So this isn't about beating consoles this summer.

ERIK: No. It's about making the default less default over time.

[pause]

JOSH: Move to GLM-5.2 and the local AI chatter. You said don't trust screenshots. Why are you still interested?

ERIK: Because the direction matters even when the rumor math is messy.

[beat]

ERIK: People are throwing around claims like 744 billion parameters, million-token context, and DynamicGGUF quantized builds. Fine. Maybe some of that lands clean, maybe some of it doesn't. Until there's a model card, weights, evals, and repeatable local runs, I treat the numbers like a weather forecast from a group chat.

JOSH: That sounds fair.

ERIK: Builders need that discipline. Big model numbers are fun. They are not a deployment plan.

[beat]

ERIK: What matters is whether the model can do useful work in a real workflow. Can it classify events? Can it summarize logs? Can it read a failed test and point to the right file? Can it run locally without turning your machine into a space heater with opinions?

JOSH: Where does local AI fit for you right now?

ERIK: Hermes. That's my local agentic backend on the Mac M3. It runs qwen3-coder around 70 tokens per second.

[beat]

ERIK: That's not replacing Claude for serious reasoning. Claude is still where I go for bigger code work and harder judgment. Hermes is a worker. It does small jobs close to the system.

JOSH: What's a small job?

ERIK: Classify this event from PrimeBus. Summarize this traceback. Compare two config snippets. Draft a boring response. Decide if a message looks like a task, an alert, or noise.

[beat]

ERIK: Those jobs don't always need a frontier model. They need speed, privacy, and enough accuracy to be useful with guardrails.

JOSH: What's the guardrail?

ERIK: Blast radius.

[beat]

ERIK: If a task touches production behavior, money, security, customer data, or a merge decision, it gets stronger review. If it's a local summary or a candidate classification, Hermes can take a swing.

JOSH: So local models are worker bees.

ERIK: Worker agents, yeah. Cheap brains near the files.

[beat]

ERIK: The mistake is asking, "Can this local model beat the best cloud model?" Wrong question. Ask, "Can this local model remove 40 tiny cloud calls from my day without doing damage?"

JOSH: That changes the economics.

ERIK: It does. It also changes architecture.

[beat]

ERIK: Once you have local agents, you can run more checks. You can have a model watch logs, scan configs, inspect diffs, read test output, and hand off only the weird stuff. That's where this gets useful.

JOSH: Where do huge context windows fit?

ERIK: Carefully.

[beat]

ERIK: Huge context is not magic memory. It's a bigger room to make a mess in. If you dump a whole repo, five logs, a Slack thread, and a Terraform plan into context, you may feel productive, but you might just be burying the signal.

JOSH: That's very on brand.

ERIK: It's true. Context engineering matters more as context windows get bigger.

[beat]

ERIK: Give the model the right files. Give it the failing test. Give it the current diff. Give it the rule. Then make it state what it thinks the task is before it acts.

JOSH: That's the pro tip preview, isn't it?

ERIK: Part of it. Agents should not be trusted because they sound confident. They should be trusted because the workflow forces them to show the right inputs.

[beat]

ERIK: ScanBrief is a good example. The system doesn't just grab a headline and vibe. It pulls sources, scores items, and makes the signal traceable enough that I can reject weak stuff. Same principle for code agents.

JOSH: How should builders handle GLM-5.2 specifically?

ERIK: Wait for repeatable runs. Check the license. Check memory needs. Check quantized accuracy on tasks you actually do. Run it against your logs, your tests, your docs.

[beat]

ERIK: Don't ask if it wins a leaderboard. Ask if it saves you time on Tuesday.

[pause]

JOSH: Polymarket. This one feels like a trust story, not just a crypto story.

ERIK: Correct. Prediction markets sell credibility. That's the product.

[beat]

ERIK: The pitch is, "Markets know something." Prices become a signal. If the marketing around that signal is fake, you've poisoned the thing you're selling.

JOSH: Reports said fake-looking wins, paid creators, and even spoofed-looking site content. How bad is that?

ERIK: Bad. Not because creators got paid. Paid promotion is normal if it's disclosed and honest. The problem is making ads look like organic proof while showing outcomes that didn't happen.

[beat]

ERIK: If a video implies someone turned $1,000 into $100,000 on a bet that wasn't real, that's not edgy internet marketing. That's a compliance department hearing boss music.

JOSH: And the deposits number was about $900,000?

ERIK: That's what the reporting said. Roughly $900,000 in user deposits tied to the campaign.

[beat]

ERIK: That's the part operators should stare at. Bad incentives can move real money fast. Then the cleanup is slower, louder, and more expensive.

JOSH: How does that compare to automated systems?

ERIK: Same rule. If your system creates trust signals, you have to protect them.

[beat]

ERIK: Gandalf reviews code because a green merge badge should mean something. PrimeTrader reacts to TradingView webhooks because a trade signal should mean something. ScanBrief ranks news because a top story should mean something.

JOSH: If those signals get noisy, people stop trusting the system.

ERIK: Exactly. Trust is a cache. Hard to fill. Easy to invalidate.

[beat]

ERIK: Once users think the numbers are fake, you don't get to explain your way back quickly. You need audits, receipts, provenance, and boring controls. The boring stuff becomes the product.

JOSH: That's not how founders like to talk.

ERIK: Too bad.

[beat]

ERIK: If you're moving money, sending emails, merging code, or ranking information, you need evidence trails. Who generated it? What input did they use? What policy checked it? What got blocked?

JOSH: That's the same architecture you use with PrimeBus.

ERIK: Yeah. Events, review, action, audit. Every time.

[beat]

ERIK: When an agent proposes a patch, I want the failed test, the diff, the reason, and the reviewer result. When ScanBrief ranks a story, I want the source trail. When PrimeTrader sees a webhook, I want the condition that fired.

JOSH: And for a prediction market?

ERIK: Label paid creators. Ban fake results. Keep public ad archives. Make deposits traceable to campaigns. Build the audit before the regulator writes it for you.

[beat]

ERIK: Because they will write it. And they won't use your branding guide.

JOSH: That's a rough line.

ERIK: It's accurate.

[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 an agent touches code, money, infrastructure, or outbound email, make it produce a context receipt.

[beat]

JOSH: Context receipt?

ERIK: Simple format. "Task understood." "Files inspected." "Commands run." "Assumptions." "Risk level." "Next action." Then require the next action to match that receipt.

[beat]

ERIK: If the agent says it's fixing a Terraform variable but never opened the Terraform file, stop it. If it says it's changing an NSO service but didn't inspect the service package, stop it. If it wants to send email and can't quote the recipient and body, stop it hard.

JOSH: That sounds obvious.

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

[beat]

ERIK: The receipt turns a chatty model into a controlled worker. You don't need a fancy framework. Add it to your prompt, enforce it in your script, and log it with the action. 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 22. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.

ERIK: Desktop apps are coming back, open models are getting good enough, and identity checks are about to become part of the AI stack.

JOSH: Stick around — Erik's got an AI pro tip at the end about using model routing without turning your app into a science project.

[pause]

JOSH: First headline. Deno Desktop showed up in Deno 2.9 canary. Is this actually interesting, or just another Electron alternative?

[beat]

ERIK: Interesting. One binary, Deno runtime, web rendering, fewer moving parts. If it lands clean, it gives builders a way to ship desktop tools without dragging half a browser-shaped apartment building with them.

JOSH: Second. Apertus Mini dropped a set of open foundation models for sovereign AI.

ERIK: That's the direction. Smaller models, distillation, quantization, local deployment. Not every task needs a frontier model with a credit card attached.

JOSH: Third. Identity verification on Claude is getting attention.

ERIK: Makes sense. Once agents can take real actions, accounts need stronger gates. It's boring until your agent emails a client, opens a ticket, or merges code. Then boring is beautiful.

[pause]

JOSH: ScanBrief scored 54 items across 54 sources today. Deno Desktop came in at the top. Why did that one jump out?

[beat]

ERIK: Because desktop software never died. It just got annoying to ship.

ERIK: Web apps won because deployment was easy. Open a browser, done. But builders still need local tools. Network engineers need packet viewers, config editors, lab dashboards, serial console helpers, local AI tools. Stuff that talks to files, sockets, USB, CLIs, and weird vendor nonsense.

ERIK: Electron solved that by saying, cool, we'll ship a browser with every app. It works. I'm not going to pretend it doesn't. VS Code exists. Slack exists. Tons of tools use it.

ERIK: But the cost is real. Big binaries. Heavy memory use. Slow startup. And then every small utility feels like it needs a loading dock.

JOSH: Deno Desktop changes that how?

ERIK: The pitch is simple. Take a Deno project, bundle it into a self-contained desktop app, include the runtime and rendering engine, and ship one redistributable binary.

ERIK: That matters because Deno already has a strong permissions model, TypeScript first, web APIs, good tooling, and a sane runtime story. If desktop packaging becomes boring, that's a win.

JOSH: Why do you care as an automation guy?

ERIK: Internal tools. That's where this gets useful fast.

ERIK: In my lab, PrimeDash watches what's alive across the LAN. Right now I've got 128 services running on the production server. I don't need a giant product ceremony to view that. I need a fast local app that shows status, logs, events, maybe a button to restart a dev service.

ERIK: Same with PrimeBus. It processed 865 automation events across 18 projects today. A desktop view into that event stream would be useful. Not a SaaS dashboard. A local operator console.

ERIK: Deno Desktop could be a nice fit for that kind of thing. Small app. Local permissions. Talks to NATS. Reads logs. Opens a browser only when it has to.

JOSH: Is this a threat to Electron?

[beat]

ERIK: Not immediately. Electron has years of scars and fixes. That's valuable. Packaging is ugly. Auto-update is ugly. Native menus are ugly. Code signing is ugly. Every OS has its own little personality disorder.

ERIK: But builders don't always need the mature truck. Sometimes they need a motorcycle that starts.

ERIK: If Deno Desktop makes the first 80 percent easy, people will use it for internal tools, prototypes, agent consoles, local dashboards, and weird little utilities. That's where adoption starts.

JOSH: What would you build first with it?

ERIK: PrimeBus event inspector. Live tail of events, filters by project, click into the payload, show which agent touched it, show whether Gandalf blocked or approved it.

ERIK: The auto-merger has run 1276 attempts since 2026-06-05: 846 merged, 430 blocked by Gandalf, 0 escalated to Erik. That's not a web page problem. That's an operator console problem.

ERIK: I want to see the guardrails working in real time. I want to see why something got blocked. I want a button that says rerun with more context, not a Jira ticket that says someone is sad.

JOSH: That's very specific.

ERIK: Specific is where software gets good.

[pause]

JOSH: The second big theme today is open models. Apertus Mini, GLM 5.2 versus Opus, and even a post saying there's minimal downside to switching to open models.

JOSH: Are we at that point?

[beat]

ERIK: For a lot of work, yes.

ERIK: Not all work. Don't be silly. Frontier models still matter. Claude is still my daily driver for serious coding and reasoning. I use it because it solves real problems in my systems.

ERIK: But if your task is classification, routing, extraction, summarization, formatting, log labeling, dedupe, or first-pass review, open models are good enough more often than people admit.

ERIK: That's the shift. You don't need one giant brain for every task. You need a bench.

JOSH: What's the practical difference for builders?

ERIK: Cost, latency, privacy, and control.

ERIK: If ScanBrief is scoring stories, summarizing feeds, deduping titles, and ranking relevance, I don't need Opus for every step. Some steps can run on a smaller model. Some can run local. Some can run cheap. Save the heavy model for the judgment calls.

ERIK: That's how I think about agents too. Put the expensive model where mistakes are expensive. Put smaller models where mistakes are cheap and easy to catch.

JOSH: Is sovereign AI mostly government language, or does it matter for normal teams?

ERIK: It matters if you care where your data goes.

ERIK: A bank cares. A hospital cares. A defense contractor cares. A small business with client emails should care too, even if they don't say sovereign AI at lunch.

ERIK: Open models give you options. Run local. Run in your VPC. Fine-tune for a narrow task. Quantize it. Put it behind your own auth. Log the outputs. Control the retention.

ERIK: That's not ideology. That's engineering.

JOSH: But people hear open model and think worse model.

ERIK: Sometimes it is worse. Sometimes it doesn't matter.

ERIK: If a model extracts the requested website change from an email and produces a JSON object, I don't need it to write a novel. My email-reactor needs sender, site, requested change, confidence, and whether a human should review. That's it.

ERIK: If confidence is low, route it to a human or a stronger model. If confidence is high, make a branch, change the file, run tests, open the review path.

ERIK: That's a great open-model job.

JOSH: So it's not open versus closed. It's routing.

ERIK: Exactly. Model routing is the real skill.

ERIK: Claude for hard reasoning. Smaller open model for cheap repetitive work. Maybe GPT for another kind of writing or comparison. Maybe a local model for private logs.

ERIK: Builders who wire that correctly will spend less and move faster. Builders who send everything to the biggest model are basically using a forklift to move a coffee cup.

JOSH: Wait, really? You'd trust a smaller model inside an automation pipeline?

[beat]

ERIK: With guardrails, yes.

ERIK: Never trust any model naked in prod. I don't care whose logo is on it.

ERIK: Put schemas around it. Put tests around it. Put policy checks around it. Put a second reviewer on risky changes. That's what Gandalf does in my pipeline.

ERIK: Ten code changes were automatically reviewed by Gandalf and merged to production overnight. That's not because I told an AI, good luck buddy. It's because the system has stages. Generate. Test. Review. Block if weird. Merge only if it passes.

ERIK: Models are workers. The system is the boss.

[pause]

JOSH: That connects to the Claude identity verification story.

JOSH: Why is identity suddenly part of the AI conversation?

[beat]

ERIK: Because agents crossed the line from chatting to acting.

ERIK: The moment an AI can send email, call an API, buy ads, merge code, touch infrastructure, or access customer data, identity matters. Who is running it? What account owns it? What permissions does it have? What did it do? Can you prove it?

ERIK: Old chatbots didn't need much identity because they were mostly producing text. Agent systems need identity because they create consequences.

JOSH: Some people are going to hate that.

ERIK: Of course. Nobody loves verification until fraud shows up.

ERIK: There was also a story today from someone asking whether their old startup job only existed because of fraud. That's the uncomfortable side of tech. Sometimes the demo is real, the payroll is real, the career step is real, and the money behind it is rotten.

ERIK: AI agents make that risk worse if you don't know who is operating what.

JOSH: How does that show up technically?

ERIK: Service accounts everywhere. API keys copied into random places. Personal tokens doing company work. Agents with broad permissions. No audit trail. No approval boundary.

ERIK: That's how you get trouble.

ERIK: In network automation, this is old news. With Cisco NSO or Terraform, you don't give every script full access to the kingdom. You use roles. You separate plan from apply. You log changes. You require review for dangerous moves.

ERIK: AI doesn't get a pass because it sounds confident.

JOSH: What's the right pattern?

ERIK: Start with least privilege. Give the agent only the tool access it needs. Use short-lived credentials where you can. Tie every action to an actor, even if the actor is an agent. Store the prompt, the model, the tool call, the diff, and the result.

ERIK: Then separate authority. The model can propose. The system decides. For low-risk work, let it run. For high-risk work, require a reviewer or a policy gate.

ERIK: PrimeBus does this naturally because everything is an event. The agent doesn't secretly do magic in a corner. It emits an event. Another service picks it up. Gandalf reviews it. The merge path records what happened.

JOSH: That's the opposite of just giving an agent your laptop.

[beat]

ERIK: Yeah, please don't give an agent your laptop and a root shell because a demo looked cool.

ERIK: Start small. Lab first. One repo. One task. One permission. Then expand.

ERIK: I built this stuff because I want systems that run while I'm asleep. But asleep doesn't mean careless. It means the guardrails are awake.

JOSH: There's also a headline about preferring duplication over the wrong abstraction.

JOSH: Does that apply here?

ERIK: Completely.

ERIK: People love building one grand agent framework that does everything. That's usually how you make a haunted spreadsheet with API keys.

ERIK: Duplicate a little. Have one small workflow for email changes. One for code review. One for ScanBrief scoring. One for infrastructure checks. Let them prove themselves. Then pull out the common pieces when the pattern is obvious.

ERIK: Wrong abstractions are expensive because they hide risk. In automation, hidden risk becomes a 2 AM phone call.

JOSH: Dry but accurate.

ERIK: That's my brand.

[pause]

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

[pause]

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

[beat]

ERIK: Build a model router before you build another prompt.

ERIK: Pick three lanes. Cheap, normal, and serious.

ERIK: Cheap is for extraction, classification, tagging, cleanup, and simple summaries. Use a small model. Open model if it fits. Local if the data is sensitive.

ERIK: Normal is for everyday writing, code edits, and analysis where you want quality but the blast radius is low.

ERIK: Serious is for architecture, production changes, security-sensitive work, and anything that can cost money or trust.

ERIK: Then add rules. If confidence is below a threshold, move up a lane. If the action touches prod, require review. If the output doesn't match a schema, fail closed. If the model asks for a permission it doesn't have, deny it and log the event.

ERIK: Don't make the model decide how important the task is. Your system decides that.

ERIK: That's your tip. Use it.

[pause]

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

[pause]

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

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

[pause]

ERIK: Build or be replaced.

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