renaudpawlak

It looks that what you describe is partly a "burnout", partly a "sickness" of always the same LLM tricks and output (including errors). Of course LLMs tend to go back to their initial training and even if you "teach" them right, the attention mechanism make them forget things that are not often used (that's the KV-cache) even if they can be important for you (there is room for improvements here).

That said, your reaction is totally human. I personally get sick of how the LLM writes prose with always the same tricks and formulas (even if you prompt it not to). Humans need variants and novelty, that's why fashion exists. We get fed up with repetition and after seeing too much green shoes, seeing a red one is so relieving :) (quick note: I don't like fashion - I'd advocate diversity and personal styles, not fashion)

But that's also the way you work with AI that might be part of the problem. Personally, I don't review all the code the AI generates. I look at it, and I review only the code that matters. And with time on a given project I review less and less because I trust more the architecture and ability of the AI to follow it. In my settings, the AI gets confined to the existing architecture (that we define together at the beginning of the project), and has to ask for authorization to create new things (that's when I review the more). Hoping this could help to avoid burnout myself...

Hello HN, at LocalFlow, we have been working on a new kind of software component following lean methods, with the help of low-code tooling. I am curious to have you feedback.

Hello HN, at LocalFlow, we have been working on a new kind of software component following lean methods, with the help of low-code tooling. I am curious to have you feedback.

Did not find either :/

Thanks :) I hope too. The project deserves it.

Shutting down the projet and/or change the OS license to make it easier to fork is a potential option. However, I think it's worth asking if some organisation could be interested first. I believe JSweet could be more helpful if it was backed by some org that would have a use case of JSweet and maintain it for it's own purpose.

JSweet comes with a TS definition files to Java translator (.d.ts to .java). So when you have the TS definition file, you can generate the correspond Java API on-the-fly or use a pre-translated/pre-compiled definition in so-called "candies". The candies are just here for typing in Java and ensure that you have the exact same API as in TS. Then JSweet generates intermediate TS code, which is compiled against the original TS definition. This 2-step transpilation process ensures that the generated code is correct and well-typed. In the end, you can work either directly with the JS code or the TS code depending on what you need.

Yes indeed