In over 40 years of coding, and 26 years of doing it professionally, I've seen a few paradigm shifts.
When I first learned to code it was in the wild world of BASIC (with GOTO everywhere), and then later in the less-wild Dijkstra-inspired world of Structured Programming in Pascal and C. Later, in university, I made the paradigm shift to object-oriented programming (C++), and in the late 90s Java was on the rise, so for my honour's degree year that was the language of choice. Then in my professional career I've seen the rise, use and death of rapid application development tools (VB6, Delphi, Oracle Forms), the continued rise of web as the dominant tech paradigm, the rise of mobile development, an explosion of programming languages, low code/no code platforms (the new RAD) and now, the latest big shift: the rise of AI.
In all of those shifts, the central skills a software developer needed to be effective did not change, and while AI augmentation is possibly the biggest shift since third-generation programming languages, the skills needed to be effective are still the same.
Over the years, the fundamentals have only become more important: while tools have chipped away at automating the non-essentials, the core activity of managing complexity and making design trade-offs has increased as a percentage of our time, and we are building ever more complex software. Some of these fundamentals are:
- Technical knowledge and capability, which are needed to evaluate trade-offs and select options.
- Methodologies, or practices, like creating feedback loops (plan-do-check-act, or read-evaluate-print loop).
- Soft skills, like communicating clearly and precisely, and understanding exactly what is needed and why, and a curious mind and love of learning.
The combination of all of these is what allows a developer to be effective: technical knowledge is the tool-belt; methodologies and practices provide the ability to wield the tools effectively (a good compilation is Modern Software Engineering by Dave Farley); communication and domain understanding is what's needed to select the right tools and the right methods to tackle an actual real-world problem, to evaluate trade-offs and to give and receive feedback to and from non-technical stakeholders that allow for course-corrections. The curious mind and love of learning is what fuels this thing, because if you stop learning, your knowledge become obsolete.
What AI brings to the table impacts the tool-belt most of all – it's like a full power-tool (albeit a power-tool that does slightly random things) when previously we had hand-tools, a petrol-powered chainsaw when we have been using hand-axes.
Meanwhile, on the practice side, there isn't much large language models (LLMs) do for us; in fact, unless you wield them with care, they will drive you to more dangerous practices, in my experience. There are whole new practices/methods coming about in the use of LLMs, but these are still people applying practices, not the LLM itself. And on communication and domain understanding, LLMs can provide a sounding-board and can help with brainstorming and research, but largely, this one is still in the realm of humans – the LLM is not really developing a mental model of the domain, nor is it co-ordinating between stakeholders. It has a wealth of knowledge, but it is neither curious nor loves learning – it is always us asking the questions.
Most people researching the effect of AI in the dev space are saying that AI is an amplifier (see We Studied 150 Developers Using AI (Here’s What's Actually Changed...) – that is, it accentuates what you already can do: it multiplies your output. For example, if your team is producing buggy code, give them AI tooling without training and they will likely produce more code that's more buggy. If your team has too much work in progress (WIP) and nothing ever coming out, AI is likely to increase what's in WIP, and a multiple of nothing is still nothing. However, if they are currently an effective team producing high quality output and continuously deploying into production, that too can be amplified: or at least this is what current studies are saying.
My own experiences working with LLMs has shown me that all the skills I've developed over the years as a software developer are even more important when adjusting my workflow to incorporate extensive use of AI (which, at Chillisoft, we have only done to date on internal and some smaller customer projects to evaluate it – corporate customers are still largely reticent to go that route):
- Feedback loops: One of the most fundamental practices in software development is checking your work end to end as often as possible, and if you've worked without tight feedback loops in place, then now is the time to develop the habit. The LLMs love to apply giant change-sets and hope for the best, which feels good when it works, but when it goes wrong it can burn time and tokens! Automated tests, tiny commits, continuous integration/continuous deployment (CI/CD) and always-releasable software are techniques that enable continuous feedback and these are now even more essential than before.
- Precision in communication: The more precise you can be in your communications with the AI, the better your outcome. This is not only in the business domain, although that's important, but also in the technical domain – knowing the difference between parameters and arguments, spies and mocks and fakes, strategy and decorator and builder patterns; these can all help you communicate with the AI more precisely and understand more precisely what it is saying.
- Critical thinking: An LLM is going to do things and you are going to need to critique it. Most developers are not used to doing this until later in their career, but it becomes absolutely essential to do so when using output from an LLM: we need to be able to tell whether it's on the wrong track; we need to build up that muscle that can look at code and smell issues with it.
- Evaluating trade-offs: If you use full-on agentic development, you are handing off most of your trade-off evaluation to the LLM, which may be okay in some cases (low stakes, demos or proofs of concept), but not in most core software engineering – there you will be incorporating an LLM at times to help rather than to do on your behalf, and if you use prompt techniques like Matt Pocock's Skills for Real Engineers, you will still be the one making the trade-off decisions (and should be).
- Reading: When working with an LLM, there is a massive amount of output and just keeping up with this is a challenge; good reading skills help a lot (and yes, reading is a skill you can get good at, just like any other, by practice and challenge).
- Parsing code: Related to reading, this is the ability to conceptually understand the code you are reading. It has always been a coder's super-power because "code is read more than it is written" (Daniel Roy Greenfeld), and when an AI is writing a portion of your code, it becomes even more important to be good at conceptually understanding code quickly. (LLMs make more complex code than you likely do, so this is one that you will need to get even better at, or, somehow, convince the LLM to write simpler code...)
- The command line: I've seen many a developer try to avoid learning the command line, and it is still criminally ignored in tech curricula. Shells are the fundamental way we harness compute power and are essential to software development and, on top of that, everything the coding agent is doing is using command line tools.
My own experience using an LLM is that if you're using an AI more extensively in your workflow, even if just for code-completion, you will be writing code a little less than before and doing more of these other skills: trade-off evaluation, critiquing, communicating precisely, reading and thinking more intensely. These fundamental skills have not changed, and the need for them will be intensified, if anything.
So if you're not able to work with Copilot or Claude in your professional life yet, or ever, don't for a minute think you're falling behind because you're not yet using AI. Instead, ensure that you are not falling behind on your fundamentals, because those skills can't be replaced by LLMs and will be even more necessary when you work with them.
And finally, a caution to developers using AI exclusively to write your code: your next job interview might be challenging unless you stop and do some hand-coding from time to time. AI use in the doing of coding work has been shown to limit learning because it turns out that doing the thing is how we learn, and if we outsource the doing, then no one is learning. I've done too many interviews where an experienced developer cannot explain a line of code they submitted as their own, and while employers want output, they also want to know that you know what it is you are producing. We might be able to prompt, but if we can't parse, understand and evaluate what comes out, then what are we even doing?
If you would want to talk about incorporating LLMs responsibly into your dev workflows, reach out to us at info@chillisoft.co.za. Chillisoft has also developed courses for software developers, born out of our own experiences as a dev consulting house. You can see a sample at https://www.udemy.com/user/devfluence/.
No LLM was used in the writing of this article.
Share
Editorial contacts