Will AI kill software development?

“Video killed the radio star” as the song goes, but could Generative AI do the same for the software development industry?

Let’s start by saying that demand for technical skills remains high; in fact the?U.S. Bureau of Labor Statistics?predicts a 26% increase in employment for software developers over the next 10 years. Not least driven by the need for business to adopt new digital ways of working, including AI. And let’s not forget, there are literally a gazillion lines of code out there, which will need to be maintained, developed, and nurtured for many decades to some.

Now we can all breathe a bit easier, let’s consider what the impact of Generative AI will be on the software industry, and will AI ever truly take over software engineering? Whilst it’s hard to fully predict the future, there are clear and emerging trends.

Turbo Charging Software Development

We are already witnessing fundamental shifts due to AI, across a range of industries such as journalism, copy writing, content production, as well as verticals like manufacturing, healthcare and legal. We can say with some certainty, is that Gen AI will also radically change software delivery processes, in the most fundamental way since the introduction of cloud computing.

At its core, this is because Generative AI is exceptionally good at understanding and generating language. Of all kinds – an image is “just” a language of ones and zeros, hence AI can understand and generate imagery. Software is “just” a language for machines, and syntactically more precise than a human language, so arguably easier for a machine to create. What’s more, there are huge repositories of software available which are being used to train large language models in all common software languages, giving AI a massive base to bootstrap with.

In the immediate term, what this practically means for software engineers is to turbo charge their software development activities. Auto-completing lines of code as you type, documenting code you’ve already written, writing code based on human language descriptions, generation of code that tests the code (unit tests), navigating complex repositories, etc. These capabilities are not only readily available now, but are almost spookily good at predicting what you intend to do next, offering to do it for you. This is because, very few software engineering problems are truly unique, most code has been written by previous developers over and over again umpteen times in the past and exists in training data fed to AIs.

The effect will be developers on steroids (minus the unhealthy side effects), accelerating everyday tasks, but not necessarily replacing them. I liken this to the introduction of the developer IDE (Integrated Development Environment). In the old days (yes, I’ve been around the block more than a few times) software was written in basic text editors. Over time, these were replaced with development tools, that highlight syntax errors, allow debugging of applications line by line, provide in context information about library functions etc. These have vastly improved developer productivity. Gen AI injected into those environments will quickly boost productivity to the next level.

?But it doesn’t stop here – tools that boost other roles in software delivery from managing agile teams, reporting, automated testing, infrastructure automation will all play their part in streamlining software development life cycles in the months and years to come.

But what comes next? AI – build me an app!

But can I ask an AI to write me a complete application? Or even improve my existing application? I could then retire my whole development team – right? Here’s the rub – but first a caveat:

If you want a relatively standalone application, no-code / low-code solutions have advanced considerably, and tools such as Bubble.io, Web Flow and many others can do the job (you do still need an engineer however). That’s a subject for another day.

But enterprise technologies do not exist in in a vacuum. They cohabit complex eco-systems made up of many other platforms and technology components. Applications themselves are mixes of open-source software, frameworks, integrations, user-interfaces, and custom code. Furthermore, systems within an enterprise are at a different states of evolution, ranging from old legacy (even undocumented) systems to more modern tech stacks, often tightly coupled and sharing data through integrations between them. Further complicating software engineering tasks.

How can Generative AI work in these company specific IT environments?

We can break this down into two problems to solve, how to instruct an AI, and how to deal with the complexity above.

Telling AI what you want

Let’s imagine we are building a new software application. It’s not enough to say, “write me a killer game app”. In the real world, an AI needs to be told very specifically what you want (or it may make it up in ways you don’t intend!).

For example, imagine our app is a simple software program, that simply asks for your name, and replies “Hello, [name]”. Ask an AI like ChatGPT to write you a program based on this information, and you will get a perfectly runnable program.

But even in this super simple example, there are other things to consider in a real world context. You might need to tell the AI which programming language (and version) to use, where you want the code to be hosted and run (in a cloud, and as part of a serverless function?), what security you want to put around it (can the world access it, or just specific users?), how to handle language translations (in which country are we launching the app?), how you want to monitor the service so you can see if it’s working properly, etc – and suddenly even this simple case needs a lot of refinement in terms of defining the requirements.

In Generative AI, getting the right response from your AI is known as Prompt Engineering i.e. the art of asking a Generative AI what you want, in a way that allows you to get the response you need. This includes the way you detail the instruction, the information (context) you provide as part of it, examples of the type output you want, etc.

Fortunately, requirements gathering in software engineering is already quite well refined and understood. User Stories for example, are commonly used to capture the behaviour of a feature in a system e.g.

As a < type of user >, I want < some goal > so that < some reason >.

User stories can also document useful things like how to test if the functionality described works, happy path flows and exception cases, and so on.

These types of documented requirements are the bread and butter of AI; understanding written language and formulating a written response. In this case, understanding business requirements and generating software that can fulfil the feature described. It’s easy to see how refinement of requirements capture and advances prompt engineering will instruct an AI to develop code that if not replaces, accelerates software engineering.

We are already seeing evidence of this in the competitive coding space, where AI is beating seasoned software developers at solving complex coding challenges. Not in part because very detailed requirements are available, but also because these are standalone problems to solve. Nevertheless, this is a huge leap forward, and proof that well-defined software specifications can be understood and implemented by AI.

So, we can tell an AI exactly what the software should do, but a bigger problem to solve, is how it should solve the problem.

Birth of the Expert System

The second challenge is how to tell an AI not just to write functionally correct code, but also for it to understand the complex environment the software will be deployed into.

Moving on from our “Hello [name]” app, let’s consider a more real-world example.

Let’s say you run an online website for finance advice, and you want to add a new feature that shows authenticated users a history of their credit score over time. Let’s also imagine that you’ve captured the requirements for the new feature, in a format that is specific enough for the AI to understand all the necessary functional requirements.

As discussed above, an AI model coupled with the right prompts and context, could now conceivably generate workable code. But for that code to be useful in amongst the complex technical environment in which it will be deployed, requires a lot more knowledge.

Remember - this is not an isolated program, but a new feature of an existing application, and so must co-exist with the technology that runs the website. This will mandate a specific programming language and version, will need to re-use existing functions and software libraries that are available (to avoid duplication of code), be deployable in a preferred cloud or on-premises infrastructure, adhere to company security policies, know about the system that holds credit history and how to access the information through some kind of interface. And a whole lot more besides.

This type of technical information typically exists across an organisation but in a variety of places; in developer’s brains, with other subject matter / systems experts, accessible from within developer tools, and (hopefully, but not always) documented across internal company intranets. This is the job of the software engineer; not just to write the code that meets the requirement, but also deliver software that meets all of the businesses technical constraints and company policies.

To replace software engineers in this situation, calls for a highly specific AI, one that is acutely aware of a business’s IT systems. This is akin to the concept of a Digital Twin of a business’s infrastructure, an AI trained on all the available information about a technology landscape.

This would be achieved by training / providing access to the AI information about how an application is constructed, its code repositories, dependant software packages, features, interface specifications of other systems it exchanges information with, hosting infrastructure, corporate policy and more.

The result would be a kind of Expert System (yes, I’m a sci-fi nerd!), that takes responsibility for an application, including the ability to translate new business requirements into code, manage time-consuming maintenance tasks such as software upgrades and proactively identifying and fixing issues.

AI is already good at generating low level test cases, coupled with infrastructure as code and other established deployment & test automation, there is no reason why AI could not ultimately manage the release of new application features into target infrastructure to be used by end-users in a highly (if not fully) automated way.

These capabilities will evolve over time of course, beginning with improved code generation that can accelerate software development, but eventually allowing a more hands off management of an application or interconnected systems in an IT landscape.

Humans will feed in new requirements; the AI will be responsible for the technical implementation and delivery of the technical changes required to deliver the change.

Sounds farfetched? The technology to achieve such a feat largely exists today; Vector Databases can make accessible large amounts of company IT information e.g. existing code repositories, non-functional requirements, user-interface specifications, data dictionaries, interface specifications, which can be retrieved and used with in-context learning to instruct a Generative AI. Rapidly expanding context windows mean that AI can consume significant amounts of data for any given prompt. Many Generative AI code tools exist today, already integrated into software developers’ environment that can manage complex software maintenance tasks, automate testing and correctly identify code issues.

What’s more, platforms like GitHub who already have access to a subset of this information (assuming they host your code repositories) are already capitalising on this, by introducing AI capabilities that manage some of these developer tasks.

The next challenge for software engineering teams, is how to assemble these into functioning systems experts that provide the next level of quality and efficiency in software delivery.

Summary

Are we ready for such radical change? I would argue that IT is the most continually disrupted industry that exists. Every few years brings a major evolution, in technology and ways of working, and engineers are genuinely excited by the opportunities for the future.

Does this replace software engineers in the long term? Certainly not, although it’s clear that development will be accelerated in the near term, and more basic tasks will evolve away from development teams and become more automated over time. And not forgetting, all of these complex systems will require lots of engineering, scaling and development to become a reality, and keep us busy for many years to come.

That’s all from me, would really love to hear your feedback and opinions!