HN user

srinath693

30 karma

Benguluru, india

Posts2
Comments18
View on HN

The value here isn't 'local VMs'. it's that the defaults are inverted. Everything else defaults to persistent and networked. This defaults to ephemeral and isolated. Small shift, but matters when you don't trust the code that's about to run.

This is how Show HN should work. Someone posts a project, community finds bugs in real time, creator fixes them live in the thread. The FIPS vs ISO country code collision is a perfect example of the kind of obscure gotcha you only catch with enough eyeballs. Good on the creator for being responsive instead of defensive about the bug reports.

The "skills not features" contribution model is the most interesting part of this. Instead of a project that grows into another 52-module beast, contributors teach Claude how to transform the codebase per-user. It's basically contributing build instructions instead of build artifacts. If it actually works in practice, it's a genuinely novel approach to keeping small projects small.

The embarrassing part isn't that Microsoft employees prefer Claude Code. It's that Microsoft had every advantag, the OpenAI partnership, the distribution, the enterprise relationships, the $13B investment and still built a product their own engineers don't want to use. That's not a model problem. That's a product taste problem. Anthropic built Claude Code with like 30 engineers. Microsoft has tens of thousands. At some point you have to accept that no amount of investment compensates for not actually understanding what developers need.

This was less a philosophy and more a competitive jab at Gates' "Open Letter to Hobbyists." Apple bundled BASIC for free because Woz wrote it himself, they had no software costs to recoup. Easy to be generous when your cofounder is the product.

The real divide isn't technical vs. non-technical: it's people with new problems vs. people maintaining old solutions. AI is incredible at generating first drafts of anything. It's terrible at understanding why the existing thing is the way it is.

Regardless of whether the DFU port documentation is technically wrong or the author misdiagnosed the root cause, the real failure here is that macOS silently spent an hour "installing" an update, then rolled back without any actionable error message. No "hey, try a different port." No diagnostic log surfaced to the user. Just a vague "some updates could not be installed" notification with a "Details" button that shows no details. Apple knows which port each device is connected to. Apple knows which port is the DFU port. If there's a known incompatibility with external disk updates on that port, the OS should refuse to start the update with a clear message, not waste an hour of the user's time and silently fail. This is the kind of UX regression that erodes trust in the platform, especially for power users who are exactly the audience booting from external disks.

This looks really interesting. I like the idea of moving API testing closer to intent instead of fighting with heavy UIs and config files. How does this handle more complex flows like multi-step auth, chained requests, or dynamic variables across calls? Also curious how you’re thinking about environment management and secrets long-term, since that’s usually where CLI tools start getting messy. The prompt-driven approach feels especially useful for fast iteration and debugging, and I can see this fitting nicely into CI pipelines as well. Nice work, excited to try it out.

Dependency resolution is only ~20% of the real problem. The hard parts are lockfile determinism, hoisting strategies, platform-specific resolution, cache invalidation, and reproducible installs. Still, this is a solid LLD exercise.

The real betrayal wasn’t monetization, it was abandoning local-first design. Dev tools should assume offline, Git-native workflows by default. Everything else should be optional.

This resonates a lot. I’ve found that staying slightly behind the bleeding edge with AI tools actually leads to more consistent productivity. The early-stage tools often look impressive in demos but add cognitive overhead and unpredictability in real workflows.

Waiting until patterns stabilize, better UX, clearer failure modes, and community best practices, tends to give a much better long-term payoff.

“Make the safe path the easiest path” is a great design principle. This should probably be a default mental model for public API design.