Programming

• A Dotfiles Manager That Snapshots Every Change

  Managing dotfiles in 2026 is a solved problem in the same way that managing your own backups is a solved problem: there are five tools for it, all of them work, all of them require you to set up some plumbing first, and once you’re set up you still don’t have a great answer to “I just broke my shell config, get me back to yesterday.”

  The conventional answer is some combination of: a git repo for your ~/.zshrc and friends, a symlink script (or stow, or chezmoi, or yadm), and the discipline to remember to commit after every change. The setup is a one-time hassle. The “wait, what did I change?” recovery story is not great. And if you want to sync across machines, you’ve now got opinions about remote repos, SSH keys on a fresh box, and which order things have to happen in.

  I wanted something different, so not a configuration framework, but a record of every change to the files I care about, in a place I can roll back from, with the lowest possible setup cost.

  That’s what dfm is.

  What It Does

  dfm is a single static Go binary. You point it at the files you want to track (~/.zshrc, anything under ~/.config/, whatever), and every time one of them changes it takes a content-addressed snapshot. The snapshots live on disk in ~/.local/share/dotfiles/backups/. A small state database (SQLite locally, or libSQL via Turso if you want cross-machine sync) records which file maps to which snapshot at which point in time.

  You can roll back. You can diff against an old snapshot. You can see when you last touched a file. And because every snapshot is content-addressed, you never re-store the same bytes twice — switching themes in ~/.zshrc ten times costs the size of two configs, not ten.

  The other half is the backup story. dfm init walks you through cloning (or creating, via gh) a private GitHub repo that mirrors your tracked files plus their history. The point isn’t to make you adopt a new git workflow. It’s that pulling your config onto a fresh machine should be one command, and recovering from rm -rf should never have a “well, hopefully my last commit was recent” caveat.

  Why Setup Is the Hard Part

  The reason people don’t audit their dotfiles is the same reason people don’t back up their laptops: the setup is annoying, and the payoff is theoretical until it isn’t.

  dfm init is a six-step interactive wizard. It detects a TURSO_DATABASE_URL env var if you’ve got one, offers sensible defaults for everything else, lets you opt in to tracking ~/.zshrc immediately, and writes a single config file with the right permissions. Re-run it on an existing config and it pre-fills every prompt with your current value, so the cost of changing your mind later is also low. --yes accepts every default for scripted setup.

  If that sounds boring, that’s the point. Boring is what makes a tool actually get used.

  The AI Bit

  There’s an optional AI integration. dfm suggest <file> asks a local AI CLI (Claude Code by default, configurable) to propose an improvement to one of your tracked files, returns the proposal as a unified diff, and stores it as a pending suggestion. dfm apply <id> reviews the diff and applies it, with a fresh snapshot first, so you can roll back if the suggestion turns out to be wrong.

  I’m exited to try this feature out, because I’m sure there is something i"m doing wrong. The “Look at my ~/.zshrc and tell me what I could clean up” is useful feature that doesn’t require me copy and pasting or granting read or write access to my entire home directory.

  Where to Get It

  github.com/llbbl/dotfiles-manager. Pre-built binaries for darwin and linux on arm64/amd64. Current version, as of writing, is v1.4.0.

  If you’ve been meaning to actually back up your dotfiles and the friction has stopped you, this is the post where I tell you the friction is solvable.

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  May 19, 2026 DevOps AI Programming Go Dotfiles

  Enjoyed this?

• Your AI Coding Agent Can Read Every Secret on Your Machine

  Every developer running an AI coding agent has handed that agent the keys to their machine. Not metaphorically. Literally. The agent runs as your user. It can read every file you can read, execute every command you can execute, and hit every API your stored credentials authorize.

  For most workflows, that’s the point. You want the agent to read your code, modify your project, ship your work. But there’s a quieter implication: the agent can also read your .env files. It can invoke your secret-management tooling. It can grep for API_KEY= across your home directory. And nothing in the agent stack says “wait, you didn’t ask for this.”

  Same-UID isolation isn’t isolation. It’s the absence of isolation labeled politely.

  The usual answer to “keep secrets safe from your coding agent” is: don’t store them where the agent can find them. Use a cloud secret manager. Rotate aggressively. These are good practices, and for local development, they’re often impractical. The agent is going to encounter secrets whether or not your security-best-practices doc approves.

  So over the last week, I built an audit subsystem into lsm, my Local Secrets Manager. The whole thing is designed to answer one forensic question: did anything weird touch my secrets last night?

  The Threat Model

  A defense without a threat model is theater, so let me be specific.

  The threat isn’t a sophisticated remote attacker. lsm is public, open-source code. The threat isn’t a buggy lsm either; bugs happen, and the user can read the source.

  The threat is the agent layer running adjacent to lsm. Coding agents have legitimate access to a wide swath of your filesystem. They’re imperfect at intent inference. They sometimes get prompt-injected. They sometimes run in the background while you’re asleep. When an agent calls lsm get prod DATABASE_URL, the action is indistinguishable from you doing the same thing. The audit log’s job is to make those calls retrospectively distinguishable.

  A secondary threat is an agent covering its tracks. If something reads a secret and then edits the audit log to erase the evidence, the log is worse than useless.

  What Got Built

  The audit subsystem records every access as a structured event: a sequence number, a timestamp, the action, the app and environment, an Actor block describing the calling process, and two cryptographic fields linking each event to the previous one.

  The Actor block was the interesting design problem. It captures parent process ID, parent process name, TTY device path (or empty if there’s no terminal), current working directory, an agent marker derived from environment variables that tools like Claude Code, Cursor, Aider, and Continue set, and the calling user ID. Every field is captured every time. No omitempty. UID zero is a real, meaningful value, and silently dropping it would be a footgun.

  Events land in a hash-chained JSONL file at ~/.lsm/audit.jsonl. Each row carries the SHA-256 of the previous row plus its own body. If anyone edits, inserts, or deletes a row in the middle, the next row’s prev no longer matches and lsm audit verify surfaces the break.

  The chain doesn’t catch tail truncation. If you chop off the end of the file, what’s left is internally consistent. A sidecar file storing the last expected hash is the obvious fix, and I deliberately rejected it. lsm is public code. Any local attacker who knows about the sidecar can rewrite both files in lockstep. Tail-truncation detection is deferred to the off-machine path: when events ship to a remote stack, the last hash naturally lives somewhere the local attacker doesn’t control.

  Reading the Log

  Three commands cover the read side. lsm audit tail does what you’d expect. lsm audit show <seq> prints a single event. lsm audit query is the workhorse, with every field as a filterable dimension: --app, --env, --event, --parent-comm, --agent-marker, --tty present|absent, --since, --until. Output is JSONL when piped and columnar text when interactive.

  Then there’s lsm audit suspicious, which runs four hard-coded detectors in one pass:

  • Outside hours. Events whose timestamps fall outside 07:00–23:00. The 3 a.m. canary.
  • Burst. More than N events from a single parent process within a sliding window. The runaway-agent canary.
  • New parent_comm. Process names not seen in the prior 30 days. The “what is this new thing” canary.
  • Non-interactive, no agent. No TTY, no recognized agent marker. The “what is even running this” canary.

  A single event can stack reasons. A 3 a.m. burst from an unknown parent is unambiguously interesting.

  The detector doesn’t learn baselines, doesn’t call out to an ML model, doesn’t require a service. High-signal patterns are obvious patterns, and obvious patterns are well-served by hard-coded predicates.

  Shipping Events Off the Box

  If you already run an observability stack, lsm can ship audit events over OTLP (the OpenTelemetry wire protocol). Three design choices matter here.

  The local file sink is always authoritative. The remote sink is a mirror, not a replacement. An lsm operation never fails because the remote endpoint is down.

  Redaction is allowlist-based. App and environment names are HMAC-hashed with a per-host salt before becoming labels. The TTY device path is dropped and replaced with a tty_present: true/false boolean. Secret values, cwd, hash, prev, and the schema version never leave the host. Secret names are replaced with key_present: true markers; the remote observer can see that a key was accessed, never which key.

  Events whose name starts with audit. (chain failures, suspicious matches, sink drops) are always local. Telling a remote attacker that local integrity has been compromised is counterproductive.

  What’s Still Open

  The most important non-feature: no command in lsm emits events yet. set doesn’t log. get doesn’t log. delete doesn’t log. The plumbing is complete, the calls are not wired in. Each emit site needs careful thought about which fields are appropriate, whether the event should be local-only, and how it interacts with sensitive operations. That’s the next chunk of work.

  The agent-coding era is normalizing a model where AI tools have wide-ranging access to developer machines. The premise that the agent operates as a fully-trusted local user is unlikely to change soon. Managing the risk means visibility. It means being able to answer “what touched my secrets last night” with a record the agent couldn’t silently rewrite.

  The code is at github.com/llbbl/lsm. The full design lives in docs/observability.md.

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  May 18, 2026 DevOps AI Programming security

  Enjoyed this?

• Five Modern JavaScript Features That Make the Old Patterns Look Silly

  I’ve been doing some reading on what JavaScript has been picking up over the last few releases, and the current batch is unusually good. Cleaner resource management, real Set math, lazy iterators, and a couple of small ergonomic wins that retire some genuinely tedious patterns. So this post is my attempt at summarizing five of the more interesting ones, what they replace, and where each one stands on browser support. I hope it helps if you’re trying to figure out what’s actually shipping versus what’s still a proposal.

  1. Explicit Resource Management with using

  If you’ve written C# or Python, this will feel familiar. The using keyword (and its async sibling await using) ensures a resource is cleaned up the moment the variable goes out of scope, even if your code throws. Under the hood it looks for Symbol.dispose or Symbol.asyncDispose on the object.

  The old way meant remembering to wrap everything in try/finally:

  async function fetchUser() {
    const db = new DatabaseConnection();
    await db.connect();
    try {
      return await db.query('SELECT * FROM users WHERE id = 1');
    } finally {
      await db.close();
    }
  }
  

  The new way:

  async function fetchUser() {
    await using db = new DatabaseConnection();
    await db.connect();
    return await db.query('SELECT * FROM users WHERE id = 1');
  }
  

  No finally, no forgetting to close the connection on the error path. The cleanup is guaranteed.

  Browser/runtime support: Chrome 123+, Firefox 119+, Node 20.9+. Safari is still pending.

  2. New Set Methods

  For years, JavaScript’s Set was basically a deduplicated array with a fancy name. If you wanted actual set math, you were converting to arrays and looping. Now the operations are built in and run at engine speed.

  const userRoles = new Set(['read', 'write', 'comment']);
  const adminRoles = new Set(['read', 'write', 'delete', 'ban', 'comment']);
  
  userRoles.intersection(adminRoles); // shared roles
  adminRoles.difference(userRoles);   // what admin has that user doesn't
  userRoles.union(adminRoles);        // everything, deduped
  userRoles.isSubsetOf(adminRoles);   // true
  

  That’s it. That’s the whole job. No more new Set([...a].filter(x => b.has(x))) incantations. The full method set also includes symmetricDifference, isSupersetOf, and isDisjointFrom.

  These shipped as part of ES2024 and have reached Baseline. Available in Chrome 122+, Safari 17+, and recent Firefox.

  3. Iterator Helpers

  Until now, .map() and .filter() only worked on arrays, and arrays load everything into memory. If you’re streaming a 50GB log file through a generator, calling Array.from() on it will introduce you to your operating system’s OOM killer.

  Iterator helpers bring those same methods to iterators, operating lazily, one item at a time.

  The old way:

  function* infiniteNumbers() {
    let i = 1;
    while (true) yield i++;
  }
  
  const evens = [];
  for (const num of infiniteNumbers()) {
    if (num % 2 === 0) {
      evens.push(num);
      if (evens.length === 3) break;
    }
  }
  

  The new way:

  const result = infiniteNumbers()
    .filter(n => n % 2 === 0)
    .take(3)
    .toArray();
  // [2, 4, 6]
  

  It only computes what take(3) needs. You can chain on an infinite sequence and it just works.

  These are part of ES2025. Firefox has shipped them, Chrome is in the process of shipping in V8, and Safari’s implementation is roughly half done.

  4. Map Upsert

  The naming bounced around (early proposals called it emplace, then upsert), but the final landing is getOrInsert(key, default) and getOrInsertComputed(key, callback). The idea is simple: stop doing the three-step “check, default, fetch” dance every time you group data.

  The old way:

  const wordMap = new Map();
  for (const word of words) {
    const key = word[0];
    if (!wordMap.has(key)) {
      wordMap.set(key, []);
    }
    wordMap.get(key).push(word);
  }
  

  The new way:

  const wordMap = new Map();
  for (const word of words) {
    wordMap.getOrInsert(word[0], []).push(word);
  }
  

  This is the kind of thing every codebase has a groupBy helper for. The proposal reached Stage 4 in January 2026, so it’s officially in the spec, but engine implementations are still in progress as of this writing. Worth knowing about, not yet safe to ship without a polyfill.

  5. Import Attributes

  As ES Modules took over, importing JSON natively became a real need. The catch is that just letting import pull in a .json file is a security problem. If the server quietly serves JavaScript instead of JSON, the engine would happily execute it as code.

  Import attributes fix that by making you declare the type explicitly. If the file isn’t what you said it was, the engine refuses.

  import config from './config.json' with { type: 'json' };
  
  console.log(config.databaseHost);
  

  No more fs.readFileSync for config, no more require hacks in otherwise-modern codebases. Just an import that’s safe by default.

  If you’ve seen the assert { type: 'json' } form in older articles, that was an earlier syntax that got renamed before shipping. The current keyword is with. Available in Chrome, Edge, Firefox, and Safari since April 2025, plus Node and Deno.

  The Through-Line

  What stands out across these five is that each one retires a pattern that’s been written into JavaScript codebases millions of times. The try/finally cleanup. The custom groupBy helper. The Lodash imports for set operations. The for loop with a manual counter because there was no .take() on generators. The fs.readFileSync for loading a config file in an otherwise-modern ESM project.

  The language is quietly absorbing the utility belt, and the code that’s left looks a lot more like what we meant to write in the first place. Sign me up.

  Sources

  • Explicit Resource Management — V8
  • JavaScript Set methods reach Baseline — web.dev
  • Iterator helpers — V8
  • Map.prototype.getOrInsert — MDN
  • Import attributes — MDN

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  May 13, 2026 Programming javascript Web development

  Enjoyed this?

• JavaScript Finally Gets a Real Date API

  When has working with dates ever been easy? Every language has its own version of the same headaches: time zones, parsing, leap years, arithmetic that does weird things at month boundaries. JavaScript just had some quirks layered on top, extra cruft left over from when the language was first created. Third party libraries like Moment.js or date-fns had to fill in the gaps.

  Those days are over. Now we have the Temporal API.

  Why Date Was Broken

  Let me give you the short version of why Date is the way it is. It was inspired by Java’s java.util.Date from the 90s, which Java itself eventually deprecated. JavaScript inherited the design and never let it go.

  The problems are well-known at this point:

  Mutability. Pass a Date to a function and that function can change it underneath you.

  const myDate = new Date('2023-01-01');
  function addDays(date, days) {
    date.setDate(date.getDate() + days);
    return date;
  }
  addDays(myDate, 5);
  console.log(myDate.toISOString().slice(0, 10)); // '2023-01-06'. Surprise, your original is gone.
  

  Time zone confusion. Date stores milliseconds since the Unix epoch but formats itself in the user’s local time zone. Working in any other zone means reaching for moment-timezone or date-fns-tz.

  Parsing roulette. new Date("2023-01-01") and new Date("Jan 1, 2023") can return different things depending on the browser and the assumed time zone.

  Math that lies. Adding a month to January 31st? Date rolls it forward to March 3rd because February doesn’t have 31 days. That’s not a bug exactly. It’s just Date being honest that it doesn’t really understand calendars.

  What Temporal Actually Fixes

  Temporal is a new global object designed from the ground up to address all of this. The design choices are worth walking through because they’re opinionated in the right ways.

  Everything is immutable

  Every operation returns a new object. Your original data stays put.

  const start = Temporal.PlainDate.from('2023-01-01');
  const end = start.add({ days: 5 });
  
  console.log(start.toString()); // '2023-01-01'
  console.log(end.toString());   // '2023-01-06'
  

  Different types for different concepts

  This is the part I find most interesting. Date tries to be everything, a timestamp, a calendar date, a wall clock time, all at once. Temporal splits these into distinct types and forces you to pick:

  • Temporal.PlainDate: a calendar date, no time, no zone. Birthdays, anniversaries.
  • Temporal.PlainTime: a wall-clock time, no date.
  • Temporal.PlainDateTime: date and time, no zone.
  • Temporal.ZonedDateTime: fully zone-aware and calendar-aware. The one for global apps.
  • Temporal.Instant: an exact point in time, like epoch milliseconds.
  • Temporal.Duration: a length of time.

  Making you pick the right type up front is the whole game. Half the bugs in date code come from pretending a Date is one thing when it’s actually another.

  Time zones and calendars built in

  Temporal natively understands IANA time zones (America/New_York, Europe/Paris) and non-Gregorian calendars (Hebrew, Islamic, Japanese). No external library needed.

  Math that respects the calendar

  const t = Temporal.PlainDate.from('2023-01-31');
  const nextMonth = t.add({ months: 1 });
  console.log(nextMonth.toString()); // '2023-02-28'
  

  It clamps to the end of the month instead of rolling over. That’s almost always what you actually wanted.

  Comparisons and Diffs

  A couple of quick ones, because these are the operations you do constantly.

  Comparing two dates:

  const t1 = Temporal.PlainDate.from('2023-01-01');
  const t2 = Temporal.PlainDate.from('2023-01-01');
  console.log(Temporal.PlainDate.compare(t1, t2) === 0); // true
  

  No more getTime() dance to compare primitives. There’s an actual comparison function.

  Finding the difference:

  const start = Temporal.PlainDate.from('2023-01-01');
  const end = Temporal.PlainDate.from('2023-12-31');
  const diff = start.until(end, { largestUnit: 'days' });
  console.log(diff.days); // 364
  

  No more dividing milliseconds by 1000 * 60 * 60 * 24 and hoping DST doesn’t mess you up.

  Should You Use It Yet?

  Check your runtime. Browser and Node support has been landing, but you’ll want to verify Temporal is available where you’re shipping, or use the official polyfill while you wait.

  For most date and time work, this replaces Moment.js and date-fns entirely. Moment has been in maintenance mode for years. Temporal gives you the good parts of those libraries as a standard, immutable, well-typed API.

  Date will stick around forever for backwards compatibility. But for new code, use Temporal. The API is better, the semantics are saner, and less bug-prone.

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  May 10, 2026 Programming javascript Web development

  Enjoyed this?

• SAST vs AI PR Review: Two Tools, Different Jobs

  If you have worked in DevSecOps, you might be wondering if AI pull request review tools are going to replace traditional SAST scanners. Short answer: no. Longer answer: they’re solving different problems, and if you’re picking one over the other, you might be making a mistake.

  Here is how I think about it.

  SAST is the Compliance Gatekeeper

  Static Application Security Testing tools, think Semgrep, SonarQube, Checkmarx, Fortify, parse your source code (usually into an Abstract Syntax Tree) and hunt for known vulnerability patterns. They don’t run the code. They just read it and “pattern-match” against rules.

  The focus here is security, compliance, and strict rule enforcement. SAST is the automated gatekeeper that makes sure your code clears the OWASP Top 10 bar before it merges.

  What SAST does well:

  • It’s deterministic. If a rule matches a pattern, the engine flags it every single time. Run it twice on the same code, get the same result.
  • It satisfies auditors. Frameworks like PCI-DSS, SOC 2, and HIPAA expect documented secure-development practices, and a formal SAST scanner is the easiest way to produce that evidence. AI agents don’t count here, at least not yet.
  • It can do real taint analysis. Enterprise tools can track untrusted input from the moment it enters your app to the moment it hits a dangerous sink.

  Where SAST falls down:

  • The false positive rate is brutal. Rigid rules with no context means a lot of noise. Developer fatigue is real, and once your team starts ignoring scanner output, you’ve lost the game.
  • It can’t see your business logic. A SAST tool has no idea what your application is supposed to do, so it can’t tell you when the logic itself is broken.
  • Comprehensive scans are slow. Hours on large codebases isn’t unusual, though Semgrep has been doing good work on this front.

  AI PR Agents are the Peer Reviewer

  Tools like CodeRabbit, Qodo, Greptile, GitHub Copilot Code Review, Cursor Bugbot, and Claude Code (set up as a review skill) plug into your version control and read the PR diff with the surrounding code context. They behave less like a scanner and more like a colleague who actually read your changes.

  The focus is developer productivity, code quality, logic bugs, and contextual feedback.

  What they do well:

  • They understand intent. LLMs can reason about why the code is changing, not just whether it matches a rule. That’s a different category of feedback.
  • The signal-to-noise ratio is good. When an AI flags something, it usually comes with an explanation that makes sense. Less noise, more useful comments.
  • They suggest fixes. Not just “this is wrong” but “here’s a diff you can apply.” That’s huge for actually closing the loop on review feedback.
  • The scope is broader. Architecture, performance, style, security, all in one pass.

  Where they fall down:

  • They’re non-deterministic. Same vulnerability, two PRs, two different outcomes. That’s not a bug, that’s how LLMs work, and it’s why auditors don’t trust them.
  • They don’t satisfy compliance. No auditor is going to accept “the AI looked at it” as a substitute for a formal scanner.
  • Hallucinations happen. Invented issues, misread intent, suggestions that refactor things that didn’t need refactoring. You still need a human filtering the output.

  The Quick Comparison

  Feature	SAST	AI PR Review
  Primary Goal	Security & Compliance	Code Quality & Productivity
  Analysis Method	Deterministic rules & AST	Non-deterministic LLMs
  Business Logic	Blind	Context-aware
  False Positives	Often high	Usually low
  Compliance Proof	Accepted as evidence	Not accepted
  Feedback Loop	Dashboard / CI output	PR comments / chat

  The Lines Are Starting to Blur

  The interesting thing happening right now is convergence from both directions.

  On the SAST side, tools like DryRun Security are pitching themselves as “AI-native SAST,” trying to keep the deterministic backbone while using LLMs to filter out the false positives that make traditional scanners painful to live with.

  On the AI agent side, CodeRabbit and Greptile keep getting better at catching real security vulnerabilities, not just style issues. They’re slowly creeping into territory that used to belong exclusively to SAST.

  This is going somewhere, but it’s not there yet.

  Where to Start Your Evaluation

  Treat them as complementary, not competitive.

  For SAST, evaluate against your audit footprint, the languages in your codebase, and how much false-positive triage your team can absorb. Semgrep, SonarQube, Checkmarx, and Fortify all sit in different price-and-friction zones, and the right one depends on what your business actually needs to prove.

  For AI PR review, evaluate based on how it fits your existing review workflow, what languages and frameworks it understands well, and the signal-to-noise ratio in practice on your codebase. CodeRabbit, Qodo, Greptile, Copilot Code Review, Bugbot, and a Claude Code review skill all approach the problem differently.

  If you pick one category and skip the other, you’re either passing compliance with mediocre code review, or getting great review feedback while failing your next audit. Neither is a win.

  The AI tools aren’t replacing SAST. They’re filling in the gap SAST was never designed to cover.

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  May 8, 2026 DevOps AI Programming security

  Enjoyed this?

• JuliusBrussee/caveman: 🪨 why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman

  🪨 why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman - JuliusBrussee/caveman

  Apr 26, 2026 Programming links open source code

• pgvector vs Pinecone: You Probably Don't Need a Separate Vector Database

  Every time someone starts building a RAG pipeline, the same question will come up: do I need a “real” vector database like Pinecone, or can I just use pgvector with the Postgres I already have?

  I can imagine teams agonizing over this decision for weeks. So maybe this will save you some time?

  The Case for Staying Put

  If you already have a PostgreSQL instance in your stack, adding pgvector is almost always the right first move.

  You manage one stateful service instead of two. Your existing backup strategy, monitoring, and security all stay the same. Your vector embeddings live next to your metadata, so you get ACID compliance and standard SQL joins. No syncing between two data stores. No eventual consistency headaches.

  Performance? From what I found, for datasets under a few million vectors, pgvector with HNSW indexes is fast. Really fast. It satisfies the latency requirements of most applications without breaking a sweat.

  And you’re not paying for another SaaS subscription…

  When Pinecone Actually Makes Sense

  Pinecone is a purpose-built vector database designed for high-dimensional data at massive scale. It’s serverless and fully managed.

  If you’re dealing with hundreds of millions or billions of vectors, a specialized engine handles memory and disk I/O for similarity searches more efficiently than Postgres can. Pinecone also gives you native namespace support, metadata filtering optimized for vector search, and live index updates that are faster than re-indexing a large Postgres table.

  Those are real advantages. At a certain scale.

  The Decision Is Simpler Than You Think

  Stay with Postgres + pgvector if:

  • You want to minimize infra sprawl and moving parts
  • Your vector dataset is under 5 to 10 million records
  • You rely on relational joins between vectors and other business data
  • You have existing observability and DBA expertise for Postgres

  Consider Pinecone if:

  • Your Postgres instance needs massive, expensive vertical scaling just to keep the vector index in memory
  • You don’t want to tune HNSW parameters, mmap settings, or vacuuming schedules for large vector tables
  • You need sub-millisecond similarity search at a scale where Postgres starts to struggle

  That is what I would use to make that decision.

  Most teams are probably nowhere near the scale where Pinecone becomes necessary. They have a few hundred thousand vectors, maybe a million or two. Postgres handles that without flinching. Adding a separate managed vector database at that point is just adding operational complexity for no measurable benefit.

  The trap is thinking you need to “plan ahead” for scale you don’t have yet. You can always migrate later if you actually hit the ceiling. Moving from pgvector to Pinecone is a well-documented path. But moving from two services back to one because you overengineered your stack? That’s a conversation nobody wants to have.

  Start with what you have. Add complexity when the numbers force you to, not when a vendor’s marketing page makes you nervous.

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  Apr 25, 2026 DevOps AI Programming Databases

  Enjoyed this?

• LangChain and LLM Routers, the Short Version

  LangChain is important to know and understand in the age of agents. Also, LLM routing. They’re related but they’re not the same thing, and the distinction matters.

  So lets break it down.

  LangChain is the Plumbing

  Out of the box, an LLM is a text-in, text-out engine. It only knows what it was trained on. That’s it. LangChain is an open-source framework that connects that engine to the outside world.

  It gives you standardized tools to build pipelines:

  • Models: Interfaces for talking to different LLMs (Gemini, Claude, OpenAI, whatever you’re using)
  • Prompts: Templates for dynamically constructing instructions based on user input
  • Memory: Letting the LLM remember past turns in a conversation
  • Retrieval (RAG): Connecting the LLM to external databases, PDFs, or the internet so it can answer questions about your data
  • Agents & Tools: Letting the LLM actually do things, like execute code, run a SQL query, or send an email

  You could wire all of this up yourself, but LangChain gives you the standard pieces so you’re not reinventing the plumbing every time.

  LLM Routers are the Traffic Controller

  A router is an architectural pattern you build on top of that plumbing. Instead of sending every request through the same prompt to the same massive model, a router evaluates the request and directs it to the right destination. Simple concept, big impact.

  Three reasons you’d want one:

  • Cost: You don’t need a giant, expensive model to answer “Hello!” or look up a basic fact. Send simple queries to a smaller, cheaper model. Save the heavy model for complex reasoning.
  • Specialization: Maybe you have one prompt for writing code and another for searching a company HR manual. The router makes sure the query hits the right expert system.
  • Speed: Smaller models and direct database lookups are faster. Routing makes your whole application more responsive.

  How Routing Actually Works

  In LangChain, there are two main approaches:

  Logical Routing uses a fast LLM to read the user’s prompt and categorize it. You tell the router LLM something like: “If the user asks about math, output MATH. If they ask about history, output HISTORY.” LangChain then branches to a specialized chain based on that output.

  Semantic Routing skips the LLM entirely for the routing decision. It converts the user’s text into a vector (an array of numbers representing the meaning of the text) and compares it to predefined routes to find the closest match. This is significantly faster and cheaper than asking an LLM to make the call.

  LangChain provides RunnableBranch in LCEL (LangChain Expression Language, their declarative syntax for chaining components) for this, basically if/then/else logic for your AI pipelines. Worth digging into if you’re building with LangChain.

  Routing is what makes AI applications practical at scale. LangChain is one way to build it. They’re complementary, not interchangeable.

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  Apr 23, 2026 AI Programming Langchain LLM

  Enjoyed this?

• What I Learned Building My First Chrome Extension

  I built a Chrome extension to navigate Letterboxd movie lists with keyboard shortcuts. Rate, like, watch, next. Here’s what I learned.

  The Idea

  I going through the Letterboxd lists, but wanted a better way. “Top 250 Films,” curated genre lists, friends’ recommendations. The flow becomes tedious: click a movie, rate it, go back to the list, find where you were, click the next one. I wanted to load a list into a queue and step through movies one by one with keyboard shortcuts.

  So I did what any reasonable person would do and built a Chrome extension for it.

  The Framework Graveyard

  The Chrome extension ecosystem has a framework problem. CRXJS, the most popular Vite plugin for extensions, was being archived. Its successor, vite-plugin-web-extension, was deprecated in favor of WXT. WXT is solid but it’s another abstraction layer that could go the same way.

  I went with plain Vite and manual configuration. Four separate Vite configs, one per entry point (content script, background worker, popup, manager page). A simple build script that runs them sequentially and copies the manifest. No framework dependency that could die on me.

  For the UI I used React and TypeScript. Not because the extension needed React, most of the work is content scripts and background messaging, but the popup and settings page benefit from component structure.

  Four Separate Worlds

  One thing I learned was a Chrome extension isn’t one app. It’s four separate JavaScript contexts that can’t directly share state:

  • Content scripts run on the webpage (letterboxd.com). They can read and modify the DOM but can’t access chrome.tabs or other extension APIs.
  • Background service worker runs independently. It handles messaging, storage, and tab navigation. It can die at any time and restart.
  • Popup is a tiny React app that opens and closes with the extension icon. It loses all state when closed.
  • Extension page (the manager) is a full tab running your own HTML. It persists as long as the tab is open.

  They communicate through chrome.runtime.sendMessage and chrome.storage.local. This is an important architectural challenge you need to be aware of. If you’ve never built an extension before, it could trip you up.

  Letterboxd’s DOM Is a Moving Target

  The existing open-source Letterboxd Shortcuts extension uses selectors like .ajax-click-action.-like to click the like button. Those selectors don’t exist anymore. Letterboxd has migrated to React components, and the sidebar buttons (watch, like, watchlist, rate) are loaded asynchronously via CSI (Client Side Includes). They’re not in the initial HTML at all.

  I had to inspect the actual loaded DOM to find the current selectors: .watch-link, .like-link, a.action.-watchlist. The rating widget still uses the old .rateit pattern with a data-rate-action attribute and CSRF token POST.

  If you’re building an extension that interacts with a third-party site’s DOM, expect the selectors to break. Build your DOM interaction layer as a thin, isolated module so you can update selectors without touching the rest of the codebase.

  Service Workers Can’t Use DOMParser

  My list scraper used DOMParser to parse HTML responses. Works fine in tests (jsdom), works fine in content scripts (browser context), fails completely in the background service worker. Service workers don’t have access to DOM APIs.

  I rewrote the parser to use regex. Less elegant but it works everywhere. If I were doing it again, I’d run the parsing in a content script and message the results back to the background worker.

  The Build System Is Simpler Than You Think

  I expected the multi-entry-point build to be painful. It wasn’t. Each Vite config is about 20 lines. Content script and background worker build as IIFE (single file, no imports). Popup and manager build as standard React apps. The build script is 30 lines of execFileSync calls.

  One gotcha: asset paths. Vite defaults to absolute paths (/assets/index.js), but extension popups and pages need relative paths (./assets/index.js). Adding base: './' to the popup and manager configs fixed it.

  TDD Was Worth It (For the Right Parts)

  The extension has four pure logic modules: rating double-tap behavior, auto-advance detection, queue state operations, and keyboard shortcut matching. These are the core of the extension and they’re completely testable without a browser.

  Writing tests first caught edge cases I wouldn’t have thought of. What happens when you press the same rating key on a movie that was already rated in a previous session? What if the queue is empty and someone hits “next”? The tests document these decisions.

  For DOM interaction code, the Letterboxd API layer, overlays, CSI-loaded content, unit testing isn’t practical. I tested those manually.

  What I’d Do Differently … or might change

  Start with the DOM. I built the pure logic first and the DOM interaction last. This meant I didn’t discover the CSI loading issue, the changed selectors, or the DOMParser problem until the end. Next time I’d build a minimal content script first, verify it can interact with the target site, then build the logic on top.

  Use fewer Vite configs. Four config files with duplicated path aliases is annoying. A single config with a build mode flag, or a shared config factory function, would be cleaner.

  Consider the popup lifecycle earlier. Popups close when you click outside them. Any state they hold is gone. I designed around this (the popup is stateless, it queries the background on every open), but it’s easy to get wrong if you don’t plan for it.

  The Result

  The extension loads any Letterboxd list into a queue, navigates through movies one by one, and lets me rate/like/watch/watchlist with single keystrokes. Auto-advance moves to the next movie when I’ve completed my actions. A dark-themed manager page shows the full queue and lets me customize every shortcut.

  It’s a personal tool right now, so not published to the Chrome Web Store. But it’s made going through movie lists is pretty cool. Sometimes the best software is the kind you build for yourself!

  If you’re a developer, I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week. Or you can find me on Mastodon at @[email protected].

  Apr 21, 2026 Programming javascript Chrome-extensions Letterboxd

  Enjoyed this?

• NotebookLM Is Just RAG With a Nice UI

  I’ve been watching AI YouTubers recommend NotebookLM integrations that involve authenticating your Claude instance with some random skill they built. “Download my thing, hook it up, trust me bro.” No details on how it works under the hood. No mention of why piping your credentials through someone else’s code might be a terrible idea. Let’s just gloss over that, I guess.

  So here we are. Let me explain what NotebookLM actually is, because once you understand RAG, the magic disappears pretty quickly.

  What Is RAG?

  RAG stands for Retrieval Augmented Generation. It’s an AI framework that improves LLM accuracy by retrieving data from trusted sources before generating a response.

  The LLM provides the reasoning and token generation. RAG provides specific, trusted context. Combining the two gives you general reasoning grounded in your actual data instead of whatever the model has or hallucinated from its training set.

  The core pipeline looks like this:

  1. Take your trusted data (docs, PDFs, YouTube transcripts, whatever)
  2. Chunk it into pieces
  3. Create vector embeddings from those chunks
  4. Store the vectors in a database
  5. When you ask a question, embed the question into the same vector space
  6. Find the most similar chunks
  7. Feed those chunks into the LLM as context alongside your question

  That’s it. That’s NotebookLM. Steps 1 through 6 are the retrieval half. Step 7 is where the LLM synthesizes an answer. The nice UI on top doesn’t change what’s happening underneath.

  I Accidentally Built Half of It?

  I was interested in the semantic embeddings portion of this pipeline and ended up building something I called Semantic Docs. It handles the retrieval half, steps 1 through 6.

  You point it at a knowledge base, internal company docs, research papers, whatever you’re interested in. It chunks the content, creates vector embeddings, and stores them in a database. When you search, it creates a new embedding from your query, finds the most similar chunks, and returns those as search results.

  The difference between Semantic Docs and NotebookLM is that last step. Semantic Docs gives you the relevant files and passages. It says “here’s where the answers live, go read it.” It doesn’t pipe everything through an LLM to generate a synthesized response. This is a choice, a deliberate choice, not a missing feature.

  Why No Official API Is a Problem

  NotebookLM doesn’t have an official API. People have reverse-engineered how it works, which means every integration you see is built on undocumented behavior that could break at any time. The AI YouTubers recommending these workflows are essentially saying “trust this unofficial thing with your data and credentials.” That should make you uncomfortable.

  If you understand RAG, you can build the parts you actually need. The retrieval half is genuinely useful on its own, and you control the whole pipeline. No third-party authentication. No undocumented APIs. No wondering what happens to your data.

  I’ll probably write more about RAG in the future. It’s a good topic and there’s a lot of noise to cut through. For now, just know that the next time someone tells you NotebookLM is magic, it’s really just vector search with a chat interface on top.

  If you’re a developer, I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week. Or you can find me on Mastodon at @[email protected].

  Apr 20, 2026 AI Programming Rag Notebooklm

  Enjoyed this?