Build or Replaced
Today: Introducing Claude Opus 4.5 | Everyone should know SIMD | Nobody knows what a used GPU cluster is worth Episode date: 2026-07-23.
Download MP3 →JOSH: It's Thursday, July 23. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: Episode 72, and the theme today is simple: faster AI is nice, but guardrails are what let it touch production. JOSH: Stick around — Erik's got an AI pro tip at the end about making agents prove their work before they edit anything. [pause] JOSH: First headline. Anthropic introduced Claude Opus 4.5. Big deal, or another model card with nicer charts? ERIK: Big deal. Opus is the expensive brain, and 4.5 is clearly aimed at coding, long-running agents, and real software work. That's the lane that matters now. JOSH: Second headline. Everyone should know SIMD. Why is that showing up next to AI stories? ERIK: Because speed still matters below the model layer. SIMD is the difference between doing one operation at a time and making the CPU do a whole row of work per tick. AI people ignore that until the bill shows up. JOSH: Third headline. Nobody knows what a used GPU cluster is worth. That sounds expensive and messy. ERIK: It is. A used GPU cluster is not a box of graphics cards. It's power, cooling, interconnects, failed fans, old firmware, weird drivers, and a seller saying "lightly used" like it didn't spend two years cooking tensors in a warehouse. [pause] JOSH: Let's start with Claude Opus 4.5. What changed here? ERIK: The important part is not "new model is smarter." That's the lazy read. The important part is that Anthropic is pushing Opus deeper into software engineering tasks, longer agent runs, and more accessible pricing. That means the model isn't just answering questions. It's sitting inside workflows. [beat] ERIK: That's where this gets real. A chat window is cute. An agent connected to Git, tests, NATS events, service logs, and a deploy gate is a different animal. JOSH: That's your world. ERIK: Yeah. PrimeBus has run 2,295 auto-merger attempts since June 5. Out of those, 1,507 merged and 788 were blocked by Gandalf. Zero escalated to me. JOSH: Zero? ERIK: Zero. And the blocked number is the story. People hear "blocked" and think failure. No. That's the guardrail doing its job. Gandalf looked at the proposed change and said, nope, this doesn't meet the bar. JOSH: So better models don't remove the guardrails. ERIK: They make the guardrails more important. Better models are more convincing when they're wrong. That's the problem. A weak model fails loudly. A strong model can produce a clean diff, a good explanation, and still break something subtle. [beat] ERIK: That's why I don't trust prose. I trust tests, telemetry, blast radius, and rollback paths. JOSH: What does that mean for a normal engineering team? ERIK: Stop treating AI like a helper sitting next to a developer. Treat it like a junior engineer with root access who never sleeps. You don't give that thing direct access to prod because it wrote a confident paragraph. JOSH: Harsh but fair. ERIK: Accurate. The workflow should be: issue comes in, agent reads context, proposes a fix, runs tests, explains the diff, checks policy, then a separate judge evaluates it. If it passes, merge. If it doesn't, block and record why. JOSH: That's Gandalf. ERIK: Right. Gandalf doesn't care how excited Claude sounds. It checks the work. PrimeSentinel watches for stuck jobs, PrimeBus carries the events, and the Echo plus Neo lab gives me a place to prove it before anything gets scary. JOSH: Where does Opus 4.5 fit? ERIK: Hard problems. Refactors. Cross-file reasoning. Weird test failures. The stuff where the cheap model can get close but misses the architecture. [beat] ERIK: My take is simple. Use the best model at the decision points, not everywhere. You don't need Opus reading every log line. Use smaller models to sort, tag, and summarize. Then call Opus when the system needs judgment. JOSH: So not one model for everything. ERIK: Exactly. Model routing matters. A lot of teams are going to burn money because they send every task to the biggest model. That's like using a core router as a doorstop. Technically possible. Financially goofy. [pause] JOSH: The next one is the used GPU cluster story. Why did that hit so high today? ERIK: Because everybody wants compute, nobody wants the invoice, and used GPU clusters look like a shortcut. JOSH: Are they? ERIK: Sometimes. Usually they're a homework assignment wearing a discount sticker. [beat] ERIK: A GPU cluster is a system. The cards are only one piece. You need the chassis, power distribution, cooling, networking, storage, firmware, drivers, orchestration, monitoring, and someone who knows what a failing riser looks like at 2:13 in the morning. JOSH: That got specific. ERIK: Because that's infrastructure. The sales page says GPUs. The reality says thermal events, PCIe weirdness, old CUDA versions, and "why did this node disappear from Kubernetes again." JOSH: How would you price one? ERIK: I wouldn't start with the GPUs. I'd start with the workload. Training? Fine-tuning? Inference? Batch jobs? Bursty experiments? Then I would price power, cooling, failure rate, replacement parts, and the human time to keep it alive. JOSH: So the sticker price is fake. ERIK: Incomplete. Not fake. Incomplete is enough to hurt you. [beat] ERIK: If someone offers you a used cluster for cheap, ask for burn-in history, power draw under load, temperatures, failed component logs, firmware versions, network topology, and whether the interconnect is actually useful for your workload. JOSH: That's a lot. ERIK: It should be. If you're buying a car, you don't just ask if it has wheels. Same idea. JOSH: How does this compare to cloud GPUs? ERIK: Cloud costs more per hour, but you can stop paying when you're done. Owned hardware can be cheaper if it's busy and you can maintain it. If it sits idle, it's furniture with fans. JOSH: Nice. ERIK: In my lab, I don't buy gear because it's cool. I buy gear because it has a job. There are 130 services running on the production server right now. That sounds like a lot, but each one has a reason to exist. If I added hardware, it would need to earn its rack space. JOSH: What's the trap for AI builders? ERIK: They think compute is the bottleneck before they prove the product. That's backward. First prove the workflow. Prove demand. Prove the data path. Prove that a model call creates value. Then worry about owning silicon. [beat] ERIK: Renting a GPU for a few painful invoices can be smarter than buying a cheap cluster that becomes your second job. JOSH: Wait, really? ERIK: Really. People love capex because it feels like control. But control includes maintenance. If your business is not operating GPU hardware, don't accidentally become a tiny data center because you saw a deal. [pause] JOSH: Third story. The startup's Postgres survival guide. This one feels less flashy. ERIK: It is less flashy, which means it probably matters more. JOSH: Why? ERIK: Because Postgres is where optimism goes to meet locks. [beat] ERIK: Startups do this thing where the app works, users show up, and suddenly the database is a crime scene. Slow queries. Missing indexes. Long transactions. One queue table doing the job of a message bus. Background workers fighting the web app. Everybody blames Postgres, but Postgres is sitting there like, you asked me to do this. JOSH: What's the practical advice? ERIK: First, measure. Turn on query logging. Use pg_stat_statements. Know your slow queries. Don't guess. Second, index based on actual query patterns, not vibes. Third, keep transactions short. Fourth, don't use the database as a dumping ground for every workflow event. JOSH: That's where NATS comes in for you. ERIK: Yep. PrimeBus uses NATS because events should move like events. The database should store state. It shouldn't be the only nervous system in the whole app. JOSH: But a lot of teams start with Postgres queues. ERIK: That's fine at the beginning. Simple is fine. The mistake is never revisiting it. A Postgres table can carry jobs for a while. Then one day you have stuck workers, retry storms, dead rows, and a dashboard that lies politely. [beat] ERIK: PrimeSentinel exists because stuck jobs are quiet. Quiet is dangerous. A failed job screams. A stuck job just sits there and steals your day later. JOSH: What should builders watch for? ERIK: Queue depth. Job age. Retry count. Dead letter rate. Long-running transactions. Replication lag. Disk growth. Connection count. Those are boring numbers until they save you. JOSH: How does AI change this? ERIK: AI makes it easier to create more background work than you understand. That's the part nobody wants to say. You add summarization, enrichment, scoring, review, extraction, embedding, reranking, and suddenly one user action creates twelve jobs. JOSH: ScanBrief does that, right? ERIK: ScanBrief is controlled chaos. Today it scored 99 items across 54 sources. That sounds simple, but under the hood it's fetch, dedupe, rank, summarize, filter, and publish. If that was all jammed into one web request, it would be a disaster. JOSH: So the architecture matters more as AI gets cheaper. ERIK: Exactly. Cheaper model calls mean people will call models more. More calls mean more jobs. More jobs mean more failure modes. The winners won't be the people who can prompt the cutest summary. It'll be the people who can run the machinery every morning without babysitting it. [beat] JOSH: That connects back to the Opus story. ERIK: It all connects. Better models create better agents. Better agents create more actions. More actions require better eventing, better observability, and stricter gates. JOSH: And if you skip that? ERIK: Then your AI system becomes a pile of cron jobs with a nice logo. [pause] JOSH: I want to go back to something you said. Better models are more convincing when they're wrong. How do you actually defend against that? ERIK: Separate generation from judgment. That's rule one. JOSH: Explain that. ERIK: The agent that writes the fix should not be the only agent that approves the fix. Same reason you don't let a developer rubber-stamp their own production change with no tests. [beat] ERIK: In my setup, one path generates the change, another path reviews it, and Gandalf can block it. PrimeBus records the whole thing as events. That history matters because you can inspect the decisions later. JOSH: Is that overkill for smaller teams? ERIK: No. The smaller the team, the more you need the machine to remember. Big teams have process. Small teams have people saying "I think I checked that." That's not a system. JOSH: What would the lightweight version look like? ERIK: GitHub issue, branch, agent-generated diff, test run, lint run, review prompt, human approval for risky files. That's enough to start. You don't need my whole fleet on day one. JOSH: But you do need the habit. ERIK: Exactly. Build the habit early. Every agent action should leave evidence. What did it read? What did it change? What command did it run? What failed? Why did it choose that fix? [beat] ERIK: If you can't answer those questions, you don't have automation. You have a magic trick. [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 coding agent produce a work order before it edits files. JOSH: What goes in it? ERIK: Four things. Files it expects to touch. Tests it expects to run. Risk level. Rollback plan. [beat] ERIK: Keep it short. This is not paperwork theater. It's a preflight check. If the agent says it's fixing a CSS bug but wants to edit your auth middleware, stop the run. If it can't name a test, make it explain why. JOSH: So the prompt is basically a contract. ERIK: Yep. Tell the agent: before making changes, write the work order. After changes, compare the final diff against the work order. If it touched extra files, it must explain why. [beat] ERIK: That one pattern catches a lot of nonsense. It also makes human review faster because you're not reading a mystery novel in git diff form. JOSH: Nice. ERIK: Start using that today in Claude, Codex, Cursor, whatever you're running. Work order first. Diff second. Evidence last. 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.