@jnkrtech @zanzi Thanks, here are my pieces about the topic:

• Histomat of F/OSS: We should reclaim LLMs, not reject them
• Acting materialistically in an imperfect world: LLMs as means of production and social relations
• Why craft-lovers are losing their craft

I hope you enjoy them!

@hongminhee @jnkrtech Yes! These are fantastic, and exactly why I've asked for a *left-wing* analysis of this question. The right-wing/liberal pro-AI takes are dogshit, either blindly following the hype or idealising the corporations and billionaires who own this tech. I wanted to see an analysis that starts off from a place of caution, and looks at ways of reclaiming this tech, rather than accepts it as a social good apriori. And I'm not a Marxist, but I can appreciate their commitment to material analysis.

I really like your idea of evolving new F/OSS licenses specifically for training (and your historical analysis of how the previous licenses evolved), I haven't considered that angle. I think it can be a good measure while the legislation/regulation is catching up. I'm also all-in on small, publicly owned models as an alternative to the frontier ones.

I think there's a lot of food for thought here, and from your second post I can see you've already gotten feedback from a more political/activist angle. So I'm going to dig into the most conceptually interesting to me aspect, which is the capability of the tech itself.

I'm a PL theorist and I work at an independent research lab that I co-founded with my friends. So I'm in the same boat as you when it comes to using these tools - I am free to use them to replace the menial parts of my job, and when it comes to code that I actually care about, that I write myself. But until recently, these tools couldn't even be used to write the kind of abstract code that I work on. Now... they can. Which is fascinating in its own way.

@hongminhee @jnkrtech So while I very much relate to your dichotomy between craft and efficiency, I want to push back on your assumption that generating code through AI is necessarily more efficient. The Opus feat of rewriting the C compiler in Rust is impressive, and shows what you can do with an unlimited compute budget, but it misses the fact that the main way we engage with code day-to-day is not by starting new greenfield projects, but by maintaining existing code. And despite how good LLMs have gotten at one-shot generating applications from scratch, the more you start changing the requirements or adding new features, the more brittle the resulting code will be, and the bigger the attack surface for bugs will become.

So the question to ask is, once an LLM writes a 100,000 LOC compiler, who will maintain it? If it's the LLM, well, then perhaps we will truly lose all connection to the code we produce But that seems too unreliable. But if it's a human, well, from talking to people who use these models at work, it seems that reviewing and maintaining LLM code is one of the most mentally taxing aspects of using these models. So whoever has to maintain this 100k LOC project is going to have a very bad time.

My partner likes to joke that a good developer should be judged not by the number of lines of code written, but by the number of lines deleted. So like you point out, it's the *metric* of LOC written that's flawed, regardless of whether it's achieved by writing code manually or by using an LLM. But if the metric is no longer the amount of code written, then what should it be?