Hacker News Reader

I am in the middle of my third AI assisted project. I disagree ~90%.

If you prompt an LLM like an architect and feed it code rather than expecting it to write your code, both ChatGPT 4o and Claude 3.7 Sonnet do a great job. Do they mess up? Regularly. But the key is to guide the LLM and not let the LLM guide you, otherwise you'll end up in purgatory.

It takes some time to get used to what types of prompts work. Remember, LLMs are just tools; used in a naive way, they can be a drain, but used effectively they can be great. The typing speed alone is something I could never match.

But just like anything, you have to know what you're doing. Don't go slapping together a bunch of source files that they spit out. Be specific, be firm, tell it what to review first, what's important and what is not. Mention specific algorithms. Detail exactly how you want something to fit together, or describe shortcomings or pitfalls. I'll be damned if they don't get it most of the time.

> Be specific, be firm, tell it what to review first, what's important and what is not [...] Detail exactly how you want something to fit together [...]

You mean like in a fast food chain?

I know how to use it. All of that was already implied in my original comment. Sometimes though, I want to cook without a rigid mindset.

I wonder how many lines of code you write in a day. Most PR I’ve seen has a diff in the lowe 2 digits, unless it’s refactoring or formatting.

If I had to guess, probably a couple hundred lines a day, maybe more if I get in a groove or have a deadline.

But with an LLM, that number goes to about 500 or so, 200 of which are real code and not definitions of some kind. Truthfully, that’s where the LLMs shine. I have this enum with 50 variants, and need to build a dictionary (with further constraints and more complex objects). That shit takes forever even with cut & paste, unless you code with code, and those one-offs aren’t my cup of tea anymore.

Pretty weak analogy. Copilot can show you how to make either McDonalds or a Michelin starred restaurant meal. It is endlessly variable.

I can do neither.

McDonald’s is a system for delivering food fast and cheap at scale. It breaks down when making one burger.

If you’re not a trained chef, you will not pump out Michelin star meals, even using the same recipe.

Asking the LLM for something is like doing an "Ask the Audience" in Who Wants to be a Millionaire. You're basically polling the consensus answer to the question you're asking.

> You're basically polling the consensus answer to the question you're asking.

There is nothing wrong with going with the consensus answer. Sure, you can't invent an O(N) sorting algorithm with the consensus, but LLMs can definitely write good, maintainable code. Michelin star analogy might be an exaggeration, but it can help cook a good homemade meal, possibly even better than most wannabe home cooks.

Dude, ask ChatGPT to explain the analogy for you. It understood well enough. It will save both of us some time.

Maybe AI is useful for some things after all.

Not sure about the reason for the personal attack, but my comment wasn't a reply to you. Michelin star restaurant was not even your analogy.

I guess you are right, though. AI is useful for some things. At least it reads the prompt before responding.

> Michelin star restaurant was not even your analogy

Precisely.

>There is nothing wrong with going with the consensus answer.

For most things, yes. But you don't hire experts to tell you what everyone else knows. You hire experts to give you the angle.

For example, an LLM trained on all AWS documentation wouldn't be super useful (possibly less useful than traditional full-text search), because what you really want to know is the things that AWS didn't write, the writing "between the lines", all the things that DynamoDB can't do.

> You're basically polling the consensus answer to the question you're asking.

That's perfectly fine, because that's what you expect from human work to begin with. From natural text like blog article or tecnical reports to software changes, all output is expected to comply with patterns we are already familiar with. Heck, look at pull requests, where you ask your audience to evaluate your work hoping to reach a consensus.

You'd expect that from an average person, but not a genius in the subject. "Genius" is almost by definition a contrarian viewpoint or technique that happens to be better than the consensus or the best-known.

> You'd expect that from an average person, but not a genius in the subject.

That's perfectly fine. It doesn't take a genius to write a webpage or a report.

It's kind of true story actually.

I found one of my license texts for a hobby project[0] in a Microsoft product[1]. I have no idea how they use it.

Copilot is very poor at understanding how the DSL arrangement of the project works or how to assemble validator trees. Before Copilot many other "enterprise" stuff like JetBrains IDEs had problems auto-completing it. But it was always good enough for me, for my own things.

It obviously have value. Maybe they're lazy and using it for something unrelated like the TLD list. I really don't know. What I know is that something of my amateur dish ended up being served in what I consider to be a fast food chain.

No, copilot is not endlessly variable. It works best with typed languages and an enterprise mindset. That's exactly the point against "vibe coding" they push. MS seems to despise anything that doesn't follow that.

Look, I love typescript and all that stuff. As I said, McDonalds meals are delicious.

But I don't want that approach for everything I code. This project is not the only one with that issue. I noticed the same in a portable shell compatibility layer, it can only help if I make it to look like other script languages.

"You're asking too much, how can copilot help with a language it was not trained on?"

I am not asking it to be good at that. Just don't make asshole posts saying anything other than MS pasteurization is "vibes".

If they paid me, then that would be another story. But they didn't, and used my "vibe" project anyways.

I am not complaining about software I released for free, before anyone tries to go for that.

I am making an observation about kinds of software that copilot can't help with. My kind of software development, in which I might take months to decide a name or redo everything several times just to try a new kind of sauce.

[0]: https://github.com/Respect/Validation [1]: https://support.microsoft.com/en-us/office/microsoft-teams-t...

> No, copilot is not endlessly variable. It works best with typed languages and an enterprise mindset.

I don't think your assumption is true. The key factor is the corpus used to train it, and the context you fed it. I already experienced Copilot fumbling references to methods of a simple Java class, whereas it pulled off thinks like ARM templates flawlessly. You need to understand that internally LLMs do probability-based text completion. If you feed them enough context to maximize the probability they output things you expect, they do so.

Please, think about what you just said.

How can I feed to it context about a DSL that does not exist yet?

> How can I feed to it context about a DSL that does not exist yet?

My example referred to ARM templates. They do exist, don't they?

I guess they do. But if that's the case then your comment brings nothing new to the discussion.

Right, but that's exactly what static typing does in most cases - it provides model with more explicit context for what it's doing.

For the same reason, they tend to handle XML better than JSON - sure, both are trees, but XML is has redundancy, and that redundancy helps keep the model on the rails, so to speak.

I actually wonder if the perfect LLM language would be something a lot more like COBOL - not in a sense of being similarly high level, but rather verbosity. And perhaps also being closer to natural English, which is, after all, still a lot of its training set, especially for reasoning stuff. For query languages they seem to like SQL the most of all the things I've tried, and I strongly suspect that it's the same underlying cause.

Of course, a new language designed like that would have the fundamental problem that there's no existing corpus in such a language. Then again, if it is also designed such that one can reliably convert e.g. from Java to that language, then perhaps we can still pull that off.

> For query languages, at least, they seem to like SQL the most of all the things I've tried, and I strongly suspect that it's the same underlying cause.

The reason they like SQL more than other query languages is primarily that their training data has orders of magnitude more of it than any other query language, and that advantage is so huge that any other possible advantage would probably have comparatively negligible effect.

I'm not so sure about that. This was in comparison to e.g. walking object graphs in Python, C#, and JavaScript using the usual APIs (i.e. where querying one one-to-many relationship looks like Foo.Bars rather than joins, and using map/fold/filter or equivalents). I would expect there to be a lot more of that kinda stuff in the training set than SQL.

> Copilot can help me cook the equivalent of a McDonalds special in terms of software. It's good, I think McDonalds is delicious.

No. The likes of Copilot help you cook the meal you'd like, how you'd like it. In some cases it forgets to crack open eggs, in other cases it cooks a meal far better than whatever you'd be able to pull together in your home kitchen. And does it in seconds.

The "does it in seconds" is the key factor. Everyone heard of the "million monkeys with a typewriter" theorem. The likes of Copilot is like that, but it takes queues and gathers context and is supervised by you. The likes of Copilot is more in line with a lazy intern that you need to hand-hold to get them to finish their assignment. And with enough feedback and retries, it does finish the assignment. With flying colors.

Sometimes it poisons your family to death. That’s the dangerous bit.

Cook a meal, yes. "How you'd like it", no. You have to use the languages that have a large enough presence in its training set that it knows them well, and ditto for frameworks and libraries. Once you step out of that zone, quality rapidly plummets.

"Does it in seconds" is kinda true if you ignore the "supervised by you" part. That part - reading through the generated diffs to catch (sometimes very subtle) errors - can take a while.

And sure, you'd have the same problem with the intern. But the intern learns from you. The LLM will make the same mistakes again in the same circumstances. Yes, I know they do have memory now, but it my experience that RAG-based stuff is not particularly reliable. I suspect this might improve once hardware is fast enough that you can use a (smallish) helper LLM for RAG with reasonable perf, but we aren't quite there yet.