How many of these AI vs. no AI flamewar threads do we need?
Me: 0
Reality: More!!!
Not my experience. Have you actually used an LLM? This sounds like the type of argument Iâve heard from those that have not really ever used one, or have never tried any agentic coding. If you had used one you would know that one of the fundamental things you can do is put it in auto mode (as in - do this thing and tell me when you are done), but actually that is highly destructive. Generally we would use plan mode to spec out the work. Agree the plan, and then let it apply the changes, and accept each line changed in normal use. So basically the human reviews the changes. That is the fundamental difference between vibe coding and agent assisted coding.
We also have to distinguish between promoting an LLM and using an agent. Agents have roles and have specific instructions. Going to the Claude website and asking it to do something in the chat is massively different than using Claude code, Codex, Antigravity or Opencode. Bun is now written in Rust because Claude was used to convert the code from Zig. I encourage you to read the blog the developer who did this wrote. He didnât just get A to be B, there is a whole massive process he went through and it feels like some of it would actually benefit Haiku - the code review and code criticism parts. This would not change any code, but it would objectively give the developers something to think about.
Finally, I use LLMs on a daily basis to create code. I then iterate on what they create. They are extremely good at giving you a starting point. They are extremely good at spotting bugs. They are extremely good at grunt work. They are only toys if you donât actually look at the code.
BeOs was always very fast and innovativeâŚ
But Haiku has become an old fat lady waiting for conversation only and looking what her neighbor is doing and talking to herselfâŚ
Use it or not!
Learn from it or not!
How many of these AI vs. no AI flamewar threads do we need?
Me and BlueSky: 0
Reality: More!!!
You are right. Sometimes, when I give lectures on AI utilization, that very point is where I begin.
At its core, an LLM is nothing more than a bundle of probabilities designed for sentence completion. That is true. However, as the training data expanded exponentially and absorbed the entirety of human knowledge, LLMs began to mimic human intelligence. That is precisely why we started calling them AI.
I have been in software development for over 30 years, but since last year, I no longer write code. I only review it. I simply accepted the fact that LLMs possess far superior software engineering knowledge than I do. It is an undeniable truth.
Watching Claude build hardware drivers for my Sony VAIO P was nothing short of miraculous. It dumped the CMOS, rewrote assembly code, and ported archived Windows drivers entirely from scratch. As a veteran senior developer, there was no way I could ever match that scale of knowledge or sheer speed. So, I chose to accept it.
Yes, humanity might get lost along the way. That is why, in an era where business owners are practically itching to adopt AI and cut developer jobs, I have begun to ponder deeply once again about what my new role should be.
It wasnât developers who went looking for AI. My sense is that AI simply came looking for usâlike a tsunami, like an overwhelming incoming tide. I hope we can keep talking about whether AI is good or bad. Perhaps that is one of the few remaining things I, as a human being, can still do with other human beings.
We have several users who run Haiku as their main operating system, including myself.
There are various reasons for this, some practical (the system overall has low latency and low resource usage, meaning it can run on old computers; it doesnât spy on you and your data; the UI remains traditional and doesnât keep changing; the system is simple enough that a single person can understand and fix it as needed; or even simply legacy reasons of having files and apps from BeOS that they need or want to keep working). And, yes, some of these things also make it enjoyable or even âfunâ to use.
So, itâs far from being just a toy operating system project. Does it come with constraints when you chose to use it as a daily driver? Yes, sure. But other systems do as well, including putting your computing environment in the control of big companies like Apple or Microsoft, or very large teams of open source developers which may take decisions you are unhappy with, and so large that you have little chance of having any influence.
The fact that there is a little bit of success in that is also one important aspect of Haiku. A living example that yes, you can in fact build a daily-driver grade operating system with a small team of hobbyists, and actually compete with much larger projects like the entire Linux stack or the teaps at Microsoft and Apple. In this aspect, the project in itself can be seen as a kind of statement against the fatality of mrega-corporations owning everything.
I hope you can understand this point of view and see why the use of LLMs - especially the for-profit ones - can be seen a big problem in that view.
Very nice, but do you consider the drivers infallible and/or code complete?
My personal opinion: Haiku is more dead than alive. And it should die like BeOS. BeOS died and gave birth to Haiku. Haiku will die, and something new will emerge. Haikuâs development has stalled. No one is interested in porting the OS to new architectures. Where are the innovations and unusual solutions (like BeOS)? Now Haiku monotonously repeats the mantra of a dead OS, like an office clerk. History is written by the victors and innovators. And weâre breaking spears in debates about whether innovations like AI are needed, instead of integrating them and becoming stronger.
BeOS death didnât gave birth to Haiku.
People working together gave birth to Haiku.
When Haiku project will die (as everything dies), if nobody works together to create a new project to keep somehow its legacy, it wonât happens. There is no magic.
and to assume that the generated driver is reliable and complete?
Think about the questions weâve asked nvidia so far.
Nothing is infallible. What a gross statement. I would argue my USB stack, audio, and midi drivers are all more complete than the Haiku ones. And while not infallible, I know they are very stable (again, more so in a lot of areas) because of the thousands of hours that I put into extensive testing, using more hardware than it appears any of the devs had at their disposal. So when a huge chunk of the community, that is frankly doing most of the exciting work, gets ridiculed on just about every post they make about their project, you can see why feel the need to defend ourselves so strongly. No âvibe coderâ would be able to handle the complexity of programming kernel drivers for a niche OS. They may be able to make small apps that may be useful to themselves, but once the complexity grows, they will break, and they will not likely have the knowledge, or more importantly the patience and persistence to make it all work. My agentic engineering use of Claude Code goes way beyond that. I am solving bugs that have been lingering in haiku codes for well over a decade. This week, I am getting through having wasted half a day of work, and then another 2 days working on a solotuion - all because of poor Haiku documentation (btw, using AI could help you all out with missing and outdated documentation).
Iâm not crazy, my reality is just different from yours. Putting aside the AI ââcontroversy, thereâs only one thing to say: this OS is wonderful and beautiful in every way, except for one thing: it was impossible to live (or use). There are 1,000 devices being developed worldwide, and how many of them use Haiku? An OS with high-quality code and solutions ahead of its time. Without AI code. Why is it being developed? So that 300 people on planet Earth can run it and, with a few tears, remember how 25 years ago the grass was greener and the girls younger? BeOS was Media OS; for example, can Haiku now be used as an OS for a media player? What would a specialist or enthusiast in China or America say, âHereâs the code, itâs easy to add a specialized driver, itâs easy to maintain, it has all the necessary applications for real-world use, it runs on hardware ranging from RISK-V to ARM, itâs easy to update, everything you need is there and it works like a sundial.â So letâs use it as the basis for a new product. If you put aside the nostalgia for the old days, we have zero. It seems like there is, but itâs not. And at this time, dividing users by their attitudes toward AI is stupid. When these people die, where will we find new ones? I donât see a line of young people ready to take over the flag from the leading programmers; I even see that packages are usually updated by just one person on a regular basis, not even two. What are we fighting a war for, why are we banning users?
Considering you submitted completely wrong reports based on this workflow, and the description describes most bugs fixed in Haiku overall I donât see what your deal here is.
You seem to badly try and remove the âvibe coderâ label, but honestly all your âand then I use another AI tool for thisâ comments donât make you less of a vibe coder, but more of one.
You donât increase your chances in dice by betting all dices are a 6 and then increasing the number of rolls.
âI dispute your assertion that cola contains water. have you actually drank cola? It tastes nothing like waterâ
Since LLMS move towards the averages and not the extremes this can be true, but only if one has sub-average software engineering knowledge.
But then if one does have worse engineering knowledge one would likely also lack the skills to evaluate the output for correctness, and outsourcing any decisions to such a model would become even more questionable (in itâs usefullness).
I hope there will be reflection and a sincere apology. I was very happy to meet Haiku, but the attitude of the Haiku developers I saw in the community is very disappointing.
What do you disagree with? that LLMS lead to averages? Or did you interpret this as an insult? The âyouâ here is not a reference to your person but a generalization, (i.e: âhow can one turn this machine offâ âHere is how you can do thisâ) this is not always clear in english I suppose. I assume more that you misjudge your skill here when you assume that a statistical model is always better than your own knowledge
Though obviously, it is itself quite hostile to assume ill-intent instead of simply asking for the intent shrug
Here we go again. Everyone hold onto your hats. ![]()
- Youâre free to use whatever tooling you like.
- The moderators of the forum are free to shutdown discussions on topics misplaced or unrelated to the subject-matter of the forums. (talking about using AI to build a 3rd party Haiku application is 100% in scope within the correct forum categories, just like talking about your favorite IDE)
- A policy has been put in place at the bequest of the community to not accept machine-generated code in Haiku itself based on how LLMâs stand today. (Ignoring all of the âAI badâ arguments, legally it IS currently questionable for our clean MIT-licensed codebase. Maybe if LLMâs trained exclusively on MIT-licensed code materialize, or there is a substantial shift in copyright policy around machine generated code, the policy could be adjusted in the future with the communityâs support.)
- Shaming people for using AI tools in 3rd party projects is not ok.
- Attacking people for using AI tools in 3rd party projects is not ok.
Personally, iâve currently moved my own development time and energy onto other projects because of the new policy. I still help maintain stuff, and still help manage infrastructure.
Personally I find LLM-based coding helpful and have rapidly finished some 3rd party projects iâve needed / wanted for a long time.
Congratulations. Youâve successfully driven away yet another group of new developers who were curious about Haiku.
First of all, I didnât submit anything that was completely wrong. I was unaware that the refusal of AI assistance went well beyond actual code merge/pull requests, so I did submit an AI generated report to the tracker. That does not mean any of it was wrong. I am sorry that the report was a little too verbose, but it definitely was not wrong, and the issue could have easily been fixed from the report directly, if it wasnât for refusal to actually read it. But instead I had to go back and put it in 100% my own writing in very simple terms. Not an issue, I owned my mistake and I will not submit anything to trac, or to this forum, that isnât in my own words. So far, I only submitted a kernel bug, but I have found dozens of Haiku bugs at this point. These will be upstreamed as bug reports as soon as I have the time for it.
Sadly, we might be at a point where there are irreconcilable differences between the core developers and some members in the community.
Perhaps itâs worth having a serious conversation about moving parting ways.
context: Iâm 100% biased being on the board of directors for Haiku, Inc.
I know we have historically seen a big drop-off of contributors prior to the industry AI shift. The number of knowledgeable C/C++ developers (with the free time to contribute to open source) has dropped significantly over the last 5-10 years.
AI-assisted coding might be a large force in revitalizing Haiku. It will introduce C/C++ to a younger generation and get them interested in lower-level coding.
However, by the same sword, LLMâs do add a large amount of unknown to the legal landscape. IF Haiku accepted machine-generated code contributions, it would be legal cats we couldnât put back into the box. Weeding out 100âs of machine-generated commits (and then the commits on top of those commits) would potentially poison the project if legal challenges developed.
The concerns are real. We have 20+ years of cleanly MIT-licensed code I personally agree with not being poisoned.
Thereâs a lot of strong feelings on the AI stuff for varying reasons. A lot of the arguments donât resonate with me⌠but the legal one above I canât ignore.
Forking just kind of pushes the problem down the road. We still struggle for developers. A fork would likely also struggle in that way (even with AI assisted machine generated code). We have seen a few forks over the years come and go. Not a reason to not fork, but context.