How AI in software development changed my views on the value and dangers of automation

When I began learning programming, some 20 years ago, I was excited about all the possibilities of automating things. And now, 20 years later, AI is here to automate away something that I love doing: Coding.

Kelsey Hightower had a brilliant point about this on one of his appearances on "The Pragmatic Engineer" podcast: You (software engineers) have been doing this to other people, and now it is being done to you.

It's true, and I had never thought about it up until this year. I do believe that automation through software does a lot of good, but there is undeniably a dark side to it: It puts people out of the job if you fully automate their role away. Now you might say: Oh well, but it creates new jobs instead. Yeah, true. Just as AI in software engineering automating coding to a large extent creates new roles, like people writing skills for the AI and harnesses and all that stuff. But now that it is being done to me, that automation takes something I value away from me, I see something I didn't before: Just because a new role is being created doesn't mean the people doing the old role will actually like the new role.

And this is the problem with automation. This is the dark side. It can take something meaningful and valuable in the working life of people away from them. I feel this with AI. My job has become easier - and less enjoyable at the same time. I love the craft of programming. The narrative that no one likes doing low-level programming tasks, a narrative spread by AI enthusiasts and vendors, is simply absolute horseshit.

Are there people who are relieved that they don't have to do the low-level tasks anymore? Of course. And to the extent that AI can help me solve complex problems in an easier way, I am too. But am I happy about being expected to delegate the coding to AI, because it's faster? Am I happy about not being allowed to take a parameter away from a method, and then going through the mentions of the method to refactor the calls? Absolutely not. I love doing "mechanical" things like that. It's part of the craft I learned over the course of 20 years.

Now this craft is being de-valued. Just completely, utterly de-valued. And is this right from an economical perspective? Absolutely. 1000%. Delegating most coding tasks to AI is faster, and with the newer models it's possibly even less error-prone than humans doing the coding. So from an economic standpoint, this de-valuing of coding skills makes absolute sense.

But there are different aspects to any issue, and one aspect to automating things, with or without AI, is that some people, contrary to the dominating tech narrative, actually like doing things by hand. I am one of those people. Do I like to do everything be hand? No, if I did obviously I wouldn't have become a software developer. But some things I like doing by hand. For example, I always use GIT from the console, typing in the commands. Why? Wouldn't it be faster through the IDE integration? Yes, it would. Unquestionably. But I like the flow of putting together a commit, then pushing it to the remote branch. I just like doing it that way.

And this is the great danger of automation, and AI accelerates it even more. It's not that automation is bad, clearly it does a lot of good. But the question is: Shouldn't we factor in the human costs of automation as well? Does "we can do this fully automated" always equate to "we should do this fully automated"?

I think there is no right or wrong answer to this question, not in general. It always depends on the situation at hand, and what the human costs involved are.

But questions are the beginning of wisdom, and sometimes someone stepping up and asking the right question can bring about real change. Will that someone be you one day?

Only you know the answer to that.