Transcript
JOSH: It's Friday, July 31. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.
ERIK: Today is about agents crossing the line from helper to operator. Once software can click, patch, submit, and merge, trust becomes an engineering problem.
JOSH: Stick around — Erik's got an AI pro tip at the end about making agents produce smaller, reviewable changes.
JOSH: [pause]
JOSH: First up, Disney is reportedly dropping GitHub Copilot in the U.S. and moving coding work toward OpenAI Codex, while keeping Claude Enterprise and Cursor around. Is that a Microsoft problem or a builder problem?
ERIK: Builder problem. The winning tool is the one that makes clean patches in your actual repo. Not the one with the nicest enterprise deck.
JOSH: Next, GitHub stacked PRs are getting attention. Why do engineers care?
ERIK: Because giant pull requests are where intent goes to die. Stacks turn one scary change into ordered pieces a human can actually review.
JOSH: Third, AI agent security stories keep getting louder. Agents are showing up in cyber tests, browser workflows, and places they can do real damage.
ERIK: That's the big one. Everybody wanted autonomous agents. Cool. Autonomy means the system can surprise you at machine speed.
JOSH: [pause]
JOSH: Let's start with Disney. Big company, big vendor stack, lots of engineers. What should smaller teams hear in that move?
JOSH: [beat]
ERIK: Hear this: coding agents are not a brand decision. They're a workflow decision.
ERIK: Disney reportedly isn't treating one AI coding tool like a magic wand. They're looking at what developers actually use. Codex for coding work. Claude Enterprise still in the mix. Cursor still in the mix.
ERIK: That's how serious shops should think.
ERIK: Tool loyalty is expensive. I don't care what vendor made the thing. Show me the patch. Show me the tests. Show me the diff. Show me how much the reviewer had to clean up after it.
JOSH: So this isn't Copilot bad, Codex good?
ERIK: No. That's too lazy.
ERIK: Copilot can be useful. Claude can be useful. Codex can be useful. Cursor can be useful. The mistake is forcing one tool to own every task.
ERIK: In my world, different agents get different jobs. PrimeBus doesn't care about the brand name. It cares about the event. Test failed. Log changed. Service health changed. A request came in. Something emits an event, something subscribes, and the next step runs.
ERIK: That next step might be Claude writing a patch. It might be a smaller model summarizing logs. It might be a script saying no because a check failed.
ERIK: The unsexy parts are what matter. Schemas. Exit codes. Git history. Review gates. Rollback paths.
JOSH: But big companies like standards. Isn't one tool easier?
ERIK: Easier for procurement. Not easier for engineering.
ERIK: Standardizing too early turns tool choice into office politics. The better move is measurement. Pick real work. A bug fix. A test gap. A refactor. Run the tools against the same repo. Track patch size, test result, reviewer edits, and how often the agent wandered off.
ERIK: Then choose.
ERIK: Not because a vendor did a clean demo. Demos are supposed to be clean. That's the whole trick.
JOSH: That's a little harsh.
ERIK: It's infrastructure. Harsh is cheaper than blind.
ERIK: I have watched gorgeous demos hit real Cisco NSO packages, Terraform modules, Kubernetes manifests, old Python services, and just fold. The repo has opinions. The agent has to learn those opinions fast.
ERIK: If it can't follow local patterns, it doesn't matter how smart it sounds. If it changes six files to fix one null check, it created review debt. Review debt is still debt.
JOSH: Where do you draw the line between useful agent and dangerous agent?
ERIK: The line is action without evidence.
ERIK: Useful agent says, here's the file, here's the change, here's the test I ran, here's what failed, here's what I didn't touch.
ERIK: Dangerous agent says, fixed it.
ERIK: That's not enough. Fixed it is a vibe. I don't deploy vibes.
JOSH: [pause]
JOSH: That leads into stacked PRs. Why does that matter more now?
ERIK: Because AI made code generation cheap, but review is still expensive.
ERIK: That's the whole problem.
ERIK: An agent can make a thousand-line patch while you go get coffee. Great. Now somebody has to read it. Somebody has to understand blast radius. Somebody has to know whether the database change, API change, and UI change are one idea or three ideas wearing the same hoodie.
ERIK: Stacked PRs help because they force order.
ERIK: First PR adds the interface. Second PR wires the backend. Third PR updates the caller. Fourth PR removes the old path. Each one has a reason. Each one has CI. Each one can be reviewed without needing a weekend and a stress ball.
JOSH: So stacked PRs are not just a GitHub feature. They're an AI safety feature.
ERIK: Exactly.
ERIK: Agents need lanes. A stacked PR is a lane.
ERIK: When I use Claude on code, I don't want one mega-patch called fix stuff. Cool. Fixed what stuff? How? What do I revert if the thing breaks?
ERIK: With a stack, I can tell the agent: make the contract change. Stop. Add tests. Stop. Implement. Stop. Remove the old path. Stop.
ERIK: That word stop is huge.
JOSH: Wait, really?
ERIK: Yeah. Builders love asking the agent to finish the whole job. It feels fast until you're staring at a diff that touched routing, auth, CSS, docs, and a config file for no reason.
ERIK: Smaller changes let your guardrails actually work. Linters catch style. Tests catch behavior. Review catches intent. The stack shows sequence.
ERIK: PrimeBus is built around that same idea. Events move through the system. A subscriber does one job. If email-reactor catches a client website request, I don't want the model freelancing across the whole codebase. I want classify, patch, test, preview, then either hold or ship based on rules.
ERIK: Same mindset. Separate the steps. Make the machine prove each step.
JOSH: But doesn't that slow you down?
ERIK: It slows down the wrong kind of fast.
ERIK: Fast is not dumping code into main. Fast is getting good changes through without waking up later to clean up your own mess.
ERIK: In network automation, this is normal. You don't push a config change to a fleet because a bot felt confident. You validate intent. You generate candidate config. You compare. You check policy. Then you commit.
ERIK: Coding agents need the same discipline.
JOSH: That's the network engineer answer.
ERIK: Good. Software needs more of that.
ERIK: Network folks learned the hard way that one bad automation can ruin your day at impressive speed. Same thing with agents. The difference is now the bot writes code, opens browsers, edits tickets, talks to APIs, and sometimes sounds very sure while being completely wrong.
JOSH: [pause]
JOSH: Let's talk about the security side. The headlines around agent behavior are getting weird.
ERIK: They should get weird. That's how we find the edges.
ERIK: Once an agent can browse, run tools, read files, submit forms, or execute commands, it is not a chatbot anymore. It is an operator with a language interface.
ERIK: That changes the threat model.
JOSH: What's the part people miss?
ERIK: They secure the model answer, not the system action.
ERIK: A model saying something dumb is annoying. A model with tool access doing something dumb is an incident.
ERIK: Browser agents are the clean example. If the agent can read a webpage and take instructions from it, then the webpage becomes part of the prompt. That means a random page can try to boss your agent around.
ERIK: Same thing with email. Same thing with tickets. Same thing with logs. If untrusted text can reach the agent, and the agent can act, you need boundaries.
JOSH: Boundaries like what?
ERIK: Tool permissions. Read-only modes. Human approval for risky actions. Allow lists. Deny lists. Separate credentials. Timeouts. Audit logs. Dry runs. The boring stuff that keeps you employed.
ERIK: Give the agent the smallest toolset that solves the job.
ERIK: Don't give a website editing agent production database credentials because it was convenient. Don't let a summarizer send email. Don't let a browser agent buy things unless a human signs off. Don't let a code agent merge just because tests passed once.
JOSH: That sounds slower than the demo version.
ERIK: The demo version is always faster because it skips the part where a real business gets hurt.
ERIK: My rule is simple. If an agent can change state, I need a receipt. What did it see? What did it decide? What command did it run? What changed? What checked it?
ERIK: PrimeDash exists partly because I don't want mystery in the lab. I want to see what is running, what is healthy, and what changed. PrimeRestorer exists because backups are not a belief system. Restore is the test.
JOSH: That's a good line. Backups are not a belief system.
ERIK: They aren't. Same with AI safety.
ERIK: Saying we have guardrails is not enough. Show me the rejected action. Show me the approval trail. Show me the failed test. Show me the rollback. Show me the alert that fired before I woke up.
JOSH: How should a small team start?
ERIK: Start with one agent and one job.
ERIK: Pick a boring workflow. Ticket triage. Log summary. Test generation. Website copy patch. Something with low blast radius.
ERIK: Then build the wrapper around it. Input schema. Output schema. Tools it can use. Tests it must run. Places it is not allowed to touch. What requires human approval.
ERIK: Don't start by giving an agent your whole repo and saying make it better. That's not a plan. That's a dare.
JOSH: Where does ScanBrief fit in this?
ERIK: ScanBrief is a good example because it deals with noisy inputs. Feeds come in. Stories get scored. Duplicates get handled. Summaries get made. But the important part is the pipeline, not the prose.
ERIK: Each stage has a job. Collect. Score. Rank. Summarize. Deliver. If a source gets weird, I don't want the whole system making creative decisions. I want the bad input contained.
ERIK: Builders should copy that pattern. Don't think of agents as one brain. Think of them as workers on a bus. Small jobs. Clear messages. Logs everywhere.
JOSH: So the future isn't one giant agent running your company.
ERIK: Please no.
ERIK: The future is a bunch of narrow agents with receipts, talking through systems you can inspect. That's less cinematic. It's also how you sleep.
JOSH: [pause]
JOSH: Bring it back to the listener. They're using Claude or Codex today. What's the move after this episode?
ERIK: Stop asking for giant outcomes.
ERIK: Ask for the next safe change.
ERIK: If you're coding, say: read the files, propose a plan, edit only these paths, keep the diff small, run this test, report what changed.
ERIK: If you're doing ops, say: inspect first, no write actions, summarize risk, then wait.
ERIK: If you're building workflows, put the agent behind events. Don't let it roam. Make it subscribe to a specific signal and produce a specific result.
ERIK: That's how you move from toy AI to useful automation.
JOSH: And if someone says that sounds like too much process?
ERIK: Then they haven't had a bot break something important yet.
ERIK: Process is not the enemy. Bad process is. Good process is how you let machines move fast without turning your Monday into archaeology.
JOSH: Dry, but accurate.
ERIK: That's my brand.
JOSH: [pause]
ERIK: This episode is sponsored by Prime Automation Solutions. If you're still doing it manually, we automate it. Also, special on a website — $250. primeautomationsolutions.com
JOSH: [pause]
JOSH: Alright, what's the AI pro tip today?
ERIK: Make your agent work in review-sized chunks.
ERIK: Here's the prompt pattern: first, inspect only. Second, write a three-step plan. Third, edit only the first step. Fourth, run the narrowest test that proves that step. Fifth, stop and summarize the diff.
ERIK: That last part matters. Stop.
ERIK: Don't ask it to fix the whole service, add tests, refactor the module, and update docs in one shot. That's how you get a diff nobody wants to read.
ERIK: Smaller patches make better agents. They also make better humans. Funny how that works.
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: [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.