Mon–Fri · 6 AM ET
← All Episodes
EP  • 00:13:58

GrapheneOS has been ported to Android 17 | Build or Be Replaced

Today: GrapheneOS has been ported to Android 17 | Running local models is good now | Humiliating IIS servers for fun and jail time Episode date: 2026-06-17.

Download MP3 →

Transcript

JOSH: It's Wednesday, June 17. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson.
ERIK: Local models are finally useful, security people are yelling about JWTs again, and PrimeBus processed 750 automation events across 13 projects today while I drank coffee.
JOSH: Stick around — Erik's got an AI pro tip at the end about using local models without turning your laptop into a space heater.
[pause]
JOSH: First headline. GrapheneOS has been ported to Android 17. Privacy phone people are probably happy, but why should builders care?
ERIK: Because mobile security matters again. Android keeps getting more locked down, and GrapheneOS usually pushes the hardening further. If you carry production access in your pocket, that pocket is part of your infrastructure.
JOSH: Second headline. Running local models is good now. The claim is that Gemma 4-class local models are landing around 75 percent of frontier model usefulness for coding tasks. Wait, really?
ERIK: Yeah, and that number feels believable for bounded work. Not for every task. But for lint fixes, test repair, small refactors, log summarization, and local code search, local models are crossing the line from toy to tool.
JOSH: Third headline. Stop using JWTs. That headline comes back every few months like a bad login cookie.
ERIK: It does, and sometimes it's right. JWTs are fine when you understand revocation, audience, expiry, signing keys, and storage. Most teams don't. They use JWTs because a tutorial said stateless auth was clean, then they spend two years rebuilding sessions badly.
[pause]
JOSH: The local model story feels like the biggest one today. For years, local AI was fun, but the real work happened through Claude or GPT APIs. What's changed?
ERIK: The gap got small enough for boring work. That's the change. Nobody needs a local model to write the next Kubernetes controller from scratch while blindfolded. That's not the point. The point is that a model running on your own machine can now do useful maintenance work without sending every file, log, and stack trace across an API.
[beat]
ERIK: That's a big deal for engineering teams. There are whole categories of work where the model doesn't need genius. It needs context, repetition, and permission to act. Read this test failure. Compare it to the last passing run. Suggest the two-line fix. Check the changelog. Draft the PR note. That is where local models are getting good.
JOSH: So it's less about replacing frontier models and more about moving the cheap work closer to the machine?
ERIK: Exactly. Frontier models are still where I go for architecture, gnarly debugging, and agent planning. Claude is still my daily driver. But I don't need Opus-level reasoning for every little thing. If a local model can triage logs, classify events, and prepare a patch candidate, then the expensive model only touches the parts that need judgment.
JOSH: How would that fit into your setup?
ERIK: PrimeBus is the obvious place. It already has agents watching events, failures, warnings, deploy signals, test results, all of it. Today the bus processed 750 automation events across 13 projects. Not all of those need a frontier model. A lot of them need a fast first pass.
[beat]
ERIK: Local model sees an event. It says, this is noisy, ignore it. Or this looks like a dependency issue. Or this belongs to PrimeRestorer because the S3 backup check failed. Then it can enrich the event before it hits Claude. That means fewer tokens, faster routing, and less junk going into the expensive brain.
JOSH: That's the part people miss, right? They compare model to model instead of workflow to workflow.
ERIK: Yep. Builders get stuck asking, is this model better than Claude? Wrong question. Ask what job it can own. If a local model can handle 30 percent of the event stream before Claude sees it, that matters. If it can write a first draft of a fix that Gandalf reviews, that matters. Overnight, 2 code changes were automatically reviewed by Gandalf and merged to production. That's the pattern. Cheap agent proposes. Strong reviewer decides. Guardrails block the dumb stuff.
JOSH: And privacy is part of it too?
ERIK: Huge part. Local models are perfect for sensitive logs. Network configs. Customer names. Internal IPs. Cisco NSO service payloads. Terraform plans. Stuff you don't want copied into random tooling because somebody got excited on a Tuesday.
[beat]
ERIK: In network automation, config context is everything. Interface names, route policies, device groups, service templates. A local model can summarize and classify that locally. Then if you need Claude, you send the smallest useful slice. That's just good engineering.
JOSH: Is there a trap here?
ERIK: Plenty. People will overtrust local models because they feel private. Private doesn't mean correct. A bad answer on your laptop is still a bad answer. Local models need tight jobs, tight prompts, and tests. Especially tests. If your agent writes code and you don't have tests, you didn't build automation. You built a slot machine.
[pause]
JOSH: Let's connect that to the GrapheneOS story. Android 17 support sounds like a phone thing, but you called the phone part of the infrastructure.
ERIK: Because it is. Builders love talking about servers, clusters, pipelines, and agents. Then they approve production changes from a phone with six years of app cruft on it. That's backwards.
JOSH: That's a little uncomfortable.
ERIK: Good. It should be. Your phone has email, Slack, GitHub, cloud console access, password manager, MFA prompts, SSH apps, maybe even your VPN. If that device is weak, your beautiful Kubernetes setup is wearing a paper hat.
[beat]
ERIK: GrapheneOS matters because it treats the phone like a hostile environment. Sandboxed Google Play, hardened memory allocator, stronger app permissions, tighter attack surface. That's the right mindset. Assume everything is trying to touch everything else. Then make it prove it needs access.
JOSH: Does that map to how you build systems?
ERIK: Directly. PrimeBus works because everything is evented and bounded. An agent doesn't get god mode because it has a cute name. Gandalf reviews merges. PrimeRestorer owns backups. PrimeDash watches services. Each piece has a job. Same idea on a phone. Apps shouldn't get the whole kingdom because they asked nicely.
JOSH: The IIS bug bounty story is kind of the opposite side of that. Old servers, weird defaults, hidden stuff.
ERIK: Yeah, and that story is timeless. Misconfigured IIS servers are not exciting because IIS is magical. They're exciting because forgotten systems are where the bodies are buried. Default splash page, odd headers, old TLS, exposed paths, stale admin panels. It's always the boring surface area.
JOSH: So the lesson isn't "go hack IIS."
ERIK: Correct. The lesson is inventory. Know what you expose. Know what headers you leak. Know what default pages are still answering. Know which old service is sitting behind a load balancer because nobody wanted to touch it in 2018.
[beat]
ERIK: This is why I like dashboards that are ugly but honest. PrimeDash tells me what is running in the lab and on prod. Right now there are 116 services running on the production server. That number matters because unknown services are risk. You can't secure a thing you don't admit exists.
JOSH: That's wild. A lot of teams probably couldn't answer that number quickly.
ERIK: Most couldn't. And that's not a people problem. It's a systems problem. If the only inventory is a spreadsheet, it's already dead. Services should announce themselves. Health checks should publish events. Deploys should emit telemetry. Weird ports should get flagged. Certificates should age out loudly.
JOSH: That's the bus again.
ERIK: Always. Get the events onto a bus. NATS, Kafka, Redis streams, whatever fits. I like NATS because it's simple and fast. Once events exist, agents can subscribe. Security agent watches headers. Backup agent watches restore status. Build agent watches tests. HumanRail-style pattern if confidence is low. Route to a person only when the machine shouldn't decide.
[pause]
JOSH: Now the JWT headline. "Stop Using JWTs" is spicy, but people use them everywhere. What's the actual issue?
ERIK: JWTs are not evil. Bad JWT architecture is evil. The problem is that JWTs make people feel like they deleted state. They didn't. They moved state into a signed blob and then pretended logout, revocation, rotation, device trust, and compromised tokens weren't real problems.
JOSH: Give me the practical version.
ERIK: If you issue a JWT that lives for seven days and somebody steals it, they have seven days. Unless you maintain a denylist, rotate secrets, bind it to a device, shorten expiry, or check session state somewhere. And the moment you do those things, congratulations, you have state again. Which is fine. Just be honest about it.
[beat]
JOSH: So sessions aren't outdated?
ERIK: Sessions are boring. Boring is good. A server-side session with a secure cookie is still a great answer for a lot of web apps. You can revoke it. You can inspect it. You can kill all sessions for a user. You can store risk signals. You don't have to ship every claim to the browser and hope nobody made a bad storage choice.
JOSH: Where do JWTs make sense?
ERIK: Service-to-service auth. Short-lived access tokens. OAuth flows where the boundaries are understood. Mobile clients with refresh token rotation done correctly. API gateways where audience and issuer checks are enforced consistently. They make sense when the team knows the failure modes.
JOSH: And where do they not make sense?
ERIK: A weekend SaaS app where someone stores the token in localStorage, sets expiry to 30 days, and calls it secure because the payload is signed. That's not auth architecture. That's vibes with base64.
[beat]
JOSH: How does this show up in automation systems?
ERIK: Agents need identity too. That's where this gets interesting. In the Bobaverse fleet, 11 agents are emitting and reacting across the system. Neo, Homer, Bill, Echo, Gandalf, Claude, GPT. If one of them can trigger a deploy, merge code, or touch backups, identity matters.
JOSH: You don't want one magic token floating around.
ERIK: Exactly. Each agent should have scoped credentials. Short life. Clear audience. Clear permissions. PrimeRestorer can do backup work. It doesn't need to approve code merges. Gandalf can review. It doesn't need S3 delete access. PrimeBus can route messages. It shouldn't be a skeleton key.
JOSH: That's a clean way to think about it.
ERIK: It also makes failure smaller. People obsess over preventing every failure. Fine, try. But also design so a failure doesn't own the whole system. If a token leaks, what can it do? If an agent gets confused, what can it touch? If a model hallucinates, what guardrail says no?
[beat]
ERIK: The auto-merger stat from this morning is the whole story. Since June 5, PrimeBus auto-merger has run 950 attempts: 634 merged, 316 blocked by Gandalf, 0 escalated to Erik. The blocked count is the win. That's the system saying, nope, not good enough, without waking me up.
JOSH: That's probably the most important sentence today.
ERIK: Yep. Builders need to stop measuring automation only by what it does. Measure what it refuses to do. Refusal is a feature. Especially when code, credentials, money, or production are involved.
[pause]
JOSH: Bring these stories together for someone building this week. Local models, hardened phones, old IIS servers, JWT drama. What's the builder's take?
ERIK: Treat everything like part of the system. Your laptop. Your phone. Your agents. Your auth tokens. Your dashboards. Your weird old Windows server nobody wants to admit exists.
[beat]
ERIK: Then add loops. Local models for first-pass work. Frontier models for judgment. Event bus for visibility. Guardrails for refusal. Real inventory for security. Short-lived credentials for agents. Backups that prove restores, not just files copied somewhere.
JOSH: That sounds less flashy than most AI advice.
ERIK: Good. Flashy doesn't keep prod alive. A boring loop that catches a bad merge at 2 AM is worth more than a demo that writes a poem about your backlog.
JOSH: Dry, but fair.
ERIK: Build the boring control plane. That's where the power is. ScanBrief scored 93 items across 54 sources today. I don't read 54 sources manually. The machine filters, scores, and ranks. Then I decide what matters. Same pattern everywhere. Let systems collect and reduce. Let agents propose. Let guardrails block. Let humans handle judgment and taste.
[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: Run a local model as a pre-filter, not as your main engineer. That's the tip.
[beat]
ERIK: Pick one narrow job today. Log triage. Test failure classification. PR title cleanup. Terraform plan summary. Something with clear inputs and clear expected outputs. Run Gemma, Qwen, Llama, whatever fits your machine. Give it examples. Make it return JSON. Then send only the high-confidence cases forward.
JOSH: And low confidence?
ERIK: Escalate. Either to Claude, GPT, or a human. Don't make the local model pretend. Add a confidence field, but don't trust the number blindly. Check it against rules. If the output is malformed, reject it. If it touches a dangerous file, reject it. If tests fail, reject it.
[beat]
ERIK: The move is not "local AI replaces API AI." The move is routing. Cheap model handles cheap decisions. Strong model handles hard reasoning. Guardrails decide what ships. That's your tip. Use it.
[pause]
ERIK: If you're building toward financial independence through automation, my first book walks through the whole path. Free chapter at erikandersonbook.com.
[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.