On Decidability of Our Jobs and AI Replacing Software Engineers

Among all the occupations AI could replace, why are we focusing so much on Engineering jobs that require such expertise? I'm well aware of quality of the code AI writes, it is beyond useful but I don't see a world where that piece of code can find its way into the real world without the help of a software engineer. First, I would like to talk about the kind of jobs that I think AI will replace first and how AI can't replace Software Engineers any time soon.

I would like to use the Turing-completeness analogy to describe jobs (a system that can simulate any computation). I think as there are two categories of jobs, decidable and undecidable. In the traditional sense, a decidable problem can be solved by a well-defined algorithm that always halts with a correct answer. Translating this to the world of work, a decidable job has well-defined inputs and a finite set of outputs. So it can be fully automated or scripted. Jobs that are mostly decidable are most prone to being replaced by AI. On the other hand, an undecidable job is open-ended. Given a problem, there is no guaranteed algorithm that always gives you a solution, or even tells you if a solution exists. An example of the decidable jobs could be a customer support agent. Even though your input set is not well-defined as it is usually a text written by a human, (probably this is the only reason why this job still exists today), your possible actions are all documented. On the other hand, an engineering job can be well-defined as undecidable, build a system that scales and supports X features under Y constraints. Arguably most of your job is to figure out how and planning the process rather than the actual implementation. Take construction engineers for example, their primary duty is to come up with a plan rather than carrying the material that is required to build.

One might say, in this context every job can be defined as either decidable or undecidable based on the job description. It's also fair to say each job has some decidable factor and some undecidable factor. For example, a customer support agent might have creating new workflows as a part of their duty rather than only using pre-existing procedures, which makes it less decidable. On the other hand, an engineer can have a job where the only expectation is to transform some data from one format to another. Therefore it is not always possible to classify an occupation entirely as decidable or undecidable. Here is a key take-away, the definition of a job ultimately determines its decidability. We create jobs to solve problems and there are infinitely many ways to define those jobs. If we are able to define those jobs with a clear separation of decidable and undecidable, we can easily replace the decidable part with AI.

However this will give birth to new jobs where the person's primary function is to split a job into a decidable and an undecidable factor. We can think them as AI-integration engineers. Their primary function is to extract out the decidable factor from the undecidable factor. Since the process of extracting decidable from undecidable is undecidable (the classic halting problem), it is fair to say their jobs are secure. I do believe software engineering overlaps quite a lot with the definition of extracting out the decidable. Not just software engineers, but most engineering jobs have this function, where engineers primary function is to create individual units of job each can be autonomously executed. It's almost like we have defined what engineering is...

As programming languages have a formal spec, their syntax is decidable. I think this is one of the pitfalls that make people think software engineering is going to vanish. However their function is absolutely not as we have discussed. Furthermore it is discussed only around one third of a Software Engineer's duties consist of writing code. So, it is fair to say most software engineers' jobs are safe. Only a small portion of their job can be replaced by AI, the syntax of their programming languages. Note that it is not possible to generalize this to all software engineers, as some engineers might find their jobs to be more decidable than others. But you don't really need AI to replace those types of Software Engineers, software can replace developers on its own. We have been seeing this shift for a while, from "punch card punchers" being replaced by terminal emulators to static website generators allowing non-programmers to create websites. However this didn't end the Web Developers' jobs but rather pushed them towards building more advanced frameworks and tackling harder problems. So ultimately, my takeaway is that AI will help us eliminate the decidable part of our jobs faster than ever, which is usually the most boring and uninspiring part anyway. It will allow us to spend more time on tinkering and building more advanced tools.

Final Remarks

I have intentionally tried to keep this article short, as there is much more to say about software engineering. The article "AI Over-Hype: A Dangerous Threat (and How to Fix It)" motivated me to write this post, as it advocates professionals to rally against the remarks of "AI will write all the code" (Another shoutout to Anthropic's CEO). It dives much deeper into the topic of software and AI, supports its arguments with empirical data. Also a great blog post from Alperen, "Verifiability is the Limit" dives much deeper into software engineering. It discusses the pitfalls of AI on correctness and verifiability in relation to software engineering, which inspired me to come up with the analogy of Turing Completeness in terms of job functions. Finally David Graeber's "Bullshit Jobs" is a must read on a broader context. It's not meaningful to discuss what jobs can be replaced and what can't without really understanding their functions and why do they exists in the first place.