[TomasBM]

I agree with the sentiment, but I think the problem is much wider.

Managers at companies are just doing what they've optimized their careers for: maintaining some edge over some competition, at some cost. What is pure FOMO to you or me, is good strategy to anyone trying to win [1]. In other words, FOMO was always the strategy.

This self-reinforcing loop is also not going away. There hasn't been any real evidence that any part of knowledge work, including coding, cannot be automated [2]. Even if human-level quality or cost-effectiveness takes 10 more years, all tasks are functionally solved or about to be. I don't like it, but it's true.

The big problem is that the people who are removed from this loop, who have the time to understand its effects and the power to make changes, are doing fuck-all.

So, whether the loop stops for a while or speeds up even more, we're fucked until we figure out how to detach full-time employment from survival.

[1] I believe this is called meta in PvP games; even if you want to subvert the meta, you gotta know it well first.

[2] Although it could just be my impression, and I'd be happy to be proven otherwise.

[ModernMech]

The evidence that software development cannot be automated is we already tried to do it in the 90s with OOP, UML, and outsourcing. It didn’t work out for the same reasons vibe coding isn’t working out — because building the system is the same as specifying it, and that is a creative iterative process.

We are at the point where sure ai can write code, but we could always do that; lack of code writing ability was not what killed the OOP automation efforts. There was plenty ability to code back then as well. The distinction of whether it’s an offshore team in India or Claude writing the code doesn’t change things as far as the larger picture of building the software.

[TomasBM]

This may be evidence that it's more difficult than evangelists first imagine, but it's not evidence of a technical obstacle. Generally, "automation failed" does not imply that "automation is impossible".

To your individual points:

- OOP and UML are domain-specific abstractions. Aside from still being very much used in expanding niches [1], they have failed to automate much work because their proponents failed to cover enough cases to have a useful general-purpose abstraction.

- Outsourcing is a labor strategy. There's nothing technical that prevents another similarly capable person from doing your job, at least in the next town, if not another country. The obstacles were/are social and political, and the WFH movement shows that. Also, outsourcing is not going anywhere, it's just reduced and converted to nearsourcing due to backlash.

- By contrast, software is a general-purpose abstraction [2]. Databases are a type of software. You can see LLMs [3] as schema-less databases that contain millions of abstractions connected to each other. You can get a UML model or Python code or text by querying the LLM's query engine in a language much more flexible than SQL.

Vibe coding makes it seem like the funny intermediate bullshit is the end result of using LLMs, but it's not. Sure, I agree that LLMs don't make sense to use when a calculator is enough, but I don't see any functional limitations to improving LLMs. Maybe new algorithms or combinations are needed, but no matter how slowly, quality is expected to reach at least human level for the majority of current tasks (on which many jobs depend).

Which leads to my point: we need political, social, philosophical reasons to limit or integrate automation in our civilization, not just watch and hope there's a big enough technical obstacle so we can keep our current jobs.

[1] For example, model-based software engineering is still a growing; slowly, but growing.

[2] So is the organization of mechanical machines or analog computers, but it's faster to reorganize and orchestrate electrical signals.

[3] More precisely, foundation models, because it's far more than natural language processing.

[ModernMech]

I'm not saying there is a technical obstacle, I'm saying there's a practical obstacle that LLMs and vibecoding don't overcome.

The evidence isn't in that it failed but why it failed. It's not that the problem was more difficult than they anticipated, it's that they didn't comprehend the nature of the problem they were solving from the outset. Software development is an incremental creative activity that involves good taste, constantly shifting and vague requirements, and keen understanding of human factors and ergonomics. LLMs fail at all three. And in fact the shifting and ambiguous requirement element is fatal to the notion of automating the process.

Outsourcing and oop and uml and LLMs and vibecoding --- they're all the same futile attempt at the same thing: abstracting the human out of a loop built for the benefit of humans. It's nonsensical, and the only people who want to do it are capitalists, so it's doomed to fail yet again.

[TomasBM]

Fair enough, I agree. The process of one or more people figuring out what is actually needed is a big part of the outcome, I'd consider an important social obstacle or limit to automation.

But here's what's important to my point:

  > abstracting the [worker] human out of a loop built for the benefit of [customer] humans

This is now technically easier and more feasible for current workers [1], which makes it economically more desirable to employers, and customers won't really know or care what happens to the workers. There's no indicator that companies can't go much leaner, even if it means that you can't automate every worker.

So, rather than wait for a technical wall to save us, or legally protect functionally replaceable jobs, or wait until people's lives implode, we should pressure our respective governments to decouple [2] the person's ability to survive from the ability to hold uninterrupted full-time employment. That's the only collective way forward that I see.

[1] We can even constrain it to existing roles: if a team of one requirements engineer, one full-stack dev/architect and LLMs can do the same job as a bigger team of specialized roles and coders, why would anyone pick the latter? I'd be happy to hear a technical or economic reason.

[2] My order of preference, preferably multiple: UBI, UBS, increased part-time work options, conditional non-basic income, union contracts, automation pauses, retraining, severance, temporarily subsidized bullshit jobs.