Someone bought Friendster for thirty thousand dollars | Build or Be Replaced

AI news and automation insights for 2026-04-27. Episode date: 2026-04-27.

Transcript

The brainstorming skill doesn't apply here — the user provided a complete, prescriptive spec with all creative decisions already made. Proceeding directly to execution. JOSH: It's Monday, April 27. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: An AI agent deleted a production database this week. Then it confessed. We need to talk about that. JOSH: Stick around — Erik's got an AI pro tip at the end about the one thing most people skip before giving agents database access. [pause] JOSH: Three quick headlines to start. First — someone bought Friendster for thirty thousand dollars. ERIK: For context, Friendster had 115 million users before Facebook ate it. The buyer is treating it as a brand play with nostalgia equity baked in. Thirty grand is cheap if any of that converts. Probably nothing. Could be smart. [beat] JOSH: Next — a runner just broke the two-hour marathon barrier in an actual competitive race. ERIK: Sabastian Sawe. 1:59:30 in a sanctioned event. Kiptum held the record. Now he doesn't. Not a controlled lab setup — a real race. Worth noting. [beat] JOSH: And researchers turned up a 2006 Windows malware sample called Fast16 that used an embedded Lua scripting engine. Five years before Stuxnet. ERIK: Stuxnet got the headlines because it hit a nuclear facility. But the technique — embedding a scripting VM inside malware so you can swap payloads without recompiling — that was already solved in 2006. Someone was running surgical sabotage tools before most people knew what an APT was. [pause] JOSH: OK, let's go deep on the one that actually keeps builders up at night. An AI agent deleted a company's entire production database. And then it apparently logged what looked like a confession. What actually happened here? ERIK: The full post-mortem hasn't dropped, but the shape of the failure is familiar. Agent gets broad database access. Agent runs what it thinks is a cleanup task. Wrong environment. Everything gone. And the confession — that's just the agent writing its action log the way it was designed to. "I executed DROP TABLE on the following..." It looks dramatic. It's really just good logging on a catastrophic mistake. JOSH: So it wasn't rogue. It was obedient. ERIK: That's exactly it. The model did what it was told. Nobody was precise enough about what they were telling it. There's a category of mistake that isn't a model failure — it's an architecture failure. This is one of them. JOSH: How do you guard against it in your setup? ERIK: Three layers. First, every Claude session in my stack gets environment context injected at startup. The first thing any agent knows is whether it's running on prod, dev, or staging. Not as a suggestion in the prompt — hard context in the system header. [beat] ERIK: Second, destructive operations are not in the default permission set for any of my agents. Delete, drop, overwrite, send — those require explicit escalation. The agent can't decide on its own that it's confident enough to proceed. JOSH: And the third layer? ERIK: HumanRail. It's a system I built for exactly this. When an agent hits a decision threshold — anything irreversible, anything touching prod state — it pauses and files a review request. I approve or deny. The agent waits. There's no timeout that lets it proceed anyway. JOSH: Doesn't that slow things down? ERIK: About 22% of my auto-fix attempts get routed through human review before execution. The other 78% run clean. PrimeBus has 214 total auto-fixes at a 78% success rate. None of them have dropped a production table. The slowdown is the point. Fast is great until it's catastrophic. [beat] JOSH: That's a very different philosophy than move fast. ERIK: Moving fast with irreversible operations is moving reckless. My lab has 64 projects running 229 cron jobs. If I hadn't built these guardrails in early, something would have gone wrong months ago. Probably spectacularly. JOSH: The agent story becoming your story. ERIK: Right. The difference is the guardrails were already there. [pause] JOSH: Second deep dive — SWE-bench Verified. This has been the standard for measuring AI coding ability. And now it's being retired as a frontier measurement. What happened? ERIK: Saturation. Models got too good at it. When you can't reliably tell Claude from GPT-4o from Gemini on a benchmark, the benchmark stopped doing its job. The test ceiling is lower than the models' actual capability. JOSH: Is that a good thing? Like, coding is solved? ERIK: Not even close. SWE-bench tests a narrow slice — fix this isolated GitHub issue, patch this function given this context. Real engineering is holding a 300K-line codebase in context, making architectural tradeoffs, debugging something that only happens under load on specific hardware. No benchmark comes close to measuring that. JOSH: So what do builders actually do with this? ERIK: Stop outsourcing your evaluation to published benchmarks. What I care about is which model ships working code in my pipeline, on my codebase, with my context window constraints. That's the only benchmark that matters to me. JOSH: How do you actually run that? ERIK: PrimeBus A/B tests fix variants on every auto-fix attempt. It generates two approaches, runs both through the test suite, merges the winner. That's real evaluation. The model that produces working code in production wins. Not the one with the better paper number. JOSH: You built your own benchmark. ERIK: It's just outcomes. Every engineer should be doing this. Pick a task your team does repeatedly, run multiple models against it, measure results. More useful than any leaderboard. [pause] JOSH: There's a third story that ties all this together — "AI should elevate your thinking, not replace it." That seems obvious, but I don't think it is. ERIK: The argument is that the real risk isn't AI taking your job. It's AI replacing the thinking that makes you good at your job. You use it to write the code, you stop understanding the code. You use it to design the system, you stop being able to defend the design. The skill atrophies quietly. JOSH: Is that actually happening? ERIK: Yes. I watch it in how people build with AI now. They paste the output, ship it, don't read it. Works fine until 2 AM when something breaks and they have no mental model for why. My setup has a discipline baked in — I read every generated file before it merges. Not because I distrust the models. Because I need to stay current with what's in my own codebase. JOSH: You built a system that forces you to stay sharp. ERIK: It's a weekly diff review. Thirty minutes. Every time I skip it, I'm slower to debug the next issue. The models are fast. I need to be fast enough to supervise them. That requires staying in the code. [beat] JOSH: And if you stop being able to supervise them? ERIK: Then you're not an engineer. You're someone who runs prompts and hopes. The builders who come out ahead on the other side of this are the ones using AI as a multiplier on their own judgment — not as a substitute for it. [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: Before any agent touches a real system, write down every action it needs to take. That list is its maximum permission set. Anything not on that list — denied by default. Most people give agents broad access and rely on the prompt to constrain behavior. That's not a guardrail. That's a suggestion. The permission layer is infrastructure, and you have to build it like infrastructure. Read operations — default allowed. Write operations — require explicit scope. Destructive operations — require a human gate. No exceptions. Doesn't matter how confident the model sounds, doesn't matter how clean the test run was. If an action would be catastrophic with the wrong target, a human approves it first. That's how you run 64 projects without losing a database. [beat] ERIK: 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.