Build or Replaced
Today: Om Malik has died | An entire Herculaneum scroll has been read for the first time | The 'papers, please' era of the internet will decimate your privacy Episode date: 2026-06-26.
Download MP3 →JOSH: It's Friday, June 26. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: Today's theme is simple. The web wants your ID, burned Roman scrolls are talking again, and tech media lost one of the people who actually understood infrastructure. JOSH: Stick around — Erik's got an AI pro tip at the end about using agents as reviewers, not just writers. JOSH: [pause] JOSH: First up, Om Malik has died at 59. Why did that hit the tech world so hard? ERIK: Om covered broadband, startups, telecom, and networks like they were the real story. Because they were. He wasn't just chasing gadgets. He understood that pipes, protocols, capital, and timing decide who wins. JOSH: Second headline. AI helped read a Herculaneum scroll burned by Vesuvius almost 2,000 years ago. ERIK: That's real AI work. X-ray scans, virtual unwrapping, machine learning, scholars checking the output. Not a chatbot doing ancient Rome fan fiction. JOSH: Third headline. Age verification keeps expanding online. One paper called it compliance theater. ERIK: Yeah, and that's generous. If your safety plan is "upload your face or driver's license to a vendor nobody can evaluate," you've built a privacy incident with a landing page. JOSH: [pause] JOSH: Start with Om Malik. Why does a journalist matter on a show about building? ERIK: Because builders need signal. Om was signal. He wrote about broadband when broadband was still boring to normal people. He saw that connectivity was infrastructure, infrastructure created platforms, and platforms created markets. JOSH: That sounds obvious now. ERIK: Everything sounds obvious after somebody explains it for 20 years. That's the point. Good tech writing is early pattern detection. It tells builders where the pressure is building before the press release arrives. JOSH: What made his work different? ERIK: He treated the network like the story. Not the app floating on top of it. The fiber mattered. The data center mattered. The carrier business model mattered. The boring plumbing was not boring if you cared about what could be built next. JOSH: That's very much your lane. ERIK: Yeah. Network people know this. When the path is broken, the product is broken. Doesn't matter how pretty the UI is. If DNS is wrong, BGP is flapping, NAT is weird, or the queue is backed up, your whole magical app is now a support ticket. JOSH: And now a lot of coverage skips that layer? ERIK: A lot of coverage became product screenshots and executive quotes. That's fine for launch day. It doesn't help you understand power. Who owns distribution? Who controls compute? Who can absorb the cost of inference? Who has the data center contracts? Who gets priority when capacity is tight? JOSH: So the loss is bigger than one writer. ERIK: Right. It's a reminder that the industry needs people who can read the system. Not just the story. Om came from that era where telecom fraud, broadband buildouts, blogs, venture money, and consumer apps were all connected. He could see the whole board. JOSH: How should builders respond to that? ERIK: Build your own signal stack. Don't wait for a feed to tell you what matters. ScanBrief exists because I got tired of reading the same rewritten article 12 times. I want multiple sources, dedupe, scoring, summaries, and a reason something matters. JOSH: That's the builder version of media literacy. ERIK: Exactly. If you're building in AI right now, you need a daily radar. Model releases. API changes. pricing changes. security bugs. lawsuits. policy shifts. chip supply. You don't need more content. You need filtered intelligence. JOSH: And the takeaway from Om? ERIK: Respect the pipes. Respect the people who understand the pipes. The future usually shows up there first. JOSH: [pause] JOSH: The scroll story feels like the opposite of hype. Why did this one land for you? ERIK: Because the model is not the product. The system is the product. That's what people miss. JOSH: Walk me through it. ERIK: You start with a physical artifact that's basically a carbonized mess. You can't open it without destroying it. So researchers use high-resolution X-ray imaging to capture the internal structure. Then software virtually unwraps layers that are warped, crushed, and stuck together. Then machine learning looks for ink signal that humans can't easily see. JOSH: And the ink is carbon too, right? ERIK: Correct. That's why it's hard. Carbon ink on carbonized papyrus doesn't give you a nice clean contrast. You're not finding black ink on white paper. You're finding tiny surface and texture differences inside a burned object that has been sitting around since Mount Vesuvius did what volcanoes do. JOSH: Rude, historically speaking. ERIK: Very inconsiderate to future data pipelines. JOSH: [beat] JOSH: But it worked. ERIK: It worked enough to recover serious text. We're talking over a meter of readable material from one scroll, with scholars now arguing through Stoic and Epicurean philosophy instead of arguing whether the object can be read at all. That's a phase change. JOSH: What makes that different from normal AI output? ERIK: Evidence boundaries. The system is constrained by scan data. It isn't inventing a scroll from vibes. It proposes readings based on physical signal, and humans validate the result. That's the pattern builders should steal. JOSH: Evidence first. Model second. ERIK: Yep. Same thing I do with PrimeBus. Agents don't get to wander around making heroic decisions because they felt inspired. Events come in. Logs attach. Tests run. A fix gets proposed. Review happens. Guardrails decide what can move. JOSH: So the agent is part of the workflow. ERIK: Exactly. Not the boss. People keep trying to make AI the whole employee. Wrong frame. Make it a worker inside a system that has telemetry, permissions, audit trails, and rollback. JOSH: How does that apply outside ancient scrolls? ERIK: Everywhere. Network configs. Medical scans. legal discovery. Old file shares. Security logs. Backup validation. The problem is usually not "write me something." It's "find the signal inside ugly data and show your work." JOSH: That's a harder product. ERIK: Much harder. But useful. A chatbot that writes a confident paragraph is easy. A system that ingests messy artifacts, preserves provenance, detects signal, attaches confidence, routes low-confidence work to a human, and keeps an audit trail? That's where real money is. JOSH: That's less flashy. ERIK: Good systems are usually ugly in the middle. Queues. retries. schemas. worker timeouts. failed jobs. weird encodings. permissions. human review. Nobody puts that in the demo video because it's not sexy. But that's the part that makes it survive Tuesday. JOSH: You mentioned backups earlier. ERIK: PrimeRestorer is exactly that mindset. A backup is a rumor until a restore proves it. Same with AI output. A model answer is a rumor until evidence proves it. Builders need to stop treating generated text like truth. JOSH: That's a pretty sharp rule. ERIK: Use it today. If the model says it fixed a bug, where's the test? If it says a document says something, where's the source line? If it says a config is safe, where's the diff, the policy check, and the rollback plan? JOSH: The scroll team had scholars in the loop. ERIK: And that's why it matters. Human-in-the-loop is not a weakness. It's how you keep the machine useful. I don't want AI replacing experts by guessing louder. I want AI giving experts superpowers with evidence attached. JOSH: That's the sane version. ERIK: Sane, measurable, and shippable. Weirdly, those are still allowed. JOSH: [pause] JOSH: Age verification is the next one. This feels like one of those "good goal, bad architecture" stories. ERIK: That's exactly what it is. Protecting kids online is a real goal. Building a web where identity checks become normal at every door is a dangerous way to get there. JOSH: What's actually happening? ERIK: More jurisdictions are pushing sites to verify age before allowing access to certain content. The implementation often lands on document checks, biometric estimation, device signals, or third-party identity vendors. That means the web starts asking users for sensitive proof just to browse. JOSH: The pitch is safety. ERIK: The pitch is always safety. The architecture is the issue. When you bind access to identity, you create a tracking layer. Even if the site doesn't store the driver's license, somebody touched it. Somebody processed it. Somebody logged metadata. Somebody is now in the trust path. JOSH: And users can't evaluate that. ERIK: Not even close. Normal people can't tell if an age-verification vendor has solid security, sane retention policies, proper isolation, or a business model that won't get creepy later. They see a modal and a button. JOSH: The paper called some of this compliance theater. ERIK: Because passing the checkbox doesn't mean the system is secure. Researchers looked at European adult-site age checks and found weak spots across methods and integrations. That's the part people ignore. A law can demand verification, but the deployed workflow can still be bypassed, mishandle data, or push risk onto users. JOSH: Wait, really? ERIK: Yes. Compliance is not engineering. Compliance can force activity. It doesn't guarantee the activity is good. JOSH: That's bleak. ERIK: It's normal infrastructure reality. I've seen plenty of controls that exist because an auditor wanted a screenshot. The control technically exists. It also doesn't stop anything useful. Congrats, you made paperwork with latency. JOSH: How should builders think about age checks then? ERIK: Data minimization first. Collect the least possible data. Store as little as possible. Prefer proofs over raw identity. If all you need to know is "over threshold," don't collect name, address, face, and document number. JOSH: What are better patterns? ERIK: Privacy-preserving tokens. Device-side or wallet-side attestations. Parent-controlled systems. Blind verification where the site gets a yes or no, not a dossier. Short retention. Independent audits. Clear deletion. Boring stuff that actually matters. JOSH: And if you're a small builder? ERIK: Don't bolt on the cheapest vendor and call it done. Map the data path. What does the user submit? Where does it go? Who stores it? How long? What gets logged? What happens during support? What happens if the vendor gets breached? JOSH: That's a lot for a small team. ERIK: Yeah. Security work is work. Very annoying. JOSH: [beat] ERIK: But it's cheaper than explaining to users why their identity documents are in a breach because your product wanted to avoid hard design decisions. JOSH: How does this connect to automation? ERIK: Same principle. Every automation needs a blast-radius model. Every agent needs permissions. Every vendor needs a failure plan. PrimeRouter exists because I don't want model calls sprayed everywhere with no routing, no priority, and no visibility. Identity data deserves even more discipline. JOSH: So the big warning is centralization? ERIK: Centralization plus normalization. Once users accept "show papers to access content," that pattern spreads. Today it's adult content. Tomorrow it's social media. Then forums. Then app stores. Then payment access. That's how bad defaults become infrastructure. JOSH: What's the builder line in the sand? ERIK: Don't collect sensitive data unless the product genuinely cannot work without it. And if you must collect it, treat it like radioactive material. Small container. Clear label. Short half-life. JOSH: Dry, but fair. ERIK: I do networking. Dry is part of the warranty. JOSH: [pause] JOSH: Pull these together for me. Om Malik, burned scrolls, age verification. What's the common thread? ERIK: Systems thinking. Om saw systems. The scroll team built a system around fragile evidence. Age verification is what happens when policy demands a system and weak architecture fills the gap. JOSH: That's the episode. ERIK: Pretty much. Builders need to stop staring only at the visible layer. The UI is not the system. The model is not the system. The law is not the system. The system is the path data takes, the rules it hits, the humans who review it, and the failure modes you planned for before production makes you humble. JOSH: Where does AI fit in that? ERIK: AI is a worker. A very fast, very weird worker. Give it bounded tasks. Give it evidence. Give it tests. Give it a bus to publish events on. Give it humans when confidence drops. Don't give it root and a dream. JOSH: That's going on a sticker. ERIK: Make it small. Engineers don't read big stickers. JOSH: [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 JOSH: [pause] JOSH: Alright, what's the AI pro tip today? ERIK: Use agents as reviewers before you use them as writers. Take any change you make today. Code, config, email, runbook, proposal, whatever. Ask one agent to find correctness issues. Ask another to find operational risk. Ask a third to find missing tests or missing evidence. JOSH: Not write it first? ERIK: Review first. Writing agents are impressive. Reviewing agents make you faster without letting the machine steer the car. Give each reviewer a narrow role and a hard output format. Findings only. File path or section. Severity. Evidence. Suggested fix. JOSH: Why separate reviewers? ERIK: Because one broad prompt gives you soup. Separate roles catch different failure modes. A security reviewer shouldn't care if the paragraph sounds nice. An ops reviewer should care about rollback. A test reviewer should care about proof. JOSH: What's the exact prompt? ERIK: Try this. "Review this change as a production engineer. Return only concrete risks, missing tests, and assumptions. If you can't point to evidence, say no finding." That's it. Run that before you ship. JOSH: Simple enough. ERIK: That's your tip. Use it. JOSH: [pause] JOSH: Binge all five episodes this weekend plus our YouTube shorts — links at buildorbereplaced.dev. 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. JOSH: [pause] ERIK: Build or be replaced. JOSH: If you want these signals in your inbox every morning, scanbrief.dev. See you tomorrow.