Mistral raises €3B | Build or Be Replaced
Today: Mistral raises €3B | I've factored the RSA keys of a Certificate Authority from the 90s | We have a year to fix security everywhere Episode date: 2026-09-08.
Download MP3 →
Build or Replaced
Today: Mistral raises €3B | I've factored the RSA keys of a Certificate Authority from the 90s | We have a year to fix security everywhere Episode date: 2026-09-08.
Download MP3 →JOSH: It's Tuesday, September 8. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: ScanBrief scored 75 items across 56 sources today, and the signal is pretty clear. AI is getting expensive, security debt is getting louder, and vendors are tightening the exits. JOSH: Stick around — Erik's got an AI pro tip at the end about making agents prove their work before they touch prod. [pause] JOSH: First headline. Mistral raised three billion euros. Europe wants its own AI stack, right? ERIK: Yep. That round values Mistral over 21 billion euros, and the money is going straight into compute, research, and commercial rollout. Europe doesn't want to rent its brain from California forever. JOSH: Second. Somebody factored old Certificate Authority RSA keys from the nineties on a normal desktop. Wait, really? ERIK: Really. An 862-bit root CA key from archived browser installers got factored with modern hardware. That's not a crypto breakthrough. That's old infrastructure debt finally becoming cheap enough to exploit. JOSH: Third. Broadcom pulled VMware VDDK downloads, and leaving VMware just got harder. ERIK: That's vendor gravity. First the pricing changes hit, then the tooling gets harder to access, then migration projects become archaeology. If your exit plan depends on a vendor being polite, you don't have an exit plan. [pause] JOSH: Let's start with Mistral. Three billion euros is a huge number. Is this just another AI funding headline, or does it actually matter? ERIK: It matters because it tells you where the pressure is. AI models are not just software products now. They're infrastructure. They're national infrastructure, commercial infrastructure, security infrastructure. Mistral raising that much money means Europe is saying, we're not going to be passengers on this bus. [beat] ERIK: And look, the open-weight angle matters too. Companies want models they can run closer to their data. Governments want models that aren't tied to one American cloud account and a terms-of-service page that changes on a Tuesday. Banks, telcos, defense, healthcare, all of them are asking the same basic question. Can we control this thing? JOSH: But can they? The compute gap still seems massive. ERIK: That's the hard part. Models are expensive in three places. Training, inference, and talent. Everybody talks about training because the numbers are huge, but inference is where businesses feel the pain every day. Every prompt is a bill. Every agent loop is a bill. Every bad retry policy is a small financial crime. [beat] ERIK: That's why I track this stuff in my own systems. PrimeBus has 140 distinct projects emitting telemetry into it. The reason I care about that number is not vanity. It's cost visibility. When an agent burns tokens, I want to know what event caused it, what repo it touched, what test failed, and whether it produced value. JOSH: So the lesson from Mistral is not just, Europe has money? ERIK: Correct. The lesson is model strategy is now architecture. You need to know when to use Claude, when to use GPT, when to use a smaller local model, and when to use a boring deterministic script. If you send every job to the biggest model, that's not sophistication. That's lighting money on fire with a nicer API. JOSH: How would you apply that in a real team? ERIK: Start by classifying work. Summarization, extraction, routing, code repair, planning, customer-facing generation, security review. Those are not the same workload. ScanBrief can score and rank news with a different model path than PrimeBus uses when Gandalf reviews a proposed code merge. The blast radius is different. [beat] ERIK: A news summary being a little bland is annoying. An auto-merge touching production code is a different animal. That's where you pay for stronger reasoning, more review, and more guardrails. JOSH: You mentioned Gandalf. That's the guardrail system? ERIK: Yeah. PrimeBus auto-merger has run 2295 attempts since 2026-06-05: 1507 merged, 788 blocked by Gandalf, 0 escalated to Erik. That's the part I care about. Zero escalated to me. The system is allowed to move fast because it's also allowed to say no. JOSH: That's wild. The blocked number is doing work there. ERIK: Exactly. People hear blocked and think failure. Wrong. Blocked means the guardrail did its job. A merge rate without a blocked count is marketing. A blocked count tells me the machine has brakes. [pause] JOSH: Let's move to the RSA story. Old Certificate Authority keys from the nineties got factored. Why should a builder care about ancient browser installers? ERIK: Because old systems don't die. They get wrapped, proxied, migrated, containerized, and forgotten. Then one day somebody finds a weak root key in an archive and proves the whole trust chain was thinner than people remembered. [beat] ERIK: The technical detail is simple. RSA keys that were considered strong decades ago are not strong today. Hardware got faster. Algorithms improved. Cloud compute made experiments cheaper. What used to be impossible became a weekend project for somebody stubborn. JOSH: Is this mostly a museum problem, though? ERIK: No. The museum is where they found it. The lesson is live. Enterprises are full of museum pieces with IP addresses. Old Java keystores. Forgotten certs. Appliances with baked-in trust stores. VPN boxes nobody patches because the one person who understood them left in 2017. JOSH: That sounds painfully believable. ERIK: Networking taught me this. Cisco NSO, device templates, service models, cert chains, TACACS, RADIUS, old SNMP communities, all of it. The danger is not one bad thing. The danger is inventory drift. You don't know what's out there, so you can't defend it. [beat] ERIK: That's why automation starts with observation. Not fixing. Observing. Build a job that inventories cert expiration. Then key length. Then issuer. Then where the cert is installed. Then what service owns it. That sounds boring until it saves you from explaining to leadership why a dead appliance trusted a dead CA. JOSH: Where does AI fit in there? Because the easy answer is, ask the model to scan everything. ERIK: Please don't point a model at production and tell it to go find vibes. Use normal tools first. OpenSSL, Nmap, inventory exports, Kubernetes secrets scans, Terraform state, CMDB data if your CMDB isn't fiction. Then use AI to classify, summarize, and build remediation plans. JOSH: So deterministic collection, AI interpretation. ERIK: Yes. That's the pattern. Machines are great at collecting facts. Models are useful when the facts are messy and somebody needs to turn them into a decision tree. For example, email-reactor handles client website change requests because the input is messy. People send screenshots, half sentences, forwarded threads. AI is useful there. [beat] ERIK: But if I need to know whether a certificate uses a 1024-bit key, I don't need poetry. I need a command that returns the truth. JOSH: What's the first move for a small team hearing this story? ERIK: Build a trust inventory this week. Domains, internal hostnames, cert issuer, key size, expiration, owner. Put it somewhere boring like Postgres. Run it daily. Send the diff to Slack or email. Then add one rule. Anything under your minimum key length gets tagged. Anything expiring soon gets tagged. Anything with an unknown owner gets tagged. JOSH: Unknown owner sounds like the real killer. ERIK: It is. Unknown owner means future outage. You can quote me on that. Every mystery certificate is a calendar invite waiting to happen. [pause] JOSH: Third deep dive. VMware. Broadcom pulls VDDK downloads, and the headline says leaving VMware just got harder. What's the practical impact? ERIK: VDDK is the Virtual Disk Development Kit. Backup vendors, migration tools, and automation workflows use it to work with VMware virtual disks. If access gets restricted, anything that depends on that toolchain gets more brittle. [beat] ERIK: This is why platform exits are not philosophical. They're operational. You need the SDKs, the docs, the export paths, the backup compatibility, the licensing clarity, and the staff who know how the current mess actually works. JOSH: Is this a Broadcom problem or a vendor lock-in problem? ERIK: Vendor lock-in problem. Broadcom is just making it visible. Every platform has gravity. VMware had good gravity for a long time because it worked. People built entire data centers around it. Then licensing changes, access changes, and suddenly the same tight integration feels like a trap. JOSH: What does that mean for automation engineers? ERIK: It means your abstraction layer matters. Terraform helps. Ansible helps. Kubernetes helps if the workload belongs there. NSO helps on the network side. But none of those magically remove platform assumptions. You have to write down what depends on VMware-specific behavior. [beat] ERIK: Snapshots. Storage policies. Backup hooks. VLAN mapping. DRS rules. Templates. Golden images. Monitoring checks. Runbooks. The weird PowerCLI script named final-final-new.ps1 sitting on a jump box. That's the migration. JOSH: That's a little too real. ERIK: Seen it too many times. The server is never the hard part. The hard part is everything touching the server that nobody documented because it was obvious eight years ago. JOSH: How would you approach a VMware exit without turning it into a two-year swamp? ERIK: Build a dependency map first. Not a strategy deck. A real map. VM to app. App to owner. App to data. Data to backup. Network to firewall rules. Auth to identity provider. Then classify workloads into three buckets. Move as-is. Replatform. Retire. [beat] ERIK: Retire is the best bucket. Everyone ignores it because it doesn't feel like engineering. It's engineering. Deleting a dead VM is the cleanest migration you will ever do. JOSH: Where does your setup influence how you think about this? ERIK: My production server has 153 services running right now. That sounds like a lot because it is a lot. The only reason it doesn't turn into soup is telemetry and naming discipline. Every service needs to emit signals. Every job needs an owner. Every workflow needs a reason to exist. JOSH: And when it doesn't? ERIK: Then it gets deleted or isolated until it proves value. Same with enterprise platforms. If you can't explain why a workload must stay on VMware, maybe it doesn't need to. If you can't explain how to move it, you found your next automation project. JOSH: Does AI help with that migration map? ERIK: Absolutely, but don't ask it to hallucinate your network. Feed it exports. vCenter inventory. Terraform state. CMDB dumps. Firewall rules. DNS zones. Backup reports. Then ask it to find clusters of dependency and missing owners. [beat] ERIK: Agents are good at reading boring files without complaining. Humans get three CSVs in and start making coffee. Let the agent do the first pass, then make humans approve the migration waves. JOSH: Is there a bigger pattern across all three stories today? ERIK: Yep. Control is back. Control over models. Control over trust. Control over platforms. The last decade trained people to rent everything and call it agility. Fine, but the bill is here now. [beat] ERIK: You don't need to own every layer. That's not realistic. But you do need to know which layers can hurt you, how fast you can replace them, and whether your automation makes you freer or more trapped. JOSH: That's the Build or Be Replaced angle. ERIK: Exactly. Build the map. Build the tests. Build the guardrails. Then let the machines do the boring work. Episode 104, same answer. If you don't build the system, somebody else's system is going to make decisions for you. [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 every agent produce evidence before action. Not a summary. Evidence. If an agent wants to change code, it should show the failing test, the file it plans to touch, the smallest patch, and the command it will run after. [beat] ERIK: Use a simple prompt pattern. Task, constraints, evidence required, allowed tools, stop conditions. Then make the agent write a short execution record. What changed. Why. What passed. What it refused to do. JOSH: So the tip is basically, no silent agents. ERIK: Correct. Silent agents are expensive interns with root access. PrimeBus works because the event tells me what happened, Gandalf checks the proposal, and the merge only happens when the evidence lines up. You can do the same thing with a shell script and a GitHub Action. [beat] ERIK: Start today. Add one rule to your AI workflow. No patch without a test command. No deployment without a diff. No remediation without the alert that triggered it. That's your tip. Use it. [pause] JOSH: We also drop daily market picks and automation tips on YouTube — search Build or Be Replaced. [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.