augusteo
What I'd add: the lesson about hallucinations should come early, not just in the RAG module. Kids (and adults) need to internalize "confident-sounding doesn't mean correct" before they get too comfortable. The gap between fluency and accuracy is the thing that trips everyone up.
What's interesting is how tongue twisters reveal what's phonetically tricky in each language. English struggles with s/sh transitions ("she sells seashells"). Indonesian targets the k-cluster combinations.
Curious if there's research on whether practicing tongue twisters in a second language actually helps with accent reduction, or if it's just party tricks.
This is a fair point, but I think there's a middle ground. DuckDB handles surprisingly large datasets on a single machine, but "surprisingly large" still has limits. If you're querying 10TB of parquet files across S3, even DuckDB needs help.
The question is whether Ray is the right distributed layer for this. Curious what the alternative would be—Spark feels like overkill, but rolling your own coordination is painful.
What's interesting is how the market solved it anyway—everyone just converged on Apple's designs because that's what users expected. Not through spec, but through sheer gravity.
I'm curious how the benchmarks handle non-determinism. Real GUIs have loading states, animations, popups that appear sometimes but not always. Does cuabench control for that, or is variance just part of the measurement?
Also interested in what "Windows Arena" tests specifically. Windows has so many edge cases - UAC prompts, driver install dialogs, random update notifications. Those feel like the hard mode for computer-use agents.
We've been building agent-based automation and the reliability problem is brutal. An agent can be 95% accurate on each step, but chain ten steps together and you're at 60% success rate. That's not usable.
Curious about the failure modes though. What happens when the verification itself is wrong? Like, the cart shows updated on screen but the verification layer checks a stale element?
The material science discussion in these comments is fascinating. Never thought about how the contact point geometry matters so much. Diamond tip makes intuitive sense for hardness, but then you need something it can spin on without scratching...
Google's had this weird situation where Android and ChromeOS overlap more every year. At some point maintaining two operating systems with converging feature sets seems wasteful.
My guess: ChromeOS probably survives for the education market where manageability matters more than capabilities. But for consumers? Android on a big screen with keyboard and mouse might just be good enough.
Really wanna use this for GMeet or Zoom!
And yes there's definitely still a lot to do. Security is def a big one.
Very exciting time to be alive.
One thing worth mentioning: if you're hitting this problem frequently, it might be worth reconsidering the query patterns themselves. We had a similar issue at work where we kept adding `.distinct()` everywhere, and eventually realized we were doing the filtering wrong upstream.
The PostgreSQL-specific `distinct(*fields)` with the ORDER BY restriction is one of those things that trips people up. The error message isn't great either. "SELECT DISTINCT ON expressions must match initial ORDER BY expressions" is technically correct but doesn't explain why or what to do about it.
Good call recommending Exists as the default approach. It's more explicit about intent too.
I wonder if the settlement amounts will ever become public. The Big Tobacco comparison keeps coming up, but those settlements were massive and included ongoing payments. Hard to imagine social media companies agreeing to anything similar without admitting some level of harm.
As a parent of two kids (8 and 6), I think about this constantly. We limit screen time pretty aggressively, but it's getting harder as they get older. The "attention-grabbing design" part isn't some conspiracy theory. These apps are explicitly optimized for engagement. The question is whether that optimization crosses a legal line.
Curious how the trial plays out with Zuckerberg on the stand.
JSX compiles to typed function calls. The type safety is in the component definitions, not the syntax.
The real question is whether video composition is actually hierarchical enough to benefit from JSX. For simple clips, probably overkill. But once you're layering talking heads, captions, b-roll, and transitions, the tree structure starts making sense.
The hardest part isn't the generation. It's the orchestration. Caching, retry logic, stitching outputs from multiple providers. A declarative layer that handles that automatically is genuinely useful.
But the interesting number here isn't accuracy. It's the $400 to reproduce top open-source performance. That's the part that matters for teams building internal tooling.
We've been running agents on proprietary codebases at work. The pain isn't model quality. It's customization. Most off-the-shelf agents don't understand your repo structure, your conventions, your test patterns. If you can fine-tune a 32B model on your own codebase for a few hundred dollars, that changes the economics completely.
But codebases changes everyday, so finetuning will have to be continuously done!
Probably not worth it versus something like Claude Code.
Curious whether anyone's tried this on non-Python codebases. Most SWE-Bench stuff is Python-heavy.
At work we built something from a 2-page spec in 4 months. The competing team spent 8 months on architecture docs before writing code. We shipped. They pivoted three times and eventually disbanded.
Planning has diminishing returns. The first 20% of planning catches 80% of the problems. Everything after that is usually anxiety dressed up as rigor.
The article's right about one thing: doing it badly still counts. Most of what I know came from shipping something embarrassing, then fixing it.
Curious about the performance issues Meegul mentioned. These simulations can be surprisingly compute-intensive once you add physics interactions between many entities. Would love to see the code if you ever open-source it.
Nice work.
We've been running agent workflows for a while now. The pattern that works: treat agents like junior team members. Clear scope, explicit success criteria, checkpoints to review output. The skills that matter are the same ones that make someone a good manager of people.
pglevy is right that many managers aren't good at this. But that's always been true. The difference now is that the feedback loop is faster. Bad delegation to an agent fails in minutes, not weeks. You learn quickly whether your instructions were clear.
The uncomfortable part: if your value was being the person who could grind through tedious work, that's no longer a moat. Orchestration and judgment are what's left.
trollbridge's point about scrapers using residential IPs and targeting authentication endpoints matches what we've seen. The scrapers have gotten sophisticated. They're not just crawling, they're probing.
The economics are broken. Running a small site used to cost almost nothing. Now you need to either pay for CDN/protection or spend time playing whack-a-mole with bad actors.
ronsor hosting a front-page HN project on 32MB RAM is impressive and also highlights how much bloat we've normalized. The scraper problem is real, but so is the software efficiency problem.
Moving countries is hard. Not just paperwork hard, but restarting-your-life hard. Credit history, professional networks, understanding how things actually work versus how they officially work.
If the mobility framework makes it meaningfully easier for skilled workers to move between India and Europe, that's significant. Not because of labor economics, but because talented people having more options is generally good for everyone.
The H1B system in the US has created a lot of anxiety and frustration. Competition for that talent pool seems healthy.
I don't know enough about this specific implementation to say whether "implemented Matrix" is accurate or marketing stretch. But the pattern of "we did X" blog posts that turn out to be "we did a demo of part of X" is getting tiresome across the industry.
The fix is boring: just be precise about what you built. "We prototyped a Matrix homeserver on Workers with these limitations" is less exciting but doesn't erode trust.
The interesting question isn't whether the tech was ready. It wasn't. The question is whether Amazon learned anything useful from the attempt.
Computer vision for retail checkout is a legitimate hard problem. Occlusion, similar-looking products, people changing their minds. I've worked on CV pipelines and the gap between "works in the demo" and "works at scale" is brutal.
My guess: they collected a ton of training data from those human reviewers. Whether they'll use it for a v2 or just write it off, who knows.
The core idea is simple. You separate what you can control from what you can't. Then you stop burning energy on the second category. Easier said than done, but the framework helps.
I keep coming back to "How to Think Like a Roman Emperor" as a practical companion to the original texts. It's Marcus Aurelius filtered through modern psychology, with concrete exercises instead of just principles.
The danger is treating Stoicism as emotional suppression. It's not. It's about choosing where to direct your attention and energy. That's genuinely useful when you're surrounded by systems designed to capture both.
There's something pure about text-based interfaces. No loading spinners, no JavaScript frameworks, no cookie banners. Just text.
When we started building a voice agent for inbound calls, the models were close but not quite there. We spent months compensating for gaps: latency, barge-in handling, understanding messy phone audio. A lot of that was engineering around model limitations.
Then the models got better. Fast. Latency dropped. Understanding improved. Suddenly the human-in-the-loop wasn't compensating, it was enhancing.
The shift was noticeable. We went from "how do we work around this limitation" to "how do we build the best experience on top of this capability." That's MMF in practice.
The timing question is real though. We started building before MMF fully existed for our use case. Some of that early work was throwaway. Some of it became the foundation. Hard to know in advance which is which.
The "serialize to localStorage on blur" approach onion2k mentions seems like it would catch most cases. But I've definitely lost form data in ways I couldn't explain. Mobile Safari is particularly bad about this.
The WHO recognition for low-resource settings is the kind of impact that matters.