alt Hacker NewsMy uncle leads IT support teams, the org is measuring AI use in writing reports and tickets. The org has very poorly structured and obsolete processes (he's trying to straighten them up as he goes), AI will probably amplify the lack of structure, by making it easier for the work to _look_ as if someone carefully reviewed the issues and followed procedure.
A friend is a team lead in an org that's mandating vibecoding via "Devin", a lesser known player an "architect" chose after shallow review. The company also has endemic process issues and simply can't do deployments reliably, it's behind the times in methodology in every other respect. Higher ups are placing their trust in a B-list agentic tool instead of fixing the problems.
Anyway, I wouldn't be caught dead working at either of those two shops even before the AI rollout, but this is what's going on in the IT underworld.
Replies
Well before offices were computerized at all some of the manual processes turned out to be more effective than after full computerization was completely accomplished. Which was sometimes decades later so nobody could tell which workflows it actually applied to, or wouldn't believe it anyway by the 21st century.
It was truly quite rare to have such well-honed manual processes though, the "average" place had a lot of elements that were far from perfect but still benefited after the computerization dust had settled. Then at the opposite end of the spectrum were companies where everything was an absolute shitshow, maybe since the beginning.
That's kind of where Conway's Law comes from, if you benchmark against a manual shitshow that has built up over the years, and replace it with a computerized version, you get a shitshow on steroids. The only other choice would have been to spend the appropriate number of years manually undoing the shitshow before making any really bold moves.
Now AI can really take things to a whole 'nother level, not just on steroids but possibly violating Conway's Law . . . squared.
I hate the AI assistants for ticket-writing. The beneficial use there would be to prompt for possibly-useful information that's not present, or call out ambiguity and let the writer decide how to resolve any of that. Coaching, basically. Suggesting actual text to include, for people who aren't already excellent at ticket-writing, just leads to noisier tickets that take more work to understand ("did they really mean this, or did the LLM just prompt them to include it and they thought sure, I guess that's good?")
[EDIT] Oh and much of your post rings true for my org. They operate at a fraction the speed they could because of organizational dysfunction and failure to use what's already available to them as far as processes and tech, but are rushing toward LLMs, LOL. Yeah, guys, the slowness has nothing to do with how fast code is written, and I'm suuuuure you'll do a great job of integrating those tools effectively when you're failing at the basics....