If you build software for a living, generative AI may be a scary development, as it has the potential to take over a lot of software creation. But I think it depends on what you see as the job of creating software.

A coder in the world of IT is somebody who writes code in some programming language. More typically they modify code instead of writing it from scratch. This is in response to bugs, feature requests, and so on. In the age of AI, a lot of coding can be automated. We have seen many examples of AI generating lots of code based on fairly compact specifications.

A software engineer builds systems out of software. This may involve coding, but there are many other ways to create business value with software.

Let’s drive this home through an example comparing the approaches that coders and software engineers would take.

Suppose the objective is to create some kind of AI-powered analysis engine. You’d like to categorize a bunch of expenses coming from a variety of sources. A coder would select a few relevant libraries to start with, such as Langchain, get API access to a model or so, and start fleshing out the program code.

A lot of this work can be generated by an AI. The tooling for that is at the moment one of the hottest areas of business development, so it is definitely a realistic approach.

However, a software engineer might consider a few alternative options. Sure, they should be familiar with writing code, but there are a lot of other options.

  • It is very conceivable that there exists a SaaS solution (and probably more than one) that largely fulfills the needs of the business stakeholder.
  • It could be a feature from one of the core systems that the data was coming from in the first place.
  • Maybe most of the analysis could be done by an Excel or Google Sheets plugin.
  • A complete open source package may already exist.

These alternatives differ in many dimensions, and the optimal trade-off between advantages and disadvantages is, what I will maintain, an engineering decision.

Dimensions that matter include:

  • cost, in particular total lifecycle cost
  • speed, as in time to value
  • flexibility, to what extent can the solution be customized, or included in a larger portfolio of applications
  • the control that the stakeholders have over the solution
  • the skills and competencies in and around the organization to keep this alive.

Just collecting the background information to evaluate these dimensions is a significant task. I have heard estimates that more than 80% of knowledge in organizations is so-called ’tribal’ knowledge. That is the knowledge that is never written down, but is perpetuated in an organization through informal channels. This information is inherently difficult to input into AI applications.

And then, think of this. The decision to use AI to develop and maintain significant parts of a code base is an important engineering decision in itself.

I have yet to see evidence that an AI tool will bring significant benefit to this situation. For instance, when I asked a chat model for alternative software options for the analysis engine, it only provided lists of technical components and technologies suitable for a coder.

In conclusion, while AI continues to evolve and certainly has the potential to transform certain aspects of coding, and possibly parts of software engineering, I see no evidence that the discipline is in danger of being automated away.