[littlestymaar]

- First commit 3hours ago.

- commit message: LLM-generated.

- README: LLM-generated.

I'm not convinced that projects vibe coded over the evening deserve the HN front page…

Edit: and of course the author's blog is also full of AI slop…

2026 hasn't even started I already hate it.

[ncgl]

Using Ai isn't lazier than your regurgitated dismissal, to be fair.

[littlestymaar]

Using AI is not necessarily lazy.

Using AI lazily is a problem though. Writing code has never been the most important part of software development, making sure that the code does what the user needs is what takes most of the time. But from the github issues and the comment here from the few who have tested the tool, it looka like the author didn't even test the AI output on real PDF.

If you use AI to build in 3 month something that would have taken a year without it, then cool. But here we're talking about someone who's spending 2-3 hours every other day building a new fake software project to pad his resume. This isn't something anyone should endorse.

[kingkongjaffa]

Wait, but why?

If it's really better than what we had before, what does it matter how it was made? It's literally hacked together with the tools of the day (LLMs) isn't that the very hacker ethos? Patching stuff together that works in a new and useful way.

5x speed improvements on pdf text extraction might be great for some applications I'm not aware of, I wouldn't just dismiss it out of hand because the author used $robot to write the code.

Presumably the thought to make the thing in the first place and decide what features to add and not add was more important than how the code is generated?

[utopiah]

> If it's really better than what we had before

That's a very big if. The whole point is that what we had before was made slowly. This was made quickly. In itself it's not better but what it typically means is hours and hours of testing. Going through painful problems that highlight idiosyncrasies of the problem space. Things that are really weird and specific to whatever the tool is trying to address.

In such cases we can be expect that with very little time very few things were tested and tested properly (including a comment mentioned how tests were also generated). "We" the audience of potentially interested users have then to do that work (as plenty did commenting on that post).

IMHO what you bring forward is precisely that :

- can the new "solution" actually pass ALL the tests the previous one did? More?

This should be brought to the top and the actual compromises can then be understood, "we" can then decide if it's "better" for our context. In some cases faster with lossy output is actually better, in others absolutely not. The difference between the new and the old solutions isn't binary and have no visibility on that is what makes such a process nothing more than yet another showcase that LLMs can indeed produce "something" that is absolutely boring while consuming a TON of resources, including our own attention.

TL;DR: there should be test "harness" made by 3rd parties (or from well known software it is the closest too) that an LLM generated piece of code should pass before being actually compared.

[utopiah]

related https://news.ycombinator.com/item?id=46437688

[dmytrish]

...and it does not work. I tried it on ~10 random pdfs, including very simple ones (e.g. a hello world from typst), it segfaults on every single one.

[forgotpwd16]

Tried few and works. Maybe you've older or newer Zig version than whatever project targets. (Mine is 0.15.2.)

[dmytrish]

   ~/c/t/s/zpdf (main)> zig version
   0.15.2

Sky is blue, water is wet, slop does not work.