It's also very frustrating to constantly have my opposition to AI be taken as an opposition to abstraction, or to automation, and a desire to do every little thing by hand. But it's the opposite. For a whole bunch of reasons, AI anti-abstracts. It adversarially creates oceans of duplication to process. It creates a situation where the AI user gets to set the terms of some ecosystem with synthetic productivity but then everyone else needs an AI to figure out what's going on in that new ecosystem.
@glyph I've been saying this for years ever since "it just speeds up the boilerplate" first ruffled my feathers and I had to sit and examine why.
If boilerplate is somehow prohibitively uncomfortable to write, that's a pain signal here to tell you something. You're missing an abstraction! Just like touching a hot stove should signal you to not do the thing. Choosing to just do the boilerplate faster with stolen training data, even if it's a task the bot can easily do correctly, is like shooting up morphine instead of moving your hand off the stove. And nearly all LLM apologia is like this!
If nothing else, I have a far more fundamental respect for friction* and pain signals than I did five years ago.
@MaddieM4 @glyph I've got a nagging suspicion some of the disconnect comes from llm side folks calling any code that frequently occurs along superficially similar lines boilerplate... when a lot of that is, rather, glue. But glue code is where the model alignment and nasty gotchas and bug nests lurk so it's absolutely not something I'd want a liar liar machine faking up.
@MaddieM4 @glyph yes, a thing I've been saying a lot is that someone resorting to LLMs to solve a problem seems pretty well correlated with the problem being one that shouldn't have existed in the first place.
Last year I talked to someone who said a large and tedious part of his job used to be transcribing tabular data out of nicely typeset PDF manuals into a machine-readable representation that can be fed to software. And then he started getting an LLM to do that for him.
But the PDFs were generated by another part of the same company! Steam came out of my ears. Why the hell is the company making life difficult for _themselves_ in that way in the first place? The people creating the data should provide it in a machine-readable format _already_, so that nobody has to convert it back into one!
In fact they ought to have been doing that all along. The red flag of "this job was so tedious I outsourced it to an LLM" _shouldn't_ have been necessary. The fact that you were making life pointlessly difficult for other humans should have been enough. But I guess a lot of this kind of nonsense exists in the world just because organisational boundaries hide the costs to _this_ department from _that_ department who caused them.
(Also, with the right tools – I quite like the Python 'pdfminer' library – you can automate that process _without_ an LLM, and have, you know, testing and repeatability and far lower computational costs. If I were receiving a PDF of that kind from some organisation I had no hope of influencing, that's what I'd do.)
@MaddieM4 @glyph When coding LLMs first came on the scene, and people were recommending them for, like, generating kubernetes yaml, my take at that time was: If a language processor is the best kind of automation that can be applied to this problem, then that's a scathing indictment of our profession. If you want to automate something, there's still nothing better than a program, and we all know how to write one.
Abstraction is leverage. Automation is the amplification of power. Abstraction is democratization. Automation repeats a duplicative process so you can stop thinking about it and focus on something higher level. Abstraction elides so architecture can expand.
AI is anti-leverage. Where an abstraction will elide duplication with semantic compression, AI steamrolls the duplication by copying and pasting faster than a human can.
@glyph LLMs also break the standard 'interchangable parts' of programming... they often end up writing whole new bespoke subroutines, systems, libraries, rather than reuse existing ones...
Like - imagine you are automating building a car, but, every component of every car is being procedurally generated and manuactured for that speciffic car. It's the dumbest possible way to automate *building* things.
@miss_rodent @glyph that depends a lot on how clear the prompts given. If a naïve user doesn't give some initial prompting and ground rules about what language versions, environments and existing libraries are available for use, many coding LLMs will reinvent the wheel with brand new errors rather than using tried And tested library code honed over decades.
Don't outsource thinking to an infinite monkey machine, you still have to task it with clearly written and considered prompts.
@zymurgic @miss_rodent @glyph it can't be that stupid, you must be prompting it wrong
Linus is saying the quiet part out loud: AI-native projects are environments where the key ingredient is _capital_. Abstraction can be performed by a quiet appreciation. True automation can be disruptive.
AI-based architectures (again, assuming that the AI works reliably, which is a highly contingent proposition) translate all that stuff into capital flows. A "machine speed" project requires _money_ to participate in, regardless of their complexity.
@glyph Linus along with his top deputies are probably being given free access to any AI models they want.
@adx when a technology empowers, entrenches, and elevates the powerful at the expense of everyone else, if you're "the powerful" it starts to look like a great idea and you're not sure why everyone wouldn't be on board
Right now it looks like AI can do "disruption" because you can apparently do things that require a team, as an individual, by taking advantage of highly subsidized token rates, or (at best) taking advantage of highly subsidized training regimes and stolen training data. But those rates will go up and while you'll still be able to nominally command those resources as an individual, doing so will still require the capital flow required to hire a team.
AI does not disrupt. AI entrenches. AI turns money into more money; AI turns investment into dependency. We are living in a funhouse mirror of that right now where the combination of overly-plausible demos and first-one's-free incentives are swamping the actual balance-sheet math. But the economics require that this stabilize, that the capital flows reverse direction. The wave has come in and we are just starting to feel the undertow.
This is an attempt to address the growing number of "oh, so you don't like automation when it comes for *you*? checkmate, programmers" articles out there, but there's so much more to say. Overall I think this idea that computer programmers just destroyed jobs is largely false. One of the weird corollaries of the Productivity Paradox is that we mostly *did* expand possibilities and make things better and more fun.
(Until all the Gig Economy stuff. But that's still a minority of tech history.)
@glyph when #AI generates code, who is responsible for it? Technically no one's and everyone's at the same time. So, what is the difference between AI slop and dev shit? who decides to take the risk of error or who accepts the code without reviewing it? I don't think there are enough professionals on the market with the technical knowledge to test/stop the slop. It is a very critical situation we have reached.
Want to know the main problem, actually? It's called capitalism! If AI were aimed at (literally improving) our lives, perhaps it would indeed be revolutionary! But it was designed precisely to produce more, receive less, scrap and cheap labor and make it very difficult for those who are learning to enter the "new job market".
The processes are becoming LESS humanized every day.