5 ms·

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

by dirkc 3mo ago

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-06-12&until=2026-06-13 https://github.com/malisper/pgrust/commits/main/?since=2026-...

bakugo 3mo ago
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.
- coldtea 3mo ago
  And run them in test setups to try to find bugs. If you find some, fix them.
- wartywhoa23 3mo ago
  > reality doesn't seem to be an obstacle for vibe Went straight into my vault of brilliant quotes!
- dirkc 3mo ago
  The challenge is that more and more people are producing project like this - 1,000s of commits and > 200k lines of code - and saying it was carefully created using agent based workflows and not vibe coded.
  - HPsquared 3mo ago
    In that case they need to document the process and workflow, and demonstrate the care that was taken.
    - jarym 3mo ago
      Quite amusing we have decades of human written code much of it sub standard and yet no one demanded proof till now of Open Source projects having to ‘demonstrate’ anything. If ya don’t wanna use it, don’t. Simple.
      - HPsquared 3mo ago
        Maybe the principal maintainer can be trusted, but pull requests could do with some of that evidence.
      - jgilias 3mo ago
        I get what you’re saying and agree with the last sentence. Just wanted to touch on the “why” part. In the world of exclusively human written software the existence of the artefact itself (code, documentation) served as the proof that there’s someone with half a brain behind it. Now that’s not the case anymore. The conclusion stays though - it’s OSS, authors/maintainers have no obligation to anyone to do anything. Like it, use it, don’t like it, don’t use it. As for me, I’ve found that the community and activity proxies are still good.
        dirkc 3mo ago
        > As for me, I’ve found that the community and activity proxies are still good. Definitely still something to look into. A project I'm checking in on from time to time is https://github.com/emdash-cms/emdash/ https://github.com/emdash-cms/emdash/. It will be interesting to see how the project activity is unfolds? Are people using it in production. How many errors do they find. What do those fixes entail. What happens with the docs over time. Etc. I haven't had a change to look in depth, but based on a quick glance I'd say that the activity on the project seems like the tempo you'd expect of a similar open source project.
- aforwardslash 3mo ago
  One of the projects Im working on and off is a tamper-proof audit log, based on some PoC code I created almost 10 years go; unit and integration testing are good at preventing defects and regressions, but they will not guarantee your software will work. However, with the power of LLMs, one can easily use model checking (in my case with Quint) and/or other formal proof approaches to ensure the software conforms as specified. The result (in my opinion) is an implementation guided by a single human that is actually more trustworthy than manual human-made software using the traditional approach.
- mvanbaak 3mo ago
  > Vibe code was never meant to be reviewed. It was also never meant to hit production.
DuncanCoffee 3mo ago
The github cli has a command to query commits with a sorting asc/desc flag https://cli.github.com/manual/gh_search_commits 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/searching-commits#search-by-authored-or-committed-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 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-06-12&until=2026-06-12 https://github.com/malisper/pgrust/commits/main/?since=2026-... first commit: https://github.com/malisper/pgrust/commit/22113dc36b02973060764f945123b0c92229bc0e https://github.com/malisper/pgrust/commit/22113dc36b02973060...
- dirkc 3mo ago
  Thanks for all the info you've provided! Maybe I'm just being a little grumpy. If I really need to look into a repository, I clone it and use vanilla git command line tools to have a look. It's just annoying that the modern web UI from GitHub takes >1s second to load a page with 34 commits
egorfine 3mo ago
> 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.
EDM115 3mo ago
> 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=3646a73515a5e4ac7d0b7df88c61b180e1cabdb2+7099 https://github.com/malisper/pgrust/commits/?after=3646a73515...
su66u 3mo ago
[dead]
booksock 3mo ago
(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/ https://danluu.com/ai-coding/
- wrs 3mo ago
  Some of this post reminds me of a story I heard long ago from someone who had worked at a HW/SW company. They’d transferred an engineer from the ASIC design team to the OS kernel team, though he’d never been on a software team before. After a while the manager called him in for the following conversation: Manager: You’re doing amazing work — zero bugs in production! I’d like you to mentor the other SWEs on how to get their bug count down too. Engineer: We’re allowed to have bugs?
  - dcrazy 3mo ago
    Hardware engineers call them errata ;-)
    - ferrouswheel 3mo ago
      How many engineers does it take to fix a bug? Hardware Engineers: "None. We'll fix it in firmware." Firmware Engineers: "None. We'll fix it in software." Software Engineers: "None. We'll document it in the manual." Technical Writers: "None. The user can figure it out." etc.
      - chipotle_coyote 3mo ago
        While I get the joke, as a technical writer, you might be surprised how often I've found myself as a defacto QA engineer: Me: This is what you said it does, and this is what it actually seems to do. Which one is right? Engineer: Shit.
        3mo ago
skydhash 3mo ago
> 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/22113dc36b02973060764f945123b0c92229bc0e https://github.com/malisper/pgrust/commit/22113dc36b02973060...
- isatty 3mo ago
  Very smart. I like it.
jimbokun 3mo ago
You don’t. You trust that passing the regression tests means you are totally compatible with the original version.
gorgoiler 3mo ago
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.
- anhner 3mo ago
  What an incredibly bad take. "It's not open source because we have the source but not the thought process of the developer" - well then no project on this earth is truly open source by your definition.
  - dzaima 3mo ago
    Rather depends on definitions; GPL does contain: > The "source code" for a work means the preferred form of the work for making modifications to it. With that definition, there's definitely space for arguing that the AI tooling for modifying the code is necessary for the modification process to be sane therefore "preferable" for any human, if the code is "designed" (or lack of design thereof) around the idea of being AI-maintained. Otherwise, it's not source-code, it's not meaningfully-modifiable, it's basically equivalent to just decompiling a binary. (similarly-bad quality may of course be human-produced too, though then at least you have direct proof of it being the preferred form for at least one person - the author)
    - hedgedoops2 3mo ago
      Excellent point
tosti 3mo ago
I started by looking at the dependencies. Then I lost count, so I ran wc -l Cargo.lock 1467 Cargo.lock Easily over a thousand dependencies. And "rewritten in Rust" is supposed to be a good thing? I bet this doesn't even compile faster than the original.
- ChadNauseam 3mo ago
  Do you pick your databases based on how quickly they compile and how many dependencies they have? I normally chose based on factors like performance and reputation for reliability
  - ubercore 3mo ago
    Reputation for reliability can be directly impacted by thousands of upstream dependencies, though.
    - cestith 3mo ago
      True, but internal dependencies aren’t upstream. I care very little how a project is laid out on disk before it’s built unless I’m going to work on the source.
      - ubercore 3mo ago
        All the cargo deps would be "upstream", and pulled on build.
  - christophilus 3mo ago
    If a dependency gets compromised, that’s a problem. If you have thousands, you increase the odds vs if you have one.
    - panick21_ 3mo ago
      You can also depend on a lot of libraries that have potentially high quality rather then writing a lot yourself. The defense against compromised dependency can't be 'Ill write everything myself and do it with the same quality as the ecosystem'.
HumblyTossed 3mo ago
> 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.
- wtetzner 3mo ago
  So your solution is to just read through all 1M+ lines of code?
  - HumblyTossed 3mo ago
    And yours is to read through all 37000 commit messages?? don't be obtuse. Nobody needs to do either.
    - wtetzner 3mo ago
      This was already addressed: > But with LLMs generating 7101 commits in less than a month that isn't feasible. I don't think trying to understand LLM generated code is feasible for anything other than very small projects. IMO it's a big problem with using LLMs for coding. Sure, they can generate a bunch of stuff, but in some ways that just makes the real problems of software development even harder.
- deleted 3mo ago
  [deleted]

by dirkc 3mo ago

bakugo 3mo ago

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.

coldtea 3mo ago
And run them in test setups to try to find bugs. If you find some, fix them.
wartywhoa23 3mo ago
> reality doesn't seem to be an obstacle for vibe Went straight into my vault of brilliant quotes!
dirkc 3mo ago
The challenge is that more and more people are producing project like this - 1,000s of commits and > 200k lines of code - and saying it was carefully created using agent based workflows and not vibe coded.
- HPsquared 3mo ago
  In that case they need to document the process and workflow, and demonstrate the care that was taken.
  - jarym 3mo ago
    Quite amusing we have decades of human written code much of it sub standard and yet no one demanded proof till now of Open Source projects having to ‘demonstrate’ anything. If ya don’t wanna use it, don’t. Simple.
    - HPsquared 3mo ago
      Maybe the principal maintainer can be trusted, but pull requests could do with some of that evidence.
    - jgilias 3mo ago
      I get what you’re saying and agree with the last sentence. Just wanted to touch on the “why” part. In the world of exclusively human written software the existence of the artefact itself (code, documentation) served as the proof that there’s someone with half a brain behind it. Now that’s not the case anymore. The conclusion stays though - it’s OSS, authors/maintainers have no obligation to anyone to do anything. Like it, use it, don’t like it, don’t use it. As for me, I’ve found that the community and activity proxies are still good.
      - dirkc 3mo ago
        > As for me, I’ve found that the community and activity proxies are still good. Definitely still something to look into. A project I'm checking in on from time to time is https://github.com/emdash-cms/emdash/ https://github.com/emdash-cms/emdash/. It will be interesting to see how the project activity is unfolds? Are people using it in production. How many errors do they find. What do those fixes entail. What happens with the docs over time. Etc. I haven't had a change to look in depth, but based on a quick glance I'd say that the activity on the project seems like the tempo you'd expect of a similar open source project.
aforwardslash 3mo ago
One of the projects Im working on and off is a tamper-proof audit log, based on some PoC code I created almost 10 years go; unit and integration testing are good at preventing defects and regressions, but they will not guarantee your software will work. However, with the power of LLMs, one can easily use model checking (in my case with Quint) and/or other formal proof approaches to ensure the software conforms as specified. The result (in my opinion) is an implementation guided by a single human that is actually more trustworthy than manual human-made software using the traditional approach.
mvanbaak 3mo ago
> Vibe code was never meant to be reviewed. It was also never meant to hit production.

DuncanCoffee 3mo ago

The github cli has a command to query commits with a sorting asc/desc flag https://cli.github.com/manual/gh_search_commits 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/searching-commits#search-by-authored-or-committed-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 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-06-12&until=2026-06-12 https://github.com/malisper/pgrust/commits/main/?since=2026-... first commit: https://github.com/malisper/pgrust/commit/22113dc36b02973060764f945123b0c92229bc0e https://github.com/malisper/pgrust/commit/22113dc36b02973060...

dirkc 3mo ago
Thanks for all the info you've provided! Maybe I'm just being a little grumpy. If I really need to look into a repository, I clone it and use vanilla git command line tools to have a look. It's just annoying that the modern web UI from GitHub takes >1s second to load a page with 34 commits

egorfine 3mo ago

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

EDM115 3mo ago

> 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=3646a73515a5e4ac7d0b7df88c61b180e1cabdb2+7099 https://github.com/malisper/pgrust/commits/?after=3646a73515...

su66u 3mo ago

[dead]

booksock 3mo ago

(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/ https://danluu.com/ai-coding/

wrs 3mo ago
Some of this post reminds me of a story I heard long ago from someone who had worked at a HW/SW company. They’d transferred an engineer from the ASIC design team to the OS kernel team, though he’d never been on a software team before. After a while the manager called him in for the following conversation: Manager: You’re doing amazing work — zero bugs in production! I’d like you to mentor the other SWEs on how to get their bug count down too. Engineer: We’re allowed to have bugs?
- dcrazy 3mo ago
  Hardware engineers call them errata ;-)
  - ferrouswheel 3mo ago
    How many engineers does it take to fix a bug? Hardware Engineers: "None. We'll fix it in firmware." Firmware Engineers: "None. We'll fix it in software." Software Engineers: "None. We'll document it in the manual." Technical Writers: "None. The user can figure it out." etc.
    - chipotle_coyote 3mo ago
      While I get the joke, as a technical writer, you might be surprised how often I've found myself as a defacto QA engineer: Me: This is what you said it does, and this is what it actually seems to do. Which one is right? Engineer: Shit.
      - 3mo ago

skydhash 3mo ago

> 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/22113dc36b02973060764f945123b0c92229bc0e https://github.com/malisper/pgrust/commit/22113dc36b02973060...

isatty 3mo ago
Very smart. I like it.

jimbokun 3mo ago

You don’t. You trust that passing the regression tests means you are totally compatible with the original version.

gorgoiler 3mo ago

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.

anhner 3mo ago
What an incredibly bad take. "It's not open source because we have the source but not the thought process of the developer" - well then no project on this earth is truly open source by your definition.
- dzaima 3mo ago
  Rather depends on definitions; GPL does contain: > The "source code" for a work means the preferred form of the work for making modifications to it. With that definition, there's definitely space for arguing that the AI tooling for modifying the code is necessary for the modification process to be sane therefore "preferable" for any human, if the code is "designed" (or lack of design thereof) around the idea of being AI-maintained. Otherwise, it's not source-code, it's not meaningfully-modifiable, it's basically equivalent to just decompiling a binary. (similarly-bad quality may of course be human-produced too, though then at least you have direct proof of it being the preferred form for at least one person - the author)
  - hedgedoops2 3mo ago
    Excellent point

tosti 3mo ago

I started by looking at the dependencies. Then I lost count, so I ran wc -l Cargo.lock 1467 Cargo.lock Easily over a thousand dependencies. And "rewritten in Rust" is supposed to be a good thing? I bet this doesn't even compile faster than the original.

ChadNauseam 3mo ago
Do you pick your databases based on how quickly they compile and how many dependencies they have? I normally chose based on factors like performance and reputation for reliability
- ubercore 3mo ago
  Reputation for reliability can be directly impacted by thousands of upstream dependencies, though.
  - cestith 3mo ago
    True, but internal dependencies aren’t upstream. I care very little how a project is laid out on disk before it’s built unless I’m going to work on the source.
    - ubercore 3mo ago
      All the cargo deps would be "upstream", and pulled on build.
- christophilus 3mo ago
  If a dependency gets compromised, that’s a problem. If you have thousands, you increase the odds vs if you have one.
  - panick21_ 3mo ago
    You can also depend on a lot of libraries that have potentially high quality rather then writing a lot yourself. The defense against compromised dependency can't be 'Ill write everything myself and do it with the same quality as the ecosystem'.

HumblyTossed 3mo ago

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

wtetzner 3mo ago
So your solution is to just read through all 1M+ lines of code?
- HumblyTossed 3mo ago
  And yours is to read through all 37000 commit messages?? don't be obtuse. Nobody needs to do either.
  - wtetzner 3mo ago
    This was already addressed: > But with LLMs generating 7101 commits in less than a month that isn't feasible. I don't think trying to understand LLM generated code is feasible for anything other than very small projects. IMO it's a big problem with using LLMs for coding. Sure, they can generate a bunch of stuff, but in some ways that just makes the real problems of software development even harder.
deleted 3mo ago
[deleted]