Daily AI Digest — 2026-07-25
Hacker News Signals
Postgres LISTEN/NOTIFY actually scales
The conventional wisdom is that Postgres LISTEN/NOTIFY breaks down under load — too many connections, too much lock contention on pg_listener, notification storms. DBOS’s post challenges this with careful benchmarking and a clear account of where the bottlenecks actually are.
The core mechanism: NOTIFY acquires a ShareUpdateExclusiveLock on the relation, writes to pg_notify, and then signals all listening backends via shared memory. The contention point historically was the global AsyncQueueLock, which serializes both sending and receiving. Postgres 14+ mitigated this somewhat by shrinking the critical section, but the architecture is still a single queue in shared memory.
The DBOS piece documents that with connection pooling (PgBouncer in transaction mode) and careful channel partitioning, you can sustain tens of thousands of notifications per second on commodity hardware. The key insight is that NOTIFY deduplicates within a transaction: multiple NOTIFY calls on the same channel within one txn collapse to one notification, which dramatically reduces queue pressure under write bursts.
Practical limits: the async notification queue is 8 GB by default (NotifyQueueSpace), and a slow listener that falls behind will cause the queue to fill, at which point the notifying backend blocks. This is the real scalability cliff — not throughput, but slow consumers. The recommendation is to treat NOTIFY as a wake-up signal only, never as a data carrier, and do the actual data fetch via a subsequent query.
For workloads like job queues, cache invalidation, or real-time dashboards where you want to avoid polling, this is a legitimate architecture. The post includes PostgreSQL source-level explanation of the locking protocol, which is useful for understanding failure modes. The conclusion is not that LISTEN/NOTIFY is unlimited, but that it is underused because of reputation rather than actual measured limits.
Source: https://www.dbos.dev/blog/postgres-listen-notify-scalability
Designing an Ethernet Switch ASIC
A detailed project walkthrough of building a functional Ethernet switch ASIC design from scratch, targeting FPGA prototyping but with ASIC-grade RTL discipline. The author works through each pipeline stage explicitly, which makes this useful both as a learning resource and as a reference for the actual engineering tradeoffs.
The pipeline follows the standard cut-through vs. store-and-forward split. Ingress parsing handles Ethernet frame reception, extracting destination MAC, VLAN tags, and computing frame validity. The MAC learning table is implemented as a CAM (content-addressable memory) backed by SRAM, with LRU eviction — the standard tradeoff between lookup latency and table density. On a real ASIC, this becomes a hashed TCAM or a pipelined parallel lookup structure to hit line-rate at 100G+.
The forwarding decision logic uses a hash of the destination MAC to index the forwarding table, with a miss path triggering a broadcast (flood) to all ports in the VLAN. The author implements this as a two-stage pipeline: lookup and then output port selection, keeping the critical path short enough for high-clock-frequency targets.
The output side implements per-port queuing with weighted round-robin scheduling across priority classes. The queue memory is modeled as a linked-list SRAM structure — a classic technique from Papaefthymiou and Rau — rather than fixed partitions, allowing dynamic buffer allocation across ports. This matters for bursty traffic profiles where static partitioning wastes memory.
The RTL is written in SystemVerilog with explicit attention to synthesis constraints: no latches, registered outputs on all inter-module boundaries, and parameterized port counts. The project also covers the verification environment, using cocotb for Python-driven stimulus generation and functional coverage tracking.
For anyone interested in networking silicon or FPGA-based network functions, this is a concrete worked example that bridges the gap between textbook switch architecture and synthesizable RTL.
Source: https://essenceia.github.io/projects/ethernet_switch_asic/
My security camera shipped a GitHub admin token in its login page
A Hanwha security camera (a major South Korean vendor with significant enterprise and government deployments) was found to embed a live GitHub personal access token with admin-level privileges in the static assets served by its local HTTP login interface. The token was sitting in JavaScript or an asset file loaded on every login page render — no authentication required to retrieve it.
The token had access to Hanwha’s GitHub organization, meaning anyone on the local network (or with camera access, which for many deployments means the open internet) could read private repositories, potentially exfiltrate source code, modify code, or pivot to CI/CD systems. The blast radius of a leaked org-admin GitHub token is substantial: read access to all private repos, ability to add deploy keys, access to Actions secrets, and in misconfigured orgs, direct push to protected branches.
The disclosure timeline is not fully detailed, but the researcher responsibly contacted Hanwha before publication. The token appears to have been committed during development and baked into a firmware release — a textbook secrets-in-artifacts failure.
The technical root cause is the absence of secret scanning in the firmware build pipeline. GitHub itself offers push protection and secret scanning that would catch this before a commit lands, but neither helps if the firmware binary is assembled from pre-committed assets or if the repo is private and secret scanning is not enabled on private repos (which requires a paid plan or explicit enablement). Tools like truffleHog, gitleaks, or detect-secrets run as a pre-commit hook or CI check would also catch this.
The broader implication is that embedded device firmware regularly ships with credentials, private keys, and API tokens baked in — this is not an isolated incident. Network-connected devices should be treated as untrusted endpoints from a secrets hygiene standpoint. Rotating secrets on firmware update is architecturally hard, which is why they should never be embedded in the first place.
Source: https://hhh.hn/hanwha-github-token/
Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
Buz is a fork of Bun (the JavaScript runtime) that replaces the older Zig codebase (Bun was written in Zig 0.11-era code) with idiomatic modern Zig, targeting significantly faster incremental build times. The headline claim is sub-1-second incremental rebuilds, compared to the multi-minute full rebuilds that Bun’s existing build system requires.
The core technical issue: Bun’s codebase accumulated patterns from early Zig that predate stable language features — manual arena allocators written before std.heap.ArenaAllocator was mature, comptime patterns that stress the compiler’s analysis budget, and large compilation units that prevent parallelism. Modern Zig (0.13+) has meaningfully improved incremental compilation, but only if the code is structured to exploit it — primarily by keeping compilation units small and avoiding excessive comptime recursion.
Buz restructures the codebase to align with Zig’s current compilation model: finer-grained module boundaries, reduced comptime computation at build time, and use of the new build.zig API features for dependency tracking. The result is that a typical change to a single module triggers recompilation of only that module and its direct dependents, rather than cascading through the whole graph.
The discussion thread on Ziggit is technically substantive, covering whether the module boundary changes break Bun’s internal API assumptions, and whether the performance gains hold for initial (cold) builds rather than just incremental ones. Cold builds apparently remain slow — the sub-1s claim is strictly for incremental.
From an ecosystem perspective, this matters because Bun’s slow build times have been a friction point for contributors. Whether Buz remains a fork or gets merged upstream depends on how much architectural divergence accumulates. The Zig community has been watching Bun as a high-profile production Zig codebase, and Buz represents a data point on what modernizing large Zig codebases actually costs.
The Visual 6502
The Visual 6502 project is a transistor-level simulation of the MOS 6502 CPU running entirely in the browser via JavaScript. The simulation is derived from a physical chip that was photographed layer by layer after chemical delayering, with the resulting images traced to produce a netlist of approximately 3,510 transistors. This netlist is then simulated as a switch-level circuit — each transistor modeled as a voltage-controlled switch — which produces cycle-accurate behavior without any behavioral model or HDL.
The simulation runs at a few kilohertz in JavaScript, far below the original 1 MHz clock, but is functionally exact. You can step through clock cycles, inspect the state of every net in the chip, watch the ALU compute, observe the microcode-like decode ROM driving control signals, and trace exactly how an instruction like LDA #imm propagates through the pipeline. The visual display maps each net to its physical polygon on the die, color-coded by logic state, so you can literally watch signals flow through the silicon layout.
The technical depth here is unusual. The 6502 has no microcode ROM in the conventional sense — its instruction decode is implemented as a PLA (programmable logic array) combined with a random logic state machine, which was a design choice driven by the chip’s small die area and the need to hit aggressive timing. The simulation makes this visible: you can observe the PLA outputs directly.
For computer architecture education, this is a uniquely concrete resource. The 6502’s simplicity (no cache, no pipeline, no branch prediction) means the full datapath is tractable, and the visual correspondence between logic state and physical layout makes the abstractions unusually transparent. The project also produced a fully extracted netlist that has been used to verify 6502 behavior against the original Rockwell documentation and catch longstanding errata.
Source: http://visual6502.org/JSSim/index.html
Show HN: OneCLI – OSS credential gateway that keeps secrets out of AI agents
OneCLI is a credential gateway designed specifically for the case where an AI agent (an LLM-driven system with tool-calling capability) needs to interact with external services that require authentication. The problem it addresses is concrete: if you give an agent an AWS access key or a Slack API token directly, that credential is in the agent’s context window, potentially logged, potentially exfiltrated via a prompt injection attack, and almost certainly visible to the LLM provider in transit.
The architecture interposes a local proxy between the agent and the target service. The agent calls OneCLI with a high-level action (e.g., “list S3 buckets in bucket foo”) rather than a raw API call. OneCLI holds the actual credential, injects it into the outgoing request, and returns the response. The agent never sees the secret.
This is structurally similar to a secrets manager with a policy-enforcing proxy layer. The novel aspect is the interface design targeting LLM tool-use patterns: each capability is exposed as a discrete tool with a schema that an LLM can call via function-calling or tool-use APIs, rather than requiring the agent to construct raw HTTP requests.
The security model is only as strong as the OneCLI process boundary. If the agent can execute arbitrary code on the host running OneCLI, the credential is accessible anyway. The real threat model is narrower: protecting against prompt injection that tries to extract credentials via the LLM’s output channel, and preventing credentials from appearing in logs or being sent to the LLM provider as input tokens.
The repository is early-stage OSS. It supports a handful of integrations (AWS, GitHub, Slack noted in comments). The design raises legitimate questions about whether the tool-level granularity is sufficient to prevent credential abuse — an agent that can call “send Slack message to any channel” still has broad capability even without seeing the token.
Source: https://github.com/onecli/onecli
Google’s ATLAS is a look at how people are using AI
Google’s ATLAS (AI Tool and Labor Activity Survey) is an attempt to measure actual patterns of AI tool adoption and usage across workers and tasks, rather than relying on capability benchmarks or self-reported sentiment. The methodology is a large-scale survey instrument designed to capture which specific task categories are being augmented or automated, with what frequency, and by whom.
The substantive findings that circulated in the HN discussion: coding and writing tasks show the highest penetration rates, which is expected. More interesting is the differential across income levels and education — higher-income knowledge workers show faster adoption than lower-income workers in the same organization, suggesting that AI tools are currently amplifying existing productivity advantages rather than leveling them. This is the opposite of the “democratization” narrative.
The survey also attempts to capture substitution vs. complementarity: are workers doing the same tasks faster, or doing different tasks? The data apparently shows predominantly complementarity in the short term — workers report doing more of the same work, not shifting to different work. Whether this is a transitional state or a stable equilibrium is not answerable from the survey.
The HN discussion is skeptical of the methodology on several counts: self-reported time allocation is unreliable, “AI tool” is defined broadly enough to include spell-checkers, and the survey instrument may not capture the difference between using AI as a crutch that degrades skill acquisition versus genuine productivity augmentation. These are legitimate methodological concerns.
From a research perspective, ATLAS-style surveys are necessary complements to capability evals — knowing that a model scores 90% on SWE-bench says nothing about whether or how software engineers are actually using it. The data collection infrastructure for measuring AI’s economic effects is genuinely underdeveloped, and efforts to build it are worth tracking even when individual survey results are noisy.
Source: https://blog.google/innovation-and-ai/technology/research/understanding-the-ai-economy/
Claude Opus 5
Anthropic released Claude Opus 5, their flagship model, claiming it as their strongest to date across coding, reasoning, and agentic tasks. The announcement is sparse on architectural specifics, which is standard for Anthropic releases.
The quantitative claims: 3.5% on SWE-bench Verified (the software engineering benchmark requiring real GitHub issue resolution), topping their previous Sonnet models, which sat around 49-50%. On GPQA Diamond (graduate-level science reasoning), it reportedly surpasses Claude 3 Opus significantly. Anthropic emphasizes agentic performance — multi-step task completion with tool use — as a design priority rather than single-turn benchmark scores.
The context window is 200K tokens, unchanged from the Sonnet line. Pricing lands at the Opus tier, substantially above Sonnet 4, which makes it a targeted deployment for high-value tasks rather than a general-purpose default. This pricing structure reflects the observed market segmentation: Sonnet-class models handle bulk inference, Opus-class handle tasks where quality has high marginal value.
The HN discussion is substantive on a few technical points. Several commenters report that the model handles long-context retrieval more reliably than previous Opus versions — less “lost in the middle” degradation. The agentic improvements are attributed in part to better instruction following under multi-turn pressure, where models tend to drift from initial constraints. Whether this is architectural or training-data-driven is not disclosed.
What Anthropic does not discuss: training compute, data composition, any RLHF or constitutional AI modifications, or how the model compares internally on the safety benchmarks they have previously published (e.g., ASL evaluations). Given that Opus 5 is their most capable model, the ASL-3 vs. ASL-4 classification question is non-trivial, but the announcement is silent on it. The model is available via API now with a waiting list for the heaviest usage tiers.
Noteworthy New Repositories
nossa-y/activity-frames
A local episodic memory layer for AI agents. The system continuously captures screen activity, segments it into discrete “activity frames” — structured records that encode what was on screen, in what application, and when — and exposes those frames via the Model Context Protocol (MCP). No data leaves the machine; there is no LLM in the loop during recording or indexing, which keeps latency low and removes any privacy dependency on a cloud provider.
The architecture is straightforward: a screen-capture daemon writes frames to a local store, a lightweight compiler normalizes and chunks them into a queryable structure, and an MCP server sits in front of that store so any MCP-compatible agent can retrieve context about recent user activity. This is essentially a read-optimized event log with a standardized agent-facing API.
The practical value is grounding: agents that need to know what a user was doing five minutes ago — to resume a task, explain a file, or avoid duplicate work — can query the frame store rather than asking the user to re-explain. The local-only constraint is a deliberate design choice that trades ecosystem breadth for auditability and zero data-egress risk. Useful for desktop AI assistants, context-aware coding agents, or any workflow automation that needs temporal user context without telemetry.
Source: https://github.com/nossa-y/activity-frames
aws-samples/sample-specship
A structured, spec-driven autonomous engineering workflow packaged as a Kiro Power. The pipeline enforces five sequential phases — recon (read codebase, understand constraints), plan (produce a machine-readable spec), build (generate code against the spec), validate (adversarial TDD: a separate agent attempts to break the output), and ship (gate on quality metrics before merge). Each phase has explicit entry and exit criteria, preventing the common failure mode where a coding agent skips straight to code generation without establishing ground truth.
The anti-slop quality gates deserve attention: the workflow explicitly checks for vague docstrings, dead code, missing edge-case tests, and spec drift — common artifacts of LLM code generation that pass naive unit tests but accumulate technical debt. The adversarial validation step runs an independent agent that attempts to construct failing inputs against the just-generated code, then feeds failures back into the build phase before shipping.
This is not a library but a workflow template and prompt-chain design. Teams integrating coding agents into CI/CD pipelines will find the phase separation useful for auditing which step introduced a regression. The TDD loop structure is particularly applicable to domains with well-defined contracts — API development, data transformers, protocol implementations.
Source: https://github.com/aws-samples/sample-specship
aipoch/open-science
A model-agnostic workbench targeting scientific discovery workflows. The core design separates the tool layer (data ingestion, hypothesis formulation, experiment tracking, literature search) from the model layer, so users can plug in any LLM or specialized scientific model without rewriting orchestration logic. This matters because scientific workflows are heterogeneous: a chemistry pipeline might need a domain-specific molecular model alongside a general-purpose reasoner, and hardcoding one provider creates brittleness.
The workbench appears structured around a task-graph abstraction — discrete steps (retrieve, hypothesize, simulate, evaluate) are composed into pipelines with typed inputs and outputs. This enables reproducibility logging at the step level, a common deficiency in ad-hoc notebook-based science workflows. The open-source framing also allows domain communities to contribute specialized modules (e.g., a PubMed retrieval tool, a protein structure evaluator) without owning the full stack.
The broader ambition is to lower the barrier for researchers who need LLM-assisted discovery workflows but lack the infrastructure engineering background to build and maintain them. Whether the abstraction layer is thin enough to stay out of the way for power users — or thick enough to be genuinely useful to domain scientists — is the key open question. Worth watching as a platform for community-contributed scientific agent tooling.
Source: https://github.com/aipoch/open-science
l0ng-ai/tty7
A terminal emulator and multiplexer written entirely in Rust, GPU-rendered via Zed’s gpui framework, with VT/ANSI parsing sourced from the Alacritty project. The combination is deliberate: gpui provides a retained-mode GPU render path that keeps frame times low even with high-throughput output (build logs, streaming model responses), while reusing Alacritty’s battle-tested VT core avoids re-implementing the dense ANSI/xterm escape sequence surface.
Beyond basic terminal emulation, tty7 integrates persistent session management (survive disconnects, reconnect to running shells), SSH support baked into the session model rather than bolted on, and first-class coding agent integration — agents can be spawned as named sessions and their I/O surfaced alongside human shells in the same workspace.
The pure-Rust stack means the binary is statically linkable with minimal system dependencies, which matters for deployment in containers or remote dev environments where installing a full desktop terminal is impractical. The GPU rendering also implies high-DPI and variable-refresh-rate displays are handled correctly without per-pixel CPU fallbacks.
The interesting architectural bet is treating coding agents and human shells as peers in the same session model rather than embedding an agent as a plugin inside a traditional terminal. Whether gpui outside the Zed editor context carries maintenance risk is the main open question.
Source: https://github.com/l0ng-ai/tty7
514-labs/dnsglobe
A terminal UI for observing DNS record propagation across 34 public resolvers distributed globally, rendered as a world map in the terminal. The visualization maps each resolver to its geographic location and colors it by response state — unresolved, stale TTL, propagated — giving operators a spatial intuition for propagation wavefronts that tabular output does not provide.
Under the hood, the tool issues parallel DNS queries to all 34 resolvers with configurable polling intervals, normalizes responses into a unified record struct (handling NXDOMAIN, SERVFAIL, and record-type differences), and diffs successive snapshots to detect when a resolver transitions state. The TUI layer renders a grid-based world map using block characters, overlaying resolver status dots at approximate longitude/latitude positions.
The practical use case is TTL-sensitive operations: CDN migrations, nameserver transfers, or A/AAAA record changes where you need to know not just “is it propagated?” but “which geographies still see the old record?” — information that single-resolver tools like dig or online checkers that query one region cannot provide.
The 34-resolver breadth covers major anycast operators (Google 8.8.8.8, Cloudflare 1.1.1.1, regional ISP resolvers) and provides statistically meaningful coverage without the latency of querying hundreds of endpoints. A clean, single-binary tool with an obvious operational niche.
Source: https://github.com/514-labs/dnsglobe
runvendo/vendo
A framework for embedding autonomous agents directly inside customer-facing products, with three primary capabilities exposed to end users: task automation (the agent performs multi-step work on behalf of the user within the product’s context), dynamic view construction (the agent builds or configures UI components in response to user intent), and tool/integration wiring (the agent connects external services on the user’s behalf).
The architecture positions Vendo as an agent runtime that product developers embed rather than build from scratch. The key design question for any such framework is trust and permission scoping: what actions can the embedded agent take, on whose authority, and with what auditability? Vendo’s model grants customers agent access within sandboxed permission boundaries defined by the embedding application, which keeps the product developer in control of the blast radius.
This is architecturally similar to LangChain’s tool-calling model but oriented toward end-user-facing deployment rather than developer-internal automation. The distinction matters: agents embedded in customer products face different reliability and explainability requirements than internal developer tools — users who aren’t ML engineers will attribute errors to the product, not to the underlying model.
The value proposition is reducing the time-to-embedded-agent for SaaS products that want to offer automation features without building a full agent infrastructure in-house.
Source: https://github.com/runvendo/vendo
persiyanov/herdr-reviewr
A sidebar tool for reviewing AI agent-generated diffs within the herdr workflow. The core loop: an agent produces a diff, the reviewer opens a file-viewer panel showing the changed code with inline comment support, writes review comments, and sends the annotated diff back to the agent for a revision cycle. The tool also surfaces the associated PR’s CI check status and existing reviewer comments in read-only mode so the human reviewer has full context without switching to a browser.
The technical substance is the structured feedback channel: rather than treating AI-generated code as a binary accept/reject decision, herdr-reviewr allows fine-grained, line-level annotation that the agent can interpret and act on. This is a meaningful improvement over the typical “regenerate with a note” pattern, because it preserves the spatial structure of the feedback (this specific line is wrong, not the whole function) in a form the agent can parse.
The read-only PR view is a small but practical addition — it prevents the reviewer from needing to context-switch out of the terminal workflow to check whether CI passed or another reviewer already flagged an issue.
For teams running agentic coding pipelines at any scale, the ability to close the human-feedback loop without friction is a genuine workflow bottleneck. This tool addresses that bottleneck directly with minimal infrastructure.
Source: https://github.com/persiyanov/herdr-reviewr
ohad6k/emulo
A local profile-mining tool that ingests conversation logs from Claude Code and OpenAI Codex (and potentially other agents), extracts recurring patterns in the user’s prompts, preferences, corrections, and workflows, and compiles them into a you.md file — a structured natural-language document describing the user’s coding style, preferred abstractions, common error patterns, and tool preferences.
The core operation is log analysis: parse raw agent conversation history, cluster similar prompts and correction patterns, infer stable preferences (e.g., “always prefers explicit type annotations,” “corrects agents that use mutable default arguments”), and render those inferences as prose or structured sections in Markdown. The resulting you.md is intended to be fed as a system prompt or context file to future agent sessions, bootstrapping personalization without requiring the user to manually write a preferences file.
This addresses a genuine friction point: users who work with coding agents daily accumulate implicit knowledge about how to get good outputs from them, but that knowledge is locked in their heads and must be re-taught to every new session or new agent. Emulo externalizes it.
The main limitation is inference quality — log-based preference extraction is noisy, and a you.md that includes incorrect inferences could actively degrade agent performance. The tool’s value scales with log volume and depends heavily on how carefully the clustering and extraction logic handles ambiguous evidence.
Source: https://github.com/ohad6k/emulo