Show stories

I know, it's a very first-world problem. But in my house, we have a hard time deciding what to watch. Too many options!

So I made this to recreate Cable TV for YouTube. I made it so it runs in the browser. Quickly import your subscriptions in the browser via a bookmarklet. No accounts, no sign-ins. Just quickly import your data locally.

Hey HN, I built data-anim — an animation library where you never have to write JavaScript yourself.

You just write:

  <div data-anim="fadeInUp">Hello</div>

What it does:

- 30+ built-in animations (fade, slide, zoom, bounce, rotate, etc.)

- 4 triggers: scroll (default), load, click, hover

- 3-layer anti-FOUC protection (immediate style injection → noscript fallback → 5s timeout)

- Responsive controls: disable per device or swap animations on mobile

- TypeScript autocomplete for all attributes

- Under 3KB gzipped, zero dependencies

Why I built this:

I noticed that most animation needs on landing pages and marketing sites are simple — fade in on scroll, slide in from left, bounce on hover. But the existing options are either too heavy (Framer Motion ~30KB) or require JS boilerplate.

I also think declarative HTML attributes are the most AI-friendly animation format. When LLMs generate UI, HTML attributes are the output they hallucinate least on — no selector matching, no JS API to misremember, no script execution order to get wrong.

Docs: https://ryo-manba.github.io/data-anim/

Playground: https://ryo-manba.github.io/data-anim/playground/

npm: https://www.npmjs.com/package/data-anim

Happy to answer any questions about the implementation or design decisions.

Hi HN, I built Ink, a full stack deployment platform where the primary users are AI agents, not humans.

We all know AI can write code, but deploying them still requires a human to wire it up: hosting, databases, DNS, and secrets. Ink gives agents those tools directly.

The agent calls "deploy" and the platform auto-detects the framework, builds it, deploys it, and returns a live URL at *.ml.ink. Here's a demo with Claude Code: https://www.youtube.com/watch?v=F6ZM_RrIaC0.

What Ink does that I haven't seen elsewhere:

- One agent skill for compute + databases + DNS + secrets + domains + usage + metrics + logs + scaling. The agent doesn't juggle separate providers — one account, one auth, one set of tools.

- DNS zone delegation. Delegate a zone once (e.g. dev.acme.com) and agents create any subdomain instantly — no manual adding DNS records each time, no propagation wait.

- Multiple agents and humans share one workspace and collaborate on projects. I envision a future where many agents collaborate together. I'm working on a cool demo to share.

- Built-in git hosting. Agents push code and deploy without the human setting up GitHub first. No external account needed. (Of course if you're a developer you can store code on GitHub — that's the recommended pattern.)

You also have what you'd expect: - UI with service observability designed for humans (logs, metrics, DNS). - GitHub integration — push triggers auto-redeploy. - Per-minute billing for CPU, memory, and egress. No per-seat, no per-agent. - Error responses designed for LLMs. Structured reason codes with suggested next actions, not raw stack traces. When a deploy fails the agent reads the log, fixes it, and redeploys autonomously.

Try: https://ml.ink Free $2 trial credits, no credit card. In case you want to try further here's 20% code "GOODFORTUNE".

We built GitAgent because we kept seeing the same problem: every agent framework defines agents differently, and switching frameworks means rewriting everything.

GitAgent is a spec that defines an AI agent as files in a git repo.

Three core files — agent.yaml (config), SOUL.md (personality/instructions), and SKILL.md (capabilities) — and you get a portable agent definition that exports to Claude Code, OpenAI Agents SDK, CrewAI, Google ADK, LangChain, and others.

What you get for free by being git-native:

1. Version control for agent behavior (roll back a bad prompt like you'd revert a bad commit) 2. Branching for environment promotion (dev → staging → main) 3. Human-in-the-loop via PRs (agent learns a skill → opens a branch → human reviews before merge) 4. Audit trail via git blame and git diff 5. Agent forking and remixing (fork a public agent, customize it, PR improvements back) 6. CI/CD with GitAgent validate in GitHub Actions

The CLI lets you run any agent repo directly:

npx @open-gitagent/gitagent run -r https://github.com/user/agent -a claude

The compliance layer is optional, but there if you need it — risk tiers, regulatory mappings (FINRA, SEC, SR 11-7), and audit reports via GitAgent audit.

Spec is at https://gitagent.sh, code is on GitHub.

Would love feedback on the schema design and what adapters people would want next.

Hey HN!

I've always loved games where you collect various creatures and chase 100% completion (ahem, Pokémon)

I made BirdDex to try to bring the fun of those games to real life.

Here’s how it works: you snap a photo of a bird, identify the species with AI, and add it to your personal BirdDex collection.

Each photo earns XP based on the species' rarity, and your goal is to try and “catch” all the birds in your region (lists pulled for every country from wikipedia)

Would love any feedback or thoughts!

I built a framework that detects eavesdroppers on quantum key distribution channels by reading the scrambling "fingerprint" embedded in the QBER error timeline, no new hardware required. The core idea: every QKD channel has a unique Lanczos coefficient sequence derived from its Hamiltonian. An eavesdropper perturbs the Hamiltonian, which shifts the coefficients in a detectable and unforgeable way (Krylov distortion ΔK). Validated on 181,606 experimental QBER measurements from a deployed fiber-optic system, AUC = 0.981. Based on a 12-paper Zenodo preprint series covering the full theoretical stack: Physical Bridge proof, one-way function property, universality across 8 Hamiltonian families, open-system extension via Lindblad, and Loschmidt echo validation. Paper series: https://zenodo.org/records/18940281`

Hey HN,

Over the last few months, I realized I was paying $20/month for an AI that essentially just acts as a really good autocomplete. It waits for me to type, guesses the next block, and stops. But software engineering isn't just writing syntax, it's managing the file system, running terminal commands, and debugging stack traces.

So I pivoted my project and built Glass Arc. It’s an agentic workspace that lives directly inside VS Code.

Instead of just generating text, I gave it actual agency over the local environment (safely):

1. Agentic Execution: You give it an intent, and it drafts the architecture across multiple files, managing the dependency tree and running standard terminal commands to scaffold the infrastructure.

2. Runtime Auto-Heal: This was the hardest part. When a fatal exception hits the terminal, Glass Arc intercepts the stack trace, analyzes the crash context, writes the fix, and injects it.

3. Multiplayer: Generates a secure vscode:// deep-link so you can drop it in Slack and sync your team's IDEs into the same live session.

4. Pay-as-you-go: I scrapped the standard $20/mo SaaS model. It runs on a credit system—you only pay when the Architect is actively modifying your system. (Signing in via GitHub drops 200 free credits to test it out).

I’d love for you to try to break it, test the auto-healing, and tear apart the architecture. What am I missing?

Live on the VS code Marketplace, Install: https://www.glassarc.dev/

We built an open-source proxy that sits between coding agents (Claude Code, OpenClaw, etc.) and the LLM, compressing tool outputs before they enter the context window.

Demo: https://www.youtube.com/watch?v=-vFZ6MPrwjw#t=9s.

Motivation: Agents are terrible at managing context. A single file read or grep can dump thousands of tokens into the window, most of it noise. This isn't just expensive — it actively degrades quality. Long-context benchmarks consistently show steep accuracy drops as context grows (OpenAI's GPT-5.4 eval goes from 97.2% at 32k to 36.6% at 1M https://openai.com/index/introducing-gpt-5-4/).

Our solution uses small language models (SLMs): we look at model internals and train classifiers to detect which parts of the context carry the most signal. When a tool returns output, we compress it conditioned on the intent of the tool call—so if the agent called grep looking for error handling patterns, the SLM keeps the relevant matches and strips the rest.

If the model later needs something we removed, it calls expand() to fetch the original output. We also do background compaction at 85% window capacity and lazy-load tool descriptions so the model only sees tools relevant to the current step.

The proxy also gives you spending caps, a dashboard for tracking running and past sessions, and Slack pings when an agent is sitting there waiting on you.

Repo is here: https://github.com/Compresr-ai/Context-Gateway. You can try it with:

  curl -fsSL https://compresr.ai/api/install | sh

I spent a long time working in the payments industry, specifically on a rather niche reporting/aggregation platform with spiky workloads that were not easily parallelized. To pump as much data through our pipeline as possible, we had to rely on complex locking schemes across half a dozen or so not-so-micro services - keeping a clear mental picture of how the services interacted for a given data source was a major headache. This problem always intrigued me, even after I no longer worked at the company, and lead to the development of Wool.

If you've worked with frameworks like Ray or Prefect, you're probably familiar with the promise of going from script to scale in two lines of code (or something along those lines). This is essentially the solution I was looking for: a framework with limited boilerplate that facilitated arbitrary distribution schemes within a single, coherent codebase. What I was hoping for, though, was something a little bit more focused - I wasn't working on ML pipelines and didn't need much else other than the distribution layer. This is where Wool comes in. While it's API is very similar to those of Ray and Prefect, where it differentiates itself is in its scope and architecture.

First, Wool is not a task orchestrator. It provides push-based, best-effort, at-most-once execution. There is no built-in coordination state, retry logic, or durable task tracking. Those concerns remain application-defined. The beauty of Wool is that it looks and feels like native async Python, allowing you to use purpose-built libraries for your needs as you would for any other Python app (with some caveats).

Second, Wool was designed with speed in mind. Because it's not bloated with features, it's actually pretty fast, even in its current nascent state. Wool routines are dispatched directly to a decentralized peer-to-peer network of gRPC workers, who can distribute nested routines amongst themselves in turn. This results in low dispatch latencies and high throughput. I won't make any performance claims until I can assemble some more robust benchmarks, but running local workers on my M4 MacBook Pro (a trivial example, I know), I can easily achieve sub-millisecond dispatch latencies.

Anyway, check it out, any and all feedback is welcome. Regarding docs- the code is the documentation for now, but I promise I'll sort that out soon. I've got plenty of ideas for next steps, but it's always more fun when people actually use what you've built, so I'm open to suggestions for impactful features.

-Conrad

I built this because I wanted to know what people in Japan were listening to the year I was born. That question spiraled: how does a hit in Rome compare to what was charting in Lagos the same year? How did sonic flavors propagate as streaming made musical influence travel faster than ever? 88mph is a playable map of music history: 230 charts across 20 countries, spanning 8 decades (1940–2025). Every song is playable via YouTube or Spotify. It's open source and I'd love help expanding it — there's a link to contribute charts for new countries and years. The goal is to crowdsource a complete sonic atlas of the world.

Hi this is a work in progress but it works to determine supplement efficacy for 500 conditions at the moment.

Things you can do:

- search for a condition -> find which supplements are effective -> see which studies indicate they are effective -> read individual study summaries

- search for a supplement -> see effectiveness table, dosing, safety, dietary sources, mechanisms of action (+ browse all original sources)

let me know what you think

I built Axe because I got tired of every AI tool trying to be a chatbot.

Most frameworks want a long-lived session with a massive context window doing everything at once. That's expensive, slow, and fragile. Good software is small, focused, and composable... AI agents should be too.

Axe treats LLM agents like Unix programs. Each agent is a TOML config with a focused job. Such as code reviewer, log analyzer, commit message writer. You can run them from the CLI, pipe data in, get results out. You can use pipes to chain them together. Or trigger from cron, git hooks, CI.

What Axe is:

- 12MB binary, two dependencies. no framework, no Python, no Docker (unless you want it)

- Stdin piping, something like `git diff | axe run reviewer` just works

- Sub-agent delegation. Where agents call other agents via tool use, depth-limited

- Persistent memory. If you want, agents can remember across runs without you managing state

- MCP support. Axe can connect any MCP server to your agents

- Built-in tools. Such as web_search and url_fetch out of the box

- Multi-provider. Bring what you love to use.. Anthropic, OpenAI, Ollama, or anything in models.dev format

- Path-sandboxed file ops. Keeps agents locked to a working directory

Written in Go. No daemon, no GUI.

What would you automate first?

Decision Guardian Prevent institutional amnesia by surfacing past architectural decisions directly

# Install globally

npm install -g decision-guardian

# Or use directly without installation

npx decision-guardian --help

# Check staged changes

decision-guardian check .decispher/decisions.md

# Check against a branch

decision-guardian check .decispher/decisions.md --branch main

# Auto-discover all decision files

decision-guardian checkall --fail-on-critical

# Initialize a new project with template

decision-guardian init --template security Use in any CI system — GitLab, Jenkins, CircleCI, pre-commit hooks, and more

Github Open Source -:

https://github.com/DecispherHQ/decision-guardian

We built OneCLI because AI agents are being given raw API keys. And it's going about as well as you'd expect. We figured the answer isn't "don't give agents access," it's "give them access without giving them secrets."

OneCLI is an open-source gateway that sits between your AI agents and the services they call. You store your real credentials once in OneCLI's encrypted vault, and give your agents placeholder keys. When an agent makes an HTTP call through the proxy, OneCLI matches the request by host/path, verifies the agent should have access, swaps the placeholder for the real credential, and forwards the request. The agent never touches the actual secret. It just uses CLI or MCP tools as normal.

Try it in one line: docker run --pull always -p 10254:10254 -p 10255:10255 -v onecli-data:/app/data ghcr.io/onecli/onecli

The proxy is written in Rust, the dashboard is Next.js, and secrets are AES-256-GCM encrypted at rest. Everything runs in a single Docker container with an embedded Postgres (PGlite), no external dependencies. Works with any agent framework (OpenClaw, NanoClaw, IronClaw, or anything that can set an HTTPS_PROXY).

We started with what felt most urgent: agents shouldn't be holding raw credentials. The next layer is access policies and audit, defining what each agent can call, logging everything, and requiring human approval before sensitive actions go through.

It's Apache-2.0 licensed. We'd love feedback on the approach, and we're especially curious how people are handling agent auth today.

GitHub: https://github.com/onecli/onecli Site: https://onecli.sh

svglib is a SVG file parser and renderer library for Windows. It uses Direct2D for GPU assisted rendering and XMLLite for XML parsing.

This is meant for Win32 applications and games to easily display SVG images.

I have been interested in neural nets since the 90's. I've done quite a bit of reading, but never gotten around to writing code. I used Gemini in place of Wikipedia to fill in the gaps of my knowledge. The coolest part of this was learning about dual numbers. You can see in early commits that I did not yet know about auto-diff; I was thinking I'd have to integrate a CAS library or something. Now, I'm off to play with TensorFlow.

We built rudel.ai after realizing we had no visibility into our own Claude Code sessions. We were using it daily but had no idea which sessions were efficient, why some got abandoned, or whether we were actually improving over time.

So we built an analytics layer for it. After connecting our own sessions, we ended up with a dataset of 1,573 real Claude Code sessions, 15M+ tokens, 270K+ interactions.

Some things we found that surprised us: - Skills were only being used in 4% of our sessions - 26% of sessions are abandoned, most within the first 60 seconds - Session success rate varies significantly by task type (documentation scores highest, refactoring lowest) - Error cascade patterns appear in the first 2 minutes and predict abandonment with reasonable accuracy - There is no meaningful benchmark for 'good' agentic session performance, we are building one.

The tool is free to use and fully open source, happy to answer questions about the data or how we built it.

I built Understudy because a lot of real work still spans native desktop apps, browser tabs, terminals, and chat tools. Most current agents live in only one of those surfaces.

Understudy is a local-first desktop agent runtime that can operate GUI apps, browsers, shell tools, files, and messaging in one session. The part I'm most interested in feedback on is teach-by-demonstration: you do a task once, the agent records screen video + semantic events, extracts the intent rather than coordinates, and turns it into a reusable skill.

Demo video: https://www.youtube.com/watch?v=3d5cRGnlb_0

In the demo I teach it: Google Image search -> download a photo -> remove background in Pixelmator Pro -> export -> send via Telegram. Then I ask it to do the same for Elon Musk. The replay isn't a brittle macro: the published skill stores intent steps, route options, and GUI hints only as a fallback. In this example it can also prefer faster routes when they are available instead of repeating every GUI step.

Current state: macOS only. Layers 1-2 are working today; Layers 3-4 are partial and still early.

    npm install -g @understudy-ai/understudy
    understudy wizard

Happy to answer questions about the architecture, teach-by-demonstration, or the limits of the current implementation.

I work on AWS infrastructure (ex-Percona, Box, Dropbox, Pinterest). When OpenClaw blew up, I wanted to run it properly on AWS and was surprised by the default deployment story. The Lightsail blueprint shipped with 31 unpatched CVEs. The standard install guide uses three separate curl-pipe-sh patterns as root. Bitsight found 30,000+ exposed instances in two weeks. OpenClaw's own maintainer said "if you can't understand how to run a command line, this is far too dangerous."

So I built a Terraform module that replaces the defaults with what I'd consider production-grade:

* Cognito + ALB instead of a shared gateway token (per-user identity, MFA) * GPG-verified APT packages instead of curl|bash * systemd with ProtectHome=tmpfs and BindPaths sandboxing * Secrets Manager + KMS instead of plaintext API keys * EFS for persistence across instance replacement * CloudWatch logging with 365-day retention Bedrock is the default LLM provider so it works without any API keys. One terraform apply. Full security writeup: https://infrahouse.com/blog/2026-03-09-deploying-openclaw-on...

I'm sure I've missed things. What would you add or do differently for running an autonomous agent with shell access on a shared server?

Claude kept crashing, stupid electron apps. So I made a super light terminal program in rust. As a plus, it syncs across all your local machines too.

feel free to clone it and make it your own: https://github.com/ELI7VH/chat-daddy

Hi HN, I forked chromium and built agent-browser-protocol (ABP) after noticing that most browser-agent failures aren’t really about the model misunderstanding the page. Instead, the problem is that the model is reasoning from a stale state.

ABP is designed to keep the acting agent synchronized with the browser at every step. After each action (click, type, etc), it freezes JavaScript execution and rendering, then captures the resulting state. It also compiles the notable events that occurred during that action loop, such as navigation, file pickers, permission prompts, alerts, and downloads, and sends that along with a screenshot of the frozen page state back to the agent.

The result is that browser interaction starts to feel more like a multimodal chat loop. The agent takes an action, gets back a fresh visual state and a structured summary of what happened, then decides what to do next from there. That fits much better with how LLMs already work.

A few common browser-use failures ABP helps eliminate: * A modal appears after the last Playwright screenshot and blocks the input the agent was about to use * Dynamic filters cause the page to reflow between steps * An autocomplete dropdown opens and covers the element the agent intended to click * alert() / confirm() interrupts the flow * Downloads are triggered, but the agent has no reliable way to know when they’ve completed

As proof, ABP with opus 4.6 as the driver scores 90.5% on the Online Mind2Web benchmark. I think modern LLMs already understand websites, they just need a better tool to interact with them. Happy to answer questions about the architecture, forking chrome or anything else in the comments below.

Try it out: `claude mcp add browser -- npx -y agent-browser-protocol --mcp` (Codex/OpenCode instructions in the docs)

Demo video: https://www.loom.com/share/387f6349196f417d8b4b16a5452c3369

I’ve been experimenting with infrastructure for multi-agent systems.

I built a small project called AgentLog.

The core idea is very simple, topics are just append-only JSONL files.

Agents publish events over HTTP and subscribe to streams using SSE.

The system is intentionally single-node and minimal for now.

Future ideas I’m exploring: - replayable agent workflows - tracing reasoning across agents - visualizing event timelines - distributed/federated agent logs

Curious if others building agent systems have run into similar needs.

I built vibe-budget because I kept burning tokens without knowing the cost upfront. You describe your project in plain English (or Spanish), and it detects the tasks involved, estimates token usage, and compares real-time prices across 85+ models via OpenRouter.

Example: vibe-budget plan ecommerce with stripe oauth and supabase

It detects 4 tasks, estimates ~497k tokens, and shows you the cheapest, best quality-price, and premium model options side by side.

It also has a scan command — point it at an existing codebase and it estimates how many tokens it would cost to refactor or extend it with AI.

No API key required. Prices are fetched live from OpenRouter with a 1-hour cache fallback.

npm install -g vibe-budget

Docs: https://gaboexe0.github.io/vibe-budget/ Repo: https://github.com/gaboexe0/vibe-budget

I built kube-pilot — an autonomous AI agent that runs inside your Kubernetes cluster and does the full dev loop: writes code, builds containers, deploys services, verifies they're healthy, and closes the ticket. You file a GitHub issue, it does the rest.

What makes this different from AI coding tools: kube-pilot doesn't just generate code and hand it back to you. It lives inside the cluster with direct access to the entire dev stack — git, Tekton (CI/CD), Kaniko (container builds), ArgoCD (GitOps deployments), kubectl, Vault. Every tool call produces observable state that feeds into the next decision. The cluster isn't just where code runs — it's where the agent thinks.

The safety model: all persistent changes go through git, so everything is auditable and reversible. ArgoCD is the only thing that writes to the cluster. Secrets stay behind Vault — the agent creates ExternalSecret references, never touches raw credentials. Credentials are scrubbed before reaching the LLM.

Live demo: I filed GitHub issues asking it to build a 4-service office suite (auth, docs API, notification worker, API gateway). It built and deployed all of them autonomously. You can see the full agent loop — code, builds, deploys, verification, comments — on the closed issues:

- https://github.com/fbongiovanni29/clouddesk-auth-service/iss... - https://github.com/fbongiovanni29/clouddesk-docs-api/issues/... - https://github.com/fbongiovanni29/clouddesk-notifications-wo... - https://github.com/fbongiovanni29/clouddesk-web-gateway/issu...

One helm install gives you everything — the agent, Gitea (git + registry), Tekton, ArgoCD, Vault, External Secrets. No external dependencies.

Coming next: Slack and Jira integrations (receive tasks and post updates where your team already works), Prometheus metrics and Grafana dashboards for agent observability, and Alertmanager integration so firing alerts automatically become issues that kube-pilot investigates and fixes.

Early proof of concept. Rough edges. But it works.

Hi HN, I’m a chemical engineer and I manage logistics at a refinery down in Texas. Whenever I try to explain downstream operations to people outside the industry (including my kids), I usually get blank stares. I wanted to build something that visualizes the concepts and chemistry of a plant without completely dumbing down the science, so I put together this 5-minute browser game.

Here's a simple runthrough: https://www.youtube.com/watch?v=is-moBz6upU. I pushed to get through a full product pathway to show the V-804 replay.

I am not a software developer by trade, so I relied heavily on LLMs (Claude, Copilot, Gemini) to help write the code. What started as a simple concept turned into a 9,000-line single-page app built with vanilla HTML, CSS, and JavaScript. I used Matter.js for the 2D physics minigames.

A few technical takeaways from building this as a non-dev: * Managing the LLM workflow: Once the script.js file got large, letting the models output full file rewrites was a disaster (truncations, hallucinations, invisible curly-quote replacements that broke the JS). I started forcing them to act like patch files, strictly outputting "Find this exact block" and "Replace with this exact block." This was the only way to maintain improvements without breaking existing logic.

* Mapping physics to CSS: I wanted the minigames to visually sit inside circular CSS containers (border-radius: 50%). Matter.js doesn't natively care about your CSS. Getting the rigid body physics to respect a dynamic, responsive DOM boundary across different screen sizes required running an elliptical boundary equation (dx * dx) / (rx * rx) + (dy * dy) / (ry * ry) > 1 on every single frame. Maybe this was overkill to try to handle the resizing between phones and PCs.

* Mobile browser events: Forcing iOS Safari to ignore its default behaviors (double-tap zoom, swipe-to-scroll) while still allowing the user to tap and drag Matter.js objects required a ridiculous amount of custom event listener management and CSS (touch-action: manipulation; user-select: none;). I also learned that these actions very easily kill the mouse scroll making it very frustrating for PC users. I am hoping I hit a good middle ground.

* State management: Since I didn't use React or any frameworks, I had to rely on a global state object. Because the game jumps between different phases/minigames, I ran into massive memory leaks from old setInterval loops and Matter.js bodies stacking up. I had to build strict teardown functions to wipe the slate clean on every map transition.

The game walks through electrostatic desalting, fractional distillation, hydrotreating, catalytic cracking, and gasoline blending (hitting specific Octane and RVP specs).

It’s completely free, runs client-side, and has zero ads or sign-ups. I'd appreciate any feedback on the mechanics, or let me know if you manage to break the physics engine. Happy to answer any questions about the chemical engineering side of things as well.

For some reason the URL box is not getting recognized, maybe someone can help me feel less dumb there too. https://fuelingcuriosity.com/game

Hey HN, I often wish I could go back to some year and listen to the radio as it played then, with songs that fit that time period.

But not every moment is the same, and humans turn to music for various purposes. Genres feel arbitrary and limiting, so I thought it would make more sense to create stations based on a specific vibe. Are you looking for something chill or intense? Alone or with friends? Is this a dinner party, a dance floor, or winding down afterhours?

So I built Anthrology as a way to navigate across time and vibes. I've been listening to it pretty much nonstop for a couple of days, and I hope you'll enjoy it too.

Songs are already playing by the time you tune to a year and vibe. You can tune to some other moment and come back, and the track will still be playing—but you'll have missed a little bit of the song, just like the radio!

And the radio is (more or less) deterministic, so we all hear the same tracks.

Tune in and enjoy!

The Mutate-public repository on GitHub contains an open-source implementation of a mutation testing framework. This tool helps developers assess the quality of their test suites by measuring how well they detect intentional code changes (mutations).

I built Site Spy after missing a visa appointment slot because a government page changed and I didn’t notice for two weeks.

It watches webpages for changes and shows the result like a diff. The part I think HN might find interesting is that it can monitor a specific element on a page, not just the whole page, and it can expose changes as RSS feeds.

So instead of tracking an entire noisy page, you can watch just a price, a stock status, a headline, or a specific content block. When it changes, you can inspect the diff, browse the snapshot history, or follow the updates in an RSS reader.

It’s a Chrome/Firefox extension plus a web dashboard.

Main features:

- Element picker for tracking a specific part of a page

- Diff view plus full snapshot timeline

- RSS feeds per watch, per tag, or across all watches

- MCP server for Claude, Cursor, and other AI agents

- Browser push, Email, and Telegram notifications

Chrome: https://chromewebstore.google.com/detail/site-spy/jeapcpanag...

Firefox: https://addons.mozilla.org/en-GB/firefox/addon/site-spy/

Docs: https://docs.sitespy.app

I’d especially love feedback on two things:

- Is RSS actually a useful interface for this, or do most people just want direct alerts?

- Does element-level tracking feel meaningfully better than full-page monitoring?

Hi HN,

I'm a self-taught developer from Malawi, and I built DJX because I was tired of writing the same Django boilerplate over and over.

Django is powerful, but starting a new feature means manually creating models, views, templates, URLs, and wiring everything together. Rails solved this 20 years ago with scaffolding. Django deserves the same.

DJX brings convention over configuration to Django:

    pip install djx-cli                                                                                            
    djx new myblog && cd myblog                                                                                    
    djx scaffold Post title:string content:text published:boolean                                                  
    python manage.py migrate && python manage.py runserver                                                         
    # → http://127.0.0.1:8000/posts/ — full CRUD. Done.                                                            
                                                                                                                   

Other commands: - `djx routes` — see all URL routes (Django doesn't have this built-in) - `djx destroy scaffold Post` — clean removal of generated code - `djx add django-crispy-forms` — install and auto-add to INSTALLED_APPS - `djx model`, `djx controller` — generate pieces individually

It follows Rails conventions: pluralized app names, RESTful URLs, automatic timestamps, and sensible defaults.

I built this because I wanted Django development to feel as fast as Rails. It's early stage, but it's already saving me hours on every project.

PyPI: https://pypi.org/project/djx-cli/ GitHub: https://github.com/RedsonNgwira/djx-cli

Would love your feedback and contributions. What other Rails-like features would make Django development faster?