Paul CantrellAug 13, 2024

In most cases, LLMs will not replace humans or reduce labor costs as companies hope. They will •increase• labor costs, in the form of tedious clean-up and rebuilding customer trust.

After a brief sugar high in which LLMs rapidly and easily create messes that look like successes, a whole lot of orgs are going to find themselves climbing out of deep holes of their own digging.

Example from @Joshsharp:
https://aus.social/@Joshsharp/112646263257692603

j# (@[email protected])

Yesterday we had another example of LLMs creating support issues for us. User: "hi, how do I do this thing? Your docs say I can go here and change some options, but there's no settings there" Me: "that's right, we don't have such a feature, but also we don't say you can do it in the docs, where did you read that?" User: "oh I didn't actually read the docs, I asked 'AI' and it hallucinated this answer. Sorry!" At this rate I'm looking forward to 2025 when I'll be spending 100% of my time doing support to correct falsehoods about our app made up by LLMs

Aus.Social
Show threadPaul CantrellAug 13, 2024

Those who’ve worked in software will immediate recognize the phenomenon of “messes that look like successes.”

One of my old Paulisms is that the real purpose of a whole lot of software processes is to make large-scale failure look like a string of small successes.

Show threadPaul CantrellAug 13, 2024

The crisp “even an executive can understand it” version of the OP is:

⚠️ AI increases labor costs ⚠️

(“Why?” “Because it’s labor-intensive to clean up its messes.”)

Show threadPaul CantrellAug 13, 2024

I said “the purpose of a whole lot of software processes is to make large-scale failure look like a string of small successes.”

Huh? What does that look like??

It looks like this:

✅ Meetings held
✅ Plan signed off
✅ Tests passed
✅ Iterations iterated
✅ Velocity increased
✅ Thing implemented
✅ Checkpoints checked
✅ Thing released
✅ Blinkenlights blink
✅ Line goes up
✅ Thing updated
❌ Software never •really• solves the problem it was supposed to solve in the first place, creates more problems

Show threadtiny_mAug 14, 2024
@inthehands I once sent a PR back to a colleague with some change requests because he'd missed a bunch of the acceptance criteria from the ticket and he told me in all seriousness that his work couldn't be wrong because he'd written unit tests and they were all passing and he honestly couldn't see the difference between building the thing we were meant to be making and building this other thing he'd actually made, regardless of how well he'd made it. I felt bad for him
Show threadPaul Cantrell
@tiny_m
Oof, yeah. I mean, a lot of what I’m talking about falls to a product manager or program manager type of role, somebody whose job is specifically looking at the long goal of the project and thinking about •who• it’s for — but that responsibility truly extends to the whole team, right down the the dev writing a unit test (or not thinking to write one) and asking “Why this? Does this make sense? What am I missing? Is this playing out the way others think it’s going to?”
Aug 14, 2024 at 2:39pmWeb
Show threadtiny_mAug 14, 2024
@inthehands I've found the only way I can be really happy as a developer is working in really tiny teams of people who all get it. I frequently hear my colleagues asking "what problem are we trying to solve" and that makes me so happy. I've tried working in bigger teams and bigger companies with roadmaps and agile and processes and raci matrices. One of my recent horror stories was being asked by an architecture committee to write an RFC explaining why we needed to change some CSS. So painful
Show threadPaul CantrellAug 14, 2024

@tiny_m
Ugh, yeah.

I’d posit that with almost no exceptions good software work happens on small teams. That’s true even in large orgs: the good ones know how to set up small teams for success even in the context of a much larger sea of people.

Show threadtiny_mAug 15, 2024
@inthehands I felt bad for them too. They'd convinced themselves if they perfected the magical formula of processes it would remove all the friction. I am not against agile, I love the underlying concept of encouraging people to talk more. Unfortunately it's too easy to fall into the habit of performing the rituals without ever questioning how effective they are or whether they are improving communication. The root of the problem was the people not their process but they couldn't see it