Build or Replaced
Today: Cool URIs Don't Change (1998) | Everything you do is being recorded | Auto mode is now the default in Claude Code Episode date: 2026-08-10.
Download MP3 →JOSH: It's Monday, August 10. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: Agents are getting more freedom, which means your guardrails better be real. JOSH: Stick around — Erik's got an AI pro tip at the end about making agents prove their work before they touch prod. [pause] JOSH: First headline. Claude Code has made auto mode the default. Erik, good idea or bad idea? ERIK: Good idea if your repo has tests, permissions, and review gates. Bad idea if your safety plan is vibes and an old README nobody reads. JOSH: That feels targeted. ERIK: It is. Auto mode isn't the problem. Unsupervised change with no telemetry is the problem. [beat] JOSH: Docker announced Sandboxes for AI agents. Disposable, isolated environments with micro-VM backing. ERIK: That's the right direction. Agents need real operating system access to be useful, but they should get it inside a box you can throw away without crying. JOSH: So not just another container story? ERIK: No. This is about giving agents teeth without handing them the house keys. [beat] JOSH: GitHub Trending has code-graph-rag, a RAG system that builds a knowledge graph over monorepos. ERIK: That one matters. Plain text search gets you close. A graph tells the agent what depends on what before it starts swinging a wrench. [pause] JOSH: The big one today is Claude Code auto mode. What actually changed? ERIK: Claude Code making auto mode the default means the tool is assuming more agency up front. It can inspect files, make edits, run commands, and keep moving with less hand-holding. That's what builders want. Nobody wants to approve every single file read forever. JOSH: But that sounds like the scary part. ERIK: It should scare people a little. Fear is useful if it turns into architecture. The wrong reaction is, "AI is dangerous, block it." The right reaction is, "Cool, put it in a lane, instrument the lane, and make it prove every step." JOSH: What does that look like in a real system? ERIK: PrimeBus is the pattern. Everything emits events. Build started. Test failed. Review posted. Fix attempted. Merge blocked. Merge allowed. The agent doesn't just do work. It leaves a trail. JOSH: And Gandalf is part of that? ERIK: Yeah. Gandalf is my code reviewer agent. Codex-backed. Runs on every push. It doesn't care if the patch looks clever. It checks behavior, tests, risk, and blast radius. If the agent touched auth, billing, infra, file deletion, secrets, anything spicy, Gandalf gets much less polite. [beat] JOSH: So auto mode is fine if the agent has a boss. ERIK: Exactly. Claude can be fast. Codex can review. NATS can carry the events. CI can run the proof. Your job is to build the cage match where only correct work survives. JOSH: That's a very Erik sentence. ERIK: Duuude, it's true. Agents don't need pep talks. They need constraints. JOSH: What does this mean for a normal developer using Claude Code today? ERIK: Start with three rules. First, don't let auto mode write into a dirty git state. Second, require a test command, even if it's tiny. Third, make the agent explain the diff after it runs the test, not before. JOSH: Why after? ERIK: Before is theater. After is evidence. Before the test, the model is predicting. After the test, it has a result. Huge difference. JOSH: What about teams? ERIK: Teams need policy. Which paths can the agent touch? Which commands can it run? Which changes require human review? Which failures open a ticket? If you don't write those rules down, your rules are whatever the agent guessed today. JOSH: That's a rough way to run engineering. ERIK: It's also how a lot of teams are about to run engineering. They want the speed, but they don't want the plumbing. Sorry. The plumbing is the product now. [pause] JOSH: Docker Sandboxes feels connected to that. Agents need more access, but the access needs walls. ERIK: Yep. Docker is seeing the same thing everyone serious is seeing. Agents are weak if they can only suggest commands in a chat box. But the second they can run commands, install packages, inspect files, and hit networks, now you have a security conversation. JOSH: What's different about disposable sandboxes? ERIK: You get a clean room. Let the agent clone the repo, install dependencies, run a migration test, maybe compile something ugly. When it's done, throw the whole environment away. No mystery files. No polluted local machine. No "why is my shell broken now" archaeology. JOSH: I have done that archaeology. ERIK: Everyone has. It's not a hobby. It's a tax. [beat] JOSH: Docker says policy can sit around these sandboxes. Is that enough? ERIK: It's a building block. The key is policy once, enforcement everywhere. That's the part enterprises care about. If every engineer invents their own agent sandbox on a Friday afternoon, you get chaos with a logo. JOSH: What policies would you start with? ERIK: Network first. Can the agent reach the public internet? Can it hit internal services? Can it call package registries? Then filesystem. Is it read-only except the workspace? Can it see SSH keys? Can it see cloud credentials? Then command classes. Build commands are different from curl-piping a shell script into root. Obvious sentence, somehow still necessary. JOSH: Wait, really? ERIK: Really. The industry spent decades learning not to run random code with broad permissions. Then AI showed up and everybody got amnesia because the text sounded confident. JOSH: That is bleak. ERIK: It's fixable. Use sandboxes. Use allowlists. Kill the environment after the job. Log everything. If the agent needs more access, make that an explicit permission request. Same as production network automation. JOSH: How does your network automation background shape this? ERIK: Cisco NSO taught me that automation touching real infrastructure needs rollback, validation, and a model of intent. You don't just blast config into routers because the script said it was fine. You check pre-state. You apply the change. You check post-state. You know how to back out. JOSH: And agents need the same pattern. ERIK: Absolutely. An AI coding agent changing Terraform is not emotionally different from an automation system changing BGP policy. Different files, same risk category. The tool is acting on your behalf. That means you need intent, validation, and rollback. [beat] JOSH: Where does PrimeSentinel fit into that? ERIK: PrimeSentinel watches for stuck jobs. That's boring until it saves you. Agents can get weird. A test runner hangs. A browser automation job never returns. A queue gets quiet in a way that looks peaceful but actually means nothing is moving. PrimeSentinel catches that and kicks the right workflow. JOSH: So the watchdog matters as much as the agent. ERIK: More, sometimes. Everyone wants the smart agent. Fewer people want the boring monitor that says, "Hey, your genius has been staring at a locked process for half an hour." Guess which one keeps the system alive. [pause] JOSH: The third story is code-graph-rag. Why does a graph help agents write better code? ERIK: Because codebases are not documents. They're relationships. Function calls, imports, database models, event names, config files, test fixtures, deployment scripts. Plain RAG treats a repo like a pile of text chunks. That's useful, but it misses shape. JOSH: Shape meaning dependencies? ERIK: Dependencies, ownership, side effects, entry points. If an agent changes a message schema in PrimeBus, I don't want it finding random files with the same string. I want it to understand producers, consumers, validators, and tests. A graph gives you a map of what breaks when one thing moves. JOSH: That sounds expensive to build. ERIK: It can be. But monorepos are already expensive to misunderstand. Pick your bill. [beat] JOSH: How would this change an agent workflow? ERIK: Today, a lot of agents do search, read, edit, test. With a code graph, the flow becomes search, reason over relationships, pick impact area, edit, test the affected paths. That's a better loop. It reduces random wandering. JOSH: Is that what you want for your own systems? ERIK: Yeah. ScanBrief is a good example. It has ingestion, scoring, ranking, summarization, delivery. If I change the scoring shape, the agent needs to know what consumes that shape later. Email rendering might break. A dashboard might expect a field. A test fixture might be stale. String search catches some of that. A graph catches the pattern. JOSH: And for smaller repos? ERIK: Still useful, but don't turn a tiny app into a research project. If your repo has one service and five files, grep is fine. If you have event buses, background workers, API contracts, React views, Terraform, and cron jobs talking to each other, you need more structure. JOSH: That's the line? ERIK: The line is pain. If agents keep editing the right file and breaking the wrong caller, you need a graph. If reviews keep saying "you missed the consumer," you need a graph. If onboarding a human takes forever because nobody knows the dependency path, you need a graph. [beat] JOSH: Where does Hermes fit into this? That's your local LLM backend, right? ERIK: Yeah, Hermes runs local agent work on the Mac M3. I like local models for fast inspection, small refactors, repo reading, and private context. I don't need every task going to a frontier model. Use the big model where judgment matters. Use local where iteration matters. JOSH: So model selection is part of the architecture too. ERIK: Exactly. Claude for deep reasoning and coding. Codex where review and patch discipline matters. Local qwen for cheap repo chewing. Selenium when the work hits a browser. NATS when agents need to coordinate. Kubernetes or plain systemd depending on what the service actually needs. Pick tools like an engineer, not like a press release. JOSH: That's going on a mug. ERIK: Please don't. We have enough mugs. [pause] JOSH: There's a bigger theme here. More agent freedom, more isolation, better code context. ERIK: That's the whole week in one sentence. The tools are growing up. The workflow around them has to grow up too. If you give agents more permission, you need better boxes. If you give them bigger repos, you need better maps. If you let them make changes, you need proof. JOSH: And if you don't? ERIK: Then you get a very confident machine making a mess at computer speed. That's not innovation. That's unpaid incident response. JOSH: What's the practical move for a builder listening today? ERIK: Make one agent lane. Not the whole company. Not the whole repo. One lane. Pick a narrow task. Dependency bumps. Test fixes. Lint fixes. Documentation checks. Put it in a sandbox. Require tests. Require review. Emit events. Watch the queue. Then expand only after the system earns it. JOSH: That's very different from "turn on AI everywhere." ERIK: Because "turn on AI everywhere" is how you create a thousand tiny permissions problems. Builders need boring wins. A boring win compounds. A flashy failure gets you a policy meeting with people who print emails. [beat] JOSH: I feel like that's personal. ERIK: Network engineering will do that to you. [pause] ERIK: This episode is sponsored by Prime Automation Solutions. If you're still doing it manually, we automate it. Also, special on a website — $250. primeautomationsolutions.com [pause] JOSH: Alright, what's the AI pro tip today? ERIK: Make your agent write a proof file before it asks to merge. Not a novel. A small artifact. Call it something like agent-proof.md. It should include the command it ran, the result, the files changed, the risk area, and the rollback plan. JOSH: Why a file instead of just chat? ERIK: Chat disappears into the scroll. A file sits in the repo or the PR. Gandalf can review it. CI can check that it exists. A human can scan it fast. The agent has to connect its claim to evidence. JOSH: What should the prompt say? ERIK: Say this: "Before you finish, create agent-proof.md with exact commands run, exact test results, changed files, risky assumptions, and rollback steps. If you did not run a test, say why." Then make the next agent or reviewer compare the proof to the diff. JOSH: That's simple. ERIK: Simple is the point. Don't start with a giant agent platform. Start by making the model leave receipts. 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.