This is the fourth part of the series “Impressions of Our Current AI Usage”, as outlined by the introduction article.
The title of this blog entry is also a continuation of an earlier article I wrote about AI advancements in computer gaming, eight years ago.
And if you are inclined to read words out “loud in your head”, you might read it in Trent Reznor’s voice this time.
There is something weird about human’s sense of achievement. Things seem to be “worth” more when they are harder to reproduce. That’s why we value live music over recordings, idolize top athletes and install examinations and tests to filter for official positions.
In the world of software development, the entry bar hung low for a decade now. Gone were the days of rigorous academic training and selection for a degree. If you wanted to go the freelance route, a decent notebook was all it took to be equipped for the job. After that, you could turn electricity and coffee into source code and source code into money.
The reason to enter the field of programming are manyfold, but two main drivers are common: Passion and money. Let’s put money aside and concentrate on the passion aspect: Many programmers love what they do. They even do it for free, in their spare time. The process of creating source code is a deeply rewarding activity for them. It’s not the finished result that “achieves” something, it’s the journey towards it.
I hope you can easily see the similarity to other mainly passion-driven activities like making music or other forms of art, athletic endeavours like mountain-climbing or scientific discoveries. You probably have a hobby yourself that you are passionate about.
Now imagine that somebody automates the journey. You don’t need to climb a mountain, you can just take the elevator. It’s faster, more convenient – and boring. You don’t need to actually play the guitar, you just need to hold it and it plays the most amazing solos itself. And you don’t need to sing, your voice will be autotuned correctly. You’ll be an amazing musician – like everybody else.
When you automate the journey part of an activity, only the chore parts remain to be done. You still need to prepare for thin air on top of the mountain and no autotune will correct your actual song text, so you still need to learn it.
In software development, creating source code is the journey part of the work. There are many supporting activities that need to be done for the journey to be successful on the long run. Things like modelling, planning iterations, bookkeeping the iterations, code review, functional review and manual testing are only some things that still need to be done, regardless of who actually programs. If you can alternate between the activities and have a suitable chore-passion-balance, things feel natural. If only the chore part is up to you, you are the assistant to the machine.
The problem is, that the support work is still necessary. For a short time, you can live without it, but things will inevitably fall apart without proper management and housekeeping. In larger software development teams, these roles are officially assigned to additional team members, but in reality, everybody needs to participate a bit or the process fails.
So why don’t we focus on the chore parts to be automated? There are attempts and the AI is getting better in that regard. But code creation is by far the easiest activity a machine can learn. It produces an immediately digestable result, follows clear rules and can be verified on correctness in multiple ways. Most of the accompanying work is more ephemeral, leaves less of a trace and is not as teachable as “typing out the right sequence of characters really fast”.
In my blog article about computer games eight years ago, I wrote that human players prefer to team up with bots instead of other humans. This only holds true as long as the speed of the game is adapted to human levels – that is, considerably slowed down. If the bots would play only with themselves, they could speed up by several orders of magnitude. And that’s the problem with integrating AI-driven work units into a human-driven choreography: The speedup is not compatible.
In the software development community, there is a legend about a “10X” developer, a human being that is capable of consistenly solving a problem in software ten times faster than the average fellow, without sacrificing quality or longterm viability of the solution. I can attest that these people exist and I’ve seen a few in my career. If you think about AI as just another programmer behind a chat window, it’s more like a 1000X developer (not to be confused with a hundred 10X developers, a whole other bunch of problems!). There is literally nobody human on this planet that can even closely compete with the speed of an AI agent (unless you slow it down by artificial hurdles).
So, looking at the situation from a money viewpoint, the situation is clear: One source of code can provide 1x to 10x product in a given timeframe, while the other source delivers a hundred times more. Both cost roughly the same. But by buying “passion-free” code, the money-driven decider produces some long-term problems that will lead to diminishing returns:
- AI code is looped back into the training set. So it will reinforce its own idioms, good and bad, just by multiplying them hundredfold into the existing world code base.
- If AI code prevented a human developer from nurturing her or his passion, it stunts the human creativity pool and leads to a bleaker learning set.
- The higher the AI code jenga tower is built, the less possible it will be for human developers to interact with it. Relying on AI will be a self-fulfilling prophecy with a ever-shrinking escape window.
To come to a conclusion here: I like to call AI-generated code “passion-free”. And I think that we concentrate too hard on the two questions “can it be done with AI?” and “will it cost less with AI?” and miss the opportunity for a third question that I find important, too: “will it make our lives more fun to do it with AI?“
One thought on “The day the machines took the fun away (AI impressions, part 4 of 5)”