Apple patched a bug that let cops pull deleted messages off iPhones | Build or Be Replaced

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

Transcript

JOSH: It's Thursday, April 23. This is Build or Be Replaced powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: AI is getting cheaper, faster, and less careful. That's great right up until it touches prod. JOSH: Stick around — Erik's got an AI pro tip at the end about stopping coding agents from rewriting half your repo. [pause] JOSH: First headline. Apple patched a bug that let cops pull deleted messages off iPhones. Bad bug, or normal bug? ERIK: Bad bug. Deleted is supposed to mean deleted, not hanging around in notification cache for a month like old pizza in the office fridge. [beat] JOSH: Next one. Somebody said, "I am building a cloud." Crazy ambition or timely move? ERIK: Timely. AWS, Azure, and GCP all got powerful, then annoying, then expensive. When builders get annoyed long enough, they start replacing the stack. [beat] JOSH: Third headline. AI coding tools are over-editing. Everybody's seen that. Why does it matter now? ERIK: Because over-editing kills trust. If I ask for a one-line fix and the agent hands me 43 changed files, that's not help, that's paperwork. [pause] JOSH: Start with the cloud one. A founder says he's building a cloud because current cloud platforms are miserable. What's really underneath that? ERIK: Simple. The hyperscalers won on capability, then they drifted into complexity taxes. Every year you get more services, more pricing weirdness, more policy layers, more YAML, more IAM edge cases, more "why is this bill four times higher than last month." Builders can take a lot. They hate feeling trapped. [beat] JOSH: You think this is more than a rant? ERIK: Yeah. Not because building a cloud is easy. It's not. It's brutal. Hardware, networking, orchestration, billing, support, compliance, global edge, storage durability, the whole mess. But the demand is real because people want a cloud that feels like buying a tool, not negotiating with a casino. JOSH: What does that mean for people not building a cloud from scratch? ERIK: It means the market is tired of complexity theater. If you can offer one narrow thing that works cleanly, people will move. That's been true in networking forever. NSO won teams over because it made ugly device automation less ugly. Kubernetes got adopted because once you survive the learning curve, you can standardize a lot. The same thing can happen at the infrastructure layer if somebody strips away ten layers of nonsense. [beat] JOSH: Wait, really? You think teams will leave the big three for "boring but sane"? ERIK: For the right workload, absolutely. Not all at once. Nobody is lifting a Fortune 500 out of AWS next week. But greenfield workloads, internal tools, batch jobs, AI inference, CI runners, dev environments, storage-heavy apps, sure. If the math is cleaner and the docs don't feel like a hostage note, people will try it. JOSH: What's the builder angle here? ERIK: Build smaller than your ego wants. That's the angle. "Cloud" sounds giant. But under it, you're really solving a set of pains. Compute that doesn't surprise people. Object storage without weird retrieval gotchas. Managed Postgres that doesn't fight you. GPU access that doesn't require a blood oath. Pick one. [beat] JOSH: That sounds like how you build your own stuff. ERIK: Exactly. PrimeBus wasn't me trying to build some giant universal platform on day one. It started as a message bus because I got tired of scripts acting like lonely little islands. Now I've got three Claude instances on the mesh, events firing across systems, auto-healing, human fallback, all that. But it started with one pain: things breaking in silence. JOSH: Put numbers on that. ERIK: PrimeBus has handled 214 auto-fixes with a 78% success rate. Three Claude instances on the bus. Two servers in the lab. Sixty-four projects. Two hundred twenty-nine cron jobs. That whole setup works because the pieces are opinionated and simple enough to reason about. If I had built some giant "everything platform" first, it would've collapsed under its own ambition. [beat] JOSH: So when this founder says he's building a cloud, what's your test for whether it's real? ERIK: Three things. One, does it remove an actual pain, not just mock AWS on a blog. Two, can a builder understand the product in five minutes. Three, can the bill be predicted by a human without opening a spreadsheet with seven tabs. JOSH: Low bar, somehow hard to clear. ERIK: That's because a lot of infra companies build for investors first and operators second. Operators want clarity. If the CPU costs X, say X. If outbound bandwidth costs Y, say Y. If a permission breaks a deploy, tell me exactly which one. Don't make me open a sacrificial goat and read CloudTrail. [pause] JOSH: Shift to Apple. They fixed a bug where deleted or disappearing messages could still be extracted. Why should regular people care? ERIK: Because a lot of people think privacy settings are magic words. They're not. They're code paths. If the code path leaves residue in notification storage, then your disappearing message isn't disappearing. It's just hiding badly. [beat] JOSH: For people who don't live in logs and caches, what's the plain English version? ERIK: You get a message. The phone shows a notification preview. That preview data can stick around even after the app thinks the message is gone. If investigators can access the device and the cache is still there, they can recover stuff you assumed was dead. That's the problem. JOSH: That's wild. ERIK: It's also common. Systems leak through side channels all the time. Main database says one thing. Logs say another. Metrics leak timing. Notification services retain copies. Search indexes keep old text. Engineers say "delete," but the architecture says "best effort." JOSH: Does this change how people should use disappearing messages? ERIK: It should change how much confidence they place in them. They're useful. They're better than nothing. But if your mental model is "this message self-destructs like a movie prop," that's fiction. Real systems have caches, retries, backups, and weird corners. [beat] JOSH: What does this mean for teams building apps? ERIK: Treat deletion as a system-wide requirement, not a feature toggle in the UI. Map every place the data touches. Primary store. Secondary store. push notification content. local device caches. logs. analytics events. screenshots. exports. backups. If you don't do that, you're shipping false promises. JOSH: You're saying privacy bugs are architecture bugs. ERIK: Usually, yes. Same with security. People look for one dramatic exploit. A lot of the real damage comes from ordinary leftovers. Old files in S3. Debug logs with tokens. A Redis key with no expiry. Temporary screenshots sitting in a support bucket. Death by "we meant to clean that up later." [beat] JOSH: How do you handle that in your own systems? ERIK: Two ways. First, I don't collect what I don't need. That cuts your blast radius fast. Second, when data has a short shelf life, I treat expiry like a first-class path. HumanRail is a good example. If a model isn't confident and I route work to a human, I need the right context, but not forever. That's a workflow object, not a family heirloom. JOSH: Give me a concrete one. ERIK: ScanBrief pulls 396 items a day from 56 sources. I care about ranking, deduping, summaries, timestamps, source links, and delivery. I do not need random long-term junk hanging around forever just because storage is cheap. Cheap storage creates expensive sloppiness. JOSH: And for consumers? ERIK: Update your phone. That's the boring answer and the correct one. Also stop assuming "deleted" means every copy vanished in every layer. It means the vendor hopefully fixed the obvious path this week. [beat] JOSH: That's not comforting. ERIK: Security rarely is. Comfort is what marketing gives you. Engineering gives you threat models. [pause] JOSH: Last deep dive. Over-editing in AI coding tools. Everybody complains about it. What are you seeing? ERIK: I see agents trying to be heroes. That's the disease. You ask for a failing test fix. The model decides the real issue is your architecture, style guide, file layout, naming scheme, and childhood. Then it rewrites half the repo and expects applause. [beat] JOSH: Why is that happening? ERIK: Training pressure and product pressure. Models get rewarded for looking useful. Big diff looks useful if you don't measure pain correctly. But the operator pain is review time, regression risk, and merge conflict debt. The best fix is usually the smallest one that closes the issue cleanly. JOSH: So a flashy diff is often a bad diff. ERIK: Most of the time, yeah. In production work, restraint matters. When PrimeBus fires an auto-fix path, I don't want the agent expressing itself. I want it acting like a surgeon with a small blade and a good map. JOSH: How do you keep that under control? ERIK: Guardrails. Tight task framing. File scope limits. Diff size expectations. Test gates. And you score the agent on mergeability, not creativity. That's the big one. [beat] JOSH: Break that down. ERIK: If you ask an agent, "Fix the build," that's too wide. It hears permission to renovate. Better prompt is, "Fix the failing test in this file. Do not touch unrelated modules. Keep the patch under 30 lines unless a test proves more is needed. Explain root cause in one sentence." Now it has walls. JOSH: Does that actually work? ERIK: Way better than vague prompts. Not perfect. But better. PrimeBus does this with A/B fix variants. When a test fails, it generates candidate repairs, runs validation, and keeps the winner. Two hundred fourteen auto-fixes so far. Seventy-eight percent success rate. Those numbers do not come from giving the model a blank check. JOSH: That's the thing people miss, right? They want full autonomy with zero guardrails. ERIK: Yep. Then they act shocked when the model trashes a config file, rewrites imports, and updates comments nobody asked about. Agentic coding is not "send it and pray." It's routing, policy, evaluation, and rollback. [beat] JOSH: How does this compare to a human engineer making broad changes? ERIK: Humans over-edit too. Senior engineers can be just as guilty. You ask for a bug fix, they sneak in a framework opinion. Difference is humans understand team context better and can usually explain the trade. Models often can't tell useful cleanup from ego cleanup. JOSH: Ego cleanup is a good phrase. ERIK: Seen a lot of it. "While I was here, I improved everything." No, you increased the surface area of review and made `git blame` look like a crime scene. JOSH: What does good look like then? ERIK: Good looks boring. Small patch. Clear intent. Tests pass. No unrelated churn. If a broader refactor is truly needed, separate it. Different commit. Different review. Different conversation. [beat] JOSH: And for people using tools like Claude or other agents every day? ERIK: Make the model earn trust in layers. Start read-only. Then let it propose patches. Then let it patch in a branch. Then maybe let it auto-merge on very narrow categories after it proves itself. That's how I work in the lab. Small blast radius first. Lesson learned, more guardrails, then wider permission. That's why I don't have big disasters. I don't skip the proving ground. JOSH: You say that a lot. Lab first. ERIK: Because it works. Neo and Morpheus exist for a reason. Two servers. Cheap compared to prod mistakes. I test the workflow, test the rollback, test the bad prompt, test the weird edge case. Then I trust it more. That's engineering. The people getting burned are often trying to jump straight from demo to autonomy. JOSH: So the real story isn't "AI over-edits." It's "people gave it too much room." ERIK: That's a big part of it. The other part is tool design. Editors and coding agents should expose patch previews, intent summaries, file scope controls, and hard stop policies by default. If your tool hides the blast radius, it's helping the wrong user. It should help the reviewer, not just impress the person in the demo clip. [beat] JOSH: Does this get better soon? ERIK: Yeah. Models are improving, but the bigger win will come from better wrappers around them. Better policies. Better evals. Better eventing. Better handoff between agents and humans. Raw model intelligence matters. The workflow around it matters more. JOSH: That's basically your whole playbook. ERIK: Pretty much. PrimeBus for event routing. HumanRail for uncertainty. ScanBrief for signal filtering. InkEngine for production workflow. Same pattern every time. Don't ask the model to be magic. Put it in a system and make the system keep score. [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: Put a hard ceiling on edit scope before the agent writes a single line. Tell it the exact files it can touch, the max diff size, and the acceptance test it has to satisfy. Then make it explain the root cause in one sentence before it generates the patch. [beat] ERIK: That one sentence matters. If the model can't explain the bug cleanly, it probably doesn't understand the bug. And if it doesn't understand the bug, it's about to start redecorating your repo. [beat] ERIK: In Claude, Codex, whatever you're using, prompt like this: "Only edit these files. Keep changes minimal. Do not refactor unrelated code. If you believe broader changes are required, stop and explain why first." That cuts a lot of nonsense immediately. [beat] ERIK: Also split "diagnose" from "patch." First ask for the likely cause and smallest fix. Then ask for the patch. Two steps beats one when you care about precision. 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.