I wanted to build something real in Zig, and I was annoyed that Postman needed an account and an internet connection just to send a GET request. So I figured I'd make something I would actually use.

It kind of snowballed from there. 50,000+ lines later, it does requests, test assertions, collections, environments, CI/CD reports, import/export, and has a browser-based Web UI (`volt ui`). All in a single binary with zero external dependencies.

Some numbers:

  - Binary size: ~4 MB (Postman: ~500 MB)
  - Startup: 42ms (Postman: 3-8 seconds)
  - RAM idle: ~5 MB (Postman: 300-800 MB)
  - Dependencies: 0
  - Account required: No

For CI, you copy one binary and run `volt test`. No npm, no Docker, no runtime.

Why Zig? Honestly, I wanted an excuse to write a lot of Zig. But the explicit allocators, comptime, and cross-compilation from one machine made it practical to ship Linux/macOS/Windows from a single codebase with no external packages.

There's a CLI, a TUI with tabs and search, and a Web UI. It's not perfect but I use it daily and it hasn't crashed on me yet.

Site: https://api-volt.com Repo: https://github.com/volt-api/volt Benchmarks: https://github.com/volt-api/volt/blob/main/BENCHMARKS.md

Happy to answer questions about the Zig implementation, that's the part I'm most excited to talk about honestly.

Comments URL: https://news.ycombinator.com/item?id=47323484

Points: 5

# Comments: 0

But I wonder if we’re now at a point where that can’t really be the default anymore. If you’re building something new in 2025, whether it’s a product, internal tool, or even just a feature, maybe it should be designed from the ground up to be usable not just by a human clicking buttons, but by another system entirely. A model, a script, an orchestration layer - whatever you want to call it.

It’s not about being “AI-first” in the marketing sense. It’s more about thinking: can this thing I’m building be used by something else without needing a human in the loop? Can it expose its core functions as callable actions? Can its state be inspected in a structured way? Can it be reasoned about or composed into a workflow? That kind of thinking, I think, will become the baseline expectation - not just a “nice to have.”

It’s also not really that complicated. Most of the time it just means thinking in terms of well-structured APIs, surfacing decisions and logs clearly, and not baking critical functionality too deeply into the front-end. But the shift is mental. You start designing features as tools - not just user flows - and that opens up all kinds of new possibilities. For example, someone might plug your service into a broader workflow and have it run unattended, or an LLM might be able to introspect your system state and take useful actions, or you can just let users automate things with much less effort.

There’s been some early but interesting work around formalising how systems expose their capabilities to automation layers. One effort I’ve been keeping an eye on is the MCP. A quick summary is basically that It aims to let a service describe what it can do - what functions it offers, what inputs it accepts, what guarantees or permissions it requires -in a way that downstream agents or orchestrators can understand without brittle hand-tuned wrappers. It’s still early days, but if this sort of approach gains traction, I can imagine a future where this kind of “self-describing system contract” becomes part of the baseline for interoperability. Kind of like how APIs used to be considered secondary, and now they are the product. It’s not there yet, but if autonomous coordination becomes more common, this may quietly become essential infrastructure.

I don’t know. Just a thought I’ve been chewing on. Curious what other people think. Is anyone building things with this mindset already or are there good examples out there of products or platforms that got this right from day one?

Comments URL: https://news.ycombinator.com/item?id=44019872

Points: 3

# Comments: 1

You would assume if it was pure ai generated it would have the correct rate limit in the comments and the code .... but honestly I don't care and yeah I ran the read me through GPT to 'prettify it'. Arrest me.

Heuristics are never perfect and it's all iterative but it's all about understanding the underlying assumptions and taking the knowledge you get out of it with your own context. Probably could enhance it slightly by a run through an LLM with a prompt but I prefer to keep things purely statistical for now.

I wrote StarGuard to put that number in perspective based on my own methodology inspired with what they did and to fold a broader supply-chain check into one command-line run.

It starts with the simplest raw input: every starred_at timestamp GitHub will give. It applies a median-absolute-deviation test to locate sudden bursts. For each spike, StarGuard pulls a random sample of the accounts behind it and asks: how old is the user? Any followers? Any contribution history? Still using the default avatar? From that, it computes a Fake Star Index, between 0 (organic) and 1 (fully synthetic).

But inflated stars are just one issue. In parallel, StarGuard parses dependency manifests or SBOMs and flags common risk signs: unpinned versions, direct Git URLs, lookalike package names. It also scans licences—AGPL sneaking into a repo claiming MIT, or other inconsistencies that can turn into compliance headaches.

It checks contributor patterns too. If 90% of commits come from one person who hasn’t pushed in months, that’s flagged. It skims for obvious code red flags: eval calls, minified blobs, sketchy install scripts—because sometimes the problem is hiding in plain sight.

All of this feeds into a weighted scoring model. The final Trust Score (0–100) reflects repo health at a glance, with direct penalties for fake-star behaviour, so a pretty README badge can’t hide inorganic hype.

I added for the fun of it it generating a cool little badge for the trust score lol.

Under the hood, its all uses, heuristics, and a lot of GitHub API paging. Run it on any public repo with:

python starguard.py owner/repo --format markdown It works without a token, but you’ll hit rate limits sooner.

Please provide any feedback you can.

Comments URL: https://news.ycombinator.com/item?id=43962427

Points: 122

# Comments: 72

The problem is familiar: as agents get access to more tools, either you overload the system with static tool lists, or you hard-code the tools at design time. Both approaches hit scaling limits quickly.

What I’ve been exploring is letting agents discover and use tools dynamically. Instead of loading every tool into the system upfront, the agent could explore an external registry at runtime, inspect tool descriptions and parameters, and decide what to use based on its current goal.

There are a few workflows I’m testing:

Manual exploration: agent lists tools, inspects them, and selects what to use.

Fuzzy auto-selection: agent describes its goal, and the system suggests a matching tool.

External LLM-assisted selection: agent outsources tool selection to another agent or service, which queries the registry and recommends a tool.

Each of these has trade-offs. Manual exploration is transparent but slow. Fuzzy matching is faster but depends on query quality. External assistance can scale to complex environments but adds system complexity.

The goal is to move away from static APIs and let agents explore tools like a developer browsing an API catalog. Search, inspect, and use tools as needed, rather than loading them all upfront.

Open questions I’m still thinking about:

Should these workflows be combined, escalating from manual to auto-selection if needed?

Should the system suggest parameter defaults or usage examples?

Should I move from basic matching to semantic search?

Would chaining tools together unlock more complex workflows?

I've written up a more detailed research note here, if anyone's interested: https://github.com/m-ahmed-elbeskeri/MCPRegistry/tree/main

Would appreciate any feedback or experiences if you've explored similar patterns.

Comments URL: https://news.ycombinator.com/item?id=43609356

Points: 2

# Comments: 1