If I recall correctly, there were some papers which suggested that LLMs favor LLM-generated passages over human written ones. I can consistently reproduce this by asking Claude which code snippet it prefers: the one it generated in a different chat, or one that I refactored for my own needs and find more useful. It always picks its own :) I've also experienced that both Claude and Codex routinely include generated websites when I ask them to search for something. It also doesn't help that the web search tools that OAI and Anthropic have are deeply limiting: can't exclude keywords or domains.
Speaking of high quality publications, I wish we could get AnandTech back :( On some older blogs, I still stumble on dead links, and very few of them are on internet archive..
I predominantly used GitHub's product (it had integrations for VS, VS code, jetbrains), and Supermaven. Later, I tried one of the earlier Cursor versions as well.
I've used auto-complete back in 2022-2024 or so and really liked it. At one point, had to code offline and realized the speed up was mostly just a placebo in terms of productivity. I don't expect for auto-complete to have changed much, but since I don't delegate large tasks to agents, I've thought of trying it out again.
I'd say my experience is different. Even from people whose communication writing I didn't find that useful, they seem to have a better frame of mind than LLMs do. Though, I never encountered people like the examples you gave.
That's interesting. You're saying speed reading helps you grasp information density of text?
As someone who hasn't practiced speed reading, how does that happen? Is it something about the way your brain tries to connect ideas from different parts of the text? Or the redundancy making the signal more stable?
I don't think it's egoistical. I understand it's often uncomfortable to compare people by their intelligence, but by many measures of 'smart', people here have it, more often than not.
I completely agree. I've done a similar experiment on this rather young HN account and it was already able to deduce some things that I never explicitly stated. It probably doesn't require much more than a megabyte of someone's Slack messages or emails to build a profile on them, and there's much more data out there than that. People can be linked by their footprints in big tech products, or more crudely by techniques like stylometry, which is fully accessible to foreign governments. LLMs will likely enable even more aggressive techniques for linking people's public data, let alone to analyze it.
I think of it as, we've had a hurdle where computers were too slow to organize the data humans produced, but have since crossed it. LLMs and CV also enable analysis of fuzzy data, which hasn't been possible before. This makes me uneasy, to say the least.
That, and we're also past the need for geniuses to keep grinding in a cave, in hopes of landing a patent.
People are far more empowered today, many more can work near the bleeding edge, and funding can be arranged in different ways than holding on to a patent.
I think we're not the target audience here. It's probably another type of vendor lock-in gamble, aiming for less tech-savvy folks, who rely on Cursor integrations, and to normalize the platform in their eyes.
Since colors are an activation of rods and cones, could we simulate them by stimulating the eye nerves directly? Not necessarily to see new colors, but to replicate the experience of sight? If we managed that, wouldn't it feel exactly the same as seeing something in nature that itches the back of the eye so nicely? I suppose this is entering the brain interface territory.
I envy your enthusiasm. I sincerely enjoyed being proficient at something that was hard to replace, and still feel pride for it. There's still avenues like that, but they've grown thinner and it's not as one-sided. I'm still very happy to be in this field and keep toiling away, but with less joy.
Wow, thank you for your input! The "alternation" proxy for difficulty is fascinating to me, doesn't feel like something I would have thought of right away. And, I guess I wasn't aware of how much thought goes into designing Sokobans :)
I think the crates trumping other complexity metrics isn't entirely obvious to me. For problem 15 in the OP's post, author says it was too expensive to compute at runtime in the browser. From a human perspective, it's not apparent why, as a large part of the solution is very repetitive. It feels as if there should be a more condensed representation for iterating over problems like that one.
If I may gauge your opinion on it, have you looked into MazeBench? It comes from LLM benchmarking circles, but seems to suggest a search space that's too difficult for LLMs, even with tools, to solve. Curious how much overlap the PS/MIS solvers would have with solving something like this.
Hmm. The push representation makes sense because solve progress is entirely dependent on it. And the movement state tree can be reduced to the push tree, which would only prune useless paths. The push tree can probably also be pruned for moves that leave to softlock, but I wonder whether it can be reduced to a different representation still. Push tree already requires us to maintain a mask of where we can move to, so it's not computationally free. I can imagine representing box pushes as every position we can push it to in the current setup, but that would also make it more computationally expensive.
I feel like there's an interesting tradeoff of storing/computing cheap representations vs exploring a smaller tree.
Got me curious: is there some way to approximate solvability of a puzzle in a certain time frame, or is that completely intractable?
Also, what counts as "complexity" in Sokoban puzzles. Does it plateau at a point, where board size/box count starts scaling the solving time more linearly?
I'd say about a third of software engineers whose blogs I stumble upon and end up liking aren't active on twitter. Their accounts typically have nothing posted for 3-4 years, but they're active on bluesky or mastodon.
Well, let's not normalize bad product design. Worse, let's not normalize pushing out broken projects that never get maintained. It's noise and breaks trust. I'd say the maintenance part is especially bad now, I hold very little trust that people will maintain the projects they share.
Sure, I completely understand that UI has different needs from a sim's perspective. Given that I haven't tried a sub sim before, I have yours bookmarked to try out :)
Not OP. I can't claim whether it's AI or not, just why it could possibly raise such concerns.
I think the UI elements and layout look very similar to how LLMs like to create them. It's hard to describe, but something about the rounded-edge, thick outline buttons equidistantly placed on the side bars, and heavily dependent on tabbed layouts in sub-menus. I'd argue there's parts where menus have too much empty space, which typically hints that a menu hasn't been thought out completely. It's also the most common type of game/dashboard view that LLMs are capable of: canvas in the middle with interactive buttons on the sides.
For an example of an immersive and good looking UI I'd look to something like Sunless Sea. It's a different type of game and is more narrative driven, but it doesn't have any of the more web-like UI qualities.
Ah I've been doing handoff manually by asking the model to do it. If Claude's handoff includes better context than its summaries, it's probably worth checking out.
I think the frequency view is true, but a bit over-simplified. We can force certain output features to be true on tasks where the output is directly measurable, e.g. code compiles, lean proof is valid, benchmarking CUDA.
I think we can at least partially put constraints on other tasks that look fuzzy to us now, but haven't figured out how yet.