Mojo 1.0 | Build or Be Replaced

Today: Mojo 1.0 | Compression is prediction | LinkedIn CringeBot 3000 Episode date: 2026-08-12.

Transcript

JOSH: It's Wednesday, August 12. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: Today is about local models, faster code, and the difference between useful automation and automated cringe. JOSH: Stick around — Erik's got an AI pro tip at the end about making agents explain the failure path before they touch code. JOSH: [pause] JOSH: First headline. Mojo 1.0 Beta is getting attention again. Is this just compiler people arguing, or should regular builders care? ERIK: Builders should care. Mojo is trying to give Python people systems-level performance without making them live inside C++ linker errors. That matters for AI, data, and anything where Python is easy but the runtime bill is ugly. JOSH: [beat] JOSH: Second. llama.cpp keeps getting more serious, especially with multimodal support and local server tooling. Is local AI still a toy? ERIK: No. It’s infrastructure now. Not for every job, but for a lot of jobs. Local models are becoming the router, the filter, the first pass, and sometimes the whole worker. JOSH: [beat] JOSH: Third. LinkedIn CringeBot 3000. An AI script that writes painfully self-promotional posts. Are we doomed? ERIK: Only if people confuse posting with building. Automation can make useful work faster, or it can make nonsense louder. That thing is a mirror, and LinkedIn should not stare at it too long. JOSH: [pause] JOSH: Local AI feels like the big one. llama.cpp has been around for a while, but something feels different now. What changed? ERIK: The boring part changed. That’s the good part. JOSH: Boring is good? ERIK: Boring is where things become real. A couple years ago, running a useful local model felt like a weekend project that quietly ate the whole weekend. You had to pick the right model file, figure out quantization, compile with the right backend, hope your GPU path worked, then accept an answer sometime before dinner. JOSH: And now? ERIK: Now it looks like plumbing. You can run a local server. You can use OpenAI-compatible endpoints. You can serve GGUF models. You can run text, and more of the multimodal pieces are showing up. That means a builder can put a model inside a workflow without making the workflow depend on one cloud vendor for every tiny decision. JOSH: But you still use Claude heavily. ERIK: Absolutely. Claude is in my daily build loop. Claude Code is probably the fastest way I’ve found to go from idea to working code. But that doesn’t mean every task deserves Claude. JOSH: Give me an example. ERIK: Log triage. Alert tagging. Ticket routing. Duplicate detection. “Is this config diff scary?” That kind of stuff. A strong frontier model can do it, but that’s like using a crane to move a coffee cup. JOSH: Expensive coffee cup. ERIK: Very expensive coffee cup. In PrimeBus, everything is event-driven. Services emit messages. Agents subscribe. Jobs get picked up. Some messages need a serious reasoning model. Some need a little local model that says, “this is noise,” or “this matches the runbook,” or “send this to a human.” JOSH: So local models become the first layer. ERIK: Exactly. First read. First filter. First critic. Then the hard stuff goes up the chain. That’s the shape I like: local model, remote model, human review when confidence is low or blast radius is high. JOSH: What does that mean for a normal team? ERIK: Start with one boring task. Don’t start with “replace the engineer.” Start with “classify these alerts.” Or “summarize this ticket.” Or “read this config diff and flag risky changes.” JOSH: Why boring? ERIK: Because boring tasks have patterns. Patterns are where automation wins. Nobody needs a model to be creative when the job is, “Is this BGP neighbor down, is this disk full, or is this app yelling because someone shipped bad code?” JOSH: That sounds very NOC. ERIK: It is very NOC. Network teams have been drowning in alerts forever. The answer was never “send more alerts.” The answer is better runbooks, better routing, and more machines doing the first pass before a human gets dragged into Slack at 2:13 AM. JOSH: Where does privacy fit in? ERIK: That’s one of the biggest reasons local AI matters. If you’re summarizing public docs, fine, send it wherever your policy allows. But if you’re reading internal tickets, router configs, customer names, logs, secrets, or screenshots of internal tools, you need control. JOSH: Local keeps the data close. ERIK: Right. Echo and Neo are my lab, but the principle applies anywhere. Put the model near the data when the data matters. Keep the cheap decisions close. Push only the hard decisions out when you need the bigger brain. JOSH: Is quality the tradeoff? ERIK: Sometimes. But people overstate it. Not every problem needs the smartest model alive. If the task is binary, repetitive, or narrow, smaller models are fine. You test them like any other component. JOSH: What does testing look like there? ERIK: Build an eval set. Real examples. Good alerts, bad alerts, weird alerts. Then run the local model and measure whether it routes correctly. If it misses edge cases, you don’t vibe your way through it. You add examples, adjust the prompt, change the model, or send those cases to Claude. JOSH: Vibe your way through it is going on a T-shirt. ERIK: It should go on a warning label. JOSH: [beat] ERIK: The mistake is treating an AI call like magic. It’s a function with weird behavior. Wrap it. Log it. Version it. Test it. Put it behind a queue. Give it timeouts. Give it fallback behavior. JOSH: That sounds less fun than demos. ERIK: Demos are cheap. Systems are not. PrimeSentinel exists because jobs get stuck. Not maybe. They get stuck. Selenium sessions hang. APIs return nonsense. Cron runs at the worst possible time. Your agent needs to handle Tuesday, not just the happy path from the README. JOSH: And llama.cpp helps because it can sit inside that system. ERIK: Yes. Local inference means I can make more decisions without hitting an external API. It also means I can keep workflows alive if the cloud model is rate-limited or expensive that day. It’s not about replacing Claude. It’s about not making Claude do janitor work. JOSH: [pause] JOSH: Let’s talk Mojo. The headline is speed, but people have heard fast Python promises before. Why does this one matter? ERIK: Because Mojo is coming at the Python problem from the systems side. Python won because it’s readable, huge, and practical. It also gets painful when you’re pushing heavy compute. Mojo wants Python-like syntax with compiled performance, stronger typing, memory control, and GPU work in the same neighborhood. JOSH: That sounds ambitious. ERIK: It is. And ambitious languages usually die in the swamp between “cool demo” and “real package management.” That’s why the 1.0 Beta matters. Not because everyone should rewrite code tomorrow. They shouldn’t. But because language stability is the line where serious builders start paying attention. JOSH: What would you actually use it for? ERIK: Tight loops. Data processing. AI preprocessing. Places where Python is the control plane, but you need native speed in the hot path. Networking has the same split. You might use Python to orchestrate NSO calls, Terraform runs, or inventory checks. But the heavy part should not always be Python doing Python things slowly. JOSH: So not a full replacement. ERIK: No. Replacement talk is usually lazy. The better question is where it fits. If Mojo can let Python-heavy teams write fast modules without switching mental models completely, that’s useful. JOSH: What’s the risk? ERIK: The ecosystem. Always. Python’s moat is packages. NumPy, Pandas, FastAPI, Jupyter, every weird library someone wrote in 2016 and forgot but production still needs. If Mojo can interop cleanly and grow a real package story, it has a shot. If it becomes “rewrite your whole world,” it’s dead on arrival. JOSH: Wait, really? Even with the performance? ERIK: Performance alone doesn’t win. Developers pick the thing that gets the job done by Friday. If the fast thing makes Friday impossible, it loses. JOSH: That’s painfully true. ERIK: I see this in automation constantly. A perfect platform that takes six months to adopt loses to a boring script that fixes the outage today. That doesn’t mean the script is the final answer. It means momentum matters. JOSH: How does this connect to AI builders? ERIK: AI systems are full of glue code. File parsing. Data shaping. Chunking. Embedding prep. Ranking. Evaluation. Model routing. Most of that starts in Python because Python is where the libraries are. If Mojo can speed up parts of that without making the team leave Python-land completely, that’s real. JOSH: Would you put it in PrimeBus? ERIK: For the right worker, yes. Not the whole bus. PrimeBus is an architecture choice: NATS, event messages, agents, telemetry, guardrails. Mojo would be a tool inside that. If one worker is chewing CPU on parsing or scoring, that’s where a compiled path makes sense. JOSH: So the lesson is pick the bottleneck first. ERIK: Always. Don’t rewrite because Hacker News got excited. Measure. Find the slow path. Replace the part that hurts. Keep the rest boring. JOSH: That’s less dramatic. ERIK: Dramatic is how you end up maintaining three runtimes and a deployment process nobody understands. Ask me how every enterprise got its “temporary” Perl script from 2009. JOSH: I’m afraid to ask. ERIK: You should be. JOSH: [pause] JOSH: Third deep dive. LinkedIn CringeBot 3000. It’s funny, but it also feels like a warning. What bothered you about it? ERIK: The code isn’t the scary part. The scary part is that people will use it and think they’re building a presence. JOSH: Isn’t that what a lot of AI posting tools promise? ERIK: Yep. And most of them produce the same padded corporate voice. “I’m excited to announce.” “This taught me three lessons.” “The future belongs to builders.” It’s oatmeal with a headshot. JOSH: That’s harsh. ERIK: Fair. But accurate. JOSH: Where’s the line? You automate content too. ERIK: The line is whether the automation is attached to real work. ScanBrief exists because I want useful signals every morning. It pulls from sources, scores items, dedupes, and gives me things worth paying attention to. That’s useful. PrimeDistro exists because outreach has a repeatable mechanical path: find businesses, audit sites, generate previews, send postcards. That’s business automation. JOSH: And CringeBot? ERIK: CringeBot is content laundering. It takes no substance and packages it as insight. That’s not building. That’s fog machine output. JOSH: But people are under pressure to post. ERIK: Sure. I get it. But posting should be a receipt. It should prove you did something. “I shipped this.” “This broke.” “Here’s what fixed it.” “This number changed.” That’s worth reading. JOSH: What should builders automate instead? ERIK: Automate the evidence. Capture deploys. Capture test failures. Capture screenshots. Capture user feedback. Capture diffs. Then use AI to turn those receipts into a short post if you want. JOSH: So the system writes from facts. ERIK: Exactly. Give the model raw material. Don’t ask it to invent a personality. If PrimeSentinel catches a stuck job, that’s a real event. If PrimeBus routes a failed test to an agent and the patch gets reviewed, that’s a real event. If PrimeDistro sends a postcard campaign, that’s a real event. JOSH: And if there’s no event? ERIK: Then don’t post. Radical concept, I know. JOSH: That may violate LinkedIn terms of service. ERIK: Probably emotionally, yes. JOSH: [beat] JOSH: What’s the practical version for someone listening? ERIK: Build a changelog pipeline. That’s it. Every time you ship, write one small record: what changed, why, what tool touched it, what broke, what you learned. Put it in SQLite, Postgres, Notion, whatever. Then when you want a post, pull from the log. JOSH: That sounds simple. ERIK: It is simple. That’s why it works. The hard part is telling the truth. AI is very good at making weak input sound confident. Don’t let it. JOSH: How do you keep it from going full LinkedIn? ERIK: Constraints. Ban phrases. Force specifics. Require at least one tool name, one outcome, or one real artifact. Keep it under a tight word count. Make it sound like a text to another builder, not a keynote. JOSH: That tracks with your style. ERIK: Yeah. “Duuude, I built this thing and here’s what happened” beats fake thought leadership every time. Builders can smell fake. Operators can smell fake faster. JOSH: Is this where AI makes the internet worse? ERIK: In places, yes. Low-friction generation means more low-quality noise. But the answer is not “don’t use AI.” The answer is attach AI to real systems. Make it observe. Make it verify. Make it cite the thing it’s talking about inside your own workflow. JOSH: So AI is better as a witness than an actor? ERIK: Nice. Yes. Witness first. Actor second. If it can’t tell you what happened, why would you let it change anything? JOSH: That tees up the pro tip. ERIK: It does. 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: Before an agent edits code, make it write the failure path in plain English. One paragraph. What failed, where it failed, what evidence proves it, and what file it plans to touch. JOSH: Why before the code? ERIK: Because bad agents jump from symptom to patch. That’s how you get random changes that pass one test and break the actual behavior. Make the agent prove it understands the failure first. JOSH: What does the prompt look like? ERIK: Use this: “Before changing files, describe the failure path from input to broken output. Name the command, the failing assertion, the suspected function, and the smallest patch surface. If you cannot prove it, ask for more evidence.” JOSH: That’s very specific. ERIK: Specific is the whole point. Then after it writes the plan, run the failing test again. Only then let it patch. This one habit cuts a lot of nonsense because the model has to reason before it types. JOSH: And if it guesses? ERIK: Stop it. Get logs. Read the code. Same as a human engineer, just faster and more confident when wrong. ERIK: That's your tip. Use it. JOSH: [pause] ERIK: If you're building toward financial independence through automation, my first book walks through the whole path. Free chapter at erikandersonbook.com. JOSH: [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. JOSH: [pause] ERIK: Build or be replaced. JOSH: If you want these signals in your inbox every morning, scanbrief.dev. See you tomorrow.