Software engineering in the year 2034

The future of software development until 2034 will be less radical than many expect: programming languages, core principles and testing capabilities will remain central. Above all, AI tools will accelerate the production of legacy code and reduce quality. Those who can precisely describe, test and ask the right questions will have the decisive advantage.

Key Takeaways

• Developers who accept generated code without checking it become maintenance programmers: they lose the creative part of their work and produce worse code faster.
• Code quality on GitHub has demonstrably declined since the widespread use of AI assistants: Code fluctuation, duplicates and copy-paste patterns are already on the rise, according to a GitClear study from January 2024.
• The most widely used programming languages worldwide were developed in the 20th century, and this composition will change little by 2034.
• Precision, testing capability and asking the right requirement questions are the core competencies that developers cannot replace with AI.
• Spreadsheets have shown that a tool that makes programming accessible to all does not destroy jobs, but creates new maintenance and quality tasks.

Programming languages are changing more slowly than the hype suggests

If you want to understand the future of software development, you should first look at the constants, not the headlines. The most widely used programming languages date mainly from the 20th century. Of the five most commonly used languages, only one was developed in the 21st century.

This inertia runs through the entire list. The top 20 and top 50 most commonly used languages also include representatives from the last century. The languages themselves continue to develop, but their composition remains surprisingly stable.

This has consequences for forecasts. No language developed in the 2020s is currently among the 20 most used. Anyone programming natively today and working with Rust will most likely still be doing so in 2034. Rust is now over ten years old.

Kevlin Henney recommends using this stability as a guide. The language you will be working in ten years from now probably already exists today. It may not be in the top 20 today, but it is very likely to be in the top 50.

Why the AI hype is missing the real trends

A sober look back helps to avoid exaggerated expectations. Anyone living in 2024 can remember 2014, 2004 and 1994. There are real changes in these cycles, but there is also a lot that has barely moved.

Several technologies sold as the future have not passed this test. The metaverse is fragmented and, in Kevlin’s estimation, will not prevail as a ubiquitous platform. More likely are further AR and VR applications in niches such as industry and gaming, and gaming already exists.

Web3 shows the pattern particularly clearly. The term has been discussed for over a decade with no real impact. By comparison, Web 2.0 was already dominant within the decade in which the term was coined. When it comes to cryptocurrencies, Kevlin only considers digital central bank currencies to be plausible.

Agile development is also one of the slow movements. The name has become the norm, but the number of teams that actually work in an agile way remains low. This is unlikely to change much until 2034.

AI raises legal and ethical questions that are not technical issues

The spread of AI depends on unanswered questions that lie outside the technology. The relationship between AI and big data is unclear: where does the training data come from and what are the copyright consequences? These questions are currently being negotiated in court.

Automated systems that make decisions about people’s lives are not about technical ability. Anyone who presents this as a purely technical issue has not understood how people work. It is a question of choice: What do we want, and how do we shape it?

The reason lies in the process itself. AI on a statistical basis maps the most probable past. This means that it systematically ignores marginal cases and minorities. Anyone who does not make this decision consciously puts a group of people at a disadvantage, because that is the nature of a statistics-based approach.

Anyone who presents this as a question of technology has not understood how people work. We have a choice here. Kevlin Henney

The impact of the regulatory framework is still open. The EU directive on AI is one of the first of its kind. It is too early to say whether it will have the same global impact as the GDPR, especially as it has been watered down. Kevlin expects it to have a noticeable practical impact in the following year at the earliest, possibly not until 2026.

The spreadsheet shows why developers are needed

The most widespread programming paradigm in the world is the spreadsheet, and it provides the best template for the future with AI. Most people who build spreadsheets have no experience in software development.

The result is well known. Most spreadsheets are unmaintainable, hard to understand and buggy. Nevertheless, they have not cost anyone their job, but have created opportunities. If more and more non-specialists start developing software in the future, the developer’s job will remain secure because this code needs to be understood and repaired.

Programming is more than just stringing together syntax. It is the pursuit of precision and the answer to the question of what is actually to be achieved. An imprecise specification in natural language often turns out worse than the same imprecision in the code.

This is exactly where the value lies. Software development has always bridged the gap between the soft, flexible space of human needs and precise, fixed notation. The same input must deliver the same result every time, empirically verifiable through tests and runtime data.

Generative AI turns many developers into maintenance programmers

The sober forecast is that most developers will produce legacy code with AI, only faster than before. This is not speculation about the technology, but an observation about how people use tools.

The irony is in the detail. Those who rely entirely on generative tools, whether Copilot or ChatGPT, end up working with code that someone else has written and whose rationale they don’t know. This means that the fun part of the work disappears. What remains is maintenance.

Initial data supports this. A study published by GitClear in January 2024 on GitHub already shows pressure on code quality. Code fluctuation is increasing, there is more duplicated and more copy-and-pasted code. More often than before, code that has just been created is being rewritten because it was wrong.

Producing the wrong thing faster is not the goal. More commits do not mean more productivity. The obvious lesson would be to focus on quality, but many organizations will not learn this lesson.

The profession is not disappearing, it is splitting

Software development will still exist in 2034, because the world runs on software and demand is not decreasing. However, the profession will split and the difference between the two groups will be great.

On the one hand, there will be developers who work in quality and understand what a tool actually does for them. This classification has always been the real challenge. On the other side are people who become puppets of their tools, embedded in inadequate management processes.

By 2034, some companies will have realized that quality counts and will act accordingly. They will be fine. Most will not realize it and will wear themselves out on the small stuff, increasing the pressure on individual developers. In such companies, work can become unpleasant.

Continuous deployment intensifies this pressure. What used to be micromanaged on a monthly basis is now a daily routine. Without an environment of real collaboration, it feels like micromanagement and constant deadline pressure.

Agility means shortening the distance between demand and code

The core of agility is the reduction of distance and communication barriers between those who need software and those who build it. This principle does not change, even if the organizational framework is constantly in flux.

A look back makes this tangible. In the past, software was often created as a customized application within the companies that used it. The distance between business users and developers was short because both were located in the same building.

Today, both exist at the same time. Outsourcing creates new organizational boundaries that need to be bridged. Small companies have a natural flexibility, large ones often sell agility, which is just fewer hierarchical levels. Three management levels instead of four do not make an organization an agile team.

What is striking is the shift in direction. Software is now driving the business instead of just being a product of business decisions. The term agile is now used as a matter of course in a general business context where it had no meaning years ago.

Software development talks more about people than other disciplines

Contrary to its own reputation, software development deals intensively with interpersonal relationships, often more so than other industries. Problems with people are discussed more here than in many technical disciplines.

This shapes the way difficulties are dealt with. Instead of personalizing conflicts, they are seen as systemic issues that need to be understood. This attitude puts the discipline in a better position than its reputation would suggest.

How to prepare for the next ten years

Focus on the basics, because they are the slowest to change. Principles, deeper skills and the question of what software should actually do will last longer than any individual tool.

There is a natural cycle between requirements and testing. To understand how to test something, you must first understand what it is supposed to do. Learn to describe both well, in natural language and in code: What does the right thing look like, what does the wrong thing look like?

When it comes to specific tools, an honest assessment of speed helps. Some things move surprisingly quickly, others hardly at all. Ten years ago, many reacted to Kubernetes with bewilderment, while JUnit dates back to the 20th century and is still used today.

Three recommendations provide orientation:

• Think more broadly about languages Don’t define yourself by one language. Anyone working in Java or C# uses other languages such as JavaScript anyway. Give them first-class status too.
• **If you use a top 10 language, look at the next top 10 and the rest of the top 20. That’s often where your next language originated.
• **Observe open source Many new ideas arise in the open source sector. That’s where you’ll find what will later become mainstream.

In the end, it’s all about balance. Stick to the basics, ask about the core principles of good software development, while keeping an eye on what innovations really work and where you can find them. Your ability to be precise, test well and ask the right question has always been relevant. In the future, it will become the visible difference between developers and between companies.