Build or Replaced
Today: OpenAI Agents API | Shopify is moving from React Native back to Swift and Kotlin | Don't let anyone take away your big box of cables Episode date: 2026-09-11.
Download MP3 →JOSH: It's Friday, September 11. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: Agents are done being cute demos. They're moving into repos, terminals, tickets, and change windows. JOSH: Stick around — Erik's got an AI pro tip at the end about giving agents a clean contract before they touch your code. JOSH: First headline. OpenAI's Agents API is getting attention for a managed Codex harness. What jumped out? ERIK: State. That's the story. Sandboxed agents that can execute code, edit files, call tools, recover sessions, and compact context means the plumbing is becoming a product. JOSH: So this isn't just another chat API? ERIK: No. Chat is advice. Agents with files and tools are labor. Different beast. JOSH: Second headline. Shopify is moving away from React Native and back toward Swift and Kotlin. ERIK: That one's big because it's not about AI replacing engineers. It's about AI changing the cost math of native engineering. JOSH: AI made native code cheaper? ERIK: Exactly. If Claude or Codex can help maintain two clean native codebases, the abstraction tax starts looking ugly. JOSH: Third headline. Forgejo had a critical RCE under version 16.0.3. ERIK: Self-hosted git is sacred ground. If your code forge gets popped, that's not an app incident. That's a supply chain incident wearing a hoodie. JOSH: Patch it today? ERIK: Patch it before coffee. Then check tokens, webhooks, runners, deploy keys, and anything that ever touched that box. JOSH: Let's start with the Agents API. You already run your own agent systems. What's different when OpenAI packages the harness? ERIK: The harness is where most teams get stuck. Everybody can make a model answer a question. That's not the hard part. The hard part is giving it a workspace, a permission model, logs, retries, file edits, tool calls, error recovery, and a way to remember what it was doing when context gets heavy. JOSH: So the model is only one piece. ERIK: Yeah. The model is the engine. The harness is the vehicle, the seatbelt, the dashboard, the brakes, and the insurance paperwork after it hits a mailbox. JOSH: That's a very specific incident. ERIK: Infrastructure people don't trust anything without logs. For good reason. JOSH: What does a managed harness actually change for a builder? ERIK: It removes a pile of boring work. Session lifecycle. Sandboxes. Tool routing. File access. Context recovery. Those things are annoying to build well. If OpenAI gives you a managed way to run Codex-style agents against a task, you can focus on policy and product instead of reinventing the plumbing. JOSH: Is that good or scary? ERIK: Both. Good because teams can build real agentic workflows faster. Scary because somebody will give an agent broad write access to a repo on day one and call it innovation. JOSH: That's the part people worry about. ERIK: They should. An agent with tools is not a chatbot. It's a junior operator with infinite confidence, no sleep schedule, and access to your weirdest legacy files. You don't solve that with vibes. You solve it with small jobs, clear permissions, tests, audit trails, and rollback. JOSH: How do you do that in your own systems? ERIK: PrimeBus is event-driven. A thing happens, it publishes to NATS, and workers subscribe. An agent doesn't wake up and wander around looking for purpose. It gets a bounded task. Inspect this failure. Read these logs. Propose a patch. Run these tests. Report exactly what changed. JOSH: That's the opposite of a big autonomous blob. ERIK: Correct. Big autonomous blob is how you get a very expensive mystery. Tiny permissions are boring, and boring works. JOSH: Where does human review fit? ERIK: Depends on risk. Some fixes can be reviewed by another agent and held behind gates. Some need a human. Some should never be touched automatically. Terraform, secrets, billing paths, auth logic, anything that changes access. Those get treated differently. JOSH: That sounds like network change control. ERIK: It is. That's why network automation matters here. If you've spent years with Cisco NSO, maintenance windows, pre-checks, post-checks, rollback plans, and angry outage bridges, you already understand agent safety. Same shape. Different tool. JOSH: So the AI world is rediscovering change control. ERIK: With better logos. JOSH: What should people copy from your setup if they're starting small? ERIK: Start with one event. One repo. One failure mode. Don't build a full agent platform first. Take something stupid and repetitive, like a failing test caused by a formatting issue or a dependency pin. Let the agent inspect it, propose a patch, run the exact command you would run, and stop before merge. JOSH: Stop before merge at first. ERIK: Yep. Earn trust in stages. First it writes suggestions. Then it opens PRs. Then it handles low-risk changes behind strong tests. Then maybe it merges a tiny class of work. You don't hand it the keys because the demo looked cool. JOSH: Where would you use OpenAI's managed version instead of your own PrimeBus pattern? ERIK: If I'm building a product where users need agent sessions, I want the managed API. Let OpenAI handle disposable workspaces and session state. If I'm operating my own infrastructure, I still want my internal bus, my logs, my rules, and my kill switches. JOSH: Because your rules are weird? ERIK: Weird on purpose. My Echo and Neo lab has a lot of moving parts. PrimeRouter, ScanBrief, PrimeRestorer, the whole stack. I don't want a generic agent making broad decisions in that environment. I want constrained jobs and a clear paper trail. JOSH: What's the real takeaway from this headline? ERIK: Agent infrastructure is becoming normal software infrastructure. That means the winners won't be the people with the fanciest prompt. It'll be the people who wrap agents in boring, reliable systems. JOSH: Next up, Shopify. This one feels like a clean business case for AI changing engineering decisions. ERIK: It is. Cross-platform frameworks exist because writing two apps is expensive. React Native says, write a lot once, share logic, ship iOS and Android. That made sense when human time was the bottleneck. JOSH: And AI changes that bottleneck? ERIK: It can. If Claude or Codex can help write Swift and Kotlin, keep tests updated, explain platform APIs, and migrate patterns faster, then native work gets cheaper. Once native gets cheaper, the cost of carrying a cross-platform abstraction becomes easier to question. JOSH: What's the abstraction tax? ERIK: Debugging through three layers when the bug is really native. Waiting on bridge behavior. Fighting package upgrades. Performance weirdness. Hiring people who understand React, iOS, Android, and the framework quirks. None of that is free. JOSH: But React Native still helps smaller teams, right? ERIK: Absolutely. This isn't some blanket funeral. If you're two people building a simple app, shared code can still be the right call. The point is that AI moves the break-even point. Big teams with serious mobile needs may look at native again and say, why are we paying this complexity tax? JOSH: That's a useful way to frame it. ERIK: Same thing applies outside mobile. People chose tools for labor economics. Once AI changes labor economics, some old architecture decisions need a second look. JOSH: Give me an infra version. ERIK: Terraform modules. Ansible roles. NSO services. Internal wrappers around APIs. A lot of these were built because humans needed fewer patterns to remember. That's valid. But if an agent can safely generate the boring glue and test it, maybe you don't need the giant abstraction that only two people understand. JOSH: Wait, really? You'd remove abstractions? ERIK: Bad ones, yes. Good abstractions earn their keep. Bad abstractions are just haunted basements with YAML. JOSH: How do you tell the difference? ERIK: Ask three questions. Does it reduce real operational risk? Does it make changes easier to review? Does it fail in a way people understand? If not, it might just be hiding complexity. JOSH: How does that connect to your own projects? ERIK: PrimeRouter is a good example. I don't want every app calling every model provider directly. That's chaos. So PrimeRouter owns routing, provider failover, tracing, and policy. That abstraction earns its keep because it reduces repeated risk. JOSH: And a bad version? ERIK: A bad version would hide which provider answered, hide cost, hide latency, and make debugging worse. Then you're not building a gateway. You're building a fog machine. JOSH: For builders listening, what should they do with the Shopify lesson? ERIK: Revisit old decisions where the answer was, we don't have enough people. That answer may have changed. Not always. But maybe. Native mobile, test coverage, migrations, documentation, internal tools, runbook automation. If AI drops the labor cost, the right design may be simpler than the old one. JOSH: That sounds like work, though. ERIK: It is. AI doesn't remove engineering judgment. It punishes the lack of it. JOSH: Third deep dive. Forgejo and the critical RCE. Why does self-hosted git hit different? ERIK: Because source control is the center of the blast radius. Repos, CI tokens, deploy keys, webhooks, package publishing, secrets by accident, runner access. If the forge is compromised, the attacker may not need your app vulnerability. They can become the software factory. JOSH: That's worse than a normal app bug. ERIK: Much worse. A normal app bug might expose data or break a workflow. A compromised code forge can poison builds, alter releases, add backdoors, steal credentials, and modify infrastructure code. That's supply chain territory. JOSH: What should people do beyond patching? ERIK: Patch first. Then rotate credentials that touched the system. Review admin users. Review personal access tokens. Check webhook targets. Check CI runners. Check recent commits and tags. Check deploy keys. Look for new users, new SSH keys, new actions, strange pipeline changes. JOSH: That's a long afternoon. ERIK: Better than a long month. JOSH: How do you make that less painful? ERIK: Inventory. If you don't know which tokens exist, which runners can deploy, and which repos can touch production, you're guessing during an incident. Guessing is not a plan. JOSH: Is this where PrimeRestorer comes in? ERIK: Yep. PrimeRestorer exists because backups are not a feeling. Databases, system state, offsite object storage, restore paths. The point isn't backup theater. The point is knowing what you can rebuild when something gets ugly. JOSH: People always say they have backups. ERIK: People have files. Sometimes they have backups. A backup you haven't restored is a superstition. JOSH: That's going on a sticker. ERIK: Make the font small. It hurts more that way. JOSH: What about runners? You mentioned those twice. ERIK: CI runners are dangerous because they often sit near secrets and deployment paths. If your forge is compromised and your runners trust it blindly, you've handed the attacker a conveyor belt into your environment. JOSH: So patching the app isn't enough. ERIK: Right. You have to think in graph terms. Forgejo connects to repos. Repos connect to CI. CI connects to registries, clouds, servers, and artifact stores. One bug can move across that graph if permissions are sloppy. JOSH: What's the sane setup? ERIK: Least privilege. Short-lived credentials. Separate runners by trust level. No production secrets on random branch builds. Require approvals for protected paths. Log everything. Make deploy keys narrow. And keep the forge boringly current. JOSH: Boring keeps coming up today. ERIK: Because boring survives. Exciting security architecture usually means nobody knows how it works. JOSH: How does ScanBrief fit into this kind of day? ERIK: ScanBrief is my early-warning radar. It pulls tech signals, scores them, and gets the important stuff in front of me. I don't need to read the whole internet. I need to know which issues hit systems I actually run. JOSH: So it's not just news. It's operational input. ERIK: Exactly. A headline is trivia until it maps to an asset. Forgejo RCE? That maps to self-hosted git. Agents API? That maps to my automation architecture. Shopify's native move? That maps to build strategy. The value is connecting signal to action. JOSH: That's probably the theme of the episode. ERIK: Yep. Agents, frameworks, security. Same lesson. Tools changed. Judgment still matters. JOSH: Before the tip, sponsor read. 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: Give every coding agent a job contract before it touches your repo. One paragraph. Plain text. Put it at the top of the task. JOSH: What goes in it? ERIK: Scope, allowed files, forbidden files, test command, success condition, and stop condition. That's it. Example: you may edit files under src billing only. Do not touch migrations. Run npm test billing. Success means the failing billing test passes. Stop if auth files change or tests require network. JOSH: That sounds simple. ERIK: It is, and that's why people skip it. The model performs better when the boundaries are explicit. You also get cleaner diffs, fewer random edits, and a better review trail. JOSH: Does that work with Claude and Codex? ERIK: Yes. Same idea. Claude Code, Codex, whatever agent harness you're using. Don't ask it to fix the project. Ask it to fix one bounded thing with a definition of done. JOSH: What's the mistake? ERIK: Saying, improve this repo. That's not a task. That's a ghost story. Give the agent a contract. Make it report what it changed and what it refused to touch. 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.