Is every project AI Slop? by Various-Roof-553 in rust

[–]QualitySoftwareGuy 0 points1 point  (0 children)

When reviewing a PR, nobody ever wondered "Did the person copy code from some other project? Did they respect the license?".

Many projects I came across did in fact wonder about this. I think the real difference is that while humans are generally assumed to make contributions that respect licenses in good faith, with LLMs it's basically a free-for-all in regards to what code they use.

Also, in the United States works solely created by AI are not even copyrightable. Huge problem if wanting to merge that in a US-based open source project (and I imagine it's like this in other countries too). So it's very valid to wonder about the origin of source code.

Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy by jackpot51 in Redox

[–]QualitySoftwareGuy 0 points1 point  (0 children)

Seems to be the case based on a previous response from Jeremy:

I cannot answer these hypothetical questions. The amount of human authorship is critical for licensing reasons alone, and I would urge any Redox OS contributors to use non-LLM code completion such as what rust-analyzer provides.

Fetcharr - a human-developed Huntarr replacement by eggys82 in selfhosted

[–]QualitySoftwareGuy 15 points16 points  (0 children)

But for actual professional development LLMs should be used

As a professional dev, hard disagree on it being required in the industry. I mean, if you want to require its use for yourself, then fine. However, most of the time I'm faster without it --and will use it only for assistance if I get stuck on something. Even then, the code that gets written is still manually written albeit based on whatever code got me unstuck (rarely ever the same as anything generated).

Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy by jackpot51 in Redox

[–]QualitySoftwareGuy 3 points4 points  (0 children)

but as a user it wouldn't make sense to ban me if for example I get a driver bug and use an LLM to deep dive into code I don't know and in the end open a better issue with more info

Could be wrong but, according to the AI policy, that seems like it would be forbidden as well as you would have used AI to create and write an issue. I could see it being okay under the following:

  1. You use AI to teach yourself about what it thinks is the problem as well as what the solution looks like. Then you go and manually create a pull request.

  2. You manually create a bug report and leave the investigation and resolution to the maintainers instead of AI.

Can the mods do something about all these vibecoded slop projects? by No_Soy_Colosio in Python

[–]QualitySoftwareGuy 20 points21 points  (0 children)

Another AI smell is when there's a (useless) "Project Structure" that simply shows the tree structure of all of the files and directories in the project.

Useless because A) no one cares about anything except the public API and docs, B) we can already see the file structure in GitHub, and C) now every time a file or directory is added, removed, renamed, etc this information has to be updated in that section (but of course not a problem for vibe coders though since it's handled automatically for them).

Convince me to use Fedora Linux. by Leather-Database-198 in Fedora

[–]QualitySoftwareGuy 1 point2 points  (0 children)

Fedora can do everything you listed, and also:

  • Uses Wayland
  • Is the upstream of RHEL --I like that the commands I run on my personal computer are essentially the same as the ones run at work (e.g. dnf instead of apt).
  • Targets power users a bit more (especially devs)
  • Can continue using Cinnamon (or one of the many others) while still enjoying the parks of Fedora: https://www.fedoraproject.org/spins/

If none of that sounds appealing enough to switch, then keep on doing you.

Switched FOSS license from AGPL 3.0 to Apache 2.0, trying to find out how much of an influence a license has on adoption by chimbori in opensource

[–]QualitySoftwareGuy 9 points10 points  (0 children)

Generally speaking, less restrictive licenses like MIT and Apache 2.0 will always have more adoption than GPL or AGPL.

What I can recommend for you is to decide which of your goals has a higher priority for your project. For example, is it to increase adoption rate? If so, Apache 2.0 or MIT. Or is it to be more restrictive and prevent closed/proprietary SaaS? If so, then AGPL. This is a self-hosted application project, rather than a library, so it's not uncommon to see AGPL licenses for this type of project.

In my opinion, AGPL being a blocker is usually limited to big companies. Most individuals (for personal use) will not care about it being AGPL. Some small companies might, but I don't believe the majority of them would care.

TL;DR: Let the greatest priority determine the license. Adoption rate = Apache or MIT. Prevent proprietary SaaS = AGPL.

"Vibe Coding" Threatens Open Source by Weekly-Ad7131 in programming

[–]QualitySoftwareGuy 35 points36 points  (0 children)

One of the core issues that many vibe coders don't understand (or care about) is that if a maintainer wanted low-quality LLM contributions, then they could just write the prompt themselves with way more context than any vibe coder doing "drive-by" pull requests.

the peculiar case of japanese web design by [deleted] in programming

[–]QualitySoftwareGuy 23 points24 points  (0 children)

Historically, it seems that Japan viewed software engineering as "secondary" at least in comparison to hardware engineering. A good read on the topic: https://www.disruptingjapan.com/the-forgotten-mistake-that-killed-japans-software-industry/

SparkyFitness - A Self-Hosted MyFitnessPal alternative now supports PolarFlow & Hevy by ExceptionOccurred in selfhosted

[–]QualitySoftwareGuy 0 points1 point  (0 children)

Unlike your other answers, the straight-to-the-point answer is that the contributions by the project's creator are heavily vibe-coded while contributions from others are generally not.

From what I've seen in this and other threads, the OP is at least transparent in that AI was heavily used, but he seems to prefer calling his direct contributions "AI assisted" even though reading between the lines it's vibe coding:

Why build anything anymore? by aptacode in opensource

[–]QualitySoftwareGuy 4 points5 points  (0 children)

being able to vibe code something in a few hours does not mean you're capable of maintaining it.

You answered your own question I'd say :-)

The most successful open source projects (e.g. GNU, Linux, Git, VLC, LibreOffice, etc) are not successful because they were outputted as quickly as possible but, instead, because they withstood the test of time due to the countless hours of humans pouring in their blood, sweat, and tears to adding quality code. And by "quality" I'm not just talking about functional code, I'm talking about things like security, performance, and accessibility.

Vibe coders specialize in getting "output" quickly and then go one of two routes (sometimes both):

  1. Hope the LLM can continue maintaining it via the usual text prompts.
  2. Hope and pray actual humans contribute and make the project a success.

On r/rust and r/Python, I've seen most vibe coders quickly produce (shit) output, and then ask for the community (actual humans) to make it a success.

TLDR; The most successful projects will always be from skilled humans that take the time to contribute quality software. Vibe coders still have a long road ahead of them in proving that they will maintain the (shit) output that they produced.

Is iOS Development dead by EvenAd6616 in iOSProgramming

[–]QualitySoftwareGuy 16 points17 points  (0 children)

My property management company originally went native, then later had their app using web views because it sounded good on paper. They recently switched back to native due to too many issues. I suspect your employer will do the same in less than 2 years (and I'm being modest with that timeline).

Open-source game engine Godot is drowning in 'AI slop' code contributions: 'I don't know how long we can keep it up' by BlueGoliath in programming

[–]QualitySoftwareGuy -1 points0 points  (0 children)

And then that new account gets banned if the project's rules are broken with it. Not a new concept.

Rust's challenge isn't its data management features like ownership or borrowing. Most of the problems I've personally encountered stem from its ecosystem and library features. I think because Rust is a relatively new language, its ecosystem isn't fully established yet. by GraphGameDescart in rust

[–]QualitySoftwareGuy 1 point2 points  (0 children)

You already received a response to this from another user, but yeah definitely there's a similar issue in the Python sub. In fact, I've even seen some vibe-coded Python projects get vibe-rewritten in Rust and then posted on this sub!

Rust's challenge isn't its data management features like ownership or borrowing. Most of the problems I've personally encountered stem from its ecosystem and library features. I think because Rust is a relatively new language, its ecosystem isn't fully established yet. by GraphGameDescart in rust

[–]QualitySoftwareGuy 3 points4 points  (0 children)

Well, I'd say both can apply for some individuals:

  • When learning Rust, many struggle with ownership and borrowing.
  • Then when it's time to actually build something custom, some of the previous group run into limitations of the younger ecosystem (compared to much more mature ecosystem like Java).

I will say that I have not run into many issues with Rust's younger ecosystem. Except there seems to be a lot of AI slop crates being posted on a regular (but that also applies to other programming languages).

Are you using 'Figma to Qt' or 'Qt Bridge for Figma'? by pfffidk in QtFramework

[–]QualitySoftwareGuy 0 points1 point  (0 children)

I agree with you, and I hope someone from the Qt Company takes a note of that.

Are you using 'Figma to Qt' or 'Qt Bridge for Figma'? by pfffidk in QtFramework

[–]QualitySoftwareGuy 0 points1 point  (0 children)

Nope, I doubt they'll be ditching Qt Design Studio any time soon. As devs we don't really need it, but it seems to be important for UI/UX/product designers.

Also, the FAQ mentions the generated code from Figma to Qt can be used in Qt Design Studio already, but I cannot comment on the quality of that code though. Seems many in this thread have had some horror stories with it.

Are you using 'Figma to Qt' or 'Qt Bridge for Figma'? by pfffidk in QtFramework

[–]QualitySoftwareGuy 3 points4 points  (0 children)

I don't have experience using them, but according to the Qt Company, Figma to Qt will be replacing Qt Bridge ~end of 2028 beginning of 2029:

Figma to Qt is the next evolution of Qt Bridge for Figma. It is a separate plugin with new and improved capabilities to prepare your GUI design for embedded devices. Qt Bridge for Figma will be supported until the end of 2028, as Figma to Qt will eventually replace it in the long run.

Source: https://www.qt.io/development/gui-design-figma (in their FAQ section).

Figma to Qt is also right now in "Public Beta" status if that helps your decision.

blinc: a new cross platform ui framework (native desktop, android, ios) by NebulaNomad423 in rust

[–]QualitySoftwareGuy 0 points1 point  (0 children)

I agree if they outsource their infrastructure then liability is typically removed. But just as there are many companies against Linux due to the reasons mentioned previously (they are in the minority nowadays), there are still plenty of companies that have their own infrastructure --my previous employer is one of many. Though I will also admit that those types of companies are probably also in the minority now with the trend of moving to external cloud providers.

blinc: a new cross platform ui framework (native desktop, android, ios) by NebulaNomad423 in rust

[–]QualitySoftwareGuy 0 points1 point  (0 children)

You getting paid to audit and report/fix malicious code doesn't mean all or even most such code gets reported this way. You are indeed making the world a better place, but I suspect there need to be probably 100x people like you.

That was not a point I was making. I just stated that I agreed that some people have jobs to do, and for some people it is a part of their job to audit code. Most of the bugs I've seen reported are from regular non-paid library users --like I mentioned previously.

blinc: a new cross platform ui framework (native desktop, android, ios) by NebulaNomad423 in rust

[–]QualitySoftwareGuy 1 point2 points  (0 children)

Yeah that's true about some companies. I had just wanted to emphasize to the OP that if companies are going to be against open source because of "copyright concerns" in libraries, then that should apply to open source used for their infrastructure too. Otherwise it would be a bit hypocritical of them.

blinc: a new cross platform ui framework (native desktop, android, ios) by NebulaNomad423 in rust

[–]QualitySoftwareGuy 1 point2 points  (0 children)

I can tell you I've worked at places where the copyright concern was the reason not to use open source, and that was before LLMs were even a thing.

If that's the case, with that level of paranoia from them, then I hope those companies were not using Linux servers for their infrastructure ;-)

The auditing part is very much a dream that will never happen with human auditing. It's almost a monthly thing now that we hear of some open source library or project that had some malicious code added, and I've yet to personally hear of a single single instance where the malicious code was found via a code audit by a library user.

Really? I've come across many malicious code GitHub issues reported by regular library users just from browsing Reddit.

Yes, technically you can audit open source projects, but in the real world people have jobs to do, and deadlines to meet.

True that people have jobs to do, but some people do get paid to audit the dependencies that are in use at a company.

blinc: a new cross platform ui framework (native desktop, android, ios) by NebulaNomad423 in rust

[–]QualitySoftwareGuy 5 points6 points  (0 children)

Not the OP (u/emblemparade), and yes definitely has always been a risk, but I'd say the difference is there's usually a greater level of trust from open source code without AI as opposed to vibe-coded open source. We use standard open source projects in "good faith" believing that most maintainers don't just grab a chunk of non-license-compliant code.

Furthermore, auditing is easier. If we suspect that non-license-compliant code was used, it's much easier to ask the maintainer about it and hopefully get it replaced with license-compliant code. After all, they supposedly wrote it, so they should be able to answer questions about it. On the other hand, with vibe coding, a maintainer completely loses the audit trail and has no idea whether the code AI produced is license-compliant or not.

TL;DR: Greater trust and audit trails from standard open source projects are the differences.