This sounds exactly like the promises of putting a PC on everyone's desktop rather than a terminal connected to a locked-down mainframe, which in the end led to the lockdown migrating to PCs and the few employees who had any interest in automation forced to use tools like Excel because it was at least an improvement over VBScript and batch files and IT wouldn't let them install legit development tools unless their job description required them.

What are the odds that the average corporate IT department is going to allow the use of anything other than locked-down corporate AI with strict token quotas and stricter acceptable use policies?

> The industry collectively started huffing their own farts and forgot they operate in a support role for most organizations.

And most organizations still treat IT as a "support role" which means "cost center", only changing attitude when they inevitably get hacked, and a few years down the line, when enough of the managers who were there during the Great Hack are gone, IT gets the cuts again.

> Today with AI I'm watching random sales people automate a large portion of the bullshit part of their jobs IT and technology systems foisted upon them for no real reason.

Sadly that doesn't help at all. Random people automating heaps of crap in order to do their actual work, just makes the crap easier to manage for them. It doesn't remove it.

I'm reminded of health workers or teachers complaining that half their time is wasted on various types of record-keeping, because employer wants to record, check & micromanage everything. Similar with tax systems becoming ever more complex. Those are just a few of many examples.

AI assisting with managing that, just puts some $profitable$ control knobs in the hands of a very few providers. While at the same time enabling the mountain of crap to grow even further.

A real fix would be to use AI to get a better understanding of the existing heap of crap, and use that understanding to cut large chunks out & re-organise the remainder into a simpler stack.

Doesn't seem to me that that's being done. So far AI is mostly used to ADD to the crap-heap, faster & easier.

First, you do realize that when in some your-employer's-boring-CRM-system a certain field cannot be edited until a specific 5 conditions is met and that conditions allows an object to transition from "new" to "processing" status before field become available etc. then there was a reason for this.

Before Claude these people used to automate their processes in Excel. Then new people would come along and say, "None of this makes any sense to me so I'll just build my own even better automation in Excel". And again, and again. "Random sales people" won't ask Claude:

- Find out who was the PO in 2019, analyze why it was decided to introduce an additional status in FSTP-14475 instead of (...) What happens if the driver currently outside mobile coverage area and the task processing will return a 202 instead of a 200 (not described in the documentation; refer to FSTP-14385 for additional information), but the status will be updated before the deferred change returns (...)

Instead, they'll do something more like:

- I need to be able to quickly change this and that right here, get it done, don't make any mistakes.

Would be good if Claude could recognize an XY problem and respond "Understanding what you don't want is even more important than understanding what you do want" or "If you try to cut corners here again instead of following the established process - thereby making things more difficult for the people in the warehouse - I will inform your manager" instead of just charging ahead "you're absolutely right, see the goal, ignore the obstacles".

Second, it is easier to fix a flawed but already functional system than build a perfect one from scratch - without running into a problems, contradictions, previously unknown nuances during implementation. Because these contradictions, problems, and oddities over the last 10 years naturally gave you the requirements and specifications that no one of the sales-people and decision-making-people were able to articulate in a coherent way. And yes, now, having these specifications, you can rewrite it in Rust and do things better.

> Frontier models can and do write readable, intelligible code

The problem is that even frontier models still are prone to regurgitation. They are not that capable of organization and relevance, which is part of why so much LLM output is insanely grating to read.

READMEs in particular are the worst. LLMs tend to regurgitate stuff like "what is located where" that is of zero relevance to the reader, especially if it's yet another bog standard Java, Symfony or React app.