There was a time when the amount of land a farmer could cultivate depended heavily on how much physical work could be done in a day. Then came the tractor. Suddenly, work that might have taken several days could be completed in hours, and one farmer could cultivate far more land than before.
Yet the arrival of the tractor did not make the farmer irrelevant. Nobody looked at a successful harvest and concluded that the tractor was now the real farmer. The tractor increased the farmer’s capacity, but the farmer still decided what to grow, when to plant, how to manage the land and whether the harvest was good enough to sell.
Artificial intelligence may be doing something very similar to software engineering.
AI is mechanising code production
For a long time, one of the most visible parts of software development has been writing code. Software developers learned programming languages, frameworks, libraries and APIs, and then spent considerable time translating solutions into instructions that computers could execute.
Generative AI is dramatically reducing the effort required for that translation. A developer can describe a REST endpoint and receive a reasonable implementation in seconds. The same can be done for database entities, SQL queries, user interfaces, unit tests, configuration files and documentation. Increasingly, a developer can describe what needs to happen and receive working code almost immediately.
This is a significant change, but it does not necessarily mean that software engineers are becoming less important. The tractor did not eliminate farming; it mechanised some of the labour involved in farming. In much the same way, AI may not eliminate software engineering. It may simply mechanise a large part of code production.
That distinction matters because producing code and engineering a software system have never been exactly the same thing.
A tractor can plough the wrong field very efficiently
Imagine giving someone who knows very little about agriculture a sophisticated modern tractor. The machine may have GPS navigation, automated steering, soil sensors and precision planting systems. With very little physical effort, that person can cover an enormous amount of land.
Unfortunately, they can also make an enormous mistake.
The tractor does not necessarily know whether this is the right field to cultivate, whether this is the right crop to plant or whether planting today is a sensible decision. Its power makes the operator more capable, but it does not automatically make the operator a good farmer.
The same is true of AI-assisted software development. A developer can now generate thousands of lines of convincing code very quickly. The application may compile, the interface may look polished, the APIs may respond correctly and the tests may even pass. Yet the system can still be badly engineered.
The components may have the wrong responsibilities. The data model may become difficult to evolve. Security assumptions may be weak. Dependencies may introduce unnecessary complexity. The architecture may work perfectly for today’s requirements but become impossible to maintain when those requirements change.
AI can help identify many of these problems, but somebody must first understand that they are problems. More importantly, somebody must decide which trade-offs are acceptable in the particular system being built.
That is software engineering.
What becomes scarce when code becomes cheap?
For many years, the ability to produce code efficiently was valuable partly because code was expensive to produce. A substantial feature could require days or weeks of implementation work. If AI reduces some of that work to minutes, the economics of software development begin to change.
Code becomes cheaper, but good engineering judgment does not.
Someone still has to decide what should be built and, equally importantly, what should not be built. Someone must determine where responsibilities belong, which components should depend on each other, how data should move through the system and what should happen when parts of the system fail. Someone must think about security, performance, maintainability, privacy and the consequences of decisions that may only become visible several years later.
These are not primarily programming-language questions. They are questions about systems, trade-offs and consequences.
This may therefore be one of the most important changes AI brings to software engineering: the scarce skill is gradually shifting from the ability to produce code to the ability to make good decisions about code.
AI can accelerate technical debt too
There is an understandable assumption that if AI makes programmers more productive, software systems will automatically become better. That does not necessarily follow.
Suppose a developer can now produce five times as much code in the same amount of time. That is impressive if the additional code represents good solutions to well-understood problems. However, if poor abstractions, unnecessary dependencies, duplicated logic and architectural mistakes can also be produced five times faster, AI has not eliminated technical debt. It has simply increased the speed at which technical debt can be created.
This is another reason the tractor analogy is useful. Mechanisation allows a knowledgeable farmer to cultivate more land, but it also allows poor decisions to be implemented at much greater scale. Technology amplifies capability. It does not automatically provide judgment.
AI may therefore make strong software engineers dramatically more productive while simultaneously making weak engineering decisions dramatically more expensive.
This should change how we teach software engineering
The implications for universities may be even more interesting.
If a student can generate a reasonable implementation of a programming problem in seconds, an assessment that simply asks the student to produce that implementation begins to measure something different from what it measured ten years ago. We can prohibit AI during the examination, but that does not remove AI from the world in which the student will eventually practise software engineering.
Perhaps our assessments should increasingly ask students to do something harder.
Instead of simply asking students to write a program, we can give them an AI-generated program and ask them to determine whether it is correct. We can present several possible architectures and ask them to choose one and defend their decision. We can give them a working system and ask them to identify how it might fail. We can introduce conflicting requirements and ask them to make and justify engineering trade-offs.
Most importantly, we can give students a solution that appears to work and ask a deceptively simple question:
Would you be willing to deploy this system?
If the system were controlling financial transactions, storing medical records, managing school examinations or delivering a government service, what evidence would they require before trusting it?
Those questions test something that generating another hundred lines of code does not necessarily test: engineering judgment.
The farmer still owns the harvest
There will probably continue to be debates about whether software created with substantial AI assistance is somehow less authentic than software written manually. Over time, that distinction may become increasingly difficult to defend.
We do not normally ask how much of a farmer’s harvest was produced by human muscle and how much was produced by machinery. We care whether the farmer produced a good crop. The machinery is part of the farmer’s capability.
Perhaps software will move in the same direction.
The important question will not be whether AI generated 10%, 50% or 90% of the code. The more important question will be whether the engineer understands the system that is being shipped. Can the engineer explain why it was designed that way? Can they identify its assumptions and risks? Can they verify that it behaves as intended? Can they maintain it when the environment changes? And, ultimately, are they willing to take responsibility for it?
That is where ownership lies.
You can continue using the mule and plough if you want. Someone else may choose the tractor. The tractor will probably allow that person to work much faster.
But neither the mule nor the tractor decides what kind of farmer you are.
AI is becoming an extraordinarily powerful tractor for software development. It can help us produce more code, explore more solutions and build systems faster than before. But the quality of what eventually ships will still depend on the people who understand the field, make the important decisions and take responsibility for the harvest.
AI may be changing how we build software. It is not removing the need to know how to engineer it.
