“Automation does not need to be our enemy. I think machines can make life easier for men, if men do not let the machines dominate them.”
John F Kennedy, “Public Papers of the Presidents of the United States: John F. Kennedy, 1963”. (https://www.azquotes.com/quotes/topics/automation.html)
There’s a rather ironic phrase that gets used in software engineering. “I want to automate myself out of a job.” I’ve said it lots of times. I’ve heard it many more. It has always been said somewhat in jest. Software engineers tend to hate manually repeating mundane tasks.
One of my first real programming jobs was in college. The development environment of choice was “vi” to write Perl. Debugging was typically writing to the console or a log file. Since it was a web server application, this required many commands to stop and start the server while cleaning up the logs. The 30-45 seconds of typing adds up pretty quickly when chasing down that “off by 1 error”, “failure to initialize”, or the “whoops wrong variable” mistake.
I took that same philosophy with me to my post college jobs. Until I started working in Eclipse and doing Java development. Remote debugging was getting easier, but still not where it is today. The Integrated Development Environment (IDE) removed many repetitive tasks. I still had to do various tasks in order to package the application up the right way and make sure certain services started up first. I coded a set of scripts to manage and monitor restarting the development environment. Several on the team adopted it.
Today there is Docker, Kubernetes, Terraform, and the IDEs are a lot better. These scripts don’t need to be written as much, but there are variations which still help. Infrastructure as code is all built around automating deployment and minimizing opportunities for mistakes being made by human error.
Similar efficiencies have happened on the build side. The amount of frameworks and libraries available save countless hours of re-coding the wheel.. err, I mean JSON parser, PDF generator, or Excel file reading and on and on. When we were building our business to business and business to consumer sites back in the early 2000s, JSP still wasn’t a thing. A consulting group had built out a branding framework for HTML. We leveraged that and built what was effectively a home grown object relationship management platform. Now, most larger languages have some open source framework like Hibernate for that. This means most software developers don’t really need to know exactly how the services interact and save data. Abstraction, reflection, and generics make so many things easy to incorporate such that only the business logic needs to be focused on.
When a developer combines the abstraction and library capabilities that exist with the ability for IDEs to do code completion and even to a degree code generation of simple methods, a developers time can be spent at a much higher level and focus on the things that are truly specific to the business.
Each one of these has made writing code faster. Each one has reduced the barrier to entry to become a developer. The side effect of that is that a lot of software is packaged with a significant amount of unused code, there’s an increase of security vulnerabilities just waiting to be loaded into memory, and many of the owners of the code do not fully understand the code itself.
Recently there has been an increase of tools which do “low code” or “no code” solutions. Some will argue how much software engineering really goes into products that are built using these solutions, but they do drive additional products being built.
Through all this, the software engineer and developer has maintained a stable career.
AI Will Change That
Many will argue that IDEs, Frameworks, and even the “Low Code”/”No Code” movement has not replaced software engineers and thus AI will not. That software developer and engineers are still in demand. And with salaries near or well over 6 figures and 150,000+ (according to LinkedIn.com as of April of 2024), that’s a fair argument.
The difficulty I have with that argument is in capability of these are not the same as what an AI coding assistant can do. Or more accurately, what AI agents can do.
Most IDEs are limited to some boiler plate code writing or take existing code and manipulate it. There are capabilities such as generating certain types of functions and for refactoring code, but there’s no way to ask the IDE to write a game of snake. Yes, some of the more recent IDEs can have the developer right click on an attribute and generate code which loops through the variable or creates a database connection to save it. These are efficiency boosts.
Another limiting factor of the IDE is that it can be rather difficult to use some of the code generation due to user interface limitations.
When looking at frameworks, they solve similar problems that the IDE does. They are able to abstract and generate code which is standard. Even some of the more complicated frameworks like Spring or Flask, still require a lot of coding to work when it comes to feature and functionality. A developer cannot ask these frameworks to code a screen which will perform some business function.
The low code / no code solutions are more platform based with limitations in features and capabilities. Can they do enough for some businesses? Yes. But once a business extends beyond those capabilities (and most do so rather quickly), they are severely limited. There’s also some solutions which have significant licensing and security issues.
None of these hold true for artificial intelligence. I can ask an artificial intelligence to “Build me an application which manages a users calendar and tracks the effectiveness of maintaining that schedule.” Or “Build me an app which helps track the efficacy of a clinical trial for curing someone of contrarian thinking.” This won’t be done in something like ChatGPT in one query, today. But it can be done with some AI tools that leverage AI agents. And they will get better when LLM and Reward Based AI’s (think DeepMind) are linked together.
Supply And Demand
Most of the code that software engineers will write is pretty similar. That is to say, they code for a business need with very little need to code file writing, database access, and a web layer. There are only a limited set that are coding hardware layer or embedded software. If most development was unique, the no code or low code solutions wouldn’t be viable businesses, DE’s wouldn’t be able to do any kind of code generation. and frameworks and existing code generation template systems wouldn’t be valued.
Software engineering still has a barrier to entry because there are skills which are needed. These skills could include learning how to program, thinking sequentially like a computer does, or having the pateince to debug nuances. Or in the case of no code solutions, there is not enough flexibility. It is for these reasons, software engineers are still needed.
Artificial Intelligence removes that barrier to entry. It removes that lock on flexibility. When someone can talk to an artificial intelligence using every day language and have it ask for what is needed, everyone basically becomes a software engineer. Think of it like what 3D printers can do for manufacturing. Only because software is easier to scale, the impact will be felt much more rapidly.
Combine that removal of barrier to entry with the capability of AI for assisting those software engineers that may be needed, most businesses will have less need for software engineers.
This will create a split. There will be a limited set of businesses or organizations which need highly skilled software engineers, but most businesses won’t. Most businesses will be able to get by on Artificial Intelligence. It will kind of be like sport players. Those who play at the top will make a lot of money, but those who do not will struggle.
The reality is that AI will be better than your average developer. It will make less mistakes. Do not think that AI will only be as good as today. Today is the worst AI will be. It is changing very rapidly and improving rapidly.
Yes, software engineers did automate themselves out of a job. While at the same time, they gave everyone the ability to be a software engineer.