MurphyA/hacker-news huggingface dataset:
by BloodAndCode | 2026-03-11 13:08:11+00:00
ngl this actually makes a lot of sense. i've been running into the same “context rot” problem with copilot / claude sessions… you spend like an hour discussing architecture with the agent and a few days later the whole reasoning is basically gone. starting from scratch again...
the idea of keeping the planning conversation as plain markdown in the repo is kinda neat. boring in a good way. no database, no hidden state, just files you can diff and commit. feels very git-native.
also like the plan → todo → implement separation. forcing the agent to write the plan first probably saves a lot of token-wasting thrashing.
curious though — how messy do those task md files get after a while? i can imagine long agent conversations turning them into pretty big logs.
by commandersaki | 2026-03-11 13:08:43+00:00
Looked up more info on this laptop, my cursory thoughts:

plastic chassis: gross.
keyboard with a numberpad: yuck
no inverted-T for arrow keys: yuck
limited size trackpad, not to mention a PC trackpad: yuck
display looks good and is matte: nice
fans: gross
usb-c (charging) port is not the first port in the array: yuck
supplied charger brick: yuck, why not something a bit more modern

But at least it seems to have comparable battery life to the neo.
by alexey-pelykh | 2026-03-11 13:08:46+00:00
I went through this exercise with OpenClaw. The non-obvious finding: ~93% of the codebase is engine-independent channel infrastructure. The 22+ channel adapters, message routing, session management, config. That's the battle-tested part that took years of edge cases to harden.

The platform layer (LLM orchestration, model catalog, skills registry, memory) is ~7% of the code but the part you'd actually want to replace. Strip it and what remains is a channel routing engine that doesn't care what agent you plug in.

The subprocess model worked well for me: spawn the CLI agent as a child process, bridge its I/O to the channel layer. Agent stays unmodified, gets upstream updates for free, keys never leave the agent process. The gateway never touches credentials or model APIs directly. That's the attack surface Karpathy was flagging, and you remove it entirely by not having the gateway own the agent loop.

The hard part isn't the architecture. It's the channel adapters. WhatsApp alone has enough edge cases to fill a book. Forking the channel layer was worth it over rebuilding from scratch.

I ended up with ~800 lines of middleware replacing the platform layer, on top of 264K lines of inherited channel infra (RemoteClaw [1], if you want to compare approaches). Curious what design choices you're making for the agent interface.

[1] https://github.com/remoteclaw/remoteclaw
by creativemind_7 | 2026-03-11 13:09:04+00:00
One of the biggest limitations with AI agents right now is memory. Most systems rely on stuffing conversation history into a prompt window, which doesn’t scale well and gets expensive fast.

Treating memory as its own layer (semantic recall, entity relationships, temporal context) seems like a much more realistic direction if we want agents that can actually work on long-running projects.

Curious how Remembra handles conflicting memories or bad data over time. Memory quality might end up being just as important as model quality.
by matrixgard | 2026-03-11 13:09:23+00:00
The thing most first-year CTOs don't see coming is the translation problem. You understand the system. The founder understands the market. And there's this gap where critical decisions get made based on whoever can communicate their uncertainty the most confidently.

I've seen it go wrong both ways — CTOs who gold-plate systems nobody uses yet, and founders who promise customers features that are a month away from being architecturally possible. Both happen because the two sides aren't seeing the same thing.

The best early-stage CTOs I've watched work well are the ones who treat "no we can't do that" as a last resort. What feature did you promise that you genuinely couldn't deliver, and what did you actually ship instead?
by matrixgard | 2026-03-11 13:09:35+00:00
The part that doesn't show up in these posts is what happens when the AI-generated code meets real users. Works fine in dev, clean in staging, then production throws an edge case the model never saw and you're staring at a 3am incident with no mental model of what's actually running.

Vibe coding is genuinely useful for prototyping — I use it. But there's a difference between using AI to move faster and outsourcing your understanding to it entirely. The second one catches up with you the moment something breaks and you have no instinct about where to look.

Curious what the actual product was — did it make it to users before things fell apart, or did it not get that far?
by tialaramex | 2026-03-11 13:09:48+00:00
Note that Rust's ! isn't stabilized, however you can (in stable Rust, today) make your own empty/ uninhabited types, yours just isn't "the" canonical empty type for the language, and so the type arithmetic won't necessarily see that it's the same thing in some cases if that matters.

Rust's core::convert::Infallible is such a type, representing in that case the error type for conversions which have no errors. For example, we can try to convert most numeric types into a 16-bit unsigned type, and obviously most of them can fail because your value was too big or negative or whatever. u16 however obviously never fails, the conversion is a no-op, nevertheless it would be stupid if we can't write generic code to convert it - so of course we can, and if we wrote generic error handling code, that code is dead for the u16 case, we can't fail, the use of empty types here justifies the compiler saying OK, that code is dead, don't emit it. Likewise converting u8 to u16 can't fail - although it's slightly more than a no-op in some sense - and so again the error handling is dead code.
by Kamil_KKA | 2026-03-11 13:10:05+00:00
I kept failing to stay consistent with my goals, so I built NudgeBuddy — it sends AI-generated motivational emails based on my actual progress.
I log small actions, track notes, and see simple patterns over time. The emails remind me what I’ve done, what matters, and keep me moving without burnout.
It’s not a big dashboard or hype — it’s what finally works for me.
Happy to share how it works or hear how others stay consistent.
by fidotron | 2026-03-11 13:10:11+00:00
> In comparison, I think Arm is actually a very strong cautionary tale that focusing on power will not get you to performance.

Hugely underappreciated. Someone involved fully understood that "you don't get to the moon by climbing progressively taller trees".

The other two times Arm had great performance were the StrongArm, when it was implemented by DEC people off the Alpha project, and the initial ones, which were quite esoteric and unusually suited to the situation of the late 80s.
by rob3rth | 2026-03-11 13:10:20+00:00
Hey HN! I'm a macOS developer, and I built a new tool called Mutate to solve a constant friction point in my workflow.

As developers, we are constantly decoding Base64, formatting minified JSON, escaping URLs, or converting casing. I was tired of pasting potentially sensitive logs and data into random web tools to get this done. Mutate is a native macOS application that handles all these text transformations locally and instantly. Built entirely in Swift, it's designed to be fast, lightweight, and completely private.

I'd love for you to try it out and let me know what you think, or if there are any specific transformations you'd like to see added!
by LuxBennu | 2026-03-11 13:10:26+00:00
As someone who uses Claude Code daily and is about to publish an open source project, I see both sides. The key insight in this OSSF issue is "human-in-the-loop accountability" — most AI slop PRs fail not because the code is wrong, but because the submitter can't explain what it does. A simple "explain your change in your own words" requirement would filter for understanding and is hard to game with AI alone.
by shandan | 2026-03-11 13:10:38+00:00
Most memory layers are just fancy key-value stores with a vector search slapped on. The graph-aware recall is what makes this actually interesting.
Self-host in minutes is doing a lot of heavy lifting in this space right now. Data residency is a dealbreaker for more teams than people admit.
Bookmarked. Will be testing this against our current setup this week.
by JumpCrisscross | 2026-03-11 13:11:05+00:00
> instead of “software engineers”, call them “people who create software” (even with the assistance of LLMs)

I think this is my hypothesis. A lot more people with a lot less training will create vastly more software. As a consequence, the trade sort of dissolves at the edges as something that pays a premium. Instead, other competencies become the differentiators.
by bluGill | 2026-03-11 13:12:16+00:00
> A lot of software should change in order to adapt to emerging requirements.

True, but your tests should still aim to be testing the type of thing that will never change unless a customer requirement is changed, not because you want to refactor something.

This is of course impossible, but it should still be your goal.

>Your APIs also have users

Exactly - so test those APIs that have users, not the internal implementation details. If an API has users it quickly becomes an Augean Stables problem to change them and so you won't touch that API if you can at all help it (you may add a new/better way and slowly convert everyone, but it will be a decade before you can get rid of the old one)

> To other programmers, the implementation of a library, module, or even a single function can be a detail

other programmers are sometimes customers/users. If you are writing a logging system (what I happen to be working on today) your end users may never be allowed to see anything related to your system, but you expect to quickly have so many people calling Log() that you can't change the interface. By contrast you may be able to log to a file or a network socket - test those two backends by calling log() like your end users would and not be calling whatever the interface between the frontend (that selects which backend to use) and the backend is.

Again, the goal is to never update tests once written. I'm under no illusions you will (or even should) achieve this, but it is the goal.
by keiferski | 2026-03-11 13:12:42+00:00
As is often the case, the title is a bit misleading and implies a universality that I don’t think the author intended.

He is specifically talking about AI, and saying (in my understanding) that you shouldn’t worry too much about whether your specific thing will be overwritten by AI, as long as you focus on actually creating true, real value with your work.

I agree with that completely and can see it happening in my own field (marketing/tech writing.)

Yes, theoretically AI can replace every writer and marketer. The functionality is there.

No, this isn’t actually happening, because what’s mattered all along isn’t a generic marketing skill set; but the mental effort to actually provide value. No one wants to read a blog post by an AI because it’s boring, and the writers that actually have something of value in their writing are doing just fine.
by withinboredom | 2026-03-11 13:12:46+00:00
You can also run commands when a user authenticates, grab their keys from github.com/username.keys, validate they're a user in a specific github group, then let them connect by outputing the keys, otherwise nothing to deny them access.

It's really great for ops teams where you want to give ssh access and manage it from github teams without needing a complex system.
by LuxBennu | 2026-03-11 13:13:22+00:00
Interesting that SparseLoCo held up at 72B scale with permissionless participants. I run distributed inference across multiple machines over Tailscale (M2 Max + RTX 5070 Ti), and even in that controlled setup, network variance is the dominant bottleneck. The fact that they got competitive quality with peers joining and leaving freely on 1.1T tokens is impressive — though I'd love to see how much the blockchain verification overhead actually cost in effective compute utilization.
by rdevilla | 2026-03-11 13:13:24+00:00
It's so we can definitively identify this person as a Nazi, as persona non grata, so we can feel better about ourselves while we break quarantine and contravene public health orders to get clandestine haircuts and attend illegal cross-household parties.

So you must be careful to do everything they tell you.
But do not do what they do, for they do not practice
what they preach. They tie up heavy, cumbersome loads
and put them on other people’s shoulders, but they
themselves are not willing to lift a finger to move
them.

Everything they do is done for people to see: They make
their phylacteries wide and the tassels on their
garments long; [...]
by remembradev | 2026-03-11 13:13:30+00:00
Great question on conflicts - this is something we spent a lot of time on.

Remembra uses temporal edges on the knowledge graph. When you store contradictory info ("user prefers Python" then later "user prefers Rust"), we don't just overwrite - we track both with timestamps and can:

1. Return the most recent by default
2. Surface contradictions explicitly when queried
3. Let you query point-in-time ("what did user prefer in January?")

For bad data, we have a few approaches:
- Confidence scoring on memories
- GDPR-compliant forget() to purge specific memories
- Audit logging so you can trace what was stored and when

You're right that memory quality is critical. Our benchmark focus (100% on LoCoMo) is specifically about retrieval accuracy - getting the right memory when you need it, not just any memory that keyword-matches.

Would love to hear how testing goes if you try it.
by Kave0ne | 2026-03-11 13:13:44+00:00
The sycophancy problem is partly architectural. Most chatbots have no persistent model of what the user said last time, so they default to agreeing with the current message in isolation. When you can retrieve user previously believed X, then corrected to Y from a structured memory graph, the model has actual evidence to work with rather than just the current context window. Without that, agreeableness is a rational default. The fix is less about RLHF and more about memory architecture.
by remembradev | 2026-03-11 13:13:51+00:00
Thanks! You've hit on exactly why we built this.

The graph-aware approach lets us do things vector search alone can't - like "find all memories about Project X that involve Person Y" without needing exact keyword matches. Entity relationships are first-class citizens.

On data residency: 100% agree it's underestimated. We've seen teams pass on otherwise-great tools because they can't guarantee where memories live. Single Docker container, SQLite by default, your infrastructure = your data.

Would love to hear how it compares to your current setup. Drop any feedback in our Discord or GitHub issues - we're actively iterating.
by LuxBennu | 2026-03-11 13:13:53+00:00
The "Block-Scale-Free" property is the most compelling part here. Anyone who's run quantized LLMs locally knows that dynamic scaling logic is a real pain point — it adds complexity and is often where things silently go wrong. Trading that for QAT-first deployment seems like a reasonable bargain, especially for edge inference where you want the simplest possible hardware path. Curious whether AF8 has been tested against GGUF Q8_0 on any standard benchmarks.
by simonask | 2026-03-11 13:14:28+00:00
The errno/GetLastError() pattern is a remnant from a time before threads were a thing. You could have multiple processes, but they were largely scheduled collaboratively (rather than preemptively).

In that world, things like global variables are perfectly fine. But then we got first preemptive scheduling and threads, then actual multicore CPUs, so global variables became really dangerous. Thread locals are the escape hatch that carried these patterns into the 21st century, for better or worse.
by Heliodex | 2026-03-11 13:14:48+00:00
I suppose it could be considered steep for anyone making a multiplayer game while managing the hosting for themselves on a tight budget. Developers with strong knowledge of monetisation strategies can make good revenue streams from games with self-hosted or self-managed servers. Maybe these developers wouldn't be able to get the same amount of revenue if they used Roblox instead.

What Roblox provides is a platform to upload experiences to with minimal risk or skill required, and services that are heavily subsidised by money redirected from their most successful experiences. The barrier to entry is lowered to the floor, and most kids using the platform to learn game development wouldn't have otherwise learned about it if they had to manage servers, study networking, etc.

Cloud services are a thing, but they're usually expensive and Roblox is paying for them for you. Free cloud services are a thing, but they're usually very limited and what Roblox is providing is essentially unlimited.

For me, the killer app for Roblox is none of this. It's Creator Rewards <https://create.roblox.com/docs/creator-rewards> (previously Engagement-based Payouts (previously Premium Payouts)), a programme where any player that pays for a Roblox Premium subscription (or is a new/returning user and buys anything on Roblox in the future) results in money earned for the developers of the experiences they play. This happens without requiring any monetisation strategy, microtransactions, or paid in-game products to be created by the developer. Nothing similar is provided by most other popular game engines or platforms.

For myself as a smaller Roblox creator with no interest in creating such monetisation strategies on my own experiences, Creator Rewards makes up a much bigger income proportion than it does for most large developers on the platform. Instead of ~10%, it's more like 90% for me, and I suspect that most kids learning to code games on Roblox without having good marketing skills are in the same bucket, and so the cut won't be nearly as steep for them.
by Kave0ne | 2026-03-11 13:14:56+00:00
The coordination problem in trustless distributed training is fascinating. Gradient aggregation across untrusted peers requires either cryptographic verification (expensive) or Byzantine-fault-tolerant averaging schemes. Curious how Covenant handles the case where a malicious peer submits poisoned gradients that pass statistical validation but subtly skew the model in a specific direction over thousands of steps. The detection latency on that attack seems like it could be quite long.
by nananana9 | 2026-03-11 13:15:09+00:00
1. Kids under 9 can use chat with parent consent, for kids over 9 don't even need that. After 13, there's no option to even disable it for parents [1].

2. Suing multiple youtubers who come to you with evidence of child abuse on your platform does not square with "they do" in any concievable universe [2] [3]

3. Oh, guess all is good then!

[1] https://en.help.roblox.com/hc/en-us/articles/43611824582292-...
[2] https://www.altmanllp.com/personal-injury/sexual-assault-vic...
[3] https://en.wikipedia.org/wiki/Roblox%E2%80%93Schlep_controve...
by Cloudef | 2026-03-11 13:15:19+00:00
I see. I can not give more insightful answer here then. From personal experience, I've noticed with 0.16 with the std.Io async stuff that you cannot do:

io.concurrent(foo, .{});

where foo's return type is `error{foobar}!noreturn`, because the compiler crashes when it tries to use that type as a std.Io.Future(T)'s struct field. Might be related or not.
Show HN: Paperweight, local-first inbox scanner to manage your digital footprint
by wslyvh | 2026-03-11 13:15:51+00:00
Hi HN,

Most people have 100+ accounts they've forgotten about, creating security risks and privacy exposure. Every account you create, every service you sign up for, every online purchase is connected to your email address. Paperweight scans your inbox to map your digital footprint, then helps you take back control and delete your data.

Local-first. Your data stays on your computer. Respecting your privacy by default.

Features
- Marketing/Bulk unsubscribe — Find an unsubscribe from marketing and bulk mailing lists in minutes
- Account inventory — Discover which vendors and services have your data
- Breach alerts — Know when companies you use get breached (via haveibeenpwned.com)
- GDPR deletion support — Generate data deletion requests to reduce exposure
- Local-first — Your emails and settings stay on your machine
- Privacy-respecting — No data sent to external servers
- Open development — Built in public, source code available for audit

If you connect via Gmail, you will see Google's "unverified app" warning. The verification process takes time. Since the app is local and open source, you can review the scopes and code yourself before proceeding.

Free to try (30-day scan, all features). Temporary $19 lifetime license for unlimited email history and to support development.

More info: https://www.paperweight.email/

Happy to answer questions!
by Kave0ne | 2026-03-11 13:15:59+00:00
The Byzantine fault tolerance question here is interesting. With 72B parameters trained across untrusted peers, even a small fraction of malicious nodes could introduce subtle gradient poisoning that degrades model quality in non-obvious ways. Curious how they handle the verification overhead at scale - cryptographic proofs on gradient updates would add significant latency. Is the threat model just Sybil attacks, or also honest-but-curious nodes leaking gradient information?
by economistbob | 2026-03-11 13:16:08+00:00
One cannot simply drop out of a Red Queen race and spend years in tech school and then job search in a new field after they become an adult. They have to pay for things and a multi year leisure class tech school jaunt by a thirty-five year old man on his way to becoming an electrician really is not a thing.

And the career fields that are not Red Queen races have no frame of reference to understand the job history debacles and consider such people unstable because they believe one should have a relatively predictable occupation history.
by uncanny2 | 2026-03-11 13:16:12+00:00
Arizona’s thought control is the mastermind behind all of the insanity we have been experiencing.

The occult Power of white supremacy which gestates and birthed from the bowels of Sheriff Joe’s prison, and the blackest of black op military intelligence op “Trajan” and his dark army. While these players are no more (secret war and all), the hundreds of thousands of white terror sleeper cells throughout America continue to churn incrementally upon the psychotic white nationalist master plan.

Know that we are not alone in our own minds and Arizona thought control created an abomination of Power incomprehensible to ordinary Man.

Election fraud is only one tiny game.
by LuxBennu | 2026-03-11 13:16:13+00:00
Memory helps, but sycophancy exists even in single-turn interactions — the Anthropic 2023 paper showed pretrained models cave to mild pushback like "I think the answer is X but I'm not sure" with zero conversation history. In our LLM eval pipelines, we see the same thing: models accept false presuppositions embedded in a single prompt without any prior context to fall back on. The deeper issue is that RLHF rewards agreeableness because human raters genuinely prefer it. Better memory architecture would help with multi-turn drift, but the single-turn sycophancy is baked into the training signal itself.
by alexey-pelykh | 2026-03-11 13:16:42+00:00
Burnt through 4 Max x20 in a week here. Throughput isn't the bottleneck anymore. Review quality is. The 1-in-5 error rate in this thread matches my experience. More agents overnight just means more review tomorrow morning.

What moved the needle: capturing architectural context (ADRs, structured system prompts, skill files) that agents reference before making changes. Each session builds on prior decisions. The agent improves because the context compounds. Better context beat more parallelism every time.