News for hackers. Stuff that matters.

MutedEstate45

Re:Code Review Can Be Better on Wednesday August 20, 2025 @09:52PM (#44968308)
Good to know! Never been a maintainer before so I thought that was required.
Re:Code Review Can Be Better on Wednesday August 20, 2025 @08:48PM (#44968015)
Agree with your pain points. One thing id add is GitHub makes you reapprove every PR after each push. As an OSS contributor it’s exhausting to chase re-approvals for minor tweaks.
Great work! Definitely feels a lot more technical than the typical internship project.
I'll look out for future iterations. Thanks and good luck with the paper.
Re:The Amaranth hardware description language on Wednesday August 06, 2025 @12:21AM (#44807607)
While Amaranth is notably Python-for-hardware, I think the real standout feature is that it all but eliminates the infamous simulation-vs-synthesis mismatch. Verilog can simulate perfectly yet explode in synthesis, but Amaranth omits non-synthesizable constructs and enforces explicit instantiation. The result: a design that passes simulation is far more likely to synthesize identically, averting costly back-end surprises. If you've ever been burned by Verilog's "works in sim, breaks in synthesis" gotchas, that philosophy alone makes Amaranth worth a look.
Re:Kitten TTS: 25MB CPU-Only, Open-Source Voice Model on Tuesday August 05, 2025 @11:58PM (#44807476)
The headline feature isn’t the 25 MB footprint alone. It’s that KittenTTS is Apache-2.0. That combo means you can embed a fully offline voice in Pi Zero-class hardware or even battery-powered toys without worrying about GPUs, cloud calls, or restrictive licenses. In one stroke it turns voice everywhere from a hardware/licensing problem into a packaging problem. Quality tweaks can come later; unlocking that deployment tier is the real game-changer.
Re:Open models by OpenAI on Tuesday August 05, 2025 @03:21PM (#44802952)
I think you're conflating real-time monitoring with data retention. Zero retention means OpenAI doesn't store user data, but they can absolutely still filter content, rate limit and block harmful prompts in real-time without retaining anything. That's processing requests as they come in, not storing them. The NYT case was about data storage for training/analysis not about real-time safety measures.
Re:Open models by OpenAI on Tuesday August 05, 2025 @01:37PM (#44801356)
True, but there's still a meaningful difference in friction and scale. With closed APIs, OpenAI can monitor for misuse, throttle abuse and deploy countermeasures in real-time. With open weights, a single prompt jailbreak or exploit spreads instantly. No need for ML expertise, just a Reddit post.

The risk isn’t that bad actors suddenly become smarter. It’s that anyone can now run unmoderated inference and OpenAI loses all visibility into how the model’s being used or misused. I think that’s the control they’re grappling with under the label of safety.

Re:Open models by OpenAI on Tuesday August 05, 2025 @01:18PM (#44801033)
The repeated safety testing delays might not be purely about technical risks like misuse or jailbreaks. Releasing open weights means relinquishing the control OpenAI has had since GPT-3. No rate limits, no enforceable RLHF guardrails, no audit trail. Unlike API access, open models can't be monitored or revoked. So safety may partly reflect OpenAI's internal reckoning with that irreversible shift in power, not just model alignment per se. What do you guys think?
Ah gotcha. Makes sense to get the benefits of modular adoption without the headaches. Nice approach.
The modular ERP/MES/QMS approach is interesting and challenges traditional manufacturing processes. Most manufacturers obsess over single source of truth. (I.e. ensuring a part number means exactly the same thing across planning, production, and quality systems.) On the one hand, breaking these into separate apps creates potential data consistency risks. On the other hand, it could enable much better adoption. Start with MES for shop floor visibility then add QMS for compliance later rather than massive all-in-one ERP implementations that often fail. Curious, how are you handling data consistency across modules? What's been the feedback from your current or potential customers on this approach versus traditional monolithic ERP systems?
Thanks. That Pareto trade-off is exactly what I'm trying to quantify not just qualify. For example, if I've got a $50 budget, what's the sweet spot?

Scenario A: 100 agents × GPT-4o-mini × 500 steps Scenario B: 500 agents × local Llama 3-8B × 1,000+ steps

A quick table like "X agents × Y model × Z steps → tokens, $, convergence score" in the README would let new users budget experiments without having to read the whole paper plus run expensive experiments just to discover basic resource planning.

Thanks for the clarification. That's a clean approach. I just stared your repo. Looking forward to seeing where sidequest.js goes :)
Re:How we made JSON.stringify more than twice as fast on Monday August 04, 2025 @04:24PM (#44790957)
I really like seeing the segmented buffer approach. It's basically the rope data structure trick I used to hand-roll in userland with libraries like fast-json-stringify, now native and way cleaner. Have you run into the bailout conditions much? Any replacer, space, or custom .toJSON() kicks you back to the slow path?
Really like your approach of using existing Postgres/MySQL instead of dragging in Redis. It feels genuinely drop-in, but still Sidekiq-class. I know it's a bit early to ask about production patterns, but I was curious: if the worker thread flood hits the same Postgres that serves the web API, how do the job-fetch queries avoid contending with OLTP traffic? Does Sidequest follow Oban's advisory-lock approach or use a different throttling strategy?
Re:Typed languages are better suited for vibecoding on Monday August 04, 2025 @12:53AM (#44782223)
The real win isn't static vs dynamic typing. It's immediate, structured feedback for LLM iteration. cargo check gives the LLM a perfectly formatted error it can fix in the next iteration. Python's runtime errors are often contextless ('NoneType has no attribute X') and only surface after execution. Even with mypy --strict, you need discipline to check it constantly. The compiler makes good feedback unavoidable.
Interesting approach, but I'm curious about the practical cost considerations. A 1,000-agent simulation could easily be hundreds of thousands of API calls. The repo recommends gpt-4o-mini over gpt-4 and supports local Llama models, but there's no guidance on the performance trade-offs.

Would love to see cost-per-experiment breakdowns and quality benchmarks across model tiers. Does a local Llama 3.1 8B produce meaningful economic simulations or do you need the reasoning power of frontier models? This could be the difference between $5 and $500 experiments.

Re:Python Testing MCP Server on Monday August 04, 2025 @12:34AM (#44782147)
I've built a couple of MCPs and what jumps out about this repo is the clean split into three MCP tools—unit, fuzz, and coverage—so an LLM can sequence tests just like any other commands. By keeping the AI layer thin and the orchestration declarative, you could swap in Hypothesis or mutation-testing backends without rewriting the workflow. It's a solid pattern for anyone grafting AI onto an existing unittest stack.
Re:Show HN: Mcp-use – Connect any LLM to any MCP on Monday August 04, 2025 @12:11AM (#44782050)
Thanks for the mention! I'm the author of Mcp-error-formatter, which was mentioned above. Exactly right about the client/server complexity. I've been working on this exact problem. Client-side heuristics can catch timeouts and HTTP codes, but nuanced business logic errors need server cooperation.

The interesting part is dual error representation: devs need full stack traces for debugging, but LLMs need clean structured metadata for retry decisions. Plus you want error telemetry flowing to observability systems.

Question for the mcp-use authors: How do you handle error propagation in multi-server setups? If Server A times out but Server B is healthy, does the agent know which server failed and whether to retry or switch servers? And are you capturing error patterns to identify flaky servers or consistently failing tool calls? The retry orchestration across multiple MCP servers seems like a really interesting problem.

Hi thanks for the suggestion! I think thats a great idea! I'll look into how to implement this

Show HN: Mcp-error-formatter – Cursor-style JSON errors for any MCP/LLM tool

https://github.com/bjoaquinc/mcp-error-formatter

Hi HN! Author here.When an LLM-powered tool call blows up, the model usually sees an opaque stack trace. It can’t tell whether to retry, give up, or suggest a fix, so users get “Something went wrong” or infinite retry loops.Cursor’s editor solved this by wrapping errors in a small, structured JSON envelope:``` Request ID: c90e… {"error":"ERROR_USER_ABORTED_REQUEST", "details":{"title":"User...

( Read More... | 2 comments | 2 points | on HN )

Show HN: System-info-now – Aggregate system debug data for LLM troubleshooting

https://github.com/bjoaquinc/system-info-now

system-info-now is a lightweight command-line utility that aggregates your system’s debugging data into a well-structured JSON snapshot. It scans your computer for a comprehensive set of details—from OS and hardware specifications to network configurations, running processes, and even language-specific diagnostics for Python and JavaScript. Currently, it supports macOS only, but Linux and...

( Read More... | no comments | 2 points | on HN )
Re:Ask HN: A tool to handle annoying testing related tasks? on Tuesday February 11, 2025 @01:46PM (#43016588)
Yeah ok that sounds really useful! Especially the sending test commands to other computers.
Re:Ask HN: Any Alternatives to Cursor? on Monday February 10, 2025 @11:42AM (#43002240)
Check out void, it's an open source alternative to Cursor and in early beta: https://github.com/voideditor/void/releases/tag/v1.0.0
Re:Ask HN: A tool to handle annoying testing related tasks? on Monday February 10, 2025 @09:51AM (#43000955)
Ohhh thats encouraging! Was it also for mock data generation or did you make it handle other annoying tasks?

Ask HN: A tool to handle annoying testing related tasks?

I’m building an internal tool that uses a local small language model to handle tasks related to testing that we find annoying like manually creating dummy data from schemas or TypeScript definitions, setting up dummy webworkers to proxy server calls for testing, and/or mapping API dependencies for integration tests, etc.I’m still at the early stages, but I was wondering if anyone else would...

( Read More... | 4 comments | 2 points | on HN )
Re:Two Programming-with-AI Approaches on Monday January 27, 2025 @06:28AM (#42839879)
I attempted the approach of having an AI write the code while I casually audited it, but the results didn’t work out well for me. It kept adding bugs and logical errors that were hard to find. I was using Cursor along with Claude 3.5 Sonnet, and perhaps my use case was too complex. What have you built using this methodology?
Great work! The visual elements are very impressive. Would you say this tool is suitable for prototyping, especially for someone with development experience but no prior AR experience?
Thanks for your suggestions, especially RocksDB! I’m gonna play around with it today. Do you have any ideas related to use cases? I was thinking something like dynamic RAG for transformers.js

Ask HN: Why Try RAG on the Client Side? Is Local-First RAG Practical?

Came across MeMemo, which runs Retrieval-Augmented Generation (RAG) directly on the client side using WebGPU. No server calls, full privacy, and faster responses—sounds great, but I’m wondering:What’s the catch? How do you scale vector search or manage embeddings locally? Can this handle complex use cases, or is it mostly for lightweight tasks? How do we navigate browser limitations, UX...

( Read More... | 2 comments | 2 points | on HN )

Older »