Hacker News Reader

Comment by yousif_123123 | Hacker News Reader

The opposite problem is also true. I was using it to edit code I had that was calling the new openai image API, which is slightly different from the dalle API. But Gemini was consistently "fixing" the OpenAI call even when I explained clearly not to do that since I'm using a new API design etc. Claude wasn't having that issue.

The models are very impressive. But issues like these still make me feel they are still more pattern matching (although there's also some magic, don't get me wrong) but not fully reasoning over everything correctly like you'd expect of a typical human reasoner.

View on HN

They are definitely pattern matching. Like, that's how we train them, and no matter how many layers of post training you add, you won't get too far from next token prediction.

And that's fine and useful.

> fine and useful

And crippled, incomplete, and deceiving, dangerous.

That's normal for any professional tool, but it's not normal to be so upset about it. A saw will take your finger off, but you still want to use it for woodworking.

> A saw

No: that in context is a plaster cast saw that looks vibrational but is instead a rotational saw for wood, and you will tend to believe it has safety features it was really not engineered with.

For plaster casts you have to have to plan, design and engineer a proper apt saw - learn what you must from the experience of saws for wood, but it's a specific project.

It seems like the fix is straightforward (check the output against a machine readable spec before providing it to the user), but perhaps I am a rube. This is no different than me clicking through a search result to the underlying page to verify the veracity of the search result surfaced.

Why coding agents et al don't make use of the AST through LSP is a question I've been asking myself since the first release of GitHub copilot.

I assume that it's trickier than it seems as it hasn't happened yet.

My guess is that it doesn’t work for several reasons.

While we have millions of LOCs to train models on, we don’t have that for ASTs. Also, except for LISP and some macro supporting languages, the AST is not usually stable at all (it’s an internal implementation detail). It’s also way too sparse because you need a pile of tokens for even simple operations. The Scala AST for 1 + 2 for example probably looks like this,

Apply(Select(scala, Select(math, Select(Int, Select(+)))), New(Literal(1)), Seq(This, New(Literal(2))) etc etc

which is way more tokens than 1 + 2. You could possibly use a token per AST operation but then you can’t train on human language anymore and you need a new LLM per PL, and you can’t solve problem X in language Y based on a solution from language Z.

> While we have millions of LOCs to train models on, we don’t have that for ASTs

Agreed, but that could be generated if it made a big difference.

I do completely take your points around the instability of the AST and the length, those are important facets to this question.

However, what I (and probably others) want is something much, much simpler. Merely (I love not having to implement this so I can use this word ;) ) check the code with the completion done (so what the AI proposes) and weight down completions that increase the number of issues found from the type-checking/linting/lsp process.

Honestly, just killing the ones that don't parse properly would be very helpful (I've noticed that both Copilot and the DBX completers are particularly bad at this one).

Microsoft is working on it

What good do you think that would do?

I've gotten a bunch of unbalanced parentheses suggestions, as well as loads of non existent variables generated.

One could use the LSP errors to remove those completions.

Reply on news.ycombinator.com