[dirkc]

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

[bakugo]

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.

[dirkc]

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]

In that case they need to document the process and workflow, and demonstrate the care that was taken.

[jarym]

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.

[jgilias]

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]

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

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.

[HPsquared]

Maybe the principal maintainer can be trusted, but pull requests could do with some of that evidence.

[mvanbaak]

spec-driven development is pretty good at this

[dmitrygr]

> The challenge is that

Why is that a challenge? As long as they are open about this, all is OK.

[wartywhoa23]

> reality doesn't seem to be an obstacle for vibe

Went straight into my vault of brilliant quotes!

[aforwardslash]

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]

> Vibe code was never meant to be reviewed.

It was also never meant to hit production.

[coldtea]

And run them in test setups to try to find bugs.

If you find some, fix them.

[booksock]

(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/

[wrs]

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?

[jeltz]

Funny story but in my experience hardware engineers produce some of the worst software of the industry. Of course there must be some hardware engineers out there who do hood software but generally what they build are disasters.

[21asdffdsa12]

Honestly, i do not blame them for that though. The whole eco-system of in C- procedurally bitbang on some registers and read on others, until some circuit that might be there is coerced into doing work - often with faulty prototypes you have to rewire yourself, whos documentation is - non-existant-complete while having deadlines within deadlines. And the project-culture is just "aggregate" a layer, wrap the problem like a pearl in shellacks as the main abstraction.

[tormeh]

I bet it's being organized by project rather than product. Conway's law ensures such an org will create code around projects, not products, and that always ends horribly.

[jgilias]

I know it’s a typo, but I love the idea of “hood software” lol

[dcrazy]

Hardware engineers call them errata ;-)

[ferrouswheel]

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]

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.

[jval43]

Very carefully - and I mean extremely carefully - word it so that it describes what it does, while implying what it should do without confirming that it actually does that.

Also helps if you fix the bug or change the behavior, the docs are still technically correct. I'm only partially kidding, I swear I've seen this a million times in documentation I read.

[dmitrygr]

And what happens when your "tests" are also vibecoded. Right now all of these houses of cards reset on human-written tests. What happens without them?

[fpgaminer]

For large projects like this I think a hierarchical division of labor also helps.

If you first carefully define the overall architecture and thus individual high level components of the system, then you know which of those components are mission critical and which are commodity. Mission critical would be anything ensuring ACID, etc. That way, no matter what you farm out to LLMs, you can keep the majority of limited human focus on the far fewer mission critical components. If tests end up not being robust enough to catch all issues, at least they'll be isolated to commodity code where damage is limited to things like DoS, etc, and not code that could cause data loss.

I also think it's important to first define the _contracts_ on and between each of these components, and derive tests from those contracts. Partly because contracts more succinct and easier to reason about. And partly because Rust provides many tools to enforce contracts at compile time, reducing the need for tests (which themselves could end up subtly flawed). Contracts can be enforced through typing, private vs public APIs, etc. Newtypes are _incredibly_ powerful for both enforcing contracts and making footguns much less likely.

[andai]

Oh, I just posted a similar comment elsewhere in the thread.

https://news.ycombinator.com/item?id=48856535

Though beyond testing, I think there will be increasing focus on proofs of correctness. (Testing can only show the presence of bugs, not the absence. —Dijkstra)

At any rate, it's never been this cheap to produce the proof of correctness of a program, or on the other hand, to produce an exploit for an incorrect program.

[erichocean]

> reviewing the testing/fuzzing process

I've got insanely good at designing testing oracles over the last year for exactly this reason.

I've ported some extremely finicky software between languages that it would have been borderline abusive to have a human do.

Codex 5.3 and later for those interested.

[DuncanCoffee]

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

[dirkc]

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

[skydhash]

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

[isatty]

Very smart. I like it.

[EDM115]

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

[tosti]

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.

[pornel]

Use cargo tree to understand Rust/Cargo deps.

The lock format is a multi-line TOML, with a varying number of lines per dep due to redundantly listing deps-of-deps, so a naive line count massively overstates the number.

Cargo.lock contains many unused dependencies, because it's a superset of all combinations of all optional/disabled features of all transitive deps across all possible platforms (so that the deps don't reshuffle even if you enable/disable feature flags or compile on another platform). But that means Cargo.lock is going to have 3 async runtimes even if you use one. It's going to have syscall definitions for RedoxOS and wrappers for WASM, because some dep of dep is compatible with those platforms. But these deps won't even be downloaded if you don't build for these platforms.

The number you got presented is not representing the unit you're insinuating. A crate in Rust is a compilation unit. It's common for projects to ship as a collection of many crates. It's a smaller unit than what C counts as one dependency, and slightly coarser than an .o file. I don't see people freaking out by how many .o files their projects have, including all transitive ones from deps like openssl or curl.

[ChadNauseam]

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

[christophilus]

If a dependency gets compromised, that’s a problem. If you have thousands, you increase the odds vs if you have one.

[panick21_]

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

[ubercore]

Reputation for reliability can be directly impacted by thousands of upstream dependencies, though.

[cestith]

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]

All the cargo deps would be "upstream", and pulled on build.

[gen2brain]

Disaster. Well, I read stories about Rust and how there isn't much in the stdlib, but this is just too much. How many dependencies are there, on average, in other projects? I guess I am spoiled with Go.

[WillDaSilva]

In a typical Rust project you organize your project into many crates. I haven't checked, but I'd guess that the vast majority of those dependencies are internal dependencies. After all, this project started by running an automated C to Rust converter, which the authors claimed produced over a thousand crates.

[figassis]

The naysaying here is insane. Should a project like this not exist?

[gorgoiler]

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]

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]

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]

Excellent point

[jimbokun]

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

[HumblyTossed]

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

So your solution is to just read through all 1M+ lines of code?

[HumblyTossed]

And yours is to read through all 37000 commit messages??

don't be obtuse. Nobody needs to do either.

[wtetzner]

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.

[egorfine]

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