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?
@aburka Well, I consider it both an insult, and a deeply unserious way to start off a conversation - by turning it into a pissing context of who is or isn't more left wing.
> How would a position between "it's great" and "it's unfit for any use" not be a centrist position?
Simple, that's not a position that I advocated for.
> I'm confused.
Good, it's okay to be confused. Perhaps next time, consider going on the offensive *after* clarifying what the person you're speaking to means to say, not *before*, yes?
@aburka You are in your right to think that. Now, since I'm so unserious, can you leave my mentions and not come back?
>I don't see you elaborating on that
Yeah, well, you're unpleasant to talk to. But you can feel free to follow along with the conversation, I'll elaborate once someone who is actually worth talking to shows up.
@D3Reo Yes, I think this gets to the heart of the issue, and this is also one of the reasons why I stayed away from this discussion so far.
I think the framing itself is flawed. By arguing that these models are bad because they're not useful, we implicitly accept the framing of the tech CEOs for whom the sole metric by which we should judge this research is by how well it replaces human labor. But there's a lot of reasons why something could be worth studying. For instance, I used to love markov models as a kid, despite them not being particularly useful at modelling language at all.
That being said, I don't think anyone owes it to any tech to be 'generous'. It's clear that it's useful for *some* tasks, but still bad at others. If it doesn't scratch someone's itch, it's fair for them to say so. And I personally find that it's much more interesting to figure out *why* it's good or bad at something, rather than tell someone that they're wrong about their own experiences with how they use these tools.
The water argument *is* an issue, though. I think that's one of the key reasons to step away from frontier models and focus on developing smaller local models instead.
@zanzi I think they're a better platform for the systems of computation for augmented intelligence that Engelbart spoke about than they are a platform for AGI.
One actual issue is they couple that augmentation to capital. So, a new compounding advantage worsening inequality. But it's also multiplicative: it just amplifies whatever direction it's turned to. Not necessarily always leading anywhere meaningful or productive.
@metarecursive Yes, I agree that they have little to do with AGI, except perhaps as a single component of a larger architecture, much like the role that brocca's area plays for us.
But the fact that they can offer a convincing simulacra of language *at all* is endlessly fascinating to me as a scientist. From the standpoint of philosophy of language, this gives us direct evidence that it's possible to separate language and reasoning.
What's funny is that many people conjectured that you could have reasoning without language, but pre-LLMs I don't think anyone was seriously considering that you could have language without reasoning. And yet here we are. I haven't followed academic philosophy for a while, but I so wish to see it start tackling what this means for our conception of language.
And I agree that as it stands, this technology is deeply tied to capital. That's why I think it's important to have these conversations now, before we get locked into this state of affairs for good.
@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.
some of the leftists are artists, hobbyists, and sex workers, the same people who are harmed by and against AI.
Zanzi @ Monoidal Cafe
aburka 🫣
Andre Videla
d3reo
Deen Abiola
jnkrtech
洪 民憙 (Hong Minhee) 
burakemir
Kouki Matsumoto