HackerTrans
トップ新着トレンドコメント過去質問紹介求人

paladin314159

no profile record

投稿

A Tale of Two Production Bugs (Part 2)

ternarysearch.blogspot.com
1 ポイント·投稿者 paladin314159·4 か月前·0 コメント

A Tale of Two Production Bugs (Part 1)

ternarysearch.blogspot.com
2 ポイント·投稿者 paladin314159·4 か月前·0 コメント

Structured Outputs for LLMs

ternarysearch.blogspot.com
1 ポイント·投稿者 paladin314159·4 か月前·0 コメント

Distributed Game Servers in KFChess

ternarysearch.blogspot.com
2 ポイント·投稿者 paladin314159·5 か月前·0 コメント

Speculative Decoding in LLM Inference

ternarysearch.blogspot.com
2 ポイント·投稿者 paladin314159·5 か月前·0 コメント

Triton Language

ternarysearch.blogspot.com
2 ポイント·投稿者 paladin314159·5 か月前·0 コメント

Linear Representations and Superposition

ternarysearch.blogspot.com
18 ポイント·投稿者 paladin314159·5 か月前·0 コメント

Reflections on Using Claude Code

ternarysearch.blogspot.com
2 ポイント·投稿者 paladin314159·5 か月前·0 コメント

Quantization-Aware Distillation

ternarysearch.blogspot.com
7 ポイント·投稿者 paladin314159·5 か月前·0 コメント

LLM Quantization and NVFP4

ternarysearch.blogspot.com
1 ポイント·投稿者 paladin314159·5 か月前·0 コメント

Sparse File LRU Cache

ternarysearch.blogspot.com
52 ポイント·投稿者 paladin314159·5 か月前·11 コメント

Observations from Using Claude Code

ternarysearch.blogspot.com
1 ポイント·投稿者 paladin314159·6 か月前·0 コメント

Why Sam Altman was booted from OpenAI, according to new testimony

theverge.com
52 ポイント·投稿者 paladin314159·8 か月前·12 コメント

Torchcomms: A modern PyTorch communications API

pytorch.org
30 ポイント·投稿者 paladin314159·9 か月前·6 コメント

コメント

paladin314159
·5 か月前·議論
I echo this sentiment. Even though I'm having Claude Code write 100% of the code for a personal project as an experiment, the need for thinking hard is very present.

In fact, since I don't need to do low-thinking tasks like writing boilerplate or repetitive tests, I find my thinking ratio is actually higher than when I write code normally.
paladin314159
·8 か月前·議論
I've been doing this a fair amount recently, and way I manage it is: first, give the LLM the PDF and ask it to summarize + provide high-level reading points. Then read the paper with that context to verify details, and while doing so, ask the LLM follow-up questions (very helpful for topics I'm less familiar with). Typically, everything is either directly in the original paper or verifiable on the internet, so if something feels off then I'll dig into it. Through the course of ~20 papers, I've run into one or two erroneous statements made by the LLM.

To your point, it would be easy to accidentally accept things as true (especially the more subjective "why" things), but the hit rate is good enough that I'm still getting tons of value through this approach. With respect to mistakes, it's honestly not that different from learning something wrong from a friend or a teacher, which, frankly, happens all the time. So it pretty much comes down to the individual person's skepticism and desire for deep understanding, which usually will reveal such falsehoods.
paladin314159
·10 か月前·議論
> I think that, if you gave me the ability to search the pre-contest Internet and a week to prepare my submissions, I would be kind of embarrassed if I didn't get gold, and I'd find the contest to be rather less interesting than I would find the real thing.

I don't know what your personal experience with competitive programming is, so your statement may be true for yourself, but I can confidently state that this is not true for the VAST majority of programmers and software engineers.

Much like trying to do IMO problems without tons of training/practice, the mid-to-hard problems in the ICPC are completely unapproachable to the average computer science student (who already has a better chance than the average software engineer) in the course of a week.

In the same way that LLMs have memorized tons of stuff, the top competitors capable of achieving a gold medal at the ICPC know algorithms, data structures, and how to pattern match them to problems to an extreme degree.