salt4034

Yes, chess has been dealing with AI for decades at this point, and it's amusing/frustrating that so many other communities are deciding to re-discover everything from scratch, rather than just learn from the chess experience.

If CTF is a player-vs-player event, then AI should just be banned outright, otherwise it will devolve into AI-vs-AI, which is just not an interesting competition format, as we learned in chess. Compared to FIDE top events (which bans AI), only a tiny niche audience actually watches the Top Chess Engine Championship (AI-centered). It turns out what we care about is not whether chess can be solved by any means available, but what are the limits of the human mind in learning chess.

Pretty much all chess coaches/educators also warn against relying heavily on AI during learning; engines only give you an illusion of understanding.

If you're directly using AOSP, can't you just change the code to remove the check?

It's hard in general, but for instruct/chat models in particular, which already assume a turn-based approach, could they not use a special token that switches control from LLM output to user input? The LLM architecture could be made so it's literally impossible for the model to even produce this token. In the example above, the LLM could then recognize this is not a legitimate user input, as it lacks the token. I'm probably overlooking something obvious.

See this Reddit post for background: https://www.reddit.com/r/ClaudeAI/comments/1sdabux/hats_off_...

TLDR: The user got his filesystem corrupted on a forced reboot; native btrfs tools made the failure worse; the user asked Claude to autonomously debug and fix the problem; after multiple days of debugging, Claude wrote a set of custom low-level C scripts to recover 99.9% of the data; the user was impressed and asked Claude to submit an issue describing the whole thing.

Not sure how I feel about this. If Take Take Take becomes very large, and most current Lichess users eventually switch to using that platform's mobile apps and website (say, because it has a few nicer features, and it's perceived as open source anyways), couldn't TTT suddenly decide to cut ties and entrap the community into yet another closed garden? By that time, there may not be a meaningful Lichess community left for users to switch back.

The author of Claude Code himself mentioned this in a recent interview. If I recall correctly, he mentioned that the best programmers he knows have an understanding of the "layer below the layer", which I think it's a good way of putting it. You're a better C programmer if you understand assembly, and you're a better "vibe coder" if you can actually understand the LLM generated code.

Here's how academics do it:

> Sam Altman confirmed power was indeed a major constraint [1].

> [1]: Personal communication.

Or even better:

> Power is a major constraint (Sam Altman, personal communication, December 9, 2025).

This part is unclear; what exactly did you change? Are you saying that the LP relaxation has value 271.666, but, when you enforce integrality, Gurobi can actually find and prove optimality of a solution with value 218?

Were you really just solving LPs up to this point in the article? How can these intermediate LPs be so slow to solve (6+ years) and yet Gurobi is able to solve the integer-restricted problem?

I think that was an intermediate model. The author updated it, then Gurobi solved the new model to optimality (i.e., the bound became equal to the value of the best solution found).

> With this improved model, I tried again and after ~23 000 seconds, Gurobi solved it to optimality!

The most commonly used term for this is lazy constraints (https://support.gurobi.com/hc/en-us/articles/360013197972-Ho...).

In addition to the value of the best integer solution found so far, Gurobi also provides a bound on the value of the best possible solution, computed using the linear relaxation of the problem, cutting planes and other techniques. So, assuming there are no bugs in the solver, this is truly the optimal solution.

Maybe the sender edited the LinkedIn message? The email shows the original version, before the user edits.

> testers that don't flip properly

I think that's the point. It shows that people don't usually flip properly, leading to biased results.

Why lower quality? The money doesn't go to authors, editors or peer-reviewers.

If I recall, it was a bit more elaborate than that. One of the three seals was obvious and easy to restore (the paper between the door and wall). If all three were broken, it meant an unsophisticated intruder was in the room (e.g. his family members). If one of the seals was restored and the other two were broken, then it was a sophisticated intruder instead (e.g. the police).

If it helps, your response here doesn't feel similar to ChatGPT output.

I agree. Before finalizing the changes, the AI could show you the diff and ask "is this what you had in mind or would you like me to change anything else?"

Ideally before downloading the extension. However, with automatic updates, this is nearly useless. Malicious code can be injected at any time in the future, long after the user audits the code.

> Chrome should verify that the extension code matches the code in the repo (without an additional build/compile step - the repo should reflect the exact code being shipped in the extension).

To ensure that the code matches, Chrome servers could download the source code and build the extension themselves. This is what F-Droid does. For each version of the extension, they could also archive the source code they used to build it. Even if the repository gets rewritten or taken down later, the archive remains.

Film studios can use deepfakes to bring back actors who passed away. Whistle-blowers could use it to have video calls with journalists without being identified. Privacy-minded regular folks could use it to have a YouTube/Twitch channel without revealing their identity.

These are just a few good-faith applications, but I think the list goes on.