Most of these "class traitors" live in high cost of living areas, and for them, the choice is "become unemployed within two weeks for not complying", or "become unemployed within a few years for complying". They are being betrayed by the shareholder class, and they in turn are betraying their customers and their species.

The only thing that we can do is to not make it worth their time in the long run. Don't let greed and fear slide. Don't hate someone for choosing their family and comfort over your own, hate the system that forces them to make that choice. Hold them accountable, but attack the system, instead of its hostages and victims.

Bridging software with domain-specific needs of its professional users is nothing new: that is how domain-specific professional software gets built. What is new is that the people doing this are being referred to hysterically as "class traitors", when the improvements they're working on will bring massive and widely available benefits to professionals the world over.

I recently stumbled upon this delightfully titled book from 1982, "Application development without programmers": https://archive.org/details/applicationdevel00mart

Which includes this excellent line:

> Unfortunately, the winds of change are sometimes irreversible. The continuing drop in cost of computers has now passed the point at which computers have become cheaper than people. The number of programmers available per computer is shrinking so fast that most computers in the future will have to work at least in part without programmers.

The article talks about 'software development will be democratized' but the current LLM hype is quite the opposite. The LLMs are owned by large companies and are quite impossible to train by any individual, if only because of energy costs. The situation where I am typing my code on my linux machine is much more democratic.

One important and often overlooked democratization is spreadsheet formulas: non-programmers began programming without knowing they were, and without concern for error and edge cases. I cannot find the reference right now, but I recall seeing years ago articles about how mistakes in spreadsheet formulae were costing millions or more.

I see an analog with AI-generated code: the disciplined among us know we are programming and consider error and edge cases, the rest don't.

Will the AIs get good enough so they/we won't have to? Or will people realize they are programming and discipline up?

I find it so fundamentally unhinged that people think things will get fully automated to the point that humans no longer matter. We are centuries into the deep automation of certain things, like looms, but people with deep understanding of those things are still needed to guide the automation and keep it working to meet human needs.

To ignore that pattern and say everything's going to be automated and humanity will be irrelevant seems to me to be... more of a death wish against human agency, than a prediction based on reality.

I remember sitting in a senior seminar class in 1989 full of CS students. We were solemnly informed by a very earnest IBM employee that we would regret having majored in computer science because IBM's CASE tools were going to kill job market. That aged like milk.

Will something come along some day that will actually drastically reduce the need for programmers/developers/software engineers? Maybe. Are we there yet? My LLM experience makes me seriously doubt it.

Developers are “unwanted overhead” until the customer money threatens to walk out the door. They’re going to damage their future products and probably reduce their customer base (fewer consumers) and then sit there looking like gaffed fish when the budget ink turns red. “Who would have thought…”

Don’t facilitate losing your job.

I remember being in my early 20s, learning C and Pascal, and having this one kid telling me I was learning dead languages and he’d earn 3 times more than me leaning 4GL as well as himself being 3 times smarter than everyone else too.

The only reason I remember this encounter so clearly was because he got rather annoyed, to the point of being aggressive, when I pointed out that most of the computing landscape was built on C and this wasn’t going to change any time soon.

Multiple decades later, and C-derived languages still rule the world. I do sometimes wonder if his opinion mellowed with time.

One other thing that is often ignored: Most of the business class, executive class, ... even working class, DON'T want to write code.

The reasons vary, but in general, just as some people don't want to touch maths (even if they might be good at it if they tried), some people loathe the very idea of being technical, either because they think it is beneath them, or they just don't see themselves that way.

And like the article explains, even when "programming" tools seem to become simpler to use, they still require technical specification, and once people feel like they are getting close to "programming" they check out.

LLMs seem quite successful when considered something like a natural langiage interface, but expecting intelligence seems a step too far. For one they do not learn, at least not online, and that is a somewhat important requirement for truly intelligent behaviour.

Arguably programming is as much learning as it is writing code. This is part of the reason some people copy an entire API and don't realise they're not so much building useful code as building an understanding.

Until a year ago I believed as the author did. Then LLMs got to the point where they sit in meetings like I do, make notes like I do, have a memory like I do, and their context window is expanding.

Only issue I saw after a month of building something complex from scratch with Opus 4.6 is poor adherence to high-level design principles and consistency. This can be solved with expert guardrails, I believe.

It won’t be long before AI employees are going to join daily standup and deliver work alongside the team with other users in the org not even realizing or caring that it’s an AI “staff member”.

It won’t be much longer after that when they will start to tech lead those same teams.

Wow it mentions practically every flavour of the month technology that was supposed to make it drag and drop to make useful programs

I recall Power builder in particular it was the rage.

There are two ways to look at it:

- Software engineering is a cost center, they are middlemen between the C-level ideas and a finished product.

- Software engineering is about figuring out how to automate a problem, exploring the domain, defining context, tradeoffs, and unlocking new capabilities in the process

This topic always reminds me of "The Last One", https://en.wikipedia.org/wiki/The_Last_One_(software) :

> "The name derived from the idea that The Last One was the last program that would ever need writing, as it could be used to generate all subsequent software."

That was released in 1981. Spoiler alert: it was not, in fact, the last one.

If most programming is <em>ShitWork &reg;</em> and most programmers are performing ShitWork and LLM's are good at ShitWork, then most programmers are out of a job. If those programmers can pivot to another non-ShitWork or programming-adjacent function, they can remain employed.

There are bookoo other things people could be doing besides coding YASW [Yet Another Stupid Website].

I'd say that the article left out Software Reuse - talked a lot more about in the late 90's early 00's than now.

You could argue that coding with LLM's is a form of software reuse, that removes some of its disadvantages.

The market however has done a pretty good job of it, especially when it's a developer bull market that suddenly shifts directions. Case in point: late 90s, the mad rush to put warm bodies in chairs for those who could even spell HTML. A few years later, many had left and gone back to selling cars or whatever they did before.

I generally agree that it's difficult and counterproductive to try to eliminate talented programmers who put together the core of systems and set up the patterns that things like LLMs can emulate.

But, the modal programmer at this point is some person who attended a front-end coding bootcamp for a few months and basically just knows how to chain together CSS selectors and React components. I do think these people are in big trouble.

So, while the core, say, 10% of people I think should remain in the system. This 90% periphery of pretty bad programmers will probably need to move on to other jobs.

Something else that really should be mentioned:

Every recession where there was mass lay-offs on programmers (not every recession hits programmers hard), there were many articles saying that whatever that latest thing [see article] was the cause of this and industry is getting rid of programmers they will never need again.

In every case of course "it is the economy stupid". The tools made little difference in the need for programmers. The tools that worked actually increased the need because things you wouldn't even attempt without the tools were now worth hiring extra people to do.

I wonder if the common gap here is the inability to reify specification.

LLMs seem to be a significant step forward in converting language to code, but they don't seem to engage self-directed abstraction.

At the moment LLM's tend to work well when you constrain them, and you can craft the constraints with the help of the same LLM in a different session. Then you can verify if the outputted code obeys the constraints in yet another session, and make it adjust the code to obey the constraints. If one of the constraints was to yield highly functional code, you can start refining function by function as well. There is a pattern here.

If you are a good engineer you can dictate data structures to it too. It then performs even better.

I believe the writing is on the wall a this point, it does a very adequate job if I invest enough time in writing and refining the specs and give it the data structures (&/| database schemas) I want it to use. And there is no comparison in the number of hours I spend wrangling it and the number of the hours it would take me to do the code myself.

This is the worst it's going to be and it's already quite good, it wasn't that good a mere three months ago.

The main pitfall is trying to get an LLM to read your mind, in doing so you are putting too much load on whatever passes for their intelligence quotient. That isn't how you get good results or get a good measure of their capabilities.

The potentially cool thing about LLM's is bootstrapping. No matter how much COBOL you wrote, COBOL didn't get better. LLM's can be used to make LLM's (and other software stuff) better. LLM's could be used to create their successor(s).

Of course, in the end, it won't do us humans any good, because when the Singularity AKA Rapture comes, we'll all be converted to Computronium. :-)

> These claims deserve scrutiny, not because they are entirely wrong, but because they echo promises made in 1959, in 1973, in 1985, and in 2015.

Seems like that little kerfuffle with all the 2-digit years in legacy COBOL code was a well-timed distraction.

Right, people misuse this term "democratized" all the time. Because it sounds nice. But it's incorrect.

Democracy is about governance, not access.

A "democratized" LLM would be one in which its users collectively made decisions about how it was managed. Or if the companies that owned LLMs were ran democratically.

It is democratising from the perspective of non-programmers- they can now make their own tools.

What you say about big tech is true at same time though. I worry about what happens when China takes the lead and no longer feels the need to do open models. First hints already showing - advance access to ds4 only for Chinese hardware makers

It's "democratizing" in the same way Uber "democratized" taxis...

That's a great point but you didn't make your linux machine yourself. A large tech corp made it, and each of its parts. Some of us could probably make their own computers but I don't think I'd be able to make one smaller than the house I live in. There's something to be said about large-scale automation and that's not that it "democratizes" anything. Like you say: quite the opposite.

You are assuming democracy wasn't designed to crush the individual and reduce autonomy at all cost. How cute.

I have a feeling that the cost of bad / inefficient / late software runs into at least the billions. The biggest risks are unavoidably attached to the most costly software projects, that are probably the most likely to be conducted in the most sophisticated and professional fashion with the latest silver bullet methodologies.

The Mythical Man Month is just over half a century old, yet still reads like it was written yesterday.

> began programming without knowing they were

Worse, they were doing functional programming just by chaining formulas without side effects, surpassing the skills of most self-proclaimed programmers out there.

A particularly alarming case: https://www.bbc.com/news/technology-54423988

And then of course there's this: https://en.wikipedia.org/wiki/Growth_in_a_Time_of_Debt#Metho...

> Or will people realize they are programming and discipline up?

Well, they apparently haven't with spreadsheets, 50 years on, so I wouldn't be optimistic.

>Or will people realize they are programming and discipline up?

Or will there be coding across disciplines, and attendant theories of literacies in context?

What I like about the OP is the consonance with literate practices, which has gone through similar generations of "our children don't know how to [...]" alongside of "our children will not need to [...] because of the machines."

I often think about how the modern world genuinely does run on Excel formulas, many written by amateurs, most without automated tests and with version control based on final_final_v2 suffixes.

Somehow civilization continues to function!

Makes me a bit less terrified that untested vibe coded slop will sink the economy. It's not that different from how things work already.

> non-programmers began programming without knowing they were

Using excel in the traditional sense isn't the same as programming. Unless they were doing some VBA or something like that which the vast majority of excel/spreadsheet users don't.

> spreadsheet formulae

formulas. We aren't speaking latin here.

> I see an analog with AI-generated code: the disciplined among us know we are programming and consider error and edge cases, the rest don't.

Programming isn't really about edge cases or errors.

> We are centuries into the deep automation of certain things, like looms, but people with deep understanding of those things are still needed to guide the automation and keep it working to meet human needs.

The difference this time is that the thing they're trying to automate is intelligence. The goal is a machine that's as smart as a Nobel Prize winner or a good CEO, across all fields of human intellectual endeavor, and which works for dollars an hour. The goal is also for this machine to be infinitely copyable for the cost of some GPUs and hard drives.

The next goal after that will be to give that machine hands, so that it can do any physical labor or troubleshooting a human can do. And again, the goal is for the hands to be cheaper to produce and cheaper to automate than humans.

You may ask yourself, who would need humans in a future where all intellectual and physical tasks can be done better and cheaper by a machine? You may also ask yourself, who would control the machines? You may ask yourself, what leverage would ordinary humans have in a future that no longer needed them for anything? Or perhaps you would not ask those questions.

But this is the future investors are dreaming of, and the future that they're investing trillions of dollars to reach. That's the dream.

The thing being automated in this case is human intelligence. If you've been paying attention more and more of economical knowledge work is threatened by advancement of AI capabilities. This is a credible threat. Deny this and you are the one in denial with reality.

Fundamentally unhinged? How presumptive of you to declare with confidence AI will never become more capable than humans.

But I suppose it's fitting. If after all that has happened your priors still have not budged then I'm sorry to say you will probably never understand this.

> I should be extremely skeptical about excitable tech guys predicting big things in short time frames.

Edit: I read your other comment. I don't disagree with you here.

I think people feel that once the pool of humans required to do a thing diminishes to the point that their occupation is rare enough to be invisible, that is essentially the same as "fully automating" it.

I have certainly never met anyone who works in "loom engineering" in my entire life.

Was a "to do" list the example they used at that time also?

In some sense, programming is about figuring out which algorithms are a fitting metaphor for business problems. By programming, you are building a model of the business problem and a model of its solution. Most of the non-programmers who are in positions of authority (managers, CEOs, even some CTOs), do not understand that this is what programmers do. From their point of view, the authorities come up with a "strategy", after dozens of meetings, and give the programmers vague instructions based on the strategy, and programmers turn those instructions into code that does something somewhere, usually after finding ways to avoid bad or unfeasible ideas, while still complying with the instructions.

To them, an LLM is indistinguishable from a programmer. From the point of view of authority, progress happens one meeting at a time. The reality is that there is a pyramid of experts beneath the authorities, that keep everything running smoothly, in spite of the best attempts of the authorities to demolish the foundation of the pyramid by "helping".

EDIT: to end on a positive note, it does not have to be this way. We just have to be willing to understand _how_ the organization we are a part of actually functions. And that means actually being curious instead of merely authoritative. I understand that curiosity is hard to maintain when you swim with sharks, so maybe don't swim with sharks.

The closer you get to releasing software, the less useful LLMs become. They tend to go into loops of 'Fixed it!' without having fixed anything.

In my opinion, attempting to hold the hand of the LLM via prompts in English for the 'last mile' to production ready code runs into the fundamental problem of ambiguity of natural languages.

From my experience, those developers that believe LLMs are good enough for production are either building systems that are not critical (e.g. 80% is correct enough), or they do not have the experience to be able to detect how LLM generated code would fail in production beyond the 'happy path'.

After 2 years of using all of these tools (Claude C, Gemini cli, opencode with all models available) I can tell you it is a huge enabler, but you have to provide these "expert guardrails" by monitoring every single deliverable.

For someone who is able to design an end to end system by themselves these tools offer a big time saving, but they come with dangers too.

Yesterday I had a mid dev in my team proudly present a Web tool he "wrote" in python (to be run on local host) that runs kubectl in the background and presents things like versions of images running in various namespaces etc. It looked very slick, I can already imagine the product managers asking for it to be put on the network.

So what's the problem? For one, no threading whatsoever, no auth, all queries run in a single thread and on and on. A maintenance nightmare waiting to happen. That is a risk of a person that knows something, but not enough building tools by themselves.

I can take a verbal description from a meeting with five to ten people and put together something they can interact with in two weeks. That is a lot slower than Claude Code! Yet everywhere I’ve worked, this is more than fast enough.

Over two more weeks I can work with those same five to ten people (who often disagree or have different goals) and get a first draft of a feature or small, targeted product together. In those latter two weeks, writing code isn’t what takes time; working through what people think they mean verses what they are actually saying, mediating one group of them to another when they disagree (or mostly agree) is the work. And then, after that, we introduce a customer. Along the way I learn to become something of an expert in whatever the thing is and continue to grow the product, handing chunks of responsibility to other developers at which point it turns into a real thing.

I work with AI tooling and leverage AI as part of products, where it makes sense. There are parts of this cycle where it is helpful and time saving, but it certainly can’t replace me. It can speed up coding in the first version but, today, I end up going back and rewriting chunks and, so far, that eats up the wins. The middle bit it clearly can’t do, and even at the end when changes are more directed it tends toward weirdly complicated solutions that aren’t really practical.

> poor adherence to high-level design principles and consistency. This can be solved with expert guardrails, I believe.

That’s a bit… handwavy…!

I've been hearing this for several years. How much longer is "it won't be long"?

Quasi-relevant excerpt from an odd essay (footnotes and references omitted).

``` My own eyes spent countless nights observing, with curiosity and wonder and delight, the responses of a computer, as I commanded it with code, like a sorcerer casting spells. I could not have known, that this obedient machine, this silicon golem, was also, slowly and imperceptibly, enchanting me, and changing how my eyes would see.

At the time^21 , I was a mere fifteen years old, young enough, so that the gravity of life was weak enough, and the mind nimble enough, to allow me to explore without any material justification.

The computer was the believed and I was the believer.

A consequence of becoming obsessed^22 with computer programming, is that one starts to see new metaphors, algorithmic metaphors, everywhere one looks. This new metaphorical lense, belongs entirely to the third eye. Without this lense, I would look at a traffic jam, and see a traffic jam. With the lense, I would look at a traffic jam, and wonder if, and to what extent, the latency-throughput trade-off^23 was true for highways. Without the lense, I would read about social theory, and simply see the words. With the lense, I would ask if society was, a tree^24 , a graph^25, a tree of graphs, or a graph of trees^26.

To generalize, the computer programmer looks at something, and asks, _is this thing an algorithm, and if so, what kind_ ? The entire _trade_ of com-puter programming, it revolves around this question, around the discovery of metaphors that fit^27[13][14].

It is thus little surprise, when a computer programmer asks if (or sometimes asserts that) a certain kind of algorithm^28 is intelligence^29 , consciousness, or both.

The entire ritual of computer programming, is similar to the trade, in that it involves discovering metaphors, not as a means to an end, but as their own end. This ritual is difficult to explain to someone who has never practiced it. Imagine, instead of trying to find metaphors that bridge the real to the algorithmic, one tries to find metaphors that bridge the algorithmic to itself.

It is very similar to what mathematicians do, but it requires writing programs in a very principled and abstract way^30 .

This ritual, unlike the ritual of writing, and unlike the ritual of mathemat-ics, has a dominant material component (the computer) which can make your code, in addition to an _imaginary_ experience, a _material_ experience^31 . This makes the computer a medium — an artificial oracle or artificial hallucinogen — that can safely imagine the unimaginable. And like the oracle, the computer exists to provide insight^32.

Without the ritual of programming, there would be no field of chaos the-ory, nor complex systems (very important for economics and environmental sciences), and _certainly_ no elaborate fractals. Pure mathematics could only scratch the surface, because the mathematical ideas, of the mid 20th century, that our imaginations could access, were insufficient for exploring these sys-tems. Computers allow us, not unlike microscopes and telescopes, to magnify the informational dimension of nature [17].

Computers, and the arcane programming languages that make them obey, are magic machines, that created a new interaction between, two elements of the human psychic triad, the immaterial and material.

What is this triad, and what is its third element? The concept of the triad appears so frequently, in recorded human thought, and in the structure of language, that it is either some kind of adaptive ideal^33 , or a consequence of language itself^34, if not both. Pythagoras called _three_ perfection itself. Plato divided the world into three parts. And, even today, our modern shamans and sages, use triads to discuss the universe.

Roger Penrose has a traid consisting of physical, platonic, and mind. Lacan has a triad consisting of real, symbolic, and imaginary. Plato has a triad of good, truth, and beauty. Of the three, Lacan’s naming is the most self-explanatory.

In this essay, the _material_ is the real, and the _immaterial_ is the other two.

The _trade_ of programming is driven by the _real_, while the _ritual_ of pro-gramming is driven by the _imaginary_. A trade is pursued because of real, material concerns (such as covering the cost of living), while a ritual is pur-sued because of imaginary concerns — concerns that can, more precisely, be called _aesthetic_. ```