Your argument that it’s a shallow argument is itself a shallow argument. ”I hate x” is not a technical argument anyway, it’s an emotional assessment.

As much as we like to think of ourselves as rational beings, emotions are still a very large part of our decision making process. I didn't build Qite because I hate React, I built it because I knew exactly how I wanted things to work. But I do hate React and it's part of why I knew exactly how I wanted things to work.

> As much as we like to think of ourselves as rational beings, emotions are still a very large part of our decision making process

And yet, plenty of people all around the world are able to get traction for their products without mentioning the hate of another.

> I didn't build Qite because I hate React,

I get that React being the most popular front-end framework means it's going to get it's fair share of criticism, but it's become pathetic the degree to which people have made hating it their personality. Even going so far as to market their own frameworks in terms of their personal feelings towards it.

Nobody is saying humans aren't emotional, you're trying to deflect from being unable to disconnect your emotions from another library.

It's React Derangement Syndrome.

Interesting to note how similar this seems to what happened with Benj Edwards at Ars Technica. AI was used to extract or summarize information, and quotes found in the summary were then used as source material for the final writing and never double checked against the actual source.

I’ve run into a similar problem myself - working with a big transcript, I asked an AI to pull out passages that related to a certain topic, and only because of oddities in the timestamps extracted did I realize that most of the quotes did not exist in the source at all.

This seems like a solved problem. Any RAG interface I design I have links to the original source and passage. Even NotebookLM does this.

For the curious, the term of art is Grounding.

e.g.: https://docs.cloud.google.com/vertex-ai/generative-ai/docs/g...

It might be a solved problem in the sense that it has a possible solution, but not in the sense that it doesn’t happen with the tools most people would expect to be able to handle the task.

It was already a solved problem with cmd/ctrl + f.

Microwaves are for heating, ovens are for cooking. Obviously it’s possible to live on only microwaved food but it sounds pretty miserable.

Part 1 discussion, December 2024: https://news.ycombinator.com/item?id=42343953

Meanwhile, iPhone is still using this design https://xkcd.com/1884/

Describing what computers do as ”thinking” is not new. It’s a useful and obvious metaphor. https://www.gutenberg.org/ebooks/68991

It is a deceitful metaphor.

That’s an interesting approach, but what do you learn from it that is applicable to the next task? Do you find that this eventually boils down to heuristics that generalize to any task? It sounds like it would only work because you already put a lot of effort into understanding the constraints of the specific problem in detail.

I wonder why they fail this specific way. If you just let them do stuff everything quickly turns spaghetti. They seem to overlook obvious opportunities to simplify things or see a pattern and follow through. The default seems to be to add more, rather than rework or adjust what’s already in place.

I suspect it has something to do with a) the average quality of code in open source repos and b) the way the reward signal is applied in RL post-training - does the model face consequences of a brittle implementation for a task?

I wonder if these RL runs can extend over multiple sequential evaluations, where poor design in an early task hampers performance later on, as measured by amount of tokens required to add new functionality without breaking existing functionality.

Yeah I've been wondering if the increasing coding RL is going to draw models towards very short term goals relative to just learning from open source code in the wild

To me this seems like a natural consequence of the next-token prediction model. In one particular prompt you can’t “backtrack” once you’ve emitted a token. You can only move forwards. You can iteratively refine (e.g the agent can one shot itself repeatedly), but the underlying mechanism is still present.

I can’t speak for all humans, but I tend to code “nonlinearly”, jumping back and forth and typically going from high level (signatures, type definitions) to low level (fill in function bodies). I also do a lot of deletion as I decide that actually one function isn’t needed or if I find a simpler way to phrase a particular section.

Edit: in fact thinking on this more, code is _much_ closer to a tree than sequence of tokens. Not sure what to do with that, except maybe to try a tree based generator which iteratively adds child nodes.

This would make sense to me as an explanation when it only outputs code. (And I think it explains why code often ends up subtly mangled when moved in a refactoring, where a human would copy paste, the agent instead has to ”retype” it and often ends up slightly changing formatting, comments, identifiers, etc.)

But for the most part, it’s spending more tokens on analysis and planning than pure code output, and that’s where these problems need to be caught.

I feel like planning is also inherently not sequential. Typically you plan in broad strokes, then recursively jump in and fill in the details. On the surface it doesn’t seem to be all that much different than codegen. Code is just more highly specified planning. Maybe I’m misunderstanding your point?

All it does is generate soup. Some of which may taste good.

There is no thinking, no matter what marketing tells you.

LLMs are next token predictors. Their core functionality boils down to simply adding more stuff.

They do what you tell them to. If you regularly tell them to look for opportunities to clean up/refactor the code, they will.

I also expected hardware to be involved. But in the context of a list of tutorials on how to use this live coding tool the title makes sense though.

And at the same time, the fastest growing consumer product of all time is called ”ChatGPT”.

Perhaps if the product is compelling enough, the name doesn’t matter - and conversely, if the product is borderline, it had better have a great name.

Chat gpt is a great name though — you “chat” with the “GPT” so its self informing (even if you dont know what a GPT is), it’s 4 syllables that roll off the tongue well together.

RSS, has no vowels, no information, and looks like an alphabet term you might see at the doctor’s office or in an HR onboarding form at a corpo.

Randos are just calling it "Chat" now.

"I'll ask Chat about x!"

In Japan it's now known colloquially as 「チャッピー」 ("Chappy" or "Chappie"). High praise that it has received such shortened and personified version so quickly.

It’s the new ”I looked it up on wiki”.

I've heard 'just ai it' from high schoolers.