Show stories

Built this over the last few days, based on a Rust codebase that parses the latest ALPR reports from OpenStreetMaps, calculates navigation statistics from every tagged residential building to nearby amenities, and tests each route for intersection with those ALPR cameras (Flock being the most widespread).

These have gotten more controversial in recent months, due to their indiscriminate large scale data collection, with 404 Media publishing many original pieces (https://www.404media.co/tag/flock/) about their adoption and (ab)use across the country. I wanted to use open source datasets to track the rapid expansion, especially per-county, as this data can be crucial for 'deflock' movements to petition counties and city governments to ban and remove them.

In some counties, the tracking becomes so widespread that most people can't go anywhere without being photographed. This includes possibly sensitive areas, like places of worship and medical facilities.

The argument for their legality rests upon the notion that these cameras are equivalent to 'mere observation', but the enormous scope and data sharing agreements in place to share and access millions of records without warrants blurs the lines of the fourth amendment.

Mobile keyboards today are almost entirely based on the 26-key, 3-row QWERTY layout. Here’s a new 2-row, 16-key alternative designed specifically for smartphones.

For years I’ve wanted to start a podcast to interview curious and passionate makers in the depths of their creative pursuits.

I would love any feedback, a rating, and if you know anyone would would make a great guest, please let me know!

The article announces the launch of Contraption's new print edition, which aims to provide a high-quality, physical magazine experience for readers interested in design, technology, and culture. It highlights the magazine's focus on in-depth reporting, thoughtful analysis, and striking visuals.

https://github.com/mcp-shark/mcp-shark Site: https://mcpshark.sh/

I built MCPShark, a traffic inspector for the Model Context Protocol (MCP).

It sits between your editor/LLM client and MCP servers so you can: • See all MCP traffic (requests, responses, tools, resources) in one place • Debug sessions when tools don’t behave as expected • Optionally run “Smart Scan” checks to flag risky tools / configs

The article discusses the future of news consumption in 2035, predicting a shift towards more personalized, interactive, and immersive news experiences driven by advancements in technology and user preferences.

We originally set out to solve complex debugging headaches and useless alerts caused by traditional security scanners in our own projects. Static Analysis (SAST) flagged too much noise because it couldn't verify runtime context, while Dynamic Analysis (DAST) missed internal logic bugs because it treated the app like a black box.

We built a CLI tool to bridge this gap using grey box testing from a red team approach. We use internal knowledge of the codebase to guide parallel execution, allowing us to find complex or hidden logic errors and attack paths standard linters/scanners miss.

The Tech (Grey Box Graphing & Execution): - Internal Graphing (The Map): It ingests the codebase to build a dependency graph of the internal logic. - Parallel Execution (The Test): The code is then tested on parallel engines. We spin up copies of your local dev environment to exercise the codebase in thousands of ways. This is the validation that proves a bug is real. - Logic Error Detection: Because It understands the intended architecture (the graph) and sees the actual behavior (execution), we can flag Logic Errors, (ex. race conditions, state inconsistencies, memory leaks etc). - Tainted Flow Mapping: We map tainted control flow over the dependency graph. This highlights exactly how external input threads through your logic to trigger a vulnerability. It then spins up a local instance to replay this flow and confirm the exploit.

How it runs: It runs locally via CLI to maintain privacy with secure repos and ease. Generates remediation via MD reports pinpointing the line of the error and downstream effects.

The Trade-off: This approach trades power for speed and deep testing. This testing engine is recommended for more sophisticated systems.

Try it out: We are currently opening our beta VS extension for early users.

Optimized for (Rust, C++, Go, Java) and IaC (Terraform, Docker, K8s). Also supports Python, TS/JS, C#, PHP, and (20+ other languages).

P.S. We are happy to run this ourselves on repos. If you maintain a complex project and want to see if our engine can find logic or security holes, drop a link or reach out via the comments/site and we’ll do it and send the results.

MimicKit is an open-source Python library that enables users to easily create realistic 3D animated characters. The library provides tools for automated lip-syncing, facial animation, and body motion generation, allowing developers to quickly generate high-quality character animations.

I built AlgoDrill because I kept grinding LeetCode, thinking I knew the pattern, and then completely blanking when I had to implement it from scratch a few weeks later.

AlgoDrill turns NeetCode 150 and more into pattern-based drills: you rebuild the solution line by line with active recall, get first principles editorials that explain why each step exists, and everything is tagged by patterns like sliding window, two pointers, and DP so you can hammer the ones you keep forgetting. The goal is simple: turn familiar patterns into code you can write quickly and confidently in a real interview.

https://algodrill.io

Would love feedback on whether this drill-style approach feels like a real upgrade over just solving problems once, and what’s most confusing or missing when you first land on the site.

We're releasing early efforts on coding agent governance with Cupcake [1] - an open-source policy enforcement layer with native integrations. You write rules in policy-as-code (OPA/Rego), and Cupcake integrates them into the agent runtime via Hooks.

See it in action (Desktop only): https://cupcake-policy-studio.vercel.app/example-policies/se...

Help us build: https://github.com/eqtylab/cupcake

We are EQTY Lab, our mission is verifiable AI (identity, provenance, and governance). With the rise of capable agents like Claude Code, it became immediately clear that those deploying these agents need the ability to conduct their own alignment and safety controls. We can’t rely solely on the frontier labs.

This is why we created the feature request for Hooks in Claude Code [2], and pivoted away from filesystem and OS-level monitoring once those hooks were implemented. Hooks provide the critical points we need:

* Evaluation: Checking agent intent and actions.

* Prevention: Stopping unsafe or unwanted actions.

* Modification: Adjusting the agent's output before execution.

Policy-as-Code with OPA/Rego - While many agent security papers suggest similar policy architectures using invented DSLs, Cupcake is fundamentally built on Open Policy Agent (OPA) and its policy language, Rego [3].

We chose Rego because it is:

* Industry-Robust: Widely adopted across enterprise DevSecOps and cloud-native environments.

* Purpose-Built: Offers unique, mature advantages for defining, managing, and enforcing policy as code.

* Enterprise-Oriented: This makes Cupcake compatible with existing enterprise governance frameworks.

Cupcake is released under the Apache-2.0 license. We will formalize a path to v1.0.0 in Q1 of 2026. This is an early preview version. The goal with Cupcake is not suppression, but to ensure an agent is able to drive fast without crashing. To collaborate, or join forces: ramos at eqtylab dot io.

[1] https://github.com/eqtylab/cupcake

[2] https://github.com/anthropics/claude-code/issues/712

[3] https://www.openpolicyagent.org/

Hey HN! Like most here regular meetings have always been a big part of my work.

Over the years I've learned the value of active note taking in these meetings. Meaning: not minutes, not transcriptions or AI summaries, but me using my brain to actively pull out the key points in short form bullet-like notes, as the meeting is going on, as I'm talking and listening (and probably typing with one hand). This could be agenda points to cover, any interesting sidebars raised, insights gotten to in a discussion, actions agreed to (and a way to track whether they got done next time!).

It's both useful just to track what's going on in all these different meetings week to week (at one point I was doing about a dozen 1-1s per week, and it just becomes impossible to hold it in RAM) but also really valuable over time when you can look back and see the full history of a particular meeting, what was discussed when, how themes and structure are changing, is the meetings effective, etc.

Anyway, I've tried a bunch of different tools for taking these notes over the years. All the obvious ones you've probably used too. And I've always just been not quite satisfied with the experience. They work, obviously (it's just text based notes at the end of the day) but nothing is first-class for this usecase.

So, I decided to build the tool I've always felt I want to use, specifically for regular 1-1s and other types of regular meetings. I've been using it myself and with friends for a while already now, and I think it's got to that point where I actually prefer to reach for it over other general purpose note taking tools now, and I want to share it more widely.

There's a free tier so you can use it right away, in fact without even signing up.

If you've also been wanting a better system to manage your notes for regular meetings, give it a go and let me know what you think!

Hi HN!

I'm building a JavaScript debugger called Wirebrowser. It combines network inspection, request rewriting, heap snapshots, and live object search.

The main experimental feature is BDHS (Breakpoint-Driven Heap Search): it hooks into the JavaScript debugger and automatically captures a heap snapshot at every pause and performs a targeted search for the value or structure of interest. This reveals the moment a value appears in memory and the user-land function responsible for creating it.

Another interesting feature is the Live Object Search: it inspects runtime objects (not just snapshots), supports regex and object similarity, and lets you patch objects directly at runtime.

Whitepaper: https://fcavallarin.github.io/wirebrowser/BDHS-Origin-Trace

Feedback very welcome, especially on whether BDHS would help your debugging workflow.

Shellican is a cross-platform shell scripting language that aims to provide a versatile and user-friendly alternative to traditional shell scripts. It combines the simplicity of shell scripting with the power of a high-level programming language, offering features such as object-oriented programming, modules, and a rich standard library.

fanfa.dev is a website that provides free and open-source tools and resources for web development, including a code editor, task runner, and package manager. The site aims to simplify the development workflow and empower developers with a user-friendly platform.

FATE is an open-source federated learning framework that enables secure and privacy-preserving collaboration among multiple parties. It provides a comprehensive set of tools for building, training, and deploying federated learning models across different platforms and cloud environments.

This article explores the capabilities of WebPiano, a web-based piano simulator that allows users to play and compose music directly in their web browsers using virtual keyboards and MIDI support.

Hi HN, tl;dr we built a bug finder that's working really well, especially for app backends. Try it out and send us your thoughts!

Long story below.

--------------------------

We originally set out to work on technical debt. We had all seen codebases with a lot of debt, so we had personal grudges about the problem, and AI seemed to be making it a lot worse.

Tech debt also seemed like a great problem for AI because: 1) a small portion of the work is thinky and strategic, and then the bulk of the execution is pretty mechanical, and 2) when you're solving technical debt, you're usually trying to preserve existing behavior, just change the implementation. That means you can treat it as a closed-loop problem if you figure out good ways to detect unintended behavior changes due to a code change. And we know how to do that – that's what tests are for!

So we started with writing tests. Tests create the guardrails that make future code changes safer. Our thinking was: if we can test well enough, we can automate a lot of other tech debt work at very high quality.

We built an agent that could write thousands of new tests for a typical codebase, most "merge-quality". Some early users merged hundreds of PRs generated this way, but intuitively the tool always felt "good but not great". We used it sporadically ourselves, and it usually felt like a chore.

Around this point we realized: while we had set out to write good tests, we had built a system that, with a few tweaks, might be very good at finding bugs. When we tested it out on some friends' codebases, we discovered that almost every repo has tons of bugs lurking in it that we were able to flag. Serious bugs, interesting enough that people dropped what they were doing to fix them. Sitting right there in peoples codebases, already merged, running in prod.

We also found a lot of vulns, even in mature codebases, and sometimes even right after someone had gotten a pentest.

Under the hood: - We check out a codebase and figure out how to build it for local dev and exercise it with tests. - We take snapshots of the built local dev state. (We use Runloop for this and are big fans.) - We spin up hundreds of copies of the local dev environment to exercise the codebase in thousands of ways and flag behaviors that seem wrong. - We pick the most salient, scary examples and deliver them as linear tickets, github issues, or emails.

In practice, it's working pretty well. We've been able to find bugs in everything from compilers to trading platforms (even in rust code), but the sweet spot is app backends.

Our approach trades compute for quality. Our codebase scans take hours, far beyond what would be practical for a code review bot. But the result is that we can make more judicious use of engineers’ attention, and we think that’s going to be the most important variable.

Longer term, we think compute is cheap, engineer attention is expensive. Wielded properly, the newest models can execute complicated changes, even in large codebases. That means the limiting reagent in building software is human attention. It still takes time and focus for an engineer to ingest information, e.g. existing code, organizational context, and product requirements. These are all necessary before an engineer can articulate what they want in precise terms and do a competent job reviewing the resulting diff.

For now we're finding bugs, but the techniques we're developing extend to a lot of other background, semi-proactive work to improve codebases.

Try it out and tell us what you think. Free first scan, no credit card required: https://detail.dev/

We're also scanning on OSS repos, if you have any requests. The system is pretty high signal-to-noise, but we don't want to risk annoying maintainers by automatically opening issues, so if you request a scan for an OSS repo the results will go to you personally. https://detail.dev/oss

Hello Everyone! We built SQLFlow as a lightweight stream processing engine.

We leverage DuckDB as the stream processing engine, which gives SQLFlow the ability to process 10's of thousands of messages a second using ~250MiB of memory!

DuckDB also supports a rich ecosystem of sinks and connectors!

https://sql-flow.com/docs/category/tutorials/

https://github.com/turbolytics/sql-flow

We were tired of running JVM's for simple stream processing, and also of bespoke one off stream processors

I would love your feedback, criticisms and/or experiences!

Thank you

Briddle.io is a platform that helps businesses manage their vendor relationships and procurement processes, offering tools for vendor management, contract management, and spend analysis.

Hi!

I got tired of setting up tools I can't explain to a team in a few words like sops or git-crypt, just to store few files with environment variables or secrets, so I built lockenv as a simple alternative.

It's basically a password-protected vault file you commit to git. No gpg keys, no cloud, just lockenv init, set a password, and lock/unlock the secrets.

This tool integrates with OS keyring, so you're not typing passwords constantly. Should work on Mac/Linux/Windows, but I tested it only on linux so far.

I am not trying to replace any mature / robust solution, just making small tool for simple cases, where I want to stop sharing secrets via slack.

Feel free to try, thank you!

Hey HN,

I'm a solo developer and kept running into the same problem: I'd want Claude CLI to work on multiple tasks at once, but locally I could only run one instance at a time. So I built The Box.

It lets you spin up isolated sandbox environments in the cloud and run Claude CLI agents in parallel. You write the prompt, pick a GitHub repo, and it handles the rest – creates a branch, does the work, and opens a PR.

The core workflow: - Connect your GitHub repos - Create tasks with prompts - Claude CLI runs in isolated sandboxes - Get notified when done (browser push or Telegram) - Review and merge PRs

Tech stack: Go (Fiber) for backend services, Next.js for frontend, PostgreSQL, Redis for signaling, RabbitMQ for task queue. Workers run Claude CLI in Docker containers.

Currently free to use (with limits) while I finish payment integration. Would love feedback from anyone who's tried to scale their AI coding workflow.

https://the-box.dev

Each AI has strengths - Claude reasons well, Gemini handles long context, Codex integrates with GitHub. But switching between them means losing context.

Built HiveTechs: one workspace where Claude Code, Gemini CLI, Codex, DROID, and 7 others run in integrated terminals with shared memory.

Also added consensus validation - 3 AIs analyze independently, 4th synthesizes.

Real IDE with Monaco editor, Git, PTY terminals. Not a wrapper.

Looking for feedback: hivetechs.io

Beelines is a cooperative puzzle game where players work together to guide a swarm of bees through a series of obstacles and challenges. The game emphasizes teamwork, problem-solving, and strategic thinking as players navigate the intricate beehive environments.

Hi HN! I've been building ReadyKit, an open-source SaaS boilerplate that handles all the hard parts: multi-tenant workspaces, Stripe billing, OAuth + MFA authentication, and a production-ready stack.

Built with Python/Flask, PostgreSQL, Redis, and Vue 3, it's designed for indie makers and teams who want to ship SaaS products fast. Clone, configure your OAuth and Stripe keys, and you're running in 5 minutes.

Features include automatic query scoping for workspace isolation, audit logs, role-based access, and a modern UX kit. MIT licensed and free forever.

GitHub: https://github.com/level09/readykit

DskDitto is a small CLI utility that rapidly scans your disk for duplicates wasting disk space. It’s written in Golang and provides a sleek TUI to interactively manage file dups. It’s very fast and capable but the project is still somewhat in its infancy. If any one wishes to become a contributor please reach out. Feedback welcome. Thanks :-)

This article describes the creation of a Traveling Salesman Problem (TSP) game that was built in just 4 hours, despite being a decade in the making. The game allows users to interactively solve TSP instances and visualize the solutions.

Browser-based fighting game where you can play as Elon, Zuck, Jensen, Sam, or Sundar.

Built it over a couple weekends using Claude Code and Cursor, deployed on Vercel.

Qyavix is a tiny DOM runtime with a React-like state hook (`u`) and a simple render function (`r`). The entire framework is only 155 bytes (minified, no gzip).

I built it for benchmarks, experiments, and micro-UI systems. The official website (https://qyavix.pages.dev) is fully rendered using Qyavix itself.

Features: 155 bytes total size Zero dependencies Works with plain DOM nodes Hooks-like state system Fast re-rendering (full refresh) Pure JavaScript, no build tools needed

Would love feedback from the community!

Diesel-Guard is a tool that helps detect and prevent diesel engine tampering, allowing fleet managers to monitor engine performance and emissions compliance through real-time data analysis and notifications.