Re:Typed languages are better suited for vibecoding
by jdiff on Monday August 04, 2025 @02:17AM
(#44782589)
I'd be interested to know the answer to this as well. Considering the wealth of AI IDE integrations, it's very eyebrow-raising that there are zero instances of this. Seems like somewhat low hanging fruit to rule out tokens that are clearly syntactically or semantically invalid.
Re:Typed languages are better suited for vibecoding
by hkt on Monday August 04, 2025 @03:43AM
(#44783030)
This can be done: I gave mine a justfile and early in the project very attentively steered it towards building out quality checks. CLAUDE.md also contains instructions to run those after each iteration.
What I'd like to see is the CLI's interaction with VSCode etc extending to understand things which the IDE has given us for free for years.
Re:Typed languages are better suited for vibecoding
by octopoc on Monday August 04, 2025 @08:54AM
(#44785127)
I’d like to constrain the output of the LLM by accessing the probabilities for the next token, pick the next token that has the highest probability and also is valid in the type system, and use that. Originally OpenAI did give you the probabilities for the next token, but apparently that made it easy to steal the weights, so they turned that feature off.
Re:Typed languages are better suited for vibecoding
by qcnguy on Monday August 04, 2025 @01:55PM
(#44789270)
It's been tried already and doesn't work. Very often a model needs to emit tokens that aren't valid yet but will become so later.
Re:Typed languages are better suited for vibecoding
by Jensson on Monday August 04, 2025 @11:05AM
(#44786847)
> Why not have static analysis tools on the other side of those generations that constrain how the LLM can write the code?
We do have it, we call those programmers, without such tools you don't get much useful output at all. But other than that static analysis tools aren't powerful enough to detect the kind of problems and issues these language models creates.
Why not have static analysis tools on the other side of those generations that constrain how the LLM can write the code?