> When it’s able to create code that compiles, the code is invariably inefficient and ugly.
Why not have static analysis tools on the other side of those generations that constrain how the LLM can write the code?
> When it’s able to create code that compiles, the code is invariably inefficient and ugly.
Why not have static analysis tools on the other side of those generations that constrain how the LLM can write the code?
> 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.
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.
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.
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.
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.