I think I'm also going to refer people to the Godot foundation's statement on this from now on. Too often people try to lay it out like a moral conundrum, or some kind of purity test for "real" programmers vs larpers, but that's all just lips flapping. Meanwhile there are real-life practical consequences that follow taking AI contributions, and the Godot foundation has done a great job articulating what those things are. It's very nice for there to be a voice like saying these things.

That is a good point indeed.

I am wondering though if that was really the world we were living in just before chatGPT launched, given that the whole OSS thing was already harvested super hard.

The "mentoring opportunities" often were just extracting free consulting out of experts + building a portfolio for getting hired by big tech.

Would we really want to go back to that?

So I agree with the idea but only in a vacuum, I think.

I've seen developers pushing code repeatedly to car engine firmware with for-loops that weren't even valid C syntax, have yet to see a modern LLM do this kind of mistake

You've not worked with average developers then, or this is a purely reactionary/emotional statement.

I know what you mean regarding the class of mistakes, but strong disagree on the "worse" part.

Or rather I envy you for your experience with humans so far.

> OSS will die because of this

OSS will not die.

I think you're wrong. And I think that FOSS is our last best hope to keep software under the control of the individual.

The sloppers are diving head-first into a world where not knowing how a basic idea translates to code is embraced. This is not true of every slopper, but it is true of enough that sloppers are a threat.

Write assembly to do the syscall instruction with whatever params you need.

Dependencies: stolen from all code ever written without permission, including extremely illegal content

But other than that, totally dependency free!

Beats copy pasting from stackoverflow and calling it yours.

I guess code you get from a book too? Or learning it, and typing it out after you've mastered a particular algorithm?

(FYI I'm not disputing that the LLM vendors didn't steal, that doesn't mean the technology is shit)

The commit it reverted has a high probability of also being generated with an LLM, though without disclosing that in the commit message.

I'm not sure that is the case in this instance. Certainly general writing is a lot more variable and harder to classify, and on the other extreme certain one-line code changes don't have enough information to say anything. However, a blob with a 500+ line code change and 200+ lines of comments is a dead ringer for some of the current class of LLMs. That isn't to say it this behavior couldn't be obfuscated, but some basic categorization could probably separate the majority of human authored commits vs. AI commits. Heck, you could probably train an AI to detect commit-style just by using pre-2022 code archives and existing known-to-be-AI edits/commits.

The heuristics that would be used to "detect AI" here would be things that shouldn't be happening anyway, so false positives wouldn't matter.

It's not just "the code itself looks LLM generated" - it's also LOC/hr by a particular author which suggests vibe coding. You could look at the author's github contributions to identify time periods when the author was generating code at super-human speeds. Combine the two signals and you might get something better than a pseudoscience?

An agent doesn't have to be perfect to be useful. If it can find clear examples of stuff you don't want to see in a (potential) dependency quickly, that will save you time. Give it search tools and some policies, then have it go find things. You then check them out, ask followups.

Agents as a super powered (re)search assistant is underrated.

It's a fair comparison. There's a fair amount of plausible-sounding bullshit being peddled as a transparent advertisement for an ai-driven "code security" firm.

and how do you propose fixing the hundreds, if not thousands, of valid, impactful security bugs that frontier models will find?

> never rely on anything that wasn't at least seriously looked over by an LLM

I can imagine LLMs becoming a mainstay, but what you are describing isn't wholly different from sufficiently advanced static code analysis - where you'd want more determinism than most LLMs normally provide.

The problem is that such a thing might take a decade and billions of dollars of investments to create per-language (e.g. actually useful code analysis for Java, for Spring Boot, for processing and validating form data, and DB schemas and document processing and rendering reports etc., literal domain checks for anything and everything that is common across various enterprises) so nobody wants to do that, so it's easier to throw LLMs at it and call it good enough.

Yes, the same way 10 years from now-10years, we'd all be looking back at how insane it was for people to drive cars.

Man do I enjoy my totally real full self driving.

In ten years we'll be drowning in subtle bugs introduced by the unreliable garbage that is machine-generated code, and the industry will hopefully have learned to never rely on anything that wasn't at least seriously looked over by an actual thinking human being that understands it. We'll look back on our youthful idealism and cultish faith in this new technology with embarrassment.

Alternate take: in ten years we'll be pulling our hair out cursing at the world over how we could possibly accept "10k lines added, 8k lines removed" as the normal everyday churn of software development. We'll curse the morons who gave up understanding our own code.

In ten years, crypto will be the world’s primary currency. Oh look, stupid hot takes aren’t that hard to have after all.

I think the copyright and license question is one of the elephants in the room that hasn't had a satisfying conclusion. It's very important to have a clear idea of this for the open source movement.

Copyright won't be a problem. There's enough big business wrapped up in AI usage that the laws will bend towards them. Code quality and community don't die just because people haven't quite figured out how to use the new tools properly yet; quality merely dips for awhile, and the community continues as before. We survived PHP. We can survive this.

I disagree, but not in a downvote sort of way. I think your position is defensible, but there is a valid second perspective.

The sorts of folks who "won't be missed" put pedantry over productivity. To paint with a very broad brush, it's been my experience that they also tend to be stubborn and frustrating team members who don't understand that there's a time to debate and the rest of the time is for shipping.

5 years ago, I would agree with you. But when you go ALL IN on LLM development, and use annealing with multi-agent harnesses, these issues disappear. One caveat: I build everything off other things that originated with my own hand written code. Auth for my site, for example. Also, most of my current projects are packed with advice I've rendered to the LLM on how git commits go down and cadence of those commits into deployments. Claude Code rarely fucks this up, and has memories and plan files that it updates if we find a hole. So, I'm comfortable with an occasional hiccup in the process. It'll get caught, eventually. Maybe. ;)

A recent analysis on my Claude Code prompts showed 1.5B input tokens over the last few months. I use 4-5 provider agents (all CLI) DAILY, so this is a small subset. I spend a lot of time using transcription services to drone on about how some agent fucked things up and how I want it fixed and how to do it.

To assist with that process, I'm currently building out a search engine that is exposed via MCP to allow auditing of the dev runs. I already have the foundation of file changes (ala Splunk style) that let me keep an eye on the agents, and an agentic terminal that allows one agent to keep an eye on what the other agent is whacking on. Combined with my constant badgering for proper systems development, these things are improving the process at an acclerated rate.

Look, I get being an "engineer" on these types of things, and I think there is an absolute purity in pushing LLM generated code out of a codebase you control. That said, that's not the ONLY way to do things, and your milage will vary based on your systems thinking hat. I prefer to push hard on getting the outcomes and sacrifice the exhaustive process of reviewing every single line of code.

Consider frameworks. They make things easier to do, if they are complete and stable. There's an argument here that LLM harnesses should probably not ALSO be maintained by LLMs (something I'm completely ignoring so probably ironic I'm mentioning it). But the point being is the harnesses SHOULD have eyes on most lines of code. Eyes on every package though? Hard to say. I've settled on doing most stuff in Rust nowadays, just because it keeps the LLM more honest. And, we can build most "packages" by hand so we can change them to match our outcomes without code bloat. By bitching at it about code refactoring constantly, annealing the codebase by high level overview, not exhaustive review, I've found things get easier to work on as I go and still stay sane.

I do catch the LLMs occasionally hard coding things that belong in their own file or configs, and am a hardass about that and file length. I do read some code and hate it being overly long (and it sucks for burning tokens).

FWIW, I typed all this out on my keyboard myself. However, if I ran it through an LLM for cleanup or whatever, the very wall of text itself helps FORCE the LLM to stick to the substantive argument and steers it away from slop prompts. The same applies to code, if you are careful.

Most software of the future will have userbase of 1.

You won't be selling software. You'll be selling a service of assisting someone so they can build software for themselves.

If you had to pick one, sure. But it's trivial to have both which is the point of those cringey websites like http://bettermotherfuckingwebsite.com