The subject matter was building an auditing system to comply with the requirements of an IRS consent decree as part of a settlement for shoddy accounting practices which may or may not have included tracking billions of dollars of assets with Excel.

Ask an LLM to reverse engineer it and explain it.

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?

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.

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.

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.

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.