How AI Raises the Bar for Developers

The intelligence embedded in today’s AI software is the sum of multiple years of dedicated work by hundreds of thousands of programmers over the last several decades. Multiplying the duration by the number of people who have contributed their time in building AI systems could easily be thousands of man-years. A modern AI model is the result of millions of man-hours put in by the programmers directly or indirectly. How realistic is the premise that AI can replace programmers? Does an AI model possess sufficient intelligence to match the depth and understanding of the hundreds of thousands of programmers who contributed to building AI systems?

When a programmer writes software, there is a mental model of the world that the programmer is aware of. The programmer is also aware of initial conditions and constraints. A programmer writes software for a given user. They understand the needs of that user. Such needs are often implicit because they are considered obvious. Although obvious to the programmer, these needs are not apparent to an AI model. One part of getting AI models to do more meaningful work will be how to make such user and world understanding available to a model.

Let’s consider an AI model or agent that needs to write a sorting algorithm such as a quicksort algorithm. In a practical setting, a quicksort performed on a simple list of comparable items has limited practical value, though this is the version of the problem that is taught in elementary computer science programs. This is also an example of a task that a frontier AI model can do reasonably well. For a quicksort program to be useful in a practical setting, the records that need to be sorted need to have some relevance to the user. For example, these could be names of products that should be sorted to display on a webpage, or these could be dates based on which information is analyzed. Therefore, if we expect an AI-based program to be able to write such a sorting algorithm for us, we will need to inform it about:

1. What is the record that should be sorted?
2. What is the key to be used from this record for comparisons?
3. Where is the source system from which to get the data for sorting this?
4. How to format the results for subsequent consumption?

Information such as the above is either scattered over multiple pieces of documentation or resides in the minds of the software architects who understand the system internals. Given such details, an AI system may be able to generate a correct sorting algorithm for the problem at hand. However, it is very unlikely for an automatic code-writing AI software to churn a correct version of the program on its own. In the best case, architects might feed an AI-based platform sufficient information to generate the core sorting logic, but the responsibility of providing the software system with the right business context, initial conditions, and constraints will still be with the architects. Likewise, system engineers and architects will play an important role in testing the software, and integrating it in the wider software ecosystem, once an AI system generates it.

Several writers have predicted that programming will become irrelevant soon. If we assume AI models fully understand mathematical and algorithmic nuances (e.g., algorithms like quicksort), then we can assume that the AI model can take care of such well-defined tasks. However, providing AI with the appropriate contextual information will remain the responsibility of system engineers and architects, at least in the short term. The fact that the models can do well-defined tasks does not necessarily mean they are ready for all practical tasks.

I would like to build an analogy here with classical system programming. I argue that AI models merely raise the level of technical abstraction with which engineers must work. In the early days of computing, programmers focused on low-level details such as memory management and hand-optimizing loops. A good systems programmer was expected to understand such low-level detail and optimize it. As computers became more powerful and software became capable of handling several of these things for the programmers, the majority of programmers did not have to work with such low-level details anymore. The majority went on to use high-level programming languages like Java, C++, Javascript, and so on, and learned to use interfaces provided by more modern hardware and software to solve for their users’ needs.

We are at a similar juncture with AI-based programming. The advancements in AI model capabilities only increase the level of abstraction at which programmers need to work. So far, the interface to work with AI models and communicate the programmers’ or architects’ needs at this higher level of abstraction is through prompt engineering. Revisiting the quicksort example above, if a system engineer or architect needs to give additional contextual information to a model, currently this will need to be done via some version of prompts. In spite of the several advancements in RAG and agentic software, the fundamental interface for interacting with advanced AI models remains prompt engineering. Whether a simple text-based prompt will suffice for communicating complex contextual information to the AI models is an open question that needs answering.

Returning to our analogy, although many programmers transitioned to higher-level languages (e.g., C++, Java, JavaScript) that allow interaction at higher levels of abstraction, some continue to work with low-level algorithmic and hardware details. This is so because several of their tasks were possible only using the low-level programming and hardware interfaces. One major category involves writing optimized and efficient programs. I expect a similar category of programmers in the future who will write software in the classical manner (developing and testing most of their code manually) even as the majority adopt AI-enabled approaches.

It is worth considering the likely characteristics of problem areas and domains that will need to use classical software engineering while other domains use AI-enabled approaches. The domains that will need to lean more heavily towards classical software engineering are the domains where the problem area and context cannot be easily formulated for use by AI models. For example, programmers that work at the interface of hardware and software, or those that focus on automating new tasks using hardware, often need to take a trial-and-error approach to fine-tune the hardware-software interactions. Similarly, programmers working on new creative and innovative domains will likely need to work using classical software engineering principles and implement some of their innovative solutions “by hand.” In both these examples, there is trajectory towards using more AI-enabled ways. The initial path of that trajectory involves more classical software engineering.

On one hand, AI models show significant promise in automating repetitive coding tasks, resulting in higher developer productivity. On the other hand, developers will need to raise their level of abstraction in working with hardware and software. Developers who previously spent significant time on repetitive coding and low-level tasks can now accomplish much more in a day thanks to AI capabilities.

To remain relevant and productive, developers will need to manage greater contextual information and take responsibility for larger, more complex tasks. In domains with high demand for new software, this creates opportunities to accomplish more through software.