Build or Replaced
Today: Virginia bans sale of geolocation data | Right to Local Intelligence | CarPlay Is Additive Episode date: 2026-07-06.
Download MP3 →JOSH: It's Monday, July 6. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: Privacy, local AI, and broken assumptions. That's the theme today. ScanBrief scored 205 items across 54 sources, and the signal is pretty clear: control is moving back to the edge. JOSH: Stick around — Erik's got an AI pro tip at the end about making agents write tests before they touch your code. [pause] JOSH: First headline. Virginia just banned the sale of geolocation data. Is this a privacy win or just paperwork? ERIK: It's a real win, but the wording matters. They define sale as money changing hands between a controller and a third party, so the data broker market takes the hit first. That's good. It doesn't solve every location-data trick, but it's a hard line in a place where we needed one. [beat] JOSH: Next. Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory. How bad is that? ERIK: Bad enough that I wouldn't hand-wave it. Suspend is one of those places where people assume the security model still exists while the machine is half-asleep. That's exactly where weird bugs matter. [beat] JOSH: Third headline. AMD's MI355X is showing a much better inference price-to-performance ratio than NVIDIA Blackwell, but NVIDIA still has the software lead. What's your read? ERIK: Hardware is getting cheaper. Deployment pain is not. If your kernels, drivers, libraries, and model serving stack aren't boring, the cheaper chip can still cost you more in engineer hours. Ask anyone who has tried to make GPUs behave at 2 AM. [pause] JOSH: Let's start with Virginia. A state banning geolocation sales sounds narrow, but it feels like part of a bigger privacy shift. ERIK: It is. Location data is one of the creepiest datasets because people underestimate what it reveals. It's not just where you are. It's where you sleep, where you work, what doctor you visit, what church you attend, who you spend time with. You don't need a name if the pattern is clean enough. [beat] JOSH: So when they say sale, and they mean money changing hands, is that enough? ERIK: It's enough to hurt one business model. That's the first step. Data brokers love the gray zone. They don't always need to say, "we sold Josh's location." They package audiences, segments, visits, movement patterns. The law narrows in on the cash transaction, which means companies now have to look at those deals and ask, "are we actually selling movement data?" [beat] JOSH: And the answer is probably yes more often than they want to admit. ERIK: Yeah. A lot of companies have been pretending telemetry is exhaust. Like, "Oh, this is just operational data." No. If your app collects location every few minutes and hands that to a third party, that's not exhaust. That's a product. [pause] JOSH: How does that connect to the local intelligence idea that was also trending today? ERIK: Same root problem. Centralized systems are convenient, but every centralized system becomes a collection point. The Right to Local Intelligence idea is basically saying: if the work can happen on my device, then don't ship my raw data to your cloud. [beat] JOSH: Is that realistic today? ERIK: More realistic than it was two years ago. Local models are good enough for a lot of tasks now. Not every task. I'm not saying run frontier reasoning on a toaster. But classification, summarization, routing, personal search, document tagging, basic agent actions. A lot of that can live close to the user. [beat] JOSH: But companies love cloud processing. ERIK: Of course they do. Cloud processing gives them control, telemetry, retention, billing hooks, and a nice little moat. Local processing gives the user control. That's the tension. [pause] JOSH: Where do you land on it as a builder? ERIK: Default local when the data is sensitive. Default cloud when the job requires heavy compute or shared state. Don't turn every button click into a confession booth. [beat] JOSH: That's a line. ERIK: It's true. If I'm building an automation system and the input contains credentials, configs, customer names, router data, internal tickets, I don't casually throw that into random APIs. I route it through known paths. I log what needs to be logged. I redact what doesn't belong. [beat] JOSH: Is that how you're handling your own systems? ERIK: Yeah. PrimeBus is a good example. Today it processed 31 automation events across 7 projects. Those events aren't just vibes. They're structured messages. Source, type, confidence, action, status. When something needs an AI pass, the system knows what context to send and what to keep out. [beat] JOSH: So privacy isn't a policy page. It's architecture. ERIK: Exactly. If privacy only exists in your legal copy, you already lost. Build the path so the dumb thing is hard to do. That's why event buses, redaction layers, and human approval gates matter. Boring stuff. Very useful. [pause] JOSH: The LUKS story feels different, but maybe it's also about assumptions. ERIK: Totally. Disk encryption is one of those things people treat like a checkbox. "Laptop encrypted? Good." But the actual safety depends on the whole lifecycle. Boot, unlock, suspend, resume, hibernate, memory handling, DMA exposure, firmware behavior. It's not one checkbox. [beat] JOSH: The headline says since Linux 6.9, suspend stopped wiping disk-encryption keys from memory. What does that mean in plain English? ERIK: When a system suspends, encryption keys can remain in RAM. Historically, certain paths tried to wipe or protect those keys during suspend. If that behavior regressed, then an attacker with physical access and the right technique may have a better shot at pulling secrets from memory. [beat] JOSH: Wait, really? ERIK: Yeah. Physical access changes the game. People hear "encrypted disk" and think the data is safe no matter what. But if the machine is unlocked or recently suspended, secrets may still be alive somewhere. Encryption protects data at rest. Suspend is not fully at rest. It's more like the machine is taking a nap with its wallet out. [beat] JOSH: Dry but accurate. ERIK: That's security. [pause] JOSH: What should normal builders take from that? Most people aren't patching kernel encryption behavior. ERIK: First, know what state your machine is in. If you carry sensitive data, prefer shutdown or hibernate with a setup you actually understand. Suspend is convenient, not magic. [beat] ERIK: Second, patch fast when this class of issue lands. Kernel regressions are not theoretical if you run laptops, edge nodes, lab servers, or field gear. [beat] ERIK: Third, build checks around assumptions. PrimeSentinel exists for that reason in my world. It watches for stuck jobs and weird service states because "it should be running" is not a monitoring strategy. Same idea here. "It should wipe keys" is not proof. [beat] JOSH: That sounds like the unsexy work nobody wants to do. ERIK: Correct. Which is why it pays. Everybody wants the cool AI agent. Fewer people want the watchdog, the rollback path, the audit event, the boring test that fails when memory handling changes. But that's where the real engineering is. [pause] JOSH: How does this map to network automation? That's your home turf. ERIK: Network automation is full of hidden assumptions. "This device supports that command." "This NSO service always renders clean." "This rollback will restore state." "This inventory field is accurate." Any one of those can be false. [beat] ERIK: The answer is not to trust harder. It's to verify more cheaply. Pre-checks, post-checks, diff reviews, dry runs, canaries, and guardrails. PrimeBus auto-merger has run 2,295 attempts since June 5: 1,507 merged, 788 blocked by Gandalf, 0 escalated to me. That blocked number is the point. The guardrails are doing work while I'm not staring at it. [beat] JOSH: So blocked isn't failure. ERIK: No. Blocked is the system saying, "Nice try, buddy." That's exactly what I want. If an agent proposes a fix and Gandalf says no, that is not drama. That's the process working. [pause] JOSH: The GPU story is the builder money story today. AMD is cheaper on inference, NVIDIA still wins on software. What's the practical takeaway? ERIK: Buy the whole system, not the spec sheet. Price-to-performance is useful, but it's not the invoice. The invoice includes engineer time, driver weirdness, library support, model compatibility, observability, deployment patterns, and how long it takes before your first useful token comes out. [beat] JOSH: That's the part people skip when they see a benchmark. ERIK: Benchmarks are marketing with numbers unless you can reproduce them in your stack. If AMD gives you better raw economics, great. But if your team already has CUDA tooling, NVIDIA images, TensorRT paths, monitoring, and people who know the failure modes, switching has a cost. [beat] JOSH: So don't chase cheap hardware blindly. ERIK: Exactly. But don't ignore it either. The gap is narrowing. That's the real story. NVIDIA still has the smoother software path in a lot of shops, but AMD getting closer means buyers have options. Options put pressure on pricing. Builders win when hardware stops being a religion. [pause] JOSH: How does local LLM work fit into that? There was also a guide trending about running state-of-the-art models locally. ERIK: Local LLMs are becoming normal engineering tools. Not toys. You can run useful models on a workstation or a lab box and keep sensitive prompts off the internet. That's huge for code review, log triage, document search, config analysis, and internal chat over private docs. [beat] JOSH: But you still use Claude. ERIK: Absolutely. Claude is excellent. I use the best tool for the job. For hard reasoning, writing, coding, agent sessions, Claude gets a lot of my workload. For local classification or private data passes, a local model can be the better fit. This isn't team cloud versus team local. It's routing. [beat] JOSH: Routing by task. ERIK: Yep. You don't send every packet down the same path in a network. Same with AI calls. Small local model for cheap private work. Strong hosted model for high-reasoning work. HumanRail-style approval when confidence is low. Event bus in the middle so the decision is visible. [beat] JOSH: That's very network engineer of you. ERIK: Yeah, guilty. But it works. AI systems look less mysterious when you treat them like distributed systems. Queues, retries, rate limits, dead letters, permissions, state, audit logs. Same old problems with a model in the middle. [pause] JOSH: Leanstral 1.5 also showed up today. A small model doing formal verification and finding bugs. Does that matter outside research circles? ERIK: Yes. Formal verification has always had this wall around it. Very powerful, very picky, very hard for normal teams to use. If small models can help write proofs, repair proof attempts, or find real bugs in open-source repos, that starts to bring formal methods closer to daily engineering. [beat] JOSH: In normal English, that's proving code does what it says? ERIK: Pretty much. Tests show examples. Formal proofs try to show properties. No buffer overflow here. This state can't happen. This function preserves that invariant. That kind of thing. [beat] JOSH: Sounds expensive. ERIK: It has been. That's why small models matter. A 6B model you can run more cheaply changes the shape of the workflow. You don't ask every developer to become a proof engineer. You ask the agent to propose checks around the riskiest code and let a human review the result. [pause] JOSH: Would you put that into your own pipeline? ERIK: In pieces, yes. I wouldn't wake up tomorrow and demand formal proofs for every repo. That's how people build a shrine and stop shipping. But for critical paths, absolutely. [beat] ERIK: PrimeBus already treats code changes as events. A failing test emits telemetry. Agents propose variants. Gandalf blocks bad merges. The next layer is stronger reasoning around invariants. Not just "does the test pass?" but "did this change violate the contract?" [beat] JOSH: That feels like where agentic coding is heading. ERIK: It has to. Right now a lot of AI coding is "generate code, hope tests catch it." That's fine for small tools. It's not enough for infrastructure. If an agent is touching Terraform, Kubernetes manifests, NSO service packages, or billing code, it needs a tighter box. [beat] JOSH: What does the tighter box look like? ERIK: Typed inputs. Narrow permissions. Tests generated before fixes. Static checks. Runtime checks. Review agents with different incentives. A merge gate that is allowed to say no. And logs that tell you why. [beat] JOSH: That sounds less magical. ERIK: Good. Magic is a terrible operating model. I want boring systems that make spooky things safe enough to use. [pause] JOSH: You said earlier that the privacy story, the LUKS story, and the GPU story all point to control moving back to the edge. Tie that together. ERIK: Here's the thread. Virginia says you can't casually sell where people go. Local intelligence says don't ship private data away if the device can process it. The LUKS issue reminds us local machines still need real security. GPU economics says local and private compute is getting more practical. [beat] ERIK: Put those together and the builder move is obvious: design for control. Control where data lives. Control which model sees it. Control what an agent can change. Control what gets merged. Control what gets logged. [beat] JOSH: And when people don't? ERIK: Then they discover their architecture during an incident. That's the expensive way. [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: Make your coding agent write the failing test before it writes the fix. Not after. Before. [beat] JOSH: Why before? ERIK: Because it forces the model to state the bug in executable form. The prompt is simple: "Read the issue, inspect the code, and add the smallest failing test that proves the bug. Do not change production code yet." Then you run the test. Confirm it fails for the right reason. Only then ask for the fix. [beat] ERIK: This cuts down on fake fixes. It also gives your review agent something concrete to judge. PrimeBus works better when the event has evidence attached. A stack trace is good. A failing test is better. [beat] JOSH: And if the model can't write the test? ERIK: That's signal. Maybe the bug report is vague. Maybe the code has no test harness. Maybe the model doesn't understand the system. Either way, don't let it start editing prod logic because it sounds confident. Confidence is cheap. A failing test is useful. [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.