Build or Replaced
Today: Building and shipping Mac and iOS apps without opening Xcode | Japan develops a method to recover up to 90% of lithium from used EV batteries | The git history command Episode date: 2026-07-14.
Download MP3 →JOSH: It's Tuesday, July 14. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: ScanBrief scored 86 items across 54 sources this morning, and the signal is pretty clear: builders are removing the last excuses from the toolchain. JOSH: Stick around — Erik's got an AI pro tip at the end about putting hard stop conditions on agentic workflows. [pause] JOSH: First headline. Developers are building and shipping Mac and iOS apps without opening Xcode. Is that actually new, or just nerds avoiding a GUI? [beat] ERIK: Both. Xcode has had command-line tools forever, but the story is the workflow maturity. If you can build, sign, test, and ship from a terminal, you can put it on a bus, wire it into CI, and stop babysitting the big shiny app. JOSH: Next one. Japan has a battery recycling method that can recover up to 90 percent of lithium from used EV batteries. ERIK: That matters because supply chains are software now. Batteries, data centers, GPUs, power contracts. If lithium recovery jumps from under 50 percent to up to 90 percent, that's not a chemistry footnote. That's infrastructure capacity coming back into the loop. JOSH: Third headline. Git is getting an experimental history command with fixup, reword, and split. ERIK: Finally. This is Git admitting that normal humans spend too much time cleaning up commits. I like jj, but getting those ideas into Git means teams can improve their flow without asking everyone to switch religion. [pause] JOSH: Let's start with the Xcode one. Why do builders care about shipping Apple apps from the command line? [beat] ERIK: Because the GUI is where automation goes to die. [beat] ERIK: That sounds dramatic, but it's true. If a build needs someone clicking around a project navigator, picking a signing profile, exporting an archive, checking a box, then it's not a pipeline. It's a ritual. JOSH: Apple's tools are famous for that. ERIK: Famous is a nice word for it. Xcode is powerful, but it also has this gravity well around it. People treat the IDE as the source of truth. Then the build works on one laptop, fails in CI, and everybody starts asking who touched the provisioning profile. JOSH: Painfully specific. ERIK: Yeah, because it's always the provisioning profile. Or the certificate. Or the scheme. Or some setting that only exists because one person clicked something three months ago and now we have archaeology. JOSH: So the command-line workflow fixes that? ERIK: It makes the work declarative. That's the important part. You can script xcodebuild. You can pin the command-line tools. You can run tests the same way every time. You can produce an archive, sign it, ship it, and leave a trail. Once it's in a shell command, it can go into GitHub Actions, Buildkite, Jenkins, whatever you're using. JOSH: And then AI agents can touch it? ERIK: Exactly. Agents are terrible at guessing what a person clicked in a GUI. They're good at reading logs, changing files, running tests, and comparing output. If your build is command-driven, Claude can make a fix, run the build, inspect the failure, try a second approach, and send the result through guardrails. JOSH: That's basically your PrimeBus pattern. ERIK: That's the pattern. PrimeBus doesn't care if the thing is Python, TypeScript, Terraform, or an Apple build. It cares about events. Build failed. Test failed. Lint failed. Review requested. Merge candidate ready. Gandalf checks it. If it's good, it moves. If it's sketchy, it gets blocked. JOSH: The live stat today was wild. Two thousand two hundred ninety-five auto-merger attempts since June 5. ERIK: Yep. One thousand five hundred seven merged, seven hundred eighty-eight blocked by Gandalf, zero escalated to me. That's the whole story. The blocked count is not failure. That's the guardrail doing its job. JOSH: Zero escalated is the part that jumps out. ERIK: That's what I care about. I don't want heroic engineering. I want systems that quietly don't bother me unless they have a real reason. I run 119 services on the production server right now. I can't treat every build like a special little snowflake. JOSH: So if someone is building an iOS app today, what's the takeaway? ERIK: Get the build out of the IDE. Keep Xcode for editing if you like it. Fine. But the source of truth should be a command that works on a fresh machine. Create a clean script. Run it locally. Run it in CI. Store the signing assumptions somewhere explicit. Then your future self, or your agent, has something to operate. JOSH: That feels less glamorous than AI writing the app. ERIK: Good. Glamour is how you end up with a demo. Boring repeatable commands are how you ship. [pause] JOSH: Second deep dive. Git history. Why are fixup, reword, and split inside Git a big deal? [beat] ERIK: Because commit hygiene is one of those things everyone claims to value and then avoids because the tooling feels like surgery with kitchen utensils. JOSH: That's accurate. ERIK: You make a change. Tests fail. You fix it. You add a little logging. Then you notice a typo. Now your branch has seven commits named stuff like "fix", "really fix", and "please work". Before merging, someone says, "Can you clean that up?" JOSH: And then comes interactive rebase. ERIK: Exactly. Interactive rebase is powerful, but it's not friendly. You have to know the mental model. Pick, squash, fixup, reword, edit. Then you hope you don't mangle the branch while Slack is blinking at you. JOSH: So git history is trying to make that safer? ERIK: That's how I read it. Experimental, yes. But the direction is right. Fixup a commit. Reword a commit. Split a commit. These are common operations. They shouldn't require a ceremony. JOSH: How does that compare to jj? ERIK: jj is great because it treats history editing like a first-class workflow. It understands that development is messy. You don't write perfect commits in order. You explore, you correct, you reshape. Git can do all of that, but it often feels like Git is judging you while you do it. JOSH: Wait, really? Git has tone now? ERIK: Git absolutely has tone. Detached HEAD is not a friendly phrase. JOSH: Fair. ERIK: The hard part is adoption. I can tell a team to switch to jj, and maybe the tool is better. But now I have to migrate habits, docs, CI assumptions, muscle memory, onboarding. That's expensive. If Git itself absorbs the best workflow ideas, you get 70 percent of the benefit with 10 percent of the organizational drama. JOSH: Where does AI fit into that? ERIK: Agents need clean history too. People think agentic coding is just "Claude, write me a thing." That's the toy version. Real agentic coding is lifecycle work. It opens an issue, changes code, runs tests, explains the delta, prepares a merge, and leaves evidence. JOSH: Evidence meaning commit history? ERIK: Commit history, test logs, review notes, telemetry, all of it. If an agent changes five unrelated things in one commit, your review system gets weaker. If it can split the refactor from the behavior change, reword the commit into something useful, and attach test output, now it's acting like a decent engineer. JOSH: That's not flashy, but it matters. ERIK: It matters more than the model benchmark of the day. PrimeRouter can route to different models, and that's useful. But the model is only part of the machine. The boring wrappers decide whether the output becomes a real shipped change or just a chat transcript with confidence. JOSH: Give me the practical version. ERIK: If you're using AI in a repo, make the agent work in small commits. One behavior change per commit. Tests in the commit message or the PR body. If it touches infrastructure, include the Terraform plan or dry-run output. If it touches networking, include the NSO dry-run or service diff. Don't accept "looks good" from a model. Make it prove the path. JOSH: That sounds like how you review humans too. ERIK: Same standard. The agent doesn't get a discount because it talks nicely. [pause] JOSH: Third topic. Forward deployed engineers are suddenly in demand again. Why now? [beat] ERIK: Because companies bought a lot of software that doesn't quite solve the problem. JOSH: That's a clean diagnosis. ERIK: Look, SaaS got very good at selling platforms. Dashboards, integrations, workflows, admin panels. But real businesses have weird edges. Old databases. Half-documented processes. A spreadsheet named final-final-v7. A VP who needs the report in exactly the wrong format. JOSH: So the forward deployed engineer shows up and glues reality together? ERIK: Pretty much. They sit with the customer, understand the mess, and build the missing parts. Not just configuration. Actual engineering. Scripts, APIs, data transforms, automations, weird little adapters that make the product useful in the real world. JOSH: Why does AI make that role more valuable? ERIK: Because AI increases the amount of possible custom work. Before, if a customer needed twenty custom workflows, that was a services nightmare. Now a strong engineer with Claude, good templates, and a controlled deployment path can build a lot faster. JOSH: So not less engineering. Different engineering. ERIK: Exactly. The value moves from typing code to understanding the system. What should exist. What shouldn't. Where the data lives. What happens when it fails. Who gets paged. Which step needs a human. Which step should never ask a human again. JOSH: That sounds like your consulting pitch. ERIK: It is. Prime Automation Solutions is built on that. If you're still doing it manually, we automate it. But the real work is not "write a script." The real work is watching how the team operates and turning the repeatable parts into a machine. JOSH: How does that show up in your own systems? ERIK: ScanBrief is a good example. It doesn't just scrape headlines. It pulls sources, scores relevance, dedupes, ranks, summarizes, and turns that into a morning signal. Today it scored 86 items across 54 sources. That's not a giant number for bragging. That's enough volume to make manual reading dumb. JOSH: And PrimeBus is the nervous system? ERIK: Yep. PrimeBus lets the rest of the fleet talk. One hundred thirty-seven distinct projects have emitted telemetry to it. That's how you stop guessing. Systems should tell you what they're doing. Then agents can subscribe to events and act. JOSH: Where do forward deployed engineers go wrong? ERIK: They become human middleware. That's the trap. Customer has a problem, engineer fixes it manually, customer loves them, company celebrates. Six months later, that engineer is the product. Every weird customer flow lives in their head. JOSH: That's bad. ERIK: It's fragile. A good forward deployed engineer leaves behind machinery. Runbooks. Tests. Dashboards. A bus event. A fallback path. A repo. Something the next person can operate without calling them during dinner. JOSH: So the job is part engineer, part product, part operations? ERIK: Yes, and that's why it's hard to hire. You need someone who can talk to a customer without making it weird, read logs without panicking, write code that won't embarrass the team, and know when not to automate. JOSH: When should they not automate? ERIK: When the process is still undefined. If five people do it five different ways and nobody can say which one is correct, automation will just freeze the confusion into software. First define the decision. Then automate it. JOSH: That's annoyingly reasonable. ERIK: Sorry. [beat] ERIK: But that's the line. AI doesn't remove judgment. It punishes the lack of it faster. [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? [beat] ERIK: Give every agentic workflow a hard stop condition before you let it touch anything important. JOSH: What does that look like in practice? ERIK: Write the rule in plain language and in code. Example: "Try two fix variants. Run the test suite after each. If both fail, stop and open a ticket. Do not keep editing." That's it. Agents get weird when you let them chase failure forever. JOSH: So it's not just better prompting. ERIK: Prompting matters, but boundaries matter more. Tell Claude what success means. Tell it what evidence to collect. Tell it when to quit. Then enforce that outside the model. Timeout, max attempts, file scope, test command, review gate. The model can suggest. The system decides. JOSH: What's the mistake people make? ERIK: They ask the model to be responsible for its own permission system. Bad idea. The agent should not be the judge, jury, and deploy button. Put Gandalf in front of the merge. Put Terraform plan review before apply. Put NSO dry-run before network change. Boring gates save weekends. JOSH: Builder version? ERIK: Pick one workflow today. A failing test, a broken scrape, a daily report, whatever. Add max attempts, required evidence, and a stop path. If it can't prove success, it stops cleanly and tells you why. 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.