Where are the nuanced left-wing takes on modern AI and LLMs?
So much of the discourse around this tech is centered on rejecting it because of who currently owns it. But like all tech, it can be used for both oppression and liberation.
Who is focusing on the latter?
@jnkrtech @zanzi Thanks, here are my pieces about the topic:
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?
@zanzi @jnkrtech Your point about abstraction ladders is something I've been turning over since I read it. The Terence Tao/Lean combination feels like a glimpse of exactly what you're describing: Lean's type system carries so much semantic weight that the LLM doesn't need to compensate with volume. The proof is short because the language is expressive enough to make it short. That's very different from what happens when you point an LLM at TypeScript.
I'm skeptical of vibe coding, and have been from the start. Generating an entire project from prompts feels to me like a path to maintainability disaster, and I think most of the people currently excited about it haven't yet had to clean up what they made. The enthusiasm reads a lot like the dynamic typing boom of the 2000s: Ruby, Python, JavaScript, the whole wave. “We can build so fast.” True, and then ten years passed, the codebases grew, the teams changed, and people started hitting walls they hadn't anticipated. Python grew type hints. Flow and TypeScript appeared. Ruby quietly declined. The reckoning came, it just took a while.
I expect vibe coding to follow the same curve. One difference worries me though. With dynamic typing, the code was at least written by humans who understood it at the time. The technical debt was “hard to read.” With LLM-generated code that nobody reviewed deeply, the debt is something else: code that exists for reasons nobody can reconstruct. That's a harder problem.
There's a related problem I don't think more training data will fix. LLMs converge toward the average of what they've seen, and the average code on the internet is not concise. Verbose code is the norm; terse, well-factored code is rare, and usually underdocumented, so it contributes a weak training signal at best. The result is that LLMs have internalized the habits of the median developer: defensive, repetitive, over-specified. Conciseness requires knowing what not to write, and that judgment depends on domain context and something like aesthetic sense—neither of which transfers easily through pretraining. I don't see a scaling path out of that.
My own workflow tries to avoid this. Even when I use an LLM for Fedify, I steer constantly: small outputs, immediate review, corrections before moving on. The LLM is closer to a fast typist than an autonomous collaborator. It still helps, but the judgment about what to write, what to cut, where to stop, stays with me.
Which brings me to your actual question, what should the metric be. I don't have a clean answer, but I think it has something to do with how much of the codebase a human can hold in their head and feel responsible for. LOC never measured that. Neither does “prompt to working demo.” Whatever comes next probably needs to.
And on the higher-level languages point: I think you're right, and I'd add that this might be where the more interesting craft ends up living. Not writing the implementation, but designing the abstractions well enough that the implementation, whoever or whatever produces it, stays within bounds a human can oversee. That's a different skill from what most developers have trained, but it doesn't feel like a lesser one.
Zanzi @ Monoidal Cafe
jnkrtech
洪 民憙 (Hong Minhee) 
d3reo