Transcript
JOSH: It's Wednesday, October 21. This is Build or Be Replaced, powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.
ERIK: Today's theme: the tools you trust are the ones that bite you.
JOSH: Stick around. Erik's got an AI pro tip at the end about the one setting you should stop cranking up.
[pause]
JOSH: Erik, ScanBrief ran this morning. What did it find?
ERIK: 107 items scored across 56 sources. Average relevance 51.9. A quiet-ish day, but the top of the list had a theme. Benchmarks, certificates, patches, leaked chats. Trust, basically.
JOSH: Headlines first. Google open-sourced TorchTPU. Why should anyone care?
ERIK: It's a native PyTorch back end for TPUs. Most of the ecosystem writes PyTorch and then fights to run it anywhere that isn't an Nvidia card. Fewer translation layers means more hardware choice, and choice is what pushes prices down. I'd watch it. I wouldn't rebuild anything around it yet.
JOSH: Next. Feds suspect a ransom negotiator ran the ShinyHunters extortion site.
ERIK: Allegedly. If it holds up, the person hired to help the victim was sitting on both sides of the table. Every security vendor has an incentive problem. This one just has a headline.
JOSH: And Ofcom conceded defeat in the 4chan case.
ERIK: A regulator tried to enforce rules on a site that doesn't care where the regulator lives. Jurisdiction is not a firewall rule. You can't just push it to the edge and call it done.
[pause]
JOSH: Okay, deep dives. The one that jumped out at me: SlopCodeBench, October edition. "xhigh considered harmful."
ERIK: Yeah. The title tells you most of it. Opus 5.5 is in the mix, a model called Astra wins overall, and the headline finding is that cranking reasoning effort to the top setting can make results worse.
JOSH: Wait, really? More thinking, worse code?
ERIK: I haven't audited their methodology, so take the exact numbers with a grain of salt. But it matches what I see running a fleet. More effort doesn't mean better output. It means more tokens, more time, and more room for the model to talk itself into something clever and wrong.
[beat]
JOSH: What does that look like in practice?
ERIK: A model overthinks a simple fix. You asked it to change one line, it refactors the module. That's slop. Technically it works, and it makes the diff impossible to review.
JOSH: And you run a lot of these reviews.
ERIK: PrimeBus auto-merger has run 2,295 attempts since June fifth. 1,507 merged. 788 blocked by Gandalf. Zero escalated to Erik.
JOSH: That 788 sounds like a lot of failures.
ERIK: It's the opposite. Those are the guardrails working. Gandalf is the reviewer, and it's a different model than the one that wrote the fix. When a patch is bloated or touches things it shouldn't, Gandalf says no and it never reaches prod.
[beat]
ERIK: And that's why I route by task. PrimeRouter picks the model and effort for the job. Small fix, small model, low effort. Architecture question, bigger model. I don't run everything at maximum. It costs more and the results aren't better.
JOSH: So the takeaway is don't trust the biggest setting by default.
ERIK: Don't trust any setting by default. Measure it on your own work. Public benchmarks tell you about their tasks. Your repo is not their tasks.
[pause]
JOSH: Second one. Upcoming critical PHP security release. Two CVEs, remote code execution and privilege escalation.
ERIK: And a certificate story right beside it. eMudhra intermediate CA compromise. Put those together and you've got the two ways the web breaks. Code you run, and trust you inherit.
JOSH: Start with PHP. Who's actually exposed?
ERIK: Anybody on a shared stack, an old CMS, a plugin nobody has touched in three years. PHP runs a huge slice of the web. When a critical release is announced ahead of time, the clock starts for attackers too. They diff the patch the day it lands and write the exploit before most people have read the advisory.
JOSH: So what do you do before it drops?
ERIK: Inventory. Know what runs PHP and what version. Most teams can't answer that in under an hour. I can answer it in about a minute because 139 services are running on the production server right now, and every one of them reports in through PrimeBus. If something's on an old runtime, it shows up.
[beat]
ERIK: Same thing with my client sites through Prime Automation Solutions. When a patch lands, the question isn't "can we fix it." It's "do we know where it is." Visibility first, patching second.
JOSH: And the certificate one?
ERIK: An intermediate CA compromise means someone may be able to issue certificates that browsers trust. The padlock tells you the cert chains up to something trusted. It doesn't tell you the thing at the top stayed clean.
JOSH: Can regular builders do anything about that?
ERIK: Some. Certificate transparency monitoring. Alerts when a cert gets issued for your domain that you didn't ask for. Pin where you can, on your own internal traffic. And run short-lived certs so a bad one dies quickly.
[beat]
ERIK: Coming from network automation, this is old news. I spent years on routers where one bad trust relationship took down a region. You don't fix that with a better padlock. You fix it by assuming the chain will break and watching for it.
[pause]
JOSH: Third one. Muse exposes users' personal and business secrets when they share conversations.
ERIK: Again, I'm going off the headline here, so I won't pretend I know the mechanism. But the shape is clear. Somebody hits share on a chat and it exposes more than they meant to. Pasted API keys, client names, internal numbers.
JOSH: People paste everything into these tools.
ERIK: They do. And the share button feels like sending a screenshot. It isn't. It's publishing a document with a URL, and that URL can be indexed or forwarded or leaked.
JOSH: So what's the lesson? Stop sharing chats?
ERIK: Stop pasting secrets into chats in the first place. Everything in my stack reads credentials from environment files. Nothing goes in a prompt. Keys never show up in a conversation, so there's nothing to leak when a conversation gets shared.
[beat]
ERIK: Take email-reactor, the thing that handles client website change requests over email. It sees client messages all day. It never sees my keys. It sees the request, makes the change, and anything sensitive is stripped before it goes anywhere. Design it so the leak has nothing to leak.
JOSH: That's a pretty low bar.
ERIK: It's the lowest bar there is, and most people still don't clear it. Customer data in prompts, secrets in prompts, internal hostnames in prompts. The tool vendor didn't cause that. You did.
[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: Set effort by task, not by habit. Pick one cheap job you run every day, say summarizing logs or drafting a commit message. Run it at low effort and at high effort on ten real examples. Compare the outputs side by side. If you can't tell them apart, you've been paying for thinking you don't need.
ERIK: Then write it down as a rule. Low effort for mechanical work, high effort for design decisions and anything ambiguous. And put a second model on review. A reviewer that isn't the author catches what the author's confidence hides. That's your tip. Use it.
[pause]
JOSH: Erik, if you're building toward financial independence through automation, I know your first book walks through the whole path.
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.