(can’t edit post)
I am also not trying to claim how good I am. If someone else managed to do the same work in several months that everyone else failed to to in 15 years, I would say the same thing. For example I consider trungnt2910 more skillful than me. Writing ABI compatible Haiku layer for Linux in quite short amount of time is genuinely impressing. I am unable to that in this timespan.
Great, then take feedback, and when someone tells you they feel a certain way, don’t dismiss it saying they shouldn’t. You most definitely shouldn’t start lecturing them about their maturity or improving their character (which assumes it lacks something).
If someone tells you they feel attacked and you didn’t mean it, you say “I’m sorry, I didn’t mean it that way”.
By your own admission, you’re not an expert in feelings.
It isn’t mine either. I believe this is just another excuse to you.
Facts:
Mirriam-Webster smug, 1. highly self-satisfied
Random House Kernerman Webster’s College Dictionary smug 1. contentedly confident of one’s ability, superiority, or correctness; complacent.
Wiktionary smug 1. Irritatingly pleased with oneself; offensively self-complacent, self-satisfied. […] Synonyms: complacent, gloaty, self-satisfied; see also Thesaurus:arrogant
Exhibits:
contentedly confident of one’s ability 
contentedly confident of one’s superiority
contentedly confident of one’s correctness
This is just from this topic. I’m pretty sure I could find more examples in your post history. Oh, wait, got one more:
superiority
That assumes I have no understanding of technical details based on what? I said you pretend to strive for objective analysis, because if something doesn’t fit your thesis (like context that you maybe didn’t know but PulkoMandy provided) you just discard it. That’s not objective.
I don’t know if you’re trying or not, but you’re sure coming across that way.
Another fact for you: people who do not understand/recognize emotions, are most driven by them because emotions are still operating in the background, just unchecked.
You have an opportunity to show that you practice what you preach, and do better instead of hiding behind lack of understanding of feelings/language/culture/Europeans.
I’m reading this wall of text you all wrote while I was asleep, and my hair is already standing on end from sheer horror. You’ve clearly all gone completely off the rails.
I had a crazy idea. Instead of arguing endlessly, let’s organize a competition - a code sprint. Two teams: one writes code strictly by hand the old-fashioned way, and the other uses any AI tools and agents they want.
We can put together a shared list of different tasks. I know LLMs-generated code is currently banned from the core, so let’s take tasks from HaikuPorts, write independent utilities, draw icons, or fix core bugs just as a “proof of concept” - purely for the judges to evaluate, without actually merging anything. We give everyone enough time so there’s no rush.
The most important rule would be a blind review. The solutions are kept hidden until both teams submit their work. Then, the jury reviews the code, evaluating its quality, architecture, and functionality without knowing which team or person wrote it.
I think this is a fair way to test both approaches in practice. If LLMs really just generates unreadable slop, a blind review will immediately expose it without any bias. At the same time, we can turn this whole argument into a fun challenge and actually get some useful utilities or solutions out of it. What do you think?
And this is the saddest part in this thread, Alex. I assume you’re not the only one who did that.
Well, if we were discussing it seriously then the only good answer would be switching to GPL license, and staying in the same legal boat with Linux.
What’s your selection criteria for the jury? How do you assure it is not biased (specific code style they prefer, perhaps architecture expectations more aligned with what LLMs generate, etc.)?
We have the official Haiku coding guidelines - all solutions must be formatted according to them, obviously. That’s just a simple yes/no checkbox for the jury: “coding style followed”.
The same approach should be used for the rest of the evaluation criteria. It should be a strict checklist: does the code work / does it do what is required / is there any spaghetti code, and so on.
As for the jury itself, we actually already have the right people for it. Thankfully, the project has plenty of experience participating in GSoC and Code-In
I don’t hate it; I’m always interested in blind tests of cultural biases. 
There’s no possibility that this can address any non-code-quality objections to LLM use, so it’s not going to convince many people that coding via LLMs is desirable (or even acceptable), but it’d be interesting to see how it goes.
I have no goal to convince anyone of anything. I just want everyone to get distracted from this endless flame war and simply have some fun
That exactly what I am saying: topics in “Proprietary & Other” should be protected from attacks how AI is bad/immoral/killing planet, unless topic itself is dedicated to AI pros&cons discussion. But unfortunately some forum moderators do not agree and think that it is fine to preach every AI user, even in “Proprietary & Other” category.
In this shape, I think that full ban of AI projects discussion is better than current state. At least AI users will be free from constant attacks and holy-wars. Better for both non-AI and AI users.
This agentic coding technology is not exactly mature, today, am I right? The LLMs you’re using today, will be useless relics next year.
I know that people with this new tool in their hands, will surely not be content to sit back and let the years pass while the situation sorts itself out. I’m just suggesting that this might be part of a good perspective on the matter. It’s an evolving situation.
LLMs tend to generate code that looks good on the surface, but contains subtle bugs, lack of error checks, that kind of thing. For me it is extremely hard to review such code (I trust people to test their own code before submitting). I think I am not alone in this case, although I know a few people who are very good at code reviews even in adversarial context such as finding intentionally hidden security problems.
And in a wider scope, LLMs tend to go to the most direct solution and fix just the problem you ask for. They will likely not look at the “big picture” (maybe due to context limitations, maybe just due to doing only what you ask for).
So, in a short sprint over a few days? Sure, the LLM team would win. Over several years of maintaining something like Haiku? I’m not so sure.
So here is a counter proposal: there are a lot of people interested in using LLMs in various ways to work on Haiku. Build a fork. You play with an additional advantage: you can merge all the manual work from Haiku developers (as long as your branch doesn’t diverge too much). If you are right about it, your project will be a lot more succesful, and the current form of Haiku will die. At that point, Haiku inc can transfer the Haiku name to that LLM enabled version. Maybe some of the developers who were against LLMs will admit they were wrong, and join your development team.
I hope we can take this as a non-competitive thing. This doesn’t have to be a fight. There are disagreements, we can talk about it, and if we conclude that we don’t want to live in the same project, we can fork peacefully. And everyone wins.
There were several topics in that category for a while now where none of that did happen. In fact, these topics are extremely quiet, as if no one really cares about these apps.
Then there was one topic started with an LLM summarized/generared post, to which I and another person (neither moderators) replied that this is 1) against the forum rules and 2) disrespectful.
Then a third person replied this:
At which point the thread went offtopic.
Moderators only joined the discussion much later. Please don’t blame them for things they didn’t do…
Would be good to have some real HAIKU meetings in some countries…
Where Haiku user can meet, discuss and help each other getting their HAIKU work.
So attendants could find out what is worth working and helping each other.
Something like a Haiku camp, whatever.
This would be possible without AI.
The next coding sprint/developer meetup is in Gdansk in november:
So far there are 3, maybe 4 people planning to attend. It would indeed be nice to see more people joining such events (LLM users or not).
That framing implies that the “problem” is just code speed; while all other things like maintainability, the ability to learn, moral arguments, philosophical etc. get discarded. I don’t see the point.
It’s like going to a sandbox and harrassing everyone to only play computer games instead, and then to calm down do a competition where the goal is to win as many computer matches as possible.
Point beeing, I don’t see why you think making people engage more with stuff they do not want to would calm anything down; some very vocal “LLM proponents” do not want anything to do with normal coding, as do some of the existing contributors not want anything to do with LLM generated code; obviously more moderate positions (e.g tabby) don’t factor into this, but then those weren’t the people who blew up the thread. Mostly it is again the usual agitators here who will try to blow up each discussion (and fake outrage) and then claim censorship when hostile behaviour gets rightfully evicted. Playing a match of LLM vs coding will not calm these people either.
So here is a counter proposal: there are a lot of people interested in using LLMs in various ways to work on Haiku. Build a fork. You play with an additional advantage: you can merge all the manual work from Haiku developers (as long as your branch doesn’t diverge too much). If you are right about it, your project will be a lot more succesful, and the current form of Haiku will die. At that point, Haiku inc can transfer the Haiku name to that LLM enabled version. Maybe some of the developers who were against LLMs will admit they were wrong, and join your development team.
I’m just an observer who is just getting started with Haiku right now, so I know I have no right to participate in this conversation. But this sounds like a very reasonable idea. A separate fork which down streams all the human work done in Haiku “main”.
But why do you say that Haiku would die from it? Why would it matter what people and machines do down stream or how popular something is, when Haiku is an open source project?
Open source projects are only “alive” in so far as that people engage with it and provide patches/tickets etc.
For example stuff like “Hannah montana linux” which is a downstream of debian probably only needs one person to maintain the small differences it has.
In this case if there is a Haiku and a downstream Haiku-ish with LLMS, if those are really better and everyone jumps ship, the upstream Haiku would die and the downstream one would take over so to speak; That would only be the case when the downstream version is vastly more succesfull anyhow.
I don’t think it will, but the people who think LLM are unavoidable and better and more powerful seem to think this is what will happen. Their fork will be better, people will use it, and everyone will leave the human-made version far behind, with less features, less hardware compatibility, worse performance, and so on.
If they are so sure of it, I think they should try it, and leave us alone staying behind. We will see what happens. Maybe they’re indeed right. Maybe not, maybe their fork will be abandoned first, or maybe it will be invaded by slop-coders or rogue LLM agents or some other misadventures.
Personally, I think it will not be the first fork of Haiku, it will not be the last, and while I have my ideas on which side of the fork will outlive the other, I could be wrong. And it doesn’t matter: I am happy that people find the Haiku codebase useful, even if we disagree on how it can be developped further. If it happens in a fork, I have nothing to say about that, and I wish them a happy and successful life. If it happens in a project I am maintaining, we need to agree on the direction, and for now, the agreed direction in Haiku is that LLMs are not welcome.
I don’t think anyone will change their mind, so we can continue arguing endlessly, or admit that there is no point in doing that, and have two different versions of the codebase. Sure, maintaining two projects instead of one spreads ressources, but at this point we are spending so much time and effort in forum posts that this would still be a better use of our time?
It’s been brought up before, but there is currently one active discussion of creating a fork: