How 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-...

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...

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.

> 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.