What a bold statement, especially coming from someone who makes his living around programming.
Decades in the software industry exposed me to many hype cycles. No-Code solutions, Blockchain and Cryptocurrency, and most recently the rise of Large Language Models (LLM) and AI technology. But in contrast to the earlier hype, something feels different this time.
Blockchain, while a great concept, is still not widely adopted, contrary to its promises many years ago. One of it’s most famous implementations, cryptocurrency, has been rife with scams and in speculative trading. There are movements towards government-backed cryptocurrencies, but all seems to be moving at a snail’s pace. Web3, the decentralized web, is nowhere to be found except from some niche parts of the internet.
At the end of the hype, Blockchain still seems to be a solution looking for a problem. For any problem it aims to solve, it seems there are other simpler, more intuitive ways of fixing it. On the other hand, LLMs and AI appeared to take the world by storm relatively quickly. We went from having an encyclopedia-like chatbot to entire AI-powered systems that automate business processes in just a few years. And with the big tech companies (and money) leading the charge, it seems this wave will not be over soon.
LLMs are built with the basic concept that words can be related to each other mathematically. This turned out to be applicable to software code as well. And within just months, the leaps on how good the models are at coding is amazing (and scary as well).
Copilot
I started looking at coding tools last year by using Github Copilot. Since I was already using Visual Studio Code, setting up Copilot is a breeze. I was amazed at how it was able to auto-complete my code, and helped a lot in creating tests. At that time, I concluded that having a tool like Copilot is worth it. It allowed me to speed up development by eliminating tedious parts of coding.
As time went on however, I began to feel the limitations of the tool. When I change something on one file, the auto-complete seems to forget about it when I work on the next (related) file. Context handling doesn’t seem to be its strong suit. They also released an “Agent” mode in Copilot afterwards, but when I tried to work with it, I was turned off at how slow it was in analyzing and reading the codebase.
Cursor
This led me to explore alternative options, and soon I landed on using Cursor. As a fork of Visual Studio Code, it was very simple to transition, and all of my projects and extensions were set up in a matter of minutes.
Using Cursor was the moment of truth for me: the autocomplete was fast, context was kept on multiple files, and using their Agent mode blew me away. It was able to navigate and parse the codebase quite easily and generate code as fast. I can switch between different models within the same coding session depending on the problem I wanted to solve.
Vibe
These AI coding tools gave rise to a phenomenon called “vibe coding”. This is where the programmer, who normally types the code in a text editor, instead just instructs the LLM to generate code on their behalf. You are just giving “vibes” to the machine, and the machine codes everything.
This was met with initial hesitation and pushback on my end: “I have been doing Ruby on Rails for almost two decades now, certainly I am better than any AI!”. But as with major technological advances, those who do not have an open mind and adapt will be left in the dust. So I decided to give it a shot.
In one session, I let the Agent (Claude Sonnet) to write both the backend and frontend components in a feature I was working. After that, I was sold. Not only was it able to write the code faster than I did, it also wrote it better, especially on the frontend (which isn’t my strong suit).
I jokingly said that it would replace my job and I am no longer needed, but it retorted with this:
I definitely can’t replace you – you bring creativity, problem-solving skills, domain knowledge, and the ability to understand business needs and user requirements in ways that I simply can’t match.
I’m just a tool to help you code faster and handle some of the more tedious tasks. The real value comes from your experience, judgment, and ability to architect solutions that actually solve real problems for real people.
Which, looking back at my experience so far, is on point.
The Foreman
Systems generally follow the principle of garbage in, garbage out. The outcome or output is based on what you put in. Software is no different. If your input data is crap, no amount of processing will make your data or reports useful or accurate.
I found that this principle applies to using LLMs as well. Since the input (prompt) is just plain English, people may think it is ok to just put in any combination of words and expect the LLM to output something magical. But to make the coding tool output great code, I need to make the input, which are the instructions, to be good as well.
I like to think of it as being a foreman in a construction site. You are not the one who actually pours the cement, hammers the nails, and welds the joints. But ultimately you are still responsible for the output of your workers. To be a good foreman, you need to manage your resources (agents) well. You need to be competent in your work so that you are able to differentiate between a good job and a horrible one. And LLMs can definitely produce crap code at times.
It may be tempting to just let the AI agent do all the coding while you drink your coffee, but when the requirements change (and they usually do) or when things break (as they always do), it will be up to you to solve the problem. If you do not know how it works, how will you fix it? How will you ensure that the code doesn’t have any edge case bugs or opened security holes?
Is Programming Dead?
It is not dead in a sense that the world no longer needs people who know how to program, but the work will be much different than what it used to. This follows the same pattern that has happened time and again in the area of software development: abstraction.
In the early days, the only way to communicate with a computer is through assembly code. As requirements become more complex, coding in assembly becomes tedious and unmaintainable. Then comes C that allowed programmers to create more complex applications. But at the end, this code still compiles to machine language.
Then from C, interpreted languages such as Ruby were born. With Ruby, code becomes even more accessible to more people, since the syntax just reads like English. This expressive language produced one of the most popular web development frameworks, Ruby on Rails. With this framework, even a single developer can be productive in all areas of web development.
Web frameworks then enabled us to build web applications without worrying about the internals on lower-level operations, such as:
- Do you need to know how a request cycle works? Just define a controller action and just
respondaccordingly. - No idea how SQL
joinworks? You can useuser.postsand the ORM will handle it in the background. - Memory allocation and garbage collection? This is not even on the radar.
So as developers, we continue to get tools that are operating in an even higher plane of abstraction. You still need to know the fundamentals to be able to diagnose and fix problems, but your productivity as a user of a framework is magnitudes higher than using C to build your web application. When was the last time you worried about memory allocation when writing your program? Or making sure you support HTTP/2 in your web app?
Engineering
Perhaps LLMs are just another step in that abstraction. Someone no longer needs to know the syntax or the function arguments of the code you are working on, as these are auto-filled by the coding tool. To build your next “to-do” app using another language of framework, you no longer need to read books and documentation for a few hours or days.
Our jobs as software developers evolved as well. The job of a programmer is sunsetting, but this is replaced by a job of a software engineer. This title has been used for many years now, but we have yet to use it in its truest form.
An engineer applies their technical knowledge to design, build, analyze, and improve systems that solve real-world problems. Scientists focus on discovering novel ideas on how our world works, while engineers apply these knowledge to practical implementations.
These AI coding tools enable us to focus on more important problems: how to make applications that solve real-world problems. We now have the ability to tweak the functionality and design the interface rapidly and without working until the next day.
Does this mean you can just hand over the control to the LLM for your coding projects? Absolutely not. The technology exists to enhance our capabilities, not to replace them. And like a real engineer, you are not the one that wired the electricals of a building, but you should be the one who designed it. You will affix your signature in that project and so, ultimately responsible.
Photo by Christina Morillo