Further development of Open Salamander

[janrysavy]

After the Czech comments have been translated into English, I would like to follow up on the question about the future development of Salamander: #92 (reply in thread)

First, I want to say that I have written almost nothing by hand for about a year now. I try to handle everything with AI. Sometime near the end of 2025, there was a major leap in the capabilities of AI agents. Something changed, and suddenly many things started to fit together. At the moment, I work with two ChatGPT Pro subscriptions ($200/month), and I routinely manage to use up their weekly Codex limits completely.

Personally, I believe the future of programming lies in AI. I do not think we will return to writing code line by line by hand, except perhaps in some very specific edge cases.

I think that if AI can now be used for Linux kernel development, then it can probably be used almost everywhere else as well. The real question is not whether we can do it, but whether we should do it — and whether we should do it right now.

A year ago, I certainly could not have imagined that I would be managing 13 parallel Codex agents working together on one task through git worktrees, coordinated by an orchestrator. Today, this is a normal reality. I have no idea what things will look like a year from now, but so far it does not look like we have reached a plateau or that progress is stopping.

What I think this means for the Open Salamander project is this: there are many areas in its code base where I would not be afraid to use AI. This includes reviews, UI work, Arm64 support, and plugins such as PictView or Web Viewer. If something breaks in a that parts, we fix it and move on. No one loses any data, because we are not touching the core file-operation logic. I can also imagine using AI to cover Salamander with several layers of tests, which would then allow us to use AI more broadly and with much higher confidence.

What I would still postpone, with a clear conscience, is touching the performance-critical core of Salamander with AI: the actual file and directory operations. Over many years, Salamander has proven that this core is stable and excellent. The idea of breaking it is a no-go. Unfortunately, this also affects the Unicode implementation.

I think it is great that AI-driven forks of Salamander are appearing. They are inspiring, and they are an excellent source of information and know-how. They can explore the blind alleys so that we do not have to.

[KRtekTM]

Thanks @janrysavy for this post, I agree with you in many ways. Since I tried working with Codex on the Open Salamander code, I have practically stopped coding by hand. That is why I still try to keep separate development branches for each of the features in my fork, precisely for the sake of possible inspiration, integration, or gradual improvement of the code using AI. As for Unicode support or other larger features, it really requires a responsible approach to maintain the quality and robustness that users are used to and expect from Salamander.

[WaldemarH]

Hi Jan. If you will continue with AI stuff, you can also contact @0xeb as he made a lot of changes already to not waist tokens on stuff that is already done... then you can continue all together with the AI development.

And as you wont need a code janitor experties from my end I'll continue developing on my own.
There is a simple reason.. I really like to code. :)

Have tons of fun. :)

[janrysavy]

Linus Torvalds and AI in Linux kernel: https://www.phoronix.com/news/Linux-Is-Not-Anti-AI

[WaldemarH]

Hi Jan, for me Linus is just a celebrity for the least 10+ years and doesn't have any real weight for me. Now LLMs are an interesting tool, but at least in my eyes are not ready for what I would use them for. There are two points that at this time I can't find the solution to: 1. LLMs need a very detailed description of what to do, if you want that the results are at least somehow proper.    And even then you need to check everything what they do (the issues are always the last 20%). 2. If I want to check what LLM does in a proper manner to hold the high standard of stability and    code format so that the app. will stand the pressures of time, I need to know what the code does in detail.    But if I lean more and more on the LLM I know less and less of what the code does.        And unfortunately I don't know anybody who can scan other's code and remember what it does and how.     It's a catch 22. After a lot of thinking and watching all sides of the LLM scene on YT (from completely against to best thing after bread), I've decided that at this stage the tool is still not for me and I will continue coding by hand. For last 20 years I've seen how the long-term developers were pushed aside by the fast-prototypers where management almost never understood that if you invest into the code now it will be much easier and at the end cheaper down the road.The issue is that nobody gets any penalties if something is not ok in the corporate world. It's just grab the money now and don't care about the later. Now I do understand fast-prototypers as sometimes you just want to test some ideas and they write code faster then long-term developers which is ok with me.With LLMs the world went another step into the fast-prototyping direction. And from what I see nobody really cares anymore if things work or not. People are getting used that they buy a thing and it doesn't work as it should from the start. The reality is also that nobody wants to pay for quality anymore, people just think they are entitled to get everything they want without any work or pay. Well I have no clue what will happen in the future and if they can fix the last 20%. I know that I really enjoy coding and will continue doing it for as long as I can. I was joking with a friend that in 2 years I'll change my title on LinkedIn to no-AI developer/code cleaner just to see if anybody will contact me. Well we'll see. :) Have a really nice time.