Is there an iterative plan for Scala 3.9.x to reduce the current 1.7K issues to a reasonable level? I think it’s possible to dedicate a version to bug fixes without adding any new features. Scala 2 still has 1.5K bugs, which, although I haven’t analyzed them in depth, seems like a lot.
4 Likes
What do we define as “reasonable”? Looking at other languages, Scala is not at such a bad state. I do agree that this number needs to be reduced to a minimum, and I think LLMs should be leveraged in doing so. Instead of forbidding them, I think we need to add agents skills and instructions to the Scala repo to guide what is expected. Scala’s OpenCB and static type checker has huge advantage over other ecosystems that can enable us with greater confidence to automate some of these tasks.
3 Likes
But AFAIK Scala maintainers do use AI and do allow it.
What they are against is
- a spam of tons of code, that some human would have to review, since even if AI can review it, to point out some obvious issues, only someone with the bigger picture can notice issues with assumptions, architecture, etc. Skills, CLAUDE.md etc can limit those, triage non-reproducible issues, group some issues together, but the human review cannot be eliminated
- a spam of reports, that they have to read whole to decide that 9/10 are hallucinations, issues pointing to wrong root causes, where the real issue might be completely unrelated to the compiler
- any activity suggesting that all that the author contributed are tokens and GH credentials - because if maintainers wanted to get some wall of text that they would not read and act on it blindly, they could use Claude Code themselves. Except that they are being held accountable for it (they make a living out of it!) and random yolo contributors are not.
5 Likes
An alternative strategy is to burn them up instead of down.
Maybe pick a Spree this fall that is a holiday, and have a bonfire.
The backlog is just a database of behaviors. If Claude really wanted to be useful, they would help identify which behaviors are related. That would help with prioritization.
I’m on the fence whether addressing “symptoms” (even very efficiently) is a recipe for success. Reviewing small fixes can be taxing. If they are not quite right, do they become a form of technical debt?
1 Like
Thank you so much for your recent PR. I’ve been following your PR and it’s been continuously fixing bugs. Thank you!
As everyone has recently seen, with the help of suitable AI, Bun has gradually migrated from Zig to Rust. I think modern AI is a lot like ancient alchemy, and we are the alchemists. This way, Scala can keep up with the pace of AI, ensuring that its language features and stability are not inferior. Especially now that new models are constantly being released and trained, if a bug keeps appearing, it will affect the technical choices and suggestions that AI sometimes makes when providing solutions. By continuously delivering high-quality software and value, we should be able to make Scala the foundation for AI native implementations. Currently in my work, I’ve found that Scala 3 is very friendly to LLM, generating excellent code. I believe that Scala 3 compilers could also learn from Rust, generating AI-friendly compilation errors, allowing Scala 3 software to formally verify the completeness of a program. This way, even Scala 3 code generated by LLM can be of very high quality and stable.
a) use of AI is not prohibited, you just have to be very open about the use of AI and take responsibility for the augmented work
b) the AGENTS.md file already exists: scala3/AGENTS.md at main · scala/scala3 · GitHub
c) unfortunately AI isn’t that useful in fixing compiler bugs - in my own experience there’s an extensive body of knowledge required to understand all the invariants and models just don’t have that knowledge readily available so even when they do fix the bug with all tests green and new tests added, they have no way of knowing they are codifying a behavior that’s essentially wrong and that’s a big no-no, that’s why we still require engineers that are well versed in the compiler internals as AI drivers
2 Likes
This last point is extremely interesting. In my thought on “/me wave at AI, collapse, burning resources, ans what it means to be a dev”, I think a sustainable way can be to find process that helps both humans and AI bots.
Documenting these invariants is exactly the kind of processes that can match that view :
- it can be done in a way that is friendly to agent with skills/whatever the currect koolaid for that,
- it can be used to help willing people to learn and avoid trying to contribute irrelevant PR,
- in any case, it’s an important part of knowledge not caputred by external artifacts today (docs, tests, etc), and it’s a bad risk management and open source strategy to only have them in the head of a few savant.
Of course it means that said savants need to at least help create these knowledge skills.
1 Like