Will FreeBSD adopt a No-AI policy or such?

The train of saying plain "no" to LLMs has left the station some time ago.

This means little.
What people want to fight against is "vibe coded" software or PRs. LLMs still have a ton of great usages around programming.

What people also want to fight against is taking the humanity out. This is not feudalism, we're not picking up a quota of crops to survive, programming and software engineering are both intellectual and artistry, for some projects, especially open source ones, the "output", the "velocity" or whatever norm is, is totally irrelevant. People need to have a good time with it. If I can't take a week to ponder and daydream about how to tackle a technical problem because some asshat with OpenAI premium acc is going to spam my project my vibe coded feature, I don't want to do it.

It is akin to the recent thing with live debates and google. You couldn't one-two in a debate prior to someone just picking up their cell from pocket with a wiseguy face. I just raise my voice and say put that shit down, do not google it. I don't care if we argue for one hour, the point is to argue.
 
There is a vibe coded BSD. Perhaps vibe coded efforts can go towards NextBSD given that it is a BSD that has already been assimilated into the collective. It will be the Brundle Fly of the BSDs.
 
There is a vibe coded BSD. Perhaps vibe coded efforts can go towards NextBSD given that it is a BSD that has already been assimilated into the collective. It will be the Brundle Fly of the BSDs.

Last I head NetBSD has a strict "no" on LLM generated code. Dunno about reviews, documentation etc.
 
What people want to fight against is "vibe coded" software or PRs. LLMs still have a ton of great usages around programming.

Correct. Regardless of the method of contributing, the contributor has to understand the code in question. This doesn't change with LLMs.
 
This means little.
What people want to fight against is "vibe coded" software or PRs. LLMs still have a ton of great usages around programming.

What people also want to fight against is taking the humanity out. This is not feudalism, we're not picking up a quota of crops to survive, programming and software engineering are both intellectual and artistry, for some projects, especially open source ones, the "output", the "velocity" or whatever norm is, is totally irrelevant. People need to have a good time with it. If I can't take a week to ponder and daydream about how to tackle a technical problem because some asshat with OpenAI premium acc is going to spam my project my vibe coded feature, I don't want to do it.

LLMs are really good at:
- Discussing ideas.
- Generating skeleton code.
- Creating unit tests.
- Documentation.
- Review.
- Finding bugs.

It's like having a second opinion, even a third. It's up to you if you want to also delegate the fun. We can throw the tedious parts to clankers.

LLM naysayers are entitled to their opinion. I don't buy the hype either. But an informed opinion involves trying the tech first, and the truth will always be somewhere in between.
 
rbranco and cracauer I generally agree but there is improvement to be done, some models are really docile and you can spin them around like a fiddle, so I've had hit and miss with the "conversation partner" and idea bounce sort of stuff.

LLMs can be a great tool to automate all the chores but it seems to me more than 50% of "developers" in this world think sitting down and typing code is a chore. Which it should not be - it is like a blacksmith saying hammering on the anvil is boring and stupid, while not being aware that person who operates the blast furnace is not a blacksmith but furnace operator. In (IRL) conversations with capable seniors around other companies, ones that are doing vibe coding, are saying the process is high quality and the code is OK, but not perfect and still leaves technical debt which will accumulate over time if mgmt persists with "no manual programming" dogma.

If anyone is not aware, vibe coding by proper people and companies looks like a completely formalized, persisted, stored set of discussions against LLM that also have a great benefit to double as ADRs (architecture decision records). A dev doesn't commit the code, but the session, the LLM does the code. This pattern was never introduced by devs but by mgmt that aimed to orchestrate the "AI" themselves, like telling it what to do via Slack bot or something.

There is an initial period where devs need to implement AI workflows inside the company and through this period the devs themselves start using the vibe workflow and cut down the standard programming. At a point near full transition, somebody from those managers will ask a senior or architect to guide them through implementing a feature, where they will witness first hand, they're useless as a developer, and everything they thought AI is is wrong. This will fly off silently, no bells no whistles because the AI investment is still alive as the developers are still being productive.

However debt is being accomulated on every project and the answer I get from people is "we don't care, its all on mgmt". Indeed they aim for a point of time when the tech debt starts crippling the project to negotiate higher pay to sort things out.
 
However debt is being accomulated on every project and the answer I get from people is "we don't care, its all on mgmt". Indeed they aim for a point of time when the tech debt starts crippling the project to negotiate higher pay to sort things out.

To be fair, that line of thinking is not new with LLMs.

In FreeBSD you need to get your code, no matter how you came up with it, past a couple of reviewers. That won't be easy for debt code.
 
Yes. Neither is suboptimal automatic code generation.

For FreeBSD I have no worries. Generally I have no worries for open source.
 
LLMs are really good at:
- Discussing ideas.
- Generating skeleton code.
- Creating unit tests.
- Documentation.
- Review.
- Finding bugs.

It's like having a second opinion, even a third. It's up to you if you want to also delegate the fun. We can throw the tedious parts to clankers.

LLM naysayers are entitled to their opinion. I don't buy the hype either. But an informed opinion involves trying the tech first, and the truth will always be somewhere in between.
Findings bugs is a joke... honestly the worst thing they do.
 
Findings bugs is a joke... honestly the worst thing they do.

Colin Percival & Linus Torvalds disagree. They have found bugs that were decades old and pieced together exploits in novel ways.

There's a huge asymmetric disadvantage for defensive security right now. It's irresponsible not to use LLMs to level the playing field.
 
Back
Top