My friend Gabe brought up an interesting point today. In discussing how AI will affect software development, he made an interesting prediction that the underlying tools, languages, frameworks, etc (“the guts”) will become less important and will largely become forgotten details in the AI era. The actual code that the AI writes will be pretty ugly by our standards, with lots of “non optimal tool for the job” situations. But we won’t care, because it gets the job done.
Historical Parallel
I buy this thesis, largely because it is a natural progression of prior stages in the evolution of software development. Consider the shift from assembly language to high level languages like C or Python. An assembly language programmer would be horrified by our modern “wasteful” practices: using multiple bytes to store a boolean, unnecessary function calls, memory reserved that wasn’t needed, and on and on. But do we modern coders care? No, because these languages allow us to work faster and we don’t care about that waste; it isn’t worth it for us to care about it. Likewise, a future AI system might write everything in PHP or other “un-cool” language, but why would the business care as long as it worked? Gabe suggested that if LLMs had come along before React it never would have gotten built, and we would all still be using jQuery. React was built specifically because jQuery led to a bunch of spaghetti code which no human could understand. But who cares about ugly code when the AI can do all that for you?
The End of Technology Lock-in
A correlate of this, and one that we are already seeing, is that “lock-in” is becoming a thing of the past. It used to be that expertise was hard to get; hard for the programer to gain the experience, and hard for businesses to find people with the right match of experience. A business would say something like “we are a postgres shop” and not consider candidates who only knew MySQL. Same for “React shops”, “python shops” and so on. But now anyone who knows good database concepts can work at that “postgres shop” and be productive: the LLM handles the details of syntax and implementation. That developer could can ask any LLM, “how do I add a primary key in postgres?” or “convert this mysql script to postgres”.
What This Means for Developers
Just before the job profession of “translator” was obliterated by AI several years ago, there was a brief windows where translators could make serious cash by using AI tools to do the majority of their work, but with inertia of “standard translator rates” keeping wages high, along with residual legal requirements for “human translated.”
We might be in or entering such a period now, where developers versed in modern AI tooling can work significantly faster than their peers. However, if you are such a developer, you shouldn’t count on this advantage lasting for long. The key is to move further up the abstraction chain. This means becoming a better architect who can design robust system structures, or a product-focused developer who deeply understands user needs and business objectives. For example, instead of just implementing a shopping cart feature, you should be able to architect an entire e-commerce system that considers scalability, user experience, and business metrics. There is no future career in simply grabbing tickets from Jira and writing code to close them out – the value will be in understanding why those tickets need to exist in the first place.
Confession and meta-thoughts: I used Claude (LLM) to give advise on this blog post and…damn if it didn’t make some good points! I used it’s version of the last paragraph entirely. Does this mean that this issue has already been discussed to death, i.e. that it saw enough training data in a similar vein so it was able to give such good feedback? The image was created by ChatGPT. We really are coming into an interesting time for thought.