Isn't this what the free software movement wanted? Code available to all?

Yes, code is cheap now. That's the new reality. Your value lies elsewhere.

You can lament the loss of your usefulness as a horse buggy mechanic, or you can adapt your knowledge and experience and use it towards those newfangled automobiles.

But this is not that. The current situations is closer to "what's yours is mine and what's mine is mine".

I have been releasing my writings under a Creative Commons Attribution-ShareAlike license which requires attribution and that anything built upon the material to be distributed "under the same license as the original". And yet I have no access to OpenAI's built-upon material (I know for a fact they scrape my posts) while they get my data for free. This is so far legal, but it's probably not ethical and definitely not what the free software movement wanted.

Available to all yes. Not available to the giant corpos while the lone hobbyist still fears getting sued to oblivion. In fact that's pretty much the opposite of what the free software movement wanted.

Also the other thing the free software movement wanted was to be able to fix bugs in the code they had to use, which AI is pulling us further and further away from.

Decompiling and re-engineering proprietary code has never been easier. You almost don't even need the source code anymore. The object code can be examined by your LLM, and binary patches applied.

Closed source is no longer the moat it was, and so keeping the source code to yourself is only going to hurt you as people pass you over for companies who realize this, and strive to make it easier for your LLM to figure their systems out.

Jesus christ.

"The people who wanted everyone to have a home should be happy with the invention of the lockpick. You can just find a nice house and open the lock and move in. Ignore the lockpick company charging essentially whatver they want for lockpicks or how they got accesss to everyones keyfob, or the danger of someone breaking into your house"

That is basically your argument. Like AI is a copyright theft machine, with companies owning the entire stack and being able to take away at will, and comitting crimes like decompiling source code instead of clean room is not a selling point either...

The open source community wants people to upskill, people become tech literate, free solutions that grow organically out of people who care, features the community needs and wants and people having the freedom to modify that code to solve their own circumstances.

Stop trying to make this into some abstract argument. It's not an argument anymore. It's already happened.

How one might choose to characterize the reality, is irrelevant. A vast (and growing) amount of source code is more open, for better or worse. Granted, this is to the chagrin of subgroups that had been pushing different strategies.

Agreed.

> Stop trying to make this into some abstract argument.

As you mentioned, it's not an abstract argument. It's statements of fact.

> A vast (and growing) amount of source code is more open...

No, not at all.

1) If you honestly believe that major tech companies will permit both copyright- and license-washing of their most important proprietary code simply because someone ran it through an LLM, you're quite the fool. If someone "trained" an LLM on -say- both Windows 11 and ReactOS, and then used that to produce "ReactDoze" while being honest about how it was produced, Microsoft would permanently nail them to the wall.

2) The LLMs that were trained on the entirety of The Internet are very, very much not open. If "Open"AI and Anthropic were making available the input data, the programs and procedures used to process that data, and all the other software, input data, and procedures required to reproduce their work, then one could reasonably entertain the claim that the system produced was open.

That ship has sailed. The revolution is happening. We live in a new reality now, one where we're still trying to figure out what rules should even be.

And there will be winners and losers, and copyright and patent law will be modified in an attempt to tame the chaos, with mixed results because of all of the powerful players on both ends.

You can live on the front of it for high risk/reward, or at the back for safety. But either way, you're going to exist in this new reality and you need to decide your risk appetite.

Code isn't like a house, you can just copy it and put the copy somewhere safe.

The reproduction of the object is essentially free in the internet, but the labour to produce it isn't.

If I spent 3 years making my codebase, and you copy paste the git repo, yeah your access to the information is not going to replace the original. But your labour cost is 0 and you can undercut the 3 years of expense, loans or debt I adquired to produce it.

Btw the FBI murdered Aaron Swartz for attempting to open access to research papers, Mark Zuckemberg admitted to stealing those ssame papers through libgen and showed off the results of Llama and his stock price went up.

I think the piracy argument falls apart when the class warfare and 2 tier justce system is openly weaponised towards open access

Almost nothing does. Value is largely subjective. You deciding it is irrelevant to you is as inherently worthless as the marxist ideal that labour is the maximal value of society.

The non subjective opinion is that there is a necesary amount of work/energy requiered to create things and that the created things can be consumed/used by others.

LLMs do not reduce labor to 0, the energy to power the GPU, the labor to create the gpus, the labor to train the models is all there, as well as all the labor to produce the original material the LLM is trained on. Even if the subjective experience of someone consuming the created thing is the same.

Or Oracle for databases.

Or Microsoft for operating systems.

Or DEC for computers.

There are perfectly good open source LLMs and agents out there, which are getting better by the day (especially after the recent leak!)

I want to support RISC V over Intel.

I want other things too, and on balance, Intel+Anthropic is most compliant with my various preferences, even if they're not perfect.

they’re not free in any sense of the word. from price to openness of the models. would openai cry if every bit of their models were wide open for us to use however we see fit? if so, then it’s not free, again, in any definition of the word.

Local models are a thing.

You speak as though that were a bad thing. I'd rather not have people accidentally burning their houses down.

Once it's approved for an area, you go to your local shop, buy an approved PV system, and plug it in. No fuss, no worries, and your insurer must cover it.

This is with today's efficiencies. They are of course improving.

But I'm not you. What works for you may not be a panacea. I work best with notes in a text editor, in markdown. I like to be able to move thoughts around, rearrange them, refine them. That also makes me remember them better. Handwritten notes are not conducive to that.

One thing I do like, however, is how agents add themselves as co-authors in commit messages. Having a signal for which commits are by hand and which are by agent is very useful, both for you and in aggregate (to see how well you are wielding AI, and the quality of the code being generated).

Even when I edit the commit message, I still leave in the Claude co-author note.

AI coding is a new skill that we're all still figuring out, so this will help us develop best practices for generating quality code.

Whoever is submitting the code is still responsible for it, why would the reviewer care if you wrote it with your fingers or if an LLM wrote (parts of) it? The quality+understanding bar shouldn't change just because "oh idk claude wrote this part". You don't get extra leeway just because you saved your own time writing the code - that fact doesn't benefit me/the project in any way.

Likewise, leaving AI attribution in will probably have the opposite effect as well, where a perfectly good few lines of code gets rejected because some reviewer saw it was claude and assumed it was slop. Neither of these cases seems helpful to anyone (obviously its not like AI can't write a single useable line of code).

The code is either good or it isn't, and you either understand it or you don't. Whether you or claude wrote it is immaterial.

AI is a very new tool, and as such the quality of the code it produces depends both on the quality of the tool, and how you've wielded it.

I want to be able to track how well I've been using the tool, to see what techniques produce better results, to see if I'm getting better. There's a lot more to AI coding than just the prompts, as we're quickly discovering.

Claude-generated code is sufficient—it works, it's decent quality—but it still isn't the same as human written code. It's just minor things, like redundant comments that waste context down the road, tests that don't test what they claim to test, or React components that reimplement everything from scratch because Claude isn't aware of existing component libraries' documentation.

But more importantly, I expect humans to be able to stand by their code, and at times defend against my review. But today's agents continue to sycophantically treat review comments like prompts. I once jokingly commented on a line using a \u escape sequence to encode an em dash, how LLMs would do anything to sneak them in, and the LLM proceeded to replace all — with --. Plus, agents do not benefit from general coding advice in reviews.

Ultimately, at least with today's Claude, I would change my review style for a human vs an agent.

As you allude to (and i agree), any non-trivial quantity of code, if SOLELY written by claude will probably be low-quality, but this is apparent whether I know its AI beforehand or not.

I am admittedly coming at this as much more of an AI-hater than many, but I still don't really get why I'd care about how-much or how-little you used AI as a standalone metric.

The people who are using AI "well" are the ones producing code where you'd never even guess it involved AI. I'm sure theres linux kernel maintainers using claude here and there, its not like they expect to have their patches merged because "oh well i just used claude here don't worry about that part".

(But also yes, of course I'm not going to talk to claude about your PR, I will only talk to you, the human contributor, and if you don't know whats up with the PR then into the trash it goes!)

While code is good or not, evaluating it is a bit of a subjective exercise. We like to think we are infallible code evaluating machines. But the truth is, we make mistakes. And we also shortcut. So knowing who made the commit, and if they used AI can help us evaluate the code more effectively.

That being said, it also matters who wrote it, because it’s more likely for LLMs to write code that looks like quality code but is wrong, than the same is for humans.

Maybe one day we can say that, but currently, it matters a lot to a lot of people for many reasons.

That was my point here, it is a false signal in both directions.

For instance, I would want any AI generated video showing real people to have a disclaimer. Same way we have disclaimers when tv ads note if the people are actors or not with testimonials and the like. That is not only not false, but is actually a useful signal that helps present overly deceptive practices.

If I have a block of human code and an identical block of llm code then whats the difference? Especially given that in reality it is trivial to obfuscate whether its human or LLM (in fact usually you have to go out of your way to identify it as such).

I am an AI hater but I'm just being realistic and practical here, I'm not sure how else to approach all this.

The problem is that submitters often do not feel responsible for it anymore. They will just feed review comments back to the LLM and let the LLM answer and make fixes.

This is disrespectful of the maintainers' time. If the submitter is just vibe/slop coding without any effort on their part, it's less work to do it myself directly using an LLM than having to instruct someone else's LLM through GitHub PR comments.

In this case it's better to just submit an issue and let me just implement it myself (with or without an LLM).

If the PR has a _co-authored by <LLM>_ signal, then I don't have to spend time giving detailed feedback under the assumption that I am helping another human.

If someone is repeatedly sending me slop to look at I'll block them whether or not they tell me an LLM was involved

A line at the bottom of PRs, reports, etc that says "authored with the help of Copilot" is fine.

And selfishly — I'd rather not run into a scenario where my boss pulls up GitHub, sees Claude credited for hundreds of commits, and then he impulsively decides that perhaps Claude's doing the real work here and that we could downsize our dev team or replace with cheaper, younger developers.

As for hobby projects, I strongly encourage you to not care. You aren't going to lawyer up to sue anybody, nor is anybody going to sue you, so YOLO. Do whatever satisfies you.

What you're doing would fundamentally be similar to copyright theft, using 'someone' else's code without attributing them (it?) to avoid repercussions

Obviously the morals and ethics of not attributing an LLM vs an actual human vary. I am not trying to simp for the machines here.

    $ yoloai new bugfix . -a --network-isolated --agent claude

Now I interact with the agent, and when it's done:

    $ yoloai diff bugfix
    diff --git a/b64.go b/b64.go
    index cfc5549..253c919 100644
    --- a/b64.go
    +++ b/b64.go
    @@ -39,7 +39,7 @@ func Encode(data []byte) string {
        val |= uint(data[i+2])
       }

    -  out[j] = alphabet[(val>>18)&0x3E]
    +  out[j] = alphabet[(val>>18)&0x3F]
       out[j+1] = alphabet[(val>>12)&0x3F]

       remaining := n - i

    $ yoloai apply bugfix
    Target: /home/ks/tmp/b64

    Commits to apply (1):
      9db260b33bcd Fix bit mask in base64 encoding

    Apply to /home/ks/tmp/b64? [y/N] y
    1 commit(s) applied to /home/ks/tmp/b64

    $ git log
    commit 5b0fc3a237efe8bbc9a9e1a05f9ce45d37d38bfa (HEAD -> main)
    Author: Karl Stenerud <kstenerud@gmail.com>
    Date:   Mon Mar 30 05:28:21 2026 +0000

        Fix bit mask in base64 encoding

        Corrected the bit mask for the first character extraction from 0x3E to 0x3F to properly extract all 6 bits.

        Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

    commit 31e12b62b0c3179f3399521d7c4326a8f6130721 (tag: init)

It also doesn't get access to my credentials, so it couldn't push even if it did have network access.

jai's -D flag captures the right data; the missing piece is surfacing it ergonomically. yoloAI uses git for the diff/apply so it already feels natural to a dev.

One thing that's not fully solved yet: your point about .git/hooks and .venv being write vectors even within the project dir. They're filtered from the diff surface but the agent can still write them during the session. A read-only flag for those paths (what you're considering adding to jai) would be a cleaner fix.

I've already shipped this and use it myself every day. I'm the author of yoloAI (https://github.com/kstenerud/yoloai), which is built around exactly this model.

The agent runs inside a Docker container or containerd vm (or seatbelt container or Tart vm on mac), against a full copy of your project directory. When it's done, `yoloai diff` gives you a unified diff of everything it changed. `yoloai apply` lands it. `yoloai reset` throws it away so you can make the agent try again. The copy lives in the sandbox, so your working tree is untouched until you explicitly say so.

The merge step turned out to be straightforward: just use git under the hood. The harder parts were: (a) making it fast enough that the copy doesn't add annoying startup overhead, (b) handling the .pyc/.venv/.git/hooks concern you raised (they're excluded from the diff surface by default), and (c) credential injection so the agent can actually reach its API without you mounting your whole home dir.

Leveraging existing tech is where it's at. Each does one thing and does it well. Network isolation is done via iptables in Docker, for example.

Still early/beta but it's working. Happy to compare notes if you're building something similar.

As soon as ground troops land in Iran, it's over for the USA. As it is, oil and goods shipping via the Persian Gulf and the Red Sea will be controlled by Iran for a very long time to come. All Iran has to do is withstand the pummeling, which it very likely will do. And they'll get plenty of support from China, since this plays into the South China Seas plan quite nicely as the USA moves carrier after carrier out of Asia.

The Iranian regime is doing much better so far, relative to where they should be after a joint military attack from the US/Israel and maybe even relative to where they were just a few months ago.

The previous Ayatollah was 86 and had multiple bouts of pancreatic cancer. He was on deaths door, Iran was destabilizing with bouts of protest and repression, the regime itself suffered major military blows, and a potentially rocky and fractured transition was imminent.

Thanks to the war, the regime survived a transition, and seems consolidated around the son of the former Ayatollah, who's entire family was killed by our strikes, and the US seems largely impotent as Iran chokes off a large portion of the worlds oil supply and strikes at energy assets in the ME.

1: Protecting against bad things (prompt injections, overeager agents, etc)

2: Containing the blast radius (preventing agents from even reaching sensitive things)

The companies building the agents make a best-effort attempt against #1 (guardrails, permissions, etc), and nothing against #2. It's why I use https://github.com/kstenerud/yoloai for everything now.