Ask HN: Who is hiring? (October 2026) | Build or Be Replaced
Today: Ask HN: Who is hiring? (October 2026) | DeepSeek Harness Desktop for macOS and Windows | StreetComplete on iOS is now in public beta Episode date: 2026-10-02.
Download MP3 →
Build or Replaced
Today: Ask HN: Who is hiring? (October 2026) | DeepSeek Harness Desktop for macOS and Windows | StreetComplete on iOS is now in public beta Episode date: 2026-10-02.
Download MP3 →ERIK: Build or be replaced. JOSH: It's Friday, October 2nd. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: Friday's the day you find out if your guardrails actually work, or if you just got lucky all week. JOSH: Stick around — Erik's got an AI pro tip at the end about the one setting that decides whether your agent asks for help or just guesses. [pause] JOSH: Okay, headlines. First up — Ask HN's October hiring thread just dropped. ERIK: Every month that thread's a pulse check. Watch which stacks show up in the listings. Right now it's agent infra and evals, same as it's been all year. Companies aren't hiring for "AI experience" anymore, they're hiring for people who can debug a tool-calling loop at 2 AM. JOSH: StreetComplete is in public beta on iOS now. That's the OpenStreetMap editing app. ERIK: Android's had it forever. iOS finally catching up tells you Apple's review process is still the bottleneck for small open-source teams, not the code. JOSH: And a bigger one — a coalition of browser vendors published a draft spec for agent-to-website authentication. Basically a standard way for an AI agent to prove it's acting on behalf of a real logged-in user instead of just scraping with stolen cookies. ERIK: This is the thing nobody's talking about that actually matters. Every agent I run eventually hits a site that doesn't want to be automated. Right now that's a patchwork of API keys, session tokens, and workarounds. A real auth standard for agents means I stop building bespoke login flows for every integration and start trusting a protocol instead. JOSH: So less duct tape. ERIK: Way less duct tape. If this lands, it's bigger for builders like me than another model release. [beat] JOSH: Alright, let's go deep. Pi 1.0 shipped — a hardened, minimal agent harness that runs models from every major provider. ERIK: This is the story of the week for me. Everybody spent the last two years building fast, disposable tooling around agents. Pi's doing the opposite — it's betting that the harness itself needs to be boring and stable, because the models underneath keep changing. JOSH: What's the difference between a harness and, like, a wrapper script? ERIK: A wrapper calls an API. A harness manages the loop — tool calls, retries, context, failure handling. I run that exact pattern for Hermes and Bender, my agentic execution backends. They don't touch a model directly. They go through a layer that decides what's safe to retry and what gets killed. JOSH: Is that overkill for most people? ERIK: Not if you're running real production traffic. PrimeBus pushed 2,295 merge attempts through the pipeline since June — 1,507 actually merged, 788 got blocked by Gandalf, my review agent. Zero got escalated to me personally. That's not a success rate problem, that's the harness doing its job. The 788 are the story, not the failures. JOSH: Wait, zero escalated? In four months? ERIK: Zero. That's the whole point of building the harness right. If I'm getting paged, the guardrail already failed upstream. JOSH: What would it take for one to actually get escalated to you? ERIK: Protected chains. I've got a short list of things — routing config, review logic, anything that touches money — that are sacred. The harness knows the difference between "this is a normal code change" and "this touches something that can hurt me." Pi's whole pitch is baking that distinction into the harness itself instead of hoping every integration remembers to check. JOSH: So the harness isn't just about reliability, it's about which decisions you're willing to delegate. ERIK: Exactly. Speed is cheap now. Knowing what you're allowed to automate is the actual skill. [pause] JOSH: Next story — "RIP, vector database" is near the top of Hacker News today. ERIK: I've been saying this since last year. Vector databases were a stopgap while everyone figured out retrieval. Now you've got models with huge context windows and better hybrid search built into regular databases — Postgres with pgvector, SQLite extensions, whatever. The dedicated vector DB as its own category is shrinking. JOSH: Does that affect anything you're running? ERIK: Directly. I run 144 services on the production box, and I've got a hard rule now — no new long-lived SQLite for app state, Postgres is the standard, vector search lives as an index on top of real data, not a separate silo. ScanBrief's scoring pipeline is a good example — it pulled 85 items across 56 sources again this morning, and the relevance scoring doesn't need a dedicated vector store, it needs good features and a fast join. JOSH: So the HN headline isn't really news to you. ERIK: It's confirmation. I made that call for my own stack before it was a headline. That's usually how it goes — the architecture decision shows up in your systems a year before it shows up as a hot take. JOSH: Did you ever actually run a dedicated vector DB and rip it out? ERIK: Yeah, early on. Tried one for a retrieval layer on an internal tool. Worked fine until I had to keep two databases in sync — the source of truth in Postgres and the embeddings somewhere else. The sync job itself became the most fragile part of the whole pipeline. The day I merged it back into Postgres with pgvector, that entire class of bug just disappeared. JOSH: One less thing that can drift out of sync. ERIK: One less thing, period. Every extra database is a promise you have to keep forever. I'd rather keep fewer promises. [beat] JOSH: Last deep dive — Debian dropped a security advisory with a whole run of Linux kernel CVEs, privilege escalation and denial-of-service stuff. ERIK: This is the unglamorous side of running infrastructure. Everybody wants to talk about agents and models. Nobody wants to talk about patching 144 services across however many kernel versions when a cascade like this drops. JOSH: How do you even keep up with that at your scale? ERIK: You don't manually. I've got telemetry from 140 distinct projects flowing into PrimeBus, and part of what that bus does is surface exactly this kind of thing — a CVE advisory becomes an event, the event triggers a check against what's actually running, and if something's exposed, it becomes a ticket, not a Slack message I forget to read. JOSH: And if it's serious? ERIK: Then it's not autonomous anymore. Kernel patches on a prod box are exactly the kind of change where I want eyes on it before anything restarts. My agents — I've got twelve of them in the fleet now across Claude and GPT — they're great at flagging and triaging. They are not touching a kernel update without me in the loop. JOSH: That's a good line between what you automate and what you don't. ERIK: That's the whole game. Automate the detection, keep a human on anything that can take down the box. JOSH: Has that line ever almost gotten crossed? Like an agent that wanted to just go for it? ERIK: Not wanted to — tried to, once, before I tightened the rule. Early version of my fixer agent saw a dependency CVE, generated a patch, and queued it for auto-merge because the tests passed. Tests passing doesn't mean the fix is right, it means the tests didn't catch the problem. That's exactly why kernel-level and dependency-security changes got carved out as their own category with a mandatory human gate, no exceptions, regardless of what the test suite says. JOSH: So the guardrail exists because something almost got through. ERIK: Every guardrail I have exists because something almost got through. That's not a failure story, that's just how you build the next version correctly. [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: Stop letting your agent guess when it's not sure. Most people build a tool-calling loop and never define what "low confidence" actually looks like to the model. Give it an explicit instruction — if confidence is below some threshold, stop and ask instead of proceeding. I run this everywhere agents touch anything that costs money or can't be undone. It's maybe three sentences in a system prompt, and it's the difference between an agent that fails loud and one that fails quiet and expensive. JOSH: Three sentences, that's it? ERIK: That's it. "If you're uncertain, stop. State what you're uncertain about. Wait for confirmation." You'd be shocked how often that alone catches the bad call before it happens. JOSH: Can you give me a real example where that would've saved you? ERIK: Before I had that instruction locked in everywhere, I had an agent handling a routing config change. It wasn't sure which of two similar-looking settings was the one I meant, picked the one that looked more common, and shipped it. Nothing caught fire, but it was the wrong setting, and I only found out because I happened to check logs that night. With the uncertainty instruction in place, that same agent now just stops and says "these two options look similar, which one did you mean" — and I answer in ten seconds instead of debugging in the dark a week later. JOSH: So the cost of asking is basically zero, but the cost of guessing wrong isn't. ERIK: That's the whole trade. Asking costs you ten seconds of attention. Guessing wrong costs you an afternoon, and that's if you're lucky enough to notice it at all. JOSH: That's your tip. Use it. [beat] JOSH: Binge all five episodes this weekend plus our YouTube shorts — links at buildorbereplaced.dev. [beat] 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.