The changes in software development over the past two years may deserve more attention than those of the previous decade or more combined. On the surface, we see Copilot, Codex and various coding agents progressing from completing a few lines of code to modifying entire projects, running tests, working with GitHub repositories and even carrying out tasks continuously in the background. But to describe all this simply as “AI getting better at writing code” is to underestimate what is happening.
What is really changing is the way software development works.
OpenAI’s recent push towards Codex Cloud is a telling example. Codex can now perform development tasks on cloud computers managed by OpenAI, connect to repositories, prepare dependencies, modify code and run tests. Tasks can continue after the developer’s own computer goes to sleep. Developers can even pick up these cloud tasks from a desktop, the web or a phone. OpenAI’s positioning of Codex has clearly moved beyond code completion towards multiple agents, background tasks and end-to-end software engineering.
Yet there is still a clear boundary at this stage.
Professional developers have not really moved beyond development environments they can control directly. This is especially true of iOS, macOS and Windows projects, and projects involving simulators, physical devices, certificates, hardware interfaces or complex debugging tools. Developers still need to understand what is happening underneath. AI can perform many operations for you, but when environment, architecture or deployment problems arise, or a bug is difficult to reproduce, knowledge of operating systems, IDEs, compilation toolchains, runtime environments and network architecture remains essential.
We are therefore in a transitional phase.
In the traditional approach, people worked directly with an IDE. We opened Visual Studio, Xcode or Android Studio, created projects, edited code, compiled, ran and debugged them, then deployed them to a server.
A different structure is now emerging.
People interact first with AI, which in turn interacts with IDEs, compilers, Git, testing frameworks, browsers, servers and other tools.
An intelligent agent has been inserted between the person and the tools.
This may look like just another interface, but it could eventually change the structure of software engineering itself. Once AI can reliably control the tools beneath it, developers no longer need to know exactly where those tools are. IDEs and compilers will not disappear. Xcode, Visual Studio, Docker and GitHub Actions will still exist, but they may gradually disappear from view.
Just as ordinary internet users today do not know how many databases, load balancers and containers sit behind a website, future software developers may not need to deal with compilers and project files every day.
They may simply say, “I want to add this feature.”
AI decides which code to change, which tools to call, which testing environment to use and which tests to run, then returns the result.
The developer’s immediate task gradually shifts from operating tools to expressing intent.
This brings another significant change. The source of advantage is shifting between people with a software development background and those without one.
Previously, the main barrier to software development was the ability to implement an idea. To turn an idea into software, a person needed to understand programming languages, data structures, operating systems, databases, networks, frameworks and deployment.
AI is rapidly lowering that barrier.
This does not mean that professional software knowledge suddenly has no value. Quite the opposite: at this stage, experienced developers usually retain a clear advantage when using AI. They understand how to divide a system into layers and how databases, front ends, back ends, authentication, caches and messaging systems relate to one another. They can also judge whether an AI-generated solution is actually sound or merely appears to work.
That advantage may persist for quite some time.
But it is moving from “Can I write this code?” to “Can I understand this system?”
As development continues, the advantage may shift to a further level—whether someone understands the problem itself.
A person without a software engineering background may not know Swift, Kubernetes or the details of OAuth. But if they truly understand an industry’s needs, what users actually do, which processes are necessary and which constraints must be respected, they may still be able to build highly complex software through AI.
Conversely, someone with excellent technical skills who does not understand the problem they are solving may simply produce meaningless software ten times faster, even if AI increases their development efficiency tenfold.
Software development capability in the AI era may therefore shift gradually from implementation to problem definition.
There is, however, a deeper change beyond the development process.
What changes in the future may be not only how software is developed, but what software is.
Software has traditionally been made primarily for people. Its design has therefore revolved around human perception and interaction. Windows, menus, buttons, mice, touchscreens and navigation bars all fundamentally serve to make computers understandable to people.
A graphical user interface is, in effect, a translation layer.
It translates the computer’s complex internal states into an interface people can understand and operate.
But if more and more software is operated by AI agents rather than directly by people, that premise changes.
An agent does not need an attractive button.
It needs a stable, explicit interface that a machine can understand.
It may not even need to “open an app”.
It may simply invoke a capability.
Searching for flights, buying products, generating invoices, updating databases, committing code and scheduling meetings are functions now scattered across different apps. They may gradually be broken into capabilities that agents can call.
At that point, the concept of an app as a complete, closed product starts to loosen.
Today, we are accustomed to opening a particular app to do something. In the future, we may ask an agent to do it. Users may neither know nor need to know how many applications, services or models are involved behind the scenes.
Software begins to move from an application towards a collection of capabilities.
The connections between those capabilities will also become increasingly oriented towards machines.
MCP is one example of this direction. Strictly speaking, MCP mainly addresses how models or agents connect to tools, data and external systems. It is not yet a comprehensive protocol for collaboration between agents. Nevertheless, the trend it reflects is clear: interfaces between software systems may increasingly be designed first for machines rather than people.
A further step would bring extensive task decomposition, collaboration and calls between agents.
One agent understands your goal.
Another gathers information.
One writes code.
One runs tests.
Another handles deployment.
There may even be an agent dedicated to checking whether the others have made mistakes.
The traditional boundaries between front ends, back ends, apps and services would then be recombined.
Software lifecycles would change as well.
Today, software typically starts, runs and exits.
Software in the agent era may not follow that pattern.
Some software may persist for long periods, continuously monitoring a condition. When that condition is met, it performs a task and returns to waiting. Some tasks may run for minutes, others for days, while some may never have anything resembling an exit.
Software may become an ongoing process of action rather than simply a program waiting for someone to click.
That would redefine what it means for software to run.
It would also redefine what it means for development to be finished.
Traditionally, releasing a piece of software largely marked the end of a phase of development.
In the future, an agent-driven software system may remain in a continuous state of modification, testing, deployment and adjustment. AI observes the results of operation, identifies problems, changes the code, tests it and deploys again. The once clear boundary between developing software and running it becomes increasingly blurred.
What we call cloud development today may therefore be only a very early step in this broader change.
The issue that deserves attention is not simply whether we will still need Xcode or whether programmers will still write code.
The more fundamental question is how the relationship between people and software is changing.
First, people learned to operate software.
Then they learned to develop it.
In the next phase, people may primarily express purposes, define constraints and judge results, while machines carry out much of the implementation.
Further ahead, even software itself may cease to be designed primarily for people and instead be designed first for other software and intelligent agents.
If this direction continues, the software engineering capabilities that matter most may no longer be proficiency with a large number of development tools. They may instead be three things—understanding the problem clearly, defining the constraints clearly, and judging whether what the machine has produced is really what we wanted.
IDEs will not disappear.
Neither will code.
Nor will servers.
They may simply retreat from view, much as data centres have today.
What developers directly engage with will no longer be a computer, but an intelligent system capable of understanding intent, organising tools, invoking software and coordinating other agents.
In this sense, what we are experiencing is already more than an upgrade to programming tools.
It is becoming a change in the form of software itself.
Discover more from Geoffrey Chen
Subscribe to get the latest posts sent to your email.