alt Hacker NewsHow would one go about reviewing a piece of code like this?
One of the things I'd typically do is peek at the commit history. Seeing what people worked on and how they did it tends to say a lot about a project. But with LLMs generating 7101 commits in less than a month that isn't feasible. Even looking at a single day is way too much [1]. It probably also doesn't make sense since the commits content won't tell you much anyway.
ps. How do you easily get to the first commit in a repo on GitHub? Browsing commit history feels rather tedious
[1] - https://github.com/malisper/pgrust/commits/main/?since=2026-...
Replies
The github cli has a command to query commits with a sorting asc/desc flag
https://cli.github.com/manual/gh_search_commits
here's the docs with more syntax using the "before x date"
https://docs.github.com/en/search-github/searching-on-github...
there's also an advanced search page, but it does not support commits when filtering with dates
https://github.com/search/advanced
or you can bisect the date in the search widget, this is the first day with a commit
https://github.com/malisper/pgrust/commits/main/?since=2026-...
first commit:
https://github.com/malisper/pgrust/commit/22113dc36b02973060...
> How do you easily get to the first commit in a repo on GitHub?
You can use the syntax github.com/user/repo/commits/?after=last_commit_hash+number_of_commits-2 (-1 for the latest and -1 for the last)
ex : https://github.com/malisper/pgrust/commits/?after=3646a73515...
> One of the things I'd typically do is peek at the commit history. Seeing what people worked on and how they did it tends to say a lot about a project
I could not care less about any of this. Truth is code, as it is now. I don't care when (and certainly not by who) a bug got introduced, it's here, shut up and fix it.
In general (I’m not saying this is the case with this project) if you don’t have their prompt history and you can’t re-run the LLM “compilation” yourself, is it open source? It feels a bit more like those “source available” projects where you can read the code but don’t have access to the build system.
On the other hand, aside from the commit messages, one didn’t ever have access to the underlying thought process of human developers either, so maybe it’s not equivalent to say that secret prompts mean closed-source.
I started by looking at the dependencies.
Then I lost count, so I ran wc -l Cargo.lock
1467 Cargo.lock
Vibe code was never meant to be reviewed.
These rewrites are just test-driven development taken to the absolute extreme. Created under the hope that the existing tests are exhaustive and cover every relevant use case, such that if they all pass, the rewrite must be at least as good as the original. So just go with the vibes and burn tokens until they pass, and your job is done.
In practice, this is never true for any codebase above a certain level of complexity, especially not one as mature and widely used as Postgres. But reality doesn't seem to be an obstacle for vibe coders.
You don’t. You trust that passing the regression tests means you are totally compatible with the original version.
> ps. How do you easily get to the first commit in a repo on GitHub? Browsing commit history feels rather tedious
I usually check the history of a file not easily changed like .gitignore.
The first commit seems to be this one
https://github.com/malisper/pgrust/commit/22113dc36b02973060...
[dead]
> How would one go about reviewing a piece of code like this?
That's a wrong question. The right question is "why would one go about rewriting a piece of code in X". Once and if you find a good answer to that question, you will see the answer to your's.
(I'm working with malisper on pgrust),
I think the focus for projects like this is going to shift to reviewing the testing/fuzzing process instead of reviewing each commit (going much further than what the postgres regression/isolation/crash tests do).
related post from danluu: https://danluu.com/ai-coding/