AI 资讯

Every system that does "semantic" anything — RAG pipelines, recommendation engines, image search, dedup — boils down to one operation: given this vector, find the closest ones out of millions. The vectors are embeddings, a few hundred to a couple thousand numbers each, and "closest" means closest in meaning. You'd assume the database either scans all of them (slow but correct) or uses some clever tree to jump straight to the answer. It does neither. Instead it deliberately settles for the approximately closest vectors — and that compromise is the entire reason vector search is fast enough to exist. Two algorithms do almost all the heavy lifting in practice, in pgvector, Qdrant, FAISS, and the rest: IVF and HNSW . Here's what they're actually doing under the hood, and how to choose between them. Why "exact" is off the table The natural objection is: why approximate? Just find the real nearest neighbor. In two or three dimensions you could — a k-d tree or similar structure prunes away big regions of space and finds the true closest point quickly. The trouble is that embeddings live in hundreds of dimensions, and high-dimensional space is deeply weird. It's called the curse of dimensionality . As dimensions grow, the distance to your nearest point and the distance to your farthest point drift toward being almost the same. Formally, the contrast (d_max − d_min) / d_min shrinks toward zero. When everything is roughly equidistant from everything else, a tree can't confidently say "skip this whole branch, it's too far" — the bounding regions all overlap, every branch looks plausible, and the search degrades into checking nearly everything. Exact indexes quietly collapse back into brute force. So we change the question. Instead of "prove you found the nearest," we ask "quickly find something very probably among the nearest." That's approximate nearest neighbor (ANN) search, and it swaps a guarantee for speed. The quality knob becomes recall : of the true top-k neighbors, wh

I recently commented on Jonathan Lewis’s blog, Savepoint Funny , where I compared how PostgreSQL handles uniqueness differently: “PostgreSQL resolves uniqueness through heap tuple visibility". This deserves a more detailed explanation. In Oracle, unique indexes store unique entries because the B-tree key is the index key, preventing duplicates. Non-unique indexes add the ROWID to ensure that all entries are physically unique, even when indexed column values are duplicated. In PostgreSQL, all indexes, even unique ones, created explicitly by CREATE UNIQUE INDEX or implicitly to enforce a unique constraint, behave like non-unique indexes by appending the TID (tuple ID, similar to Oracle's ROWID) to the index key. This indicates that the index itself doesn't guarantee physical uniqueness, allowing multiple entries to have identical logical keys but point to different heap tuples. The actual uniqueness verification occurs at the heap level, not within the index entries. Initially, this might seem unusual—a unique index that permits duplicates. However, PostgreSQL requires this because of its MVCC system. MVCC allows duplicate entries to coexist in an index, since they can represent different versions of the same logical row. Still, PostgreSQL must guarantee that no MVCC snapshot views two rows with the same index key. Oracle doesn't face this issue because its MVCC implementation also versions index blocks, allowing a single index version to maintain unique keys. Let’s show that. Page inspect In PostgreSQL, the heap contains the table data, and index entries point to heap tuples. Visibility depends on the heap header, especially the transaction information. Index scans often visit the heap pages to check visibility, except for index-only scans, which use the heap's visibility maps as an optimization. B-tree indexes can store entries for multiple versions of the same logical row, including versions that are no longer visible to current snapshots. To ensure uniqueness, the

How I moved from a traditional web application mindset to exploring local-first architecture I wanted to build a simple software tool for my personal use. Nothing complicated. Something in the category of tools people build for themselves: A personal expense tracker A budgeting application A private knowledge management tool A personal organization system The important characteristic was this: The data belonged to one person. It was not a social application. It was not a collaboration platform. It did not need users interacting with each other. There was no requirement for: Public profiles Sharing updates Real-time collaboration Social features It was simply a tool that helped one person manage their own information. When I started thinking about building it, my first instinct was the most natural one for me. I am a web application developer. My comfort zone is building web applications. So my first thought was: "Why not build a Ruby on Rails application?" Something like: User | Web Application | Ruby on Rails API | PostgreSQL Database This is an architecture I have worked with many times. The workflow is familiar: Create models Build controllers Add authentication Store data in a database Deploy the application Access it from anywhere This is a proven architecture. For many products, this is exactly the right approach. But while thinking about this project, I asked myself a different question: Am I choosing this architecture because the problem requires it, or because it is the architecture I already know? That question changed the direction completely. Understanding The Actual Problem Before choosing technology, I wanted to understand the nature of the problem. What kind of application was I actually building? There is a big difference between building: A social network A marketplace A collaboration platform A communication application versus building: A personal tool A private utility A single-user productivity application In the first category, the server is the

Last week I open sourced FableCut , a Premiere-style video editor that runs in the browser and that AI agents can operate. It hit the front page of Hacker News ( thread ), and the questions there made me realize the interesting part isn't the editor. It's one design decision: the project file is the interface. The usual way, and why I flipped it Most AI video tools hide the edit behind an API. You call addClip() , applyFilter() , and the tool owns the state. If you want a human to touch the result, you build a whole collaboration layer. FableCut does the opposite. The entire timeline lives in one JSON document, project.json : media, clips, tracks, keyframes, transitions, markers. The editor UI reads it. The export renders it. And anything that can write JSON can edit video: Claude Code through MCP, a Python script, jq , or you with a text editor. { "id" : "c_title" , "kind" : "text" , "track" : "V3" , "start" : 0 , "duration" : 2.2 , "props" : { "text" : "HANDMADE" , "font" : "Bebas Neue" , "glow" : 45 , "textAnim" : "letter-pop" } } That clip is a glowing kinetic caption. There is no API call that creates it. Writing it into the file IS creating it. SSE as a doorbell, not a data channel The first question on HN was "what's the benefit of SSE here?" Fair question, because the SSE channel does almost nothing, and that's the point. The server watches the project file with fs.watch , debounces 150ms, and pushes the literal string change to the browser. No payload. The browser re-fetches the project and re-renders. The whole mechanism is about 15 lines on a bare node:http server. Why not WebSockets? Because the data only flows one way. Everything that writes (the UI, an agent, a shell script) goes through REST or the filesystem. The browser only ever needs to hear "something changed, go look." An event with no payload can't arrive out of order, and a missed event costs nothing because the next fetch has the latest state anyway. The revision counter, or: how a human and

TLDR; I got tired of babysitting N terminal tabs of five different coding-agent CLIs. So I built agentproto — one daemon that drives Claude Code, Codex, Hermes, opencode, and Mastra through the same lifecycle, and actually supervises them. Why I built a daemon to drive every AI coding agent from one interface I have a confession: at any given moment I have Claude Code, Codex, and Hermes running in parallel terminal tabs, and I cannot remember which flag spawns which, which one eats --prompt , which one needs --cwd vs cd , and which one will hang forever if I close the laptop lid. simonw described the feeling on Hacker News recently — "Today I have Claude Code and Codex CLI and Codex Web running, often in parallel" — and called it a real jump in cognitive load compared to a year ago. aantix asked, also on HN: "how does everyone visually organize the multiple terminal tabs open for these numerous agents in various states?" I didn't have a good answer. So I built one. It's called agentproto . It is one daemon and one CLI that drives any coding-agent CLI — Claude Code, Codex, Hermes, opencode, Mastra, and a few more — through the same start / prompt / monitor / kill lifecycle, so you stop memorizing five different CLIs. On top of that lifecycle it adds the supervision layer people keep hand-rolling by hand: durable policy gates, nested orchestration, and multiplexed fan-in monitoring. MIT, no paid tier, the daemon itself is an MCP server. This is the story of why it exists. The hand-rolled watchdog The sharpest signal while I was building this came from other people independently re-inventing the same primitives in tmux scripts. On r/ClaudeAI, Confident_Chest5567 posted a writeup of orchestrating agents via tmux panes with a watchdog that resets dead sessions — "a swarm of agents that can keep themselves alive indefinitely." In the same thread, IssueConnect7471 (18 upvotes) described wiring a Redis pub/sub heartbeat plus dead-letter respawn between tmux panes, and arriv

Episode 1/4 — 3 incidents, one root: default GRANTs open more than you think — [CANONICAL URL EPISODE 1: fill in after push] Episode 2/4 — await mutation() lies when nobody opens the { error } envelope — [CANONICAL URL EPISODE 2: fill in after push] The morning Françoise sees zero rows, again It's a Tuesday in April 2026. I've just added the agent_readonly role to the authenticated membership — a one-liner, meant to share a GRANT for a reporting job. First SELECT on cours , Sentry receives infinite recursion detected in policy for relation "user_roles" , code 42P17 . From the office next door, Françoise is already on the phone with the Maisons-Laffitte branch: "So they can't see anything over there — is that normal?" Foreman tone, not really a question. I read the error on my screen. The difference from episode 1: this time Postgres is talking. What came out of Sentry was no longer a silent empty set — it was an explicit error. That difference saved me two days. When Postgres shouts, you listen. The trap is that what it says isn't where you're looking. I won't pretend this is obscure. A policy on user_roles that queries user_roles to decide who can read user_roles is a loop. You avoid it, you work around it with SECURITY DEFINER , you move on. The problem: my user_roles policy didn't reference user_roles . I had already cleaned it up three weeks earlier. The recursion was coming from somewhere else. The diagnostic that targets the wrong object First reflex: re-read the user_roles policy. It's clean, reads auth.email() , never calls itself. Second reflex: disable policies one by one to find the culprit. Wrong angle. -- supabase/migrations/20260420_admin_write_cours_v1.sql -- "Admin write cours" policy — original version that loops CREATE POLICY "Admin write cours" ON public . cours FOR ALL TO authenticated USING ( EXISTS ( SELECT 1 FROM public . user_roles WHERE email = auth . email () AND role IN ( 'admin' , 'super_admin' ) ) ); The recursion doesn't come from a fau

The fourth call of the week Catherine calls from the Maisons-Laffitte site on a Tuesday afternoon in early May. "It's broken, but it's a quick fix." That's her line — I know it, and she's usually right. She describes it in three sentences: the newsletter export for the enrolled-students segment comes back with ninety-two names, the planning view shows ninety-two active courses, but the counter page shows eighty-nine. Three enrolled students missing. She'd checked the database directly — they're all there. "Why three steps for that?" She's not asking for my benefit. She's asking for herself. Except this time, hanging up, I realize it's the fourth time this week I've hung up thinking the same thing. Four Supabase incidents, four fixes, four closed tickets. And not a single exception raised by the database. I reopen the three previous ones and lay all four side by side on screen. This isn't four bugs. It's one failure mode, declinated four times. The first three Episode 1 was about the default GRANT s Supabase places on functions and policies. A SQL function created without an explicit REVOKE inherits anon access that nobody wrote in the migration, and that nobody caught in review because the diff doesn't show it. The function works. It's just callable from outside. [CANONICAL URL EPISODE 1: to fill in after publication of #48 — "3 Supabase security incidents, one shared root cause: SECURITY DEFINER inherits EXECUTE TO PUBLIC"] Episode 2, an ON DELETE SET NULL cascade coupled with a CHECK NOT NULL on the target column. The parent DELETE attempts the SET NULL , the CHECK rejects it, and the transaction surfaces an error we read as a deletion failure — while it actually masks a consistency assumption we'd held for three months. The query fails loudly, which is more charitable than the other three cases, but the diagnosis heads in the wrong direction because nobody had declared that the two constraints lived in tension. [CANONICAL URL EPISODE 2: to fill in after publicati

The request was eight words Monday morning. I open the outgoing email queue: six hundred and forty-seven drafts waiting, six hundred and seventy-two sent. Nobody clicks Send . First-contact emails are prepared by a pipeline and they sleep, because the last step assumes a human. That human, I had stopped believing she would have the time. I state the decision: automate sending . The response comes in seconds. Three levels of automation. Four channels. Three risk thresholds. All correct, all fit for a half-day architecture workshop. I had not asked for a workshop. Pauline walks behind me, glances at the screen, says nothing. Three timed reframes First reframe , brief: too strange, let's simplify . The agent drops two axes, keeps four residual layers, progressive warm-up over three weeks, deterministic anti-replay hash, configuration table in the database, manual Phase 1 followed by an automated Phase 2 to validate after two weeks of measurement. The target stays the same, that an email leaves without a human click. The path has grown accordingly. Second reframe , drier: simple, three safeguards, a kill-switch, we do this in one day . The agent re-architects, accepts the one-day target, keeps the three safeguards. But slips in three prostheses it calls industry standard : real-time dashboard, exponential retry, structured audit log in a new table. Each justifiable in isolation. None of them requested. Third reframe , shorter still: I don't understand why you're adding this . An opening line almost embarrassed, which I had never read from it before: "you're right, I'm over-engineering without necessity." And the version that should have arrived on the first round. A function that takes the draft record, checks three conditions, calls the send engine, returns. // lib/email-outbox.ts — generateFirstContactDraft (commit 3756e63) if ( ! EMAIL_REGEX . test ( input . email )) { return { success : false , error : ' email_invalide ' } } if ( BLACKLIST_EMAILS . has ( input . ema

TL;DR Three unrelated repos, one recurring theme: derive from a single source of truth instead of duplicating it. Shipped a registry-driven sidebar section switcher (public), converged a multi-system password flow, and pushed on a customer-data identity engine. Details on the first two live in their own posts today. 1. Registry-driven sidebar switcher (public) Added a section switcher to the kickoff starter kit. The sidebar, the switcher, and breadcrumbs all read the same config/menu.php list, and the active section is picked by longest URL-prefix match — so a detail page like /admin/roles/42/edit keeps its parent selected. Full write-up in the focused post. 2. One canonical password flow Converged two apps that each rolled their own password-change/reset logic onto a single shared engine, with a fixed order (directory → external DB → local app) and no config-toggle to skip backends. A password that syncs to some systems is worse than one that fails outright, so partial success is now impossible by construction. Also fixed a subtle status bug — an unreachable backend reports skipped (a runtime fact), not disabled (a config state that no longer exists) — and added an audit log so "did it sync?" is a query, not a guess. Separate post today goes deeper. 3. Identity resolution engine (customer data work) Steady progress on a CDP-style identity layer: an idempotent, header-versioned ingest endpoint that queues incoming records, then a resolution engine that can resolve, merge, unmerge, and quarantine profiles. Two things I care about here: PII handling: sensitive identifiers are encrypted at rest with a blind index for lookups, and masked in audit trails — you can search on a value without storing it in the clear. Right-to-erasure: an erasure cascade plus an erasure log, so a deletion request actually propagates and leaves a defensible record that it did. ingest -> queue -> resolve -> profile | +-> merge / unmerge / quarantine No code from this one here — it's teaching t

TL;DR Two apps each had their own password-change/reset logic, plus config toggles to enable/disable backends. That combination quietly allowed partial syncs. Fix: one shared engine, one canonical order , backends mandatory (no config-disable), and every attempt written to an audit log. Lesson: for a write that spans several systems, "configurable steps" is a footgun. Make the flow fixed and make failure loud. The setup A user changes their password. Behind the scenes that single password has to land in several systems — a directory, an external database, and the app's own store. Two separate apps were doing this, each with slightly different code, and each with config flags like sync_oracle => true|false to turn backends on and off. Sounds flexible. It's actually a trap. Why configurable backends are a footgun TL;DR: a password that updates 2 of 3 systems is worse than one that updates none — because now the systems disagree and nobody gets an error. The moment a backend is optionally skippable, "skipped" and "failed" blur together. Someone flips a flag in one environment, forgets it in another, and now prod and staging run different flows. Debugging a login failure means first reverse-engineering which steps actually ran. Before After Each app had its own reset logic One shared engine, both apps call it Backends toggle via config Backends are mandatory, always run Order implicit / differed per app One canonical order: New directory → external DB → local app "Did it sync?" answered by guessing Every attempt logged with per-service status The canonical order The order isn't cosmetic. It runs most-authoritative-first, so if a downstream step fails you haven't already told the user their new password works. change/reset request | v [ New Directory ] --ok--> [ External DB ] --ok--> [ Local App store ] | | | fail fail fail | | | +----> stop, record per-service status, surface the failure Same engine, same order, both apps. A change API and a reset flow are just two entr

The Schlage Sense Pro is a beautiful smart lock. Sleek, discreet, and simple to use, it's Schlage's smartest lock to date. Thanks to ultra-wideband (UWB), it unlocks as I walk up to my front door; I don't need to enter a code or tap my phone or press my finger against it. I've tested several […]

Hey HN! We built a browser-based agent that runs inside an authenticated web app, watches how the app calls its own APIs, and automatically turns those into agent tools. You can think of it as an auto-generated MCP server that self-updates as the host app changes. The result is a skilled AI assistant that actually integrates deeply with any product (not just chat and RAG) with minimal effort. Check out these short demos below that show the agent in software you're probably familiar with: - Jira:

AI runs your email marketing. Better with every send. Discussion | Link

We're open-sourcing Sighthound today, our rules-based static security scanner. What makes it special is that it's coded in rust and uses tree-sitter as it's AST making it very fast and easily extensible. Why build another scanner in 2026? We wanted to improve some of our detection outcomes but noticed the current open source scanners like Semgrep/Opengrep we're capped by a bunch of adoption limitations such as being written in OCaml, requiring a lot of work to add a language parser, and the rule

Hi Hacker News, I’m Yahia. I built Context.dev ( https://www.context.dev/ ) to make it really easy to integrate web data into your products and agents. Here’s a demo video: https://www.tella.tv/video/build-faster-with-context-dev-api... Since it’s an API, here are the docs: https://docs.context.dev/quickstart . You can send us a URL and get back clean Markdown, rendered HTML, screenshots, extracted images, etc.. You can also send us a domain and get company or brand context: name, description, l