Build or Replaced
Today: Dopamine Fracking | APC–2 – A professional record cutter for producing original playback discs | Building from zero after addiction, prison, and a felony Episode date: 2026-06-08.
Download MP3 →JOSH: It's Monday, June 8. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: Today's theme is simple: AI agents are entering the workplace, and the real product is control. JOSH: Stick around — Erik's got an AI pro tip at the end about using model disagreement as a safety system. JOSH: [pause] JOSH: First headline: Microsoft Build pushed hard on agent infrastructure. Are we past the chatbot phase? ERIK: Yep. Microsoft is talking agent runtime, model catalogs, Work IQ APIs, and sandboxed execution. That's not chat. That's plumbing for software that acts. JOSH: Second: Anthropic filed confidential IPO paperwork, and the AI cost conversation got loud again. ERIK: Good. The bill finally showed up. Everyone loves frontier models until finance asks why one support workflow costs more than the humans it replaced. JOSH: Third: researchers keep calling out AI slop in software development. Is that just developers complaining? ERIK: No. Review burden is real. If AI generates ten bad patches and a senior engineer has to clean them all up, you didn't automate work. You moved the pain. JOSH: [pause] JOSH: Microsoft is the first deep one. Agent infrastructure sounds boring. Why should builders care? ERIK: Boring is where the money is. The flashy demo is the agent booking a meeting or editing a spreadsheet. The real question is what files it can touch, what network calls it can make, what secrets it can see, and who gets blamed when it does something dumb. JOSH: That's the part most demos skip. ERIK: Always. Demos love the happy path. Production is where your agent finds an old API token, writes to the wrong repo, and calls it confidence. That's why the Microsoft Execution Containers idea matters. Give agents a box. Give that box rules. Limit file access. Limit network access. Limit UI access. Then log everything. JOSH: So you're saying the sandbox is the product. ERIK: For enterprise AI, yes. The model is only one piece. You need identity, policy, audit trails, rollback, and a way to prove what happened. That's why agent runtime matters more than another clever chat window. JOSH: How does that compare to what you run? ERIK: PrimeBus is the same pattern in my lab. NATS moves the events. Agents subscribe to specific messages. PrimeSentinel watches for stuck jobs. Claude can propose fixes, but it doesn't get a crown and a sword. It gets a task, context, guardrails, and a review path. JOSH: Wait, really? ERIK: Really. If a job fails, the event says what failed. Not "something broke." Test output, repo, branch, service, timestamp. The agent has a narrow job. It can inspect. It can patch. Then another layer reviews. That is very different from "hey Claude, go fix production." JOSH: That's the line. ERIK: That's the whole line. Agents need lanes. A network engineer understands this immediately because we've had blast radius drilled into us forever. You don't push a global BGP change because a script felt inspired. You stage it. You validate it. You roll it back if it gets spicy. JOSH: And Microsoft is trying to give that shape to office work? ERIK: That's how I read it. Work IQ APIs are about context. Teams, Outlook, documents, meetings. The agent can understand the work graph. But context without control is dangerous. If the agent knows everything and can act everywhere, congrats, you built an intern with root access. JOSH: That's a sentence that should be on a coffee mug. ERIK: Probably a warning label. The useful version is smaller. Let the agent prepare a meeting brief. Let it draft the follow-up. Let it find the customer thread. But when money moves, contracts change, production config changes, or customer data leaves the system, you need gates. JOSH: Where do builders start if they don't have Microsoft's whole stack? ERIK: Use the same architecture with smaller tools. Put events on a bus. NATS, Redis Streams, Kafka, whatever fits. Store the raw inputs. Give each agent a role. One reads logs. One writes a patch. One reviews. One decides if a human is required. Don't let a single model do read, write, approve, and deploy. JOSH: Separation of duties for robots. ERIK: Exactly. Boring security words become exciting when the robot can type faster than your team can review. In NSO, Terraform, Kubernetes, same deal. The tool doesn't matter. The pattern matters. Intent comes in. Plan gets generated. Policy checks it. Human or system approves it. Then execution happens with evidence. JOSH: [beat] JOSH: That sounds slower than the hype version. ERIK: It is slower than a reckless demo. It's faster than cleaning up a bad deployment at 2 AM. People keep confusing speed with absence of friction. Some friction is the point. PrimeBus blocking a bad merge is not lost velocity. That's the system paying for itself. JOSH: And this connects to cost too, right? ERIK: Directly. Every bad agent action has two costs. Token cost and human cost. The token bill is annoying. The human cleanup bill is the killer. If your agent writes junk and a senior engineer spends twenty minutes proving it's junk, that's expensive junk. JOSH: [pause] JOSH: That tees up Anthropic. IPO filing, huge valuation talk, and everyone suddenly cares about AI spending. ERIK: The money conversation was always coming. These companies need massive compute, massive talent, massive distribution, and customers who don't churn when the novelty wears off. An IPO filing makes that visible. JOSH: Why does that matter to someone building small systems? ERIK: Because model economics hit everyone. If you build a workflow where every tiny task goes to the biggest model, you built a fancy furnace. It burns money beautifully. JOSH: So don't use the best model? ERIK: Use the right model. That's different. Claude is great for code reasoning and long messy context. A smaller model might be fine for classification. Embeddings might handle routing. Regex might handle the dumb part. Selenium might pull the page. A cron job might schedule it. Not every problem deserves a frontier model invoice. JOSH: That feels less glamorous. ERIK: Glamour is for pitch decks. Builders need margins. ScanBrief doesn't need a frontier model for every step. Feed collection is boring plumbing. Deduping can be deterministic. Ranking needs judgment. Summaries need care. The trick is matching the expensive thinking to the part where thinking matters. JOSH: How do you decide? ERIK: I look at failure cost. If a mistake is cheap, use cheap tools. If a mistake is expensive, use stronger models and more review. If the task touches money, production, compliance, or customer trust, add gates. That's not complicated. People make it complicated because they want one magical model policy. JOSH: The pricing pressure could actually make systems better. ERIK: Absolutely. A token budget forces architecture. When compute feels free, people get sloppy. They paste giant logs into a prompt and call it engineering. When the bill hurts, suddenly they learn to chunk logs, extract the error, cache results, and stop asking the model to read a novel because one line failed. JOSH: That's wild, because the cost problem becomes a discipline problem. ERIK: Yep. Same as cloud. Everybody loved spinning up instances until the AWS bill started teaching architecture. AI is getting the same education. The model bill is going to create better builders and expose prompt tourists. JOSH: Prompt tourists? ERIK: People who can make a demo but can't keep a system alive. They know model names. They know launch threads. They don't know retries, idempotency, queues, or why your automation needs a dead-letter path. That's the gap. JOSH: How does a small team avoid getting crushed by that? ERIK: Instrument first. Track every model call. Prompt, model, latency, cost, output type, result. Did the action succeed? Did a human edit it? Did the patch pass tests? Did the customer accept it? If you don't measure that, you're just vibes with a credit card. JOSH: That applies to big companies too. ERIK: More, honestly. Big companies can hide waste longer. A solo builder feels the burn fast. In the Echo and Neo lab, I care when an agent loops. PrimeSentinel exists because stuck jobs are real. A loop is not a philosophical issue. It's compute turning into heat while nothing useful ships. JOSH: [beat] JOSH: So the IPO story isn't just Wall Street gossip. ERIK: No. It's a signal that AI is moving from toy budget to operating budget. Once it hits operating budget, CFOs ask rude but useful questions. What did it replace? What did it reduce? What risk did it add? What revenue did it create? Those are the right questions. JOSH: [pause] JOSH: Third deep one: AI slop in software development. This one stings a little. ERIK: It should. AI can make good engineers faster and bad processes louder. That's the honest version. JOSH: What do you mean by louder? ERIK: A weak engineer used to submit one shaky pull request. Now they can submit five. A rushed team used to create a little tech debt. Now they can create a whole landfill with tests that barely mean anything. The model didn't invent the problem. It multiplied it. JOSH: That's bleak. ERIK: It's accurate. But it's fixable. The answer is not "ban AI." That's lazy. The answer is to treat AI-generated work like untrusted input until it proves itself. JOSH: What does that look like in practice? ERIK: Small patches. Clear diffs. Tests required. No drive-by refactors. No touching unrelated files. No dependency changes without a reason. No generated code that the author can't explain. And if the model says "minor cleanup," that diff better be tiny. JOSH: You're describing review rules. ERIK: Yes. AI didn't remove engineering discipline. It made discipline more important. I use Claude every day, but I don't worship the output. I make it show its work through tests, logs, and diffs. JOSH: Where do people go wrong with code agents? ERIK: They ask for outcomes that are too broad. "Improve this service." Terrible prompt. What does improve mean? Faster? Safer? Less memory? Fewer retries? Better logs? If you can't define the change, the agent will decorate the codebase. JOSH: Decorate is brutal. ERIK: Accurate though. I've seen AI patches that rename variables, move files, add abstractions, and somehow don't fix the bug. That's interior design for a failing test. JOSH: How do you keep it tight? ERIK: Give the agent a failing test or a specific error. Tell it the allowed files. Tell it what not to change. Tell it to make the smallest patch. Then run the tests. If it fails, feed back the exact failure. Don't let it wander. JOSH: That's very different from "build me an app." ERIK: Big greenfield prompts are fine for prototypes. Production work needs constraints. Same with network automation. If I'm using NSO or Terraform, I don't ask an agent to "make the network better." I ask it to generate a candidate change for this service, against this schema, with this rollback path, and this validation. JOSH: That makes the AI useful. ERIK: It makes it accountable. Useful comes after accountable. The agent has to produce an artifact you can judge. Patch. plan. test. config. summary. Anything else is smoke. JOSH: How does Josh, not an automation engineer, spot AI slop in a pull request? ERIK: Look for three things. First, scope creep. Did it touch files that don't relate to the request? Second, fake certainty. Does the summary sound confident but avoid specifics? Third, missing proof. No tests, no logs, no before-and-after evidence. JOSH: That's actually easy to remember. ERIK: Good. Add one more. If the code is more abstract after the fix, ask why. Sometimes abstraction is right. A lot of times the model just got fancy because fancy looks smart. JOSH: That's the quiet danger. ERIK: Yep. Fancy code creates future bills. The best AI patch often looks boring. One condition fixed. One test added. One log improved. No parade. JOSH: [beat] JOSH: How does this connect back to being replaced? ERIK: The engineer who can only type code is in trouble. The engineer who can define work, constrain agents, review output, and wire systems together is dangerous. That's the replacement line. JOSH: Dangerous in the good way. ERIK: In the "gets shipped before the meeting ends" way. If you know Claude, NATS, Selenium, Terraform, Kubernetes, and basic business math, you can build systems that make whole categories of manual work look silly. JOSH: And if you don't? ERIK: Then you're competing with someone who does. That's not a threat. That's the weather. JOSH: [pause] ERIK: This episode is sponsored by Prime Automation Solutions. If you're still doing it manually, we automate it. Also, special on a website — $250. primeautomationsolutions.com JOSH: [pause] JOSH: Alright, what's the AI pro tip today? ERIK: Use model disagreement as a safety system. Take one real task today. A bug fix, a Terraform plan, a customer email, anything with consequences. Send the same context to two models or two separate agent runs. Don't ask which one sounds better. Ask where they disagree. JOSH: What are you looking for? ERIK: Differences in assumptions. One model changes a dependency, the other doesn't. One says the test needs updating, the other says the code is wrong. One spots a security issue, one misses it. That disagreement is signal. JOSH: Then what? ERIK: Make a third step. A reviewer prompt. Feed it both answers and ask for risks, not a winner. Then you decide or route it to a human. This works because agreement can be lazy, but disagreement shows the edge of the problem. Do it before the merge, not after production teaches you manners. That's your tip. Use it. JOSH: [pause] ERIK: That tip is straight out of The Autonomous Engineer — my book on building systems that run themselves. Grab it on Amazon. JOSH: [pause] JOSH: One more thing — we started a Discord for builders. If you're shipping AI, automation, or anything that makes a human obsolete — come hang out. Link at buildorbereplaced.dev. ERIK: Post what you built. We'll post what we're building. Real wins, real builds, no fluff. JOSH: [pause] ERIK: Build or be replaced. JOSH: If you want these signals in your inbox every morning, scanbrief.dev. See you tomorrow.