Code is cheap. Thinking isn't.
Thoughts on what AI coding productivity is.
With the advent of capable Large Language Models (LLMs) like Claude Opus, AI-coding, which is the act of letting LLMs write code partially or completely, has taken the world by storm. Indeed, the ubiquity of software and the movement towards a highly connected world meant that people with coding skills were in high-demand and commanded high salaries. Hence, if the act of writing code, which in its essence is a form of language generation, can be taken over by compliant machines, then the economic impact of replacing human coders with AI is great. AI-coding optimists started to herald an age where polished software just “fell out of the sky” to deliver tailored “N=1” applications to users.
To wit, I’d say, it’s a little bit more nuanced than that.
Many people outside of roles that require writing code do not know how much time is spent dealing with the peculiarities of software languages/frameworks/libraries/legacy code and troubleshooting. The short answer is, unless you are one of the few expert coders, a lot.
For example, one would need to know how to use evalMapAccumulate in Scala fs2 to implement a state machine in an effectful manner and would have to troll through documentation to understand the fundamentals of how the fs2 library is put together to get things going, if you do not already know. LLMs nowadays already know.
Or how about the case where you have to take over a legacy code base? You’d have to understand how the functions and classes that are custom to the application are structured and what arguments they take. That would take a long time and a lot of trial-and-error for a human developer, even with good documentation. LLMs with long context windows can hold much more in memory than a human and hence make references across the codebase much faster and much more accurately.
AI-coding’s key benefit is, in my own opinion, in taking away the time and toil of navigating and writing code. In short, the execution of the act of typing code is now a non-issue.
In fact, I would say that, at time of writing, AI can already write code better than most developers, on a code snippet basis and can structure code on a module-basis (an application is made up of many modules) better than many developers. Which means that on average, it is better to get AI to write the code than for human developers to type code.
Notice the words in italics. I said “on average” because there will be cases where the developer knows the tool/language inside-out, in which case, it might be better for the developer to just write the code anyway (I’ve alluded to this in my previous post). But from what I see, that would not be the case for many developers, nor would it be the case for most developers all the time (no one knows everything inside out). I also emphasised the word “type” because that is what AI takes over. The act of putting programming language on the screen or in a file. But it doesn’t negate the thinking that is required.
The key downside, that is also not apparent to people outside tech-heavy roles, is that AI-coding quickly lands you in a place where you lose ownership of what you are developing, if you are not careful.
Before AI-coding, there was the toil of writing code, which slowed things down and forces us to think. But now, code is cheap. We seem to be able to do a lot. But we might end up achieving nothing.
This deluge of AI-generated code causing loss of ownership is widely reported in the technology industry where human code reviewers cannot keep up with the amount of sheer code on a screen that AI produces.
I speak also from personal experience. There are many times where I’m simply following the AI suggestions or addressing the questions asked by AI regarding code issues reactively. There are also times where I felt lost in my own codebase, not being able to navigate it without asking AI. This rang alarm bells in my head and made me realise that working with AI-coding requires a discipline that is different from my past experiences.
AI-coding removes the toil related to the writing of code and puts the emphasis squarely on design and thinking. Unless it is done right, it is not guaranteed to reduce the total amount of effort needed to deliver software services. In a way, one can think of its benefits like those of Robotic Process Automation (RPA). RPA takes away the toil of the execution of the process but it doesn’t help if you have a bad process to begin with. In fact, all you get is a bad process that generates errors faster!
With AI-coding, many teams will seem to deliver more “stuff”. And that’s what many AI coding optimists think will happen. New features seem to come out effortlessly. Bugs are magically fixed overnight. Analyses with beautiful visualisations become the de facto presentation standard.
But more doesn’t mean better. New features might have no users. Bugs fixed might generate more bugs else where that needs to be fixed. Analyses might just be a bunch of data transformation that have no real connection to business objectives.
At the end of the day, whether AI coding helps depends on how deep the team thinks about their product or their business purpose. Teams that spend more time thinking about their product, aligning their purpose and sharpening their focus, while relegating writing code to AI agents working at night, will be the ones who can take advantage of AI coding. It might then lead to a situation where, contrary to popular expectations, these teams that are deeply connected to their purpose and good at AI coding won’t necessarily deliver more things in a short time. They deliver the right things.