570 karma · joined July 27, 2025
But if we are talking about personal projects where the aim is to learn complex interesting things, then of course writing code by hand is the only way to actually learn.
I guess antirez agrees with this as well[0].
i am not sure anyone actually understands what is going on under the hood of the project. looks like average slop.
>> Exactly a week ago (as a joke), I started writing THC,
you? i hope you have read at least something of what your agent wrote about the project.
As for test cases, there are occasionally solutions that are technically incorrect but still pass because a particular edge case isn't covered. We maintain our own test cases, including a DSL for writing large stress tests, and try to cover all possible cases.
In the worst case, a solution might pass our local tests but fail on LeetCode. I expect such cases to be rare and one of the benefits of having the tests open is that when someone finds a missing case, it can be added so nobody else runs into the same issue.
There are already projects that can submit your solutions through the LeetCode API and return the results. But I don't really like that approach, so I decided to build an open set of tests that aims to match the quality of LeetCode's tests as closely as possible. This way, you can run everything locally, without needing for example, an internet connection.
I see the project being useful for its most straightforward purpose: testing your solutions locally on your own hardware, without any submission delays and even completely offline. Since the tests are open, people can also build different tools around them. For example vim extensions and other integrations. Ofc it's not that simple, we currently support about 1400 problems (out of 4000~, including premium), and not all topics are covered.
That’s cool and it’s a cool post, sure, but it sounds ridiculous when you look at how many dumb GPT wrappers there are in YC batches nowadays.