This circles back to the OP's point: they're not appropriate to use directly, so we layer a framework on top of them (Lit), and now we're just using another framework with one small piece swapped out.

Except for the hyphens, I don't feel any closer to the platform when I use Lit.

You can inspect a Lit component directly in Chrome, it’s just a custom element. No need for a browser dev extension. You can use this custom element from React or any other JS framework. You can also use this custom element in a server-rendered template, no need for any custom SSR setup. Feel close to the platform yet?

> Reading the code does not mean you understand the code.

Reading the code may not be enough to understand the behaviour of your program, but believing you can understand the behaviour of a program without at least reading the high level code is truly silly.

(by high level, I mean the code living in the higher layers - of course we don't often read the code of the generated assembly, or the interpreter, or the browser, but that's because they're reliable abstractions, unlike prompts!)

> believing you can understand the behaviour of a program without at least reading the high level code is truly silly.

have you ever used a library after only reading the README and documentation, or do you always pull the source and read through it before you think you understand it?

I would draw the difference here that a library is used by hundreds (of thousands) of people, and established across different scenarios. I don't read the boto3 library AWS provides, but I can trust them and the amount of customers enough to be certain enough that it behaves the way I expect it to. The same can't be said with code we write in silos at our workplace or at home. It simply does not have the same test bench.

Yes, libraries aren't bug-free, but they give me a reliable abstraction tested in the field. Not rarely you dig into library code if you notice unexpected behavior.

If we could rely on our LLM or colleague written code, or own code, have run through the same amount of requests, sure I wouldn't need to review it, as my confidence can be north of 99.9999% it works correctly. But we can't.

Nothing you’re saying excludes AI from writing code. In fact I’ll bet my salary that boto3 has AI written code in it and you happily trust it.

I've used libraries before, where I call the API surface that they expose based on method names and parameter types, without reading all the source. Generally those libraries don't implement my software's entire problem domain area; they tend to implement things like "CSV parser" or "HTTP server". The important code, that I'm actively reading and writing, tends to be the code around those library calls.

This is different from building a product, which you only interact with via UI buttons/CLI/etc, without reading any code to understand how it conceptualizes that product's problem domain area.

People do that latter thing, and we call them "users", not "developers".

You can use it without understanding, but this won't help you actually understand how it behaves.

I believe I can understand how a library behaves from the README and docs. I do this all the time. We all do.

You haven't run into cases where the documentation is missing or incomplete? You must be dealing with different libraries than I am.

Of course. And then we fix the problem. It's no different here. The point is that reading the code first is absolutely not a requirement when adopting a new library.

It is not. But there’s an element of trust being involved. Something like libflac or libcurl, I don’t read the code. I read the doc which does outline the behavior of each function and the conceptual model. If something break, it’s quite often my code. Why? because their code is battle tested. Which is quite different from AI generated code.

That's because it's new. libflac and libcurl didn't come out as battle tested code. That takes time and...battles. And what are those battles if not people seeing issues with what those libraries are doing and fixing the code? There absolutely no reason that AI written code can't or won't become battle tested.

> There absolutely no reason that AI written code can't or won't become battle tested.

I can think of 2:

1. Low trust: I'm not going to trust some rando's AI-generated code/PR when I can make my own AI generated code. Maintainer will (rightly) not trust my awesome AI-generated PR because I'm a rando to them.

2. Fragmentation, if a lot of people are doing (1), they wont contribute to the same upstream codebase like they would in the past, which means each codebase only runs through a small subset of potential environments.

The interplay between 1 & 2 will result in a lot of siloed code, with no accounting for taste (i.e. sensibilities developed by maintainers)

Low trust is not a reason that code can’t be battle tested. All non battle tested code starts as low trust by default. AI written or otherwise. I’m not even sure what you mean by fragmentation tbh. This feels like a very vague argument in general.

But you’re right that it’s the hill climb of human trust that AI is going through right now. Some of us are just farther along than others. Some of us refuse to consider trusting AI out of fear, and not rational evaluation of its capability.

The battle tested part is the reason I suspect my code rather than theirs first. The trust part is in their engineering process. New project from OpenBSD or Debian, I’m ready to try. Random guy on Github, bring out the 10 foot pole.

You can’t say a new project is battle tested. Those are mutually exclusive, regardless of who or what wrote the code.

I wouldn’t be able to fix a bug in a library I have only called but never contributed to, without a lot of time and effort.

But SOMEBODY should be familiar enough with the code to fix, improve and maintain it. Using unmaintained libraries can be risky.

Whenever there is a bug in a library or a hard to diagnose issue and there is no information on the internet about it, I tend to just dive right into the dependency source code for debugging.

It's hard for me to understand how you could work on software and not understand the qualitative difference between the Unix File API and some code that an AI spat out 5 minutes ago.

No, but the authors of $LIBRARY are accountable if it fails

Are they? I've never been able to blame library authors or hold them accountable for code running in my production environment.

They are accountable for their library, you are accountable for putting it in your production environment.

If they fail you can stop using their library. If you fail your company can stop using you.

Rails is the most cult-like, anti-learning, anti-choice and even anti-engineering technology I have ever used. It does NOT want you to make your own choices, it does NOT want you to decouple from the framework, it does NOT want you to grow. It’s frightening.

I mean, in an app that uses Rails by-the-book, you won’t even find a class instantiation. No call to new. You won’t find a class that does not inherit from a framework bass class either. The framework handles everything, don’t worry.

I did interviews almost weekly from about 2017-2024, when I was working in a Rails company.

About half the people had no idea how to use Ruby without Rails, and most of them would open a whole-ass Rails app to do a simple FizzBuzz (I would naturally provide assistance in maths).

A minority (only 3 or 4 people) were unable to create a Rails app, and had to run FizzBuzz in their employee's own app.

Those were people in Mid-Level and Senior positions in other companies, that had documentation proving as such, and also managed to pass an HR screening.

The one thing that gets with those PRs is that they want you to read stuff they haven’t even read themselves! Yeah, no.

Two years ago? I don’t get it, coding agents have been compelling for barely a year.

Cursor and aider were definitely compelling two years ago. Nothing compared to now, of course, but still better than raw dogging it.

I would say from march this year.

I trailed off a few lines into the README. No human ever edited any of this. « LLM detected, project rejected ».

Every third post in HN has this same complaint comment. Everybody knows.

It's better that everyone is loud about it then everyone giving up and being silently irritated. At least if people complain it's possible to read the room

Just flag the post so it drops off the home page and loses audience.

That risks not communicating the reason for the downvotes / flags to the submitter. I think the value of complaining loudly is signalling to those who think LLM write-ups are acceptable (some folks are acting in good faith without understanding why the content is unwanted).

Especially when the article _is plainly about the use of LLMs to do LLM things_.

If this was talking about buying the best apples are the supermarket, sure, complain away about the use of an LLM to talk about apples.

But it's really a specious argument about something that likely only exists because an LLM is good at creating that type of project.

Tbh, I still wonder why people even bother releasing such tools that were shitted out by an LLM in an hour or two, these are basically the modern equivalent of a hastily cobbled together 10-liner shell script (still useful, but not something you'd ever put up as its own Github project).

Everybody else can write such tools now by themselves in at most an hour, and they get a tool that's more personalized to their tastes. And why have a readme at all when it's just LLM mumbo-jumbo - that sort of mumbo-jumbo is written for LLMs to consume, not humans.

In theory, there is some value in deciding what the LLM ought to shit out, and checking that it works, and maybe even making a design decision or two to try and create something that would be relevant or useful for many people. And then others can possibly save an hour or two, and the data centre can save some water and electricity.

In practice, well.

That sort of careful work would take more than 7 commits and 1 hour though ;)

That's 6 more commits than I'm used to seeing for these sorts of efforts, honestly. (But I will cede that people might be doing all the changes locally and then pushing a single commit, without any real understanding of how version control works.)

If folks do this; I'd love for them to also be in the habit of shipping their prompts + harness configuration too. If we are moving to another code abstraction, then that becomes the source code to modify, adapt and extend.

I mean -- compilers used to annoy developers who knew how to hand-roll machine code, with bad outputs and inefficient algorithms, till the compilers got better than most of them...

I prefer when I see other comments to confirm or infirm my opinion.

>Everybody knows.

Awesome!

I think these repo owners should be required to film themselves reading out their Claudemade readmes with a straight face.

Every honest caveat. Every seam. Every "Frames lie, so the walk prunes hard".

I appreciate it when people say something is slop. Saves me from wasting my time looking at it.

How many slop ideas have come to the front page, never to be heard from again because the execution isn’t actually any good? I’m guessing most of them.

Hmm, I wonder if we can automate that

Just because the ReadMe is slop, doesn’t mean the code is slop. People are starting to make apps for themselves now and open-sourcing them so they’re not putting much thought into the ReadMe or distribution.

This just means ReadMe’s are less important now. I just have my terminal agent dig into the code and tell me what features are there. If the app is actually useful.

Even before AI, there were so many projects with subpar ReadMes, no screenshots, etc. But once you use the software, you realize how good it is.

Source: I maintain a massive collection of open-source alternatives and quality of open-source alternatives have increased a lot

If you do not respect your project to write your readme yourself chances are i will not care though.

For many new coders, LLMs are so good at writing the code, asking it to write the ReadMe sounds like a good idea. Clearly it’s the first impression your project makes so handwriting it is important.

Being turned off by the project because of the ReadMe is your prerogative. I’m just suggesting you dig into the code sometimes, the ReadMe is not the be all, end all.

> For many new coders, LLMs are so good at writing the code, asking it to write the ReadMe sounds like a good idea. Clearly it’s the first impression your project makes so handwriting it is important.

The point is that if they looked at the result they'd question themselves. And the fact that they don't is a violation of the social contract: I can hardly be expected to care about your work, if you don't.

But it takes so little effort to wade through an LLM readme and cut out or edit it down to something palatable.

Just the bare minimum effort to do that would be nice.

I apply the same rule to the code, unless it is on the job and I have to follow along with the herd, or else....

Your comment might be sarcastic, but AGENTS.md already exists for the explicit purpose of agents reading and using it.

You’re right that a poor quality readme doesn’t mean a poor-quality product, but it seems more likely than not to me.

Slop is an instant tab close for me. If something’s good, it’ll come around again. I’ll catch it when there's some evidence that it’s worth my time.

This project is 100% slop, as evidenced by all commits having a Claude attribution. https://github.com/awlevin/typesafe-computer-use/graphs/cont...

You can produce good code and good projects with Claude doing all the work. This might even be an example of one, but the description on GitHub makes so little sense that I stopped reading before I figured out what it even does.

If the author is too lazy to even write their own commits, I doubt there would be any effort put into the codebase.

Clearly the people writing these annoying articles don't know.

I wish they'd just use Astra instead. It doesn't write this awful prose.

And every comment on HN calling out vibe-coded slop has this same complaint comment in turn. OP has an actual complaint, your complaint is just "stop complaining".

It’s not stop complaining as much as it is please contribute something of substance instead of venting hot air into a comment thread where everyone is already aware.

1/3 of articles warrantying such a comment means it is still important information. If it was 100% of the articles I would agree that it gives no information, but with 1/3 one cannot claim it does not contribute information.

I'd rather read it's slop, it actually adds something to the conversation.

I'd say "imagine if half the posts on HN aren't worth your time" but this is genuinely how it feels nowadays. I'm not sorry

The problem is that not everyone thinks like you. You're dictating what is and isn't a signal to others. OP left a comment to signal to people like me. It saved me a click.

The title was perplexing enough for me.

I stopped reading at “The honest caveat”…

An llm response here would be more respectful than a downvote without a comment.

And it’s quite disrespectful to dismiss a project that may have taken a lot of time and thought, even with agents, to build, and just dismiss it because the readme was created by an agent.

> Good models these days spit out architecture and code fairly indistinguishable from your average developer.

Emphatically, no. It’s way too complex, every time. Ceinture et bretelles, as we say in French.

> Ceinture et bretelles

I do not know much French but that seems to translate literally into the common English phrase "belt and braces"

Did not know belt and braces was a saying in English! I learned something today.

Everything I've vibe coded is utlitarian, sparse, barebones, and the code itself is fewer bytes than the documentation.

You can do this if you hold its hand a lot. Claude by default will do insane levels of abstraction for small things. Also make Python docstrings 3x longer than the actual code.

Anthropic bills by the token. Incentives might be different for open weight models.

and if you hand hold its not vibe coding.

If only!

My favorite thing is leaving the skin and slicing them. Each slice has the perfect amount of skin and pulp, it’s crunchy, it’s heaven!

Did the author really put significant effort here? The LLM speak suggests the opposite.

> These are not market personas. They are architecture tests.

Indeed.

This is obviously written by an LLM. Should we flag such content?

Did I even tried to pretend the article wasn't generated with Claude's help?

I even shared the initial prompt in some comment in this thread. I don't understand what is the matter with also using AI help with generating articles. I still reviewed the article and put all the ideas I wanted to discuss in that article. I don't see why people are often complaining about this. The article content is much more important than how it was generated.