Hacker News Reader

Comment by felixgallo | Hacker News Reader

We as a society have to cut this low effort commenting out. The documentation is perfectly comprehensible. What action would you take differently if a given feature were implemented by Claude, or a human?

View on HN

If you've ever been tasked with coming up to speed on a system mostly documented with AI writing, you'll quickly realise how hard it is to trust anything you are reading. Even if the Claude documentation is 100% accurate, you'll never shake the worry that some crucial fact you founded your understanding on was wrong. It's a fast recipe for psychosis.

That's without even mentioning that AI writing can often state the what but not the why. That human perspective is usually the most valuable knowledge to get across in writing.

There’s no reason to trust a human any more than an LLM for this. Humans are not 100% accurate and very capable of making crucial factual errors in documentation. Ask me how I know.

There’s a _very_ good reason. Humans have a much richer mental mental model of the codebase, design decisions, external factors, etc.

Of course Humans can make errors when translating that to English. But if you’ve read any amount of Claudish it should be obvious that interpolating the code to documentation with an LLM typically produces a significantly worse result in almost every way. Except for superficially “sounding” correct.

That’s just not true especially when the author designed the language with the LLM like he says in the end (the AI is very good at forcing you to be specific and make decisions on ambiguous terms): all decisions can be included in the repository in a way the computer can follow and understand, which is a pattern called specification graphs. You can just document things in the docs as well if you want a more basic method. If you are claiming this language is worse in every way than others that were made by humans alone, could you be specific?? What are the bad things you’ve found? What part of the docs are incorrect? Or are you just commenting without having looked at any of that?

That is not necessarily true if the codebase is written by AI unless the human chose to be involved. That was also not necessarily true before AI either. Human skill level is wildly variable

Above all, I think I like human docs because then I not only know someone has a deep understanding of it, but also that someone can actually be queried about it. With Claude, there is always the accountability problem. If something seems off, do I even have someone other than Claude that understand it all and who is accountable ?

I don't want to read software written by misanthropes. If you've given up on working with other people, then what is the point exactly?

Amen. Not to mention these people usually want others to laud them for creating a world they can't bring themselves to actually live in.

If you believe you are making something worth other people's time, you should ALSO believe you are making something worthy of your own time.

we need an equivalent of the medieval "stand under the bridge you built" trust system.

would you fly in an airplane if the software was written mostly by Claude?

If an engineer who mostly used Claude left the company, can his replacement understand his mental model, given that he himself doesn't ?

It's probably possible to prompt an LLM into writing well, but most LLM writing that I've seen is poorly structured (e.g., the paragraphs in this post feel like strings of punchy marketing phrases), and the LLMs are too good at sounding like they're saying a lot while saying very little.

Plus, if a human puts the effort into writing something, that signals to me that it's worth something, because human time is much more scarce than LLM time.

I recently saw a language posted that caught my interest. I went into the docs and read the page "How X compares to Y", and Y is my favorite language

Within the first couple of paragraphs and bullets it made a completely false claim that is the opposite of how the language operates, something any person that knows the essentials of it would know. Language Y was listed in the front page as an inspiration (and I don't doubt them) but clearly they either did not read the docs the LLM wrote or did not use the language for long enough to know it has zero structural typing

at that point i just ask an ai questions about how the system works and hope the reasons for particular decisions can be reverse engineered from git history/pr comments etc.

As I said in my message, it would determine whether I use the project or not. I need to match it to my use cases, and if I find a match I need to know: is it matching because my use case falls in the domain of what the human collaborator wants from this project, or is my use case a hallucination that will go unsupported?

You cannot tell either from the AI written docs. I'd rather OP gave a rambling post about some problem he has in gamedev that led him to think a new language was needed, why the constraints are different, and how this will improve X, Y, or Z in his own words. Then I can infer what this project is and where it is going. Right now, I have no clue.

The docs are perfectly legible and to the point. I don't see the need to waste the author's time with aesthetics

Legibility is not the concern. The issue is whether the point the docs are making are the actual point the author is concerned with.

literally the first point under Why Goose -

"Faster than C++ and than safe Rust, ..."

perfectly legible ?

With respect, what on earth are you talking about? The documentation is clear about what the language does. You can download it and test it out if you like, and verify if yourself if the documentation matches the feature descriptions. What the human collaborator wants is immaterial. You get the code.

The author has written that post about why the language came about. He doesn't owe you that, but he did it anyway. He doesn't owe you anything more. You can use it or not. Advising him to throw away all the documentation and rewrite it again by hand from scratch so that adastra22 can deign to examine it further is ridiculous.

If you have a question about whether or not this further iterations will fit your specific (and so far undescribed) particular use case, the correct avenue for that is to ask the author politely. Or Fable; Fable could probably tell you without having to bother the author. But holy cow, the entitlement.

Are we now in a situation where all code is disposable, throwaway things with no long-lived projects?

We're talking about a programming language. Languages, and their compilers, evolve over time. Where is this one headed?

If you think you'll be able to divine that if and only if the documentation is entirely written by a human, then I'm afraid I'll have to disappoint you: no language has ever evolved strictly according to the initial plan of their authors. Nor has any author's strongly held belief about the future ever panned out the way they thought. Nor has the documentation ever held the immutable future of the language, even when fully human generated (which essentially zero languages have, even before AI).

The way to find out if a language is suitable for your needs is not to demand, in an entitled way, that the author perform an act for you. It is to (a) ask the author politely; or, failing that, (b) to examine it yourself (or ask Fable to evaluate it, using tokens you paid for).

This particular language, further, is Apache 2.0 licensed. If it's not working for you, fix it. Jesus.

Your correspondent keeps moving the goalposts and never presents a coherent argument. I would just leave them be.

How have I been inconsistent?

pretty much that's the default assumption yeah. Anything new is probably a throwaway. If there's anything cool in it - rebuild it to your own taste. There will be exceptions that do become long lived projects of course. probably even the same amount there were before. But there's going to be a few orders of magnitude more throwaways so on average any new piece of code is going to be a throwaway

Do you not see the problems that arise here? Are we losing our accumulated engineering best practice knowledge? Standardized, common, highly reviewed subsystems provide working engineering know-how and accumulated lessons learned. Not even the best AI systems can keep that many considerations in mind when re-spinning code.

If this is your default assumption, I hope I never have to rely on code you generate.

Who said it's my assumption for code I generate? We're talking about how I evaluate code other people generated. If that wasn't my default assumption - then you should never trust anything I create because I would be naively trusting other people to maintain throwaway projects.

Are we losing our accumulated engineering best practice knowledge? Yes. Have you seen the quality of new hires recently? The ones who've cheated their way through school and don't know what a for loop is? People that have those skills aren't letting them atrophy but the chain of transmission is in crisis. Breaking news, sometimes things suck

with programming languages which just rehash ideas (not saying it's a bad thing mind you! a good mix is better than a sum of its parts) you can nowadays get literally years of work in a week. truly novel stuff like bend2 takes longer (ask Victor), but I expect the next generation of models to compress those timelines, too (if the next generation is allowed to be released, since the security brouhaha going on now is seriously concerning)

Seems like an AI could be tasked with verifying the docs. Then a human can double check it's work if it finds anything.

Verify against what? What I want verification against lives in the human's head, not the repo.

Oh, I was thinking verify what the doc claims to what the code actually does, I misunderstood you.

What's left to determine? Obviously AI written docs are a deal breaker for you. Seems very straightforward. If docs are ai written, move on. That's an immediate and obvious fundamental incompatibility you have with the project. Why are you still complaining about the docs being ai written getting in the way of making your decision when you've clearly already made it?

Why are low effort comments not worthwhile but low effort docs are fine?

Comprehensibility does not equal correctness or fitness. As if that wasn't enough, or perhaps in most related manner, an LLM/AI cannot be held responsible for what it produces, by nature, especially considering the fact that a _human_ claims all of it as their own work, or at least take responsibility. Meaning that when a parable of documentation is discovered to be bogus, you can't pin it on AI, you go to the human and ask them why the documentation is wrong, and it's not a good look.

> The documentation is perfectly comprehensible

For a programming language? It's subpar and you know it.

See this for a language docs site by a small-ish team, but a significant effort was put into making it nice to read: https://tour.gleam.run/everything/

> The documentation is perfectly comprehensible

That's, like, a stunningly low bar for documentation. "The vehicle is perfectly capable of performing motion, why are you complaining?"

> What action would you take differently if a given feature were implemented by Claude, or a human?

This one is easy: I'd read the docs if it were written by a human, but I won't read them if they're written by Claude.

I find your comment much much lower effort than GP you took a snip at. It's true that more ppl may align in your thinking, but dissing the other side's concern as low effort does not belong in hn.

Reply on news.ycombinator.com