507 Mechanical Movements | Build or Be Replaced

Today: 507 Mechanical Movements | Suica, Japan's First IC Transit Card | Gemini-3.5-Transcribe Episode date: 2026-08-28.

Download MP3 →

Transcript

JOSH: It's Friday, August 28. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: Small models are getting useful, DNS caches are getting cheaper, and giant projects are still where budgets go to die. JOSH: Stick around — Erik's got an AI pro tip at the end about making agents prove their work before they touch prod. JOSH: Headlines first. Gemini-3.5-Transcribe hit the feed today. Is transcription still interesting, or are we past that? ERIK: Still interesting. Voice is becoming an input layer for work. Not cute demos. Real work. Calls into tickets. Meetings into commits. Audio notes into runbooks. If the transcript stays a blob of text, nobody cares. If it becomes structured action, now we have something. JOSH: Next one. Stripe reportedly walked away from a 50 billion dollar PayPal pursuit. What does that tell you? ERIK: Payments is infrastructure with lawyers attached. A deal that big isn't just revenue. It's fraud systems, compliance, merchant risk, identity, uptime, migration, culture, and ten thousand tiny edge cases. Walking away can be the smartest engineering decision in the room. JOSH: And Sovereign Tech Agency is putting 500 thousand euros into Flatpak. ERIK: Good. Desktop plumbing matters. Sandboxing, signing, package distribution, update paths. Nobody claps for that until the update system breaks and your fleet is held together by a bash script called final-final-two. JOSH: Main story one. Cloudflare says it saved about 100 terabytes of memory by changing its DNS cache. That number sounds made up. ERIK: It sounds made up because 100 terabytes of RAM is absurd at human scale. But Cloudflare isn't human scale. They were talking about a DNS cache with 250 billion records. At that size, shaving bytes off one record turns into a warehouse problem. JOSH: What actually changed? ERIK: They reworked the cache design in Big Pineapple, their DNS platform. The memory cost per cache entry dropped by more than half. That freed roughly 100 terabytes of RAM across the fleet. Same work also pushed insert throughput up 43 percent and cut lookup latency 19 percent. JOSH: That's more than a cost story. ERIK: Exactly. Cheaper is nice. Faster inserts and faster lookups mean the system has more room to breathe. DNS is one of those things people ignore until it gets slow. Then suddenly every app is broken and everyone becomes a DNS expert for six terrible hours. JOSH: What does a normal team take from that? ERIK: Stop treating memory like a junk drawer. Most teams don't have 250 billion DNS records. Fine. But they do have queues full of giant JSON payloads, event buses carrying logs they shouldn't carry, and databases storing the same field in six shapes because nobody wanted to make a contract. JOSH: That's very specific. ERIK: Because it happens constantly. Automation systems grow sideways. At first the event says, this test failed. Then someone adds the full traceback. Then the whole diff. Then screenshots. Then the entire config snapshot. Six months later NATS is moving furniture instead of messages. JOSH: How do you handle that in PrimeBus? ERIK: PrimeBus events are pointers and decisions. They carry enough to route, audit, and reproduce. Project name, event type, severity, commit SHA when it matters, result pointer, and metadata the agent needs. The heavy stuff lives somewhere else. Logs belong in log storage. Diffs belong in git. Artifacts belong in artifact storage. JOSH: So the bus tells the worker where to go. ERIK: Right. The bus should not carry your couch. It should say, couch is in storage unit B, here is the claim ticket. That sounds boring until you realize it keeps the whole automation pipeline from getting fat and slow. JOSH: Does this apply outside AI systems? ERIK: Absolutely. Network automation, too. In Cisco NSO, you don't want every workflow passing a full device inventory through every step if all you need is device name, service ID, and intended operation. Pass the contract. Fetch detail when you need it. Less memory. Less serialization. Fewer weird bugs. JOSH: Is this one of those things people only fix after pain? ERIK: Usually. Nobody wakes up excited to reduce object size. But that's where real engineering lives. Not in the flashy dashboard. In the payload nobody sees. Cloudflare saving 100 terabytes is the giant version. A small team might save a few gigs and stop a worker from dying every Thursday. Still worth it. JOSH: Second story. Small AI models are getting fast and cheap. The feed called out models like gpt-5.6-luna and GLM 5.3 running around 100 tokens per second. Why does that matter? ERIK: Because AI gets expensive when you put it inside every workflow. One chat window is cheap. Every email, ticket, alert, pull request, log event, test failure, and customer request is not cheap. That's where model routing matters. JOSH: Small model for small job? ERIK: Better frame is narrow model for narrow job. Don't ask a small model to redesign your billing system from three vague sentences. Ask it to classify this alert, extract the circuit ID, identify the runbook, summarize the log, or draft the first patch. Then escalate when the risk goes up. JOSH: People hear small model and think worse. ERIK: Wrong. Worse at what? If I need a torque wrench, I don't complain that it isn't a bulldozer. Hermes runs qwen3-coder locally on my Mac M3 around 70 tokens per second. That's plenty for code reading, small patches, test interpretation, and boring glue work. The cloud model doesn't need to read every log line like it's writing a dissertation. JOSH: Where does that show up in your actual workflow? ERIK: email-reactor is a clean example. Client sends a website change request by email. The system can parse the request, map it to the site, identify likely files, draft the change, and put it into review. That first pass does not need the biggest model in the building. It needs to be fast, cheap, and consistent. JOSH: Then when do you use the bigger model? ERIK: When judgment matters. Ambiguous requirement. Security-sensitive change. Data migration. Anything touching auth, billing, customer data, or production infra. Bigger model gets the hard call. Small model handles the sorting room. JOSH: That sounds like network engineering again. ERIK: It is. Same pattern as NOC triage. Not every alarm needs the principal engineer. Interface flap? Check runbook. BGP neighbor down on a core edge? Different path. Customer outage tied to a maintenance window? Different again. AI agents should follow severity and confidence, not vibes. JOSH: Wait, really? Vibes aren't an architecture? ERIK: Painful news, I know. But no. You need routing. Confidence thresholds. Human approval points. Audit logs. Replay. If the agent can't tell you why it made the choice, it doesn't get the keys. JOSH: How do you keep that from becoming too much process? ERIK: Automate the process. That's the point. Humans shouldn't fill out ceremony. Systems should collect evidence while work happens. PrimeBus receives the event, agents inspect it, tests run, review happens, and the result is recorded. The human sees the decision packet, not a pile of screenshots and a prayer. JOSH: What's the business angle? ERIK: Cost control. If every task goes to the biggest model, your AI budget becomes a mystery subscription with teeth. Use local or cheaper models for extraction, classification, summarization, and first-pass edits. Use the expensive model where being wrong costs more than the tokens. JOSH: Third story. Stripe and PayPal. Why spend time on a deal that didn't happen? ERIK: Because the non-deal is the lesson. Builders love imagining the combined platform. Stripe plus PayPal sounds huge. But integrating two payment giants is not gluing two APIs together. It's risk engines, settlement flows, chargebacks, merchant onboarding, compliance, identity, support, data migrations, and uptime promises. JOSH: So the headline number isn't the hard part. ERIK: The 50 billion dollar number gets attention. The real monster is integration tax. Every old system has business logic hiding inside it. Some of it is documented. Some of it lives in one service nobody wants to restart. Some of it lives in a person named Dave who knows why refunds from 2019 still use a special path. JOSH: There's always a Dave. ERIK: There is always a Dave. And if Dave retires during the migration, congratulations, you bought archaeology. JOSH: How should smaller companies think about that? ERIK: Before you buy, merge, rewrite, or replace anything, map the workflows. Not the org chart. The actual flows. Money moves here. Approval happens there. Fraud check calls this service. Email fires from that job. Manual spreadsheet appears on Friday. That last one is usually where the bodies are buried. JOSH: That sounds like consulting work. ERIK: That's Prime Automation Solutions all day. People think they need a new platform. A lot of times they need their runbooks turned into real automation and their manual steps exposed. The ugly spreadsheet isn't embarrassing. It's a signal. It tells you where the system never got finished. JOSH: How does AI change that work? ERIK: AI is great at reading the mess. Give it tickets, logs, emails, runbooks, configs, and change records, and it can find repeated patterns. But don't let it act until you've defined the guardrails. Discovery is low risk. Production change is not. JOSH: That connects back to your pro tip, I think. ERIK: Yep. Agentic workflows aren't magic. They're junior engineers with perfect memory and no common sense unless you design the common sense around them. You need test gates, diff checks, blast radius limits, and human approval where the cost of being wrong is high. JOSH: Is this why you like event buses so much? ERIK: Events make systems observable. If everything important emits an event, you can route, inspect, replay, and audit. PrimeBus is the nervous system. ScanBrief pulls signals from the news side. PrimeRestorer handles backup orchestration. Hermes handles local agent work. Different systems, same principle: make the work visible, then let agents subscribe to it. JOSH: That's the part people skip? ERIK: They skip the boring foundation. Then they wonder why the AI agent did something weird and nobody can reconstruct it. If an agent changed a file, I want the prompt, model, inputs, diff, tests, reviewer result, and final decision. Not because I enjoy paperwork. Because future me deserves evidence. JOSH: Dry, but fair. ERIK: Future me has been through enough. JOSH: Back to Flatpak for a minute. Why should builders care about a 500 thousand euro grant to desktop packaging? ERIK: Because distribution is product. If users can't install, update, rollback, or trust your app, the app isn't done. Flatpak is boring in the best way. It gives Linux desktop apps a cleaner path for sandboxing and distribution. JOSH: This isn't flashy AI news. ERIK: That's why it's useful. Everybody wants to build the model wrapper. Fewer people want to build the update channel, signing process, permission model, and rollback plan. But that plumbing decides whether software survives contact with real users. JOSH: Same lesson again? ERIK: Same lesson. Infrastructure wins quietly. DNS cache shape. Model routing. Package distribution. Payment integration. None of those sound like launch-day fireworks. They decide whether the thing keeps working after the demo. JOSH: Give me the builder takeaway for today. ERIK: Pick one hidden cost in your system and make it visible. Memory per event. Tokens per workflow. Manual approvals per deployment. Failed updates per device. Something. Measure it, then reduce it. That's how you build systems that compound instead of systems that rot. JOSH: That's the episode in one sentence. ERIK: Pretty much. Build the boring parts before the boring parts build your incident report. 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: Alright, what's the AI pro tip today? ERIK: Make your agent produce an evidence packet before it changes anything important. Not a paragraph saying it feels confident. Actual evidence. The files it inspected. The assumptions it made. The command it wants to run. The expected result. The rollback path. Then have a second model or a rule checker review that packet before execution. JOSH: What does that look like in practice? ERIK: Simple version. Tell the agent: before editing prod config, output a plan with affected services, exact commands, validation checks, and rollback commands. If any field is missing, block it. If the validation command can't prove success, block it. If rollback is hand-wavy, block it. JOSH: That's usable today. ERIK: Yep. You can do it with Claude, local models, CI scripts, whatever. The tool doesn't matter as much as the gate. Agents should earn permission one step at a time. That's your tip. Use it. 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. ERIK: Build or be replaced. JOSH: If you want these signals in your inbox every morning, scanbrief.dev. See you tomorrow.