The Role of the Digital Engineer

Change Has Always Been the Job

Dr. Johannes Mainusch, October 2026. Written with the help of AI. All images are real photographs. Best before 13 April 2027.

The questions of our time

Will humans still be writing code two years from now? Is it still worth finishing my computer science degree? Will my job even exist in two years?

These are the questions creating deep uncertainty across our profession right now. Change has accelerated to a point where any confident prediction about the future would be dishonest. But looking back may help us more than looking ahead.

Engineering has always been about change and innovation

The term “software engineering” was born out of crisis. At the NATO conference in Garmisch in 1968, the organizers chose it, as the report puts it, “deliberately … as being provocative.”¹ Back then, calling software development “engineering” was a provocation. Today, many would argue it simply describes what we do.² Projects were late, over budget and unreliable, and the industry needed a discipline that did not yet exist. From the very beginning, software engineering was not a description of a stable craft. It was a response to a technology that kept outgrowing our ability to manage it.

Two decades later, Fred Brooks drew a line that matters more than ever today. In No Silver Bullet (1986) he separated accidental complexity, the friction caused by our tools and languages, from essential complexity, the difficulty of understanding a problem and shaping a solution.³ Every wave of innovation, from compilers to cloud, has attacked the accidental part. AI is the first that also helps with the essential part: it lets us explore problems, challenge requirements and compare alternatives. But judgment and responsibility stay with us. That is where engineers earn their keep.

Learning in uncertain, fast-changing environments

If our field has always been changing, then the core skill was never a particular language or framework. It was learning. Winston Royce had already recommended to “do it twice” in 1970, ironically in the very paper later cited as the origin of the waterfall model.⁴ Brooks echoed this in 1975 with “plan to throw one away”, because the first version teaches you what you actually need to build.⁵ Tom DeMarco, who once taught a generation that you cannot control what you cannot measure, later revisited his own position in 2009. He argued that the most valuable software projects are those where control matters least, and that software development is inherently experimental.⁶

That is the mindset our current moment demands: not certainty, but the ability to learn faster than the environment changes.

Responding to change over following a plan

In 2001, seventeen practitioners wrote the Agile Manifesto and put this principle in plain words: “Responding to change over following a plan.”⁷ It was not a rejection of planning. It was an admission that in product development, the plan is a hypothesis, and reality gets the final vote. And this is not a software peculiarity: even when the goal is clear, every engineering discipline builds prototypes and works incrementally.

Twenty-five years later, this sentence applies not only to our products but to our careers and organizations. Nobody can give you a reliable prediction for 2028. What we can build is the capacity to respond.

Co-working of intelligent humans and machines

The idea of humans and computers working as partners is older than most of our careers. In 1960, J.C.R. Licklider described a “man-computer symbiosis”: machines handling the routine, humans setting goals and judging results, both cooperating on complex decisions without being bound to predetermined programs.⁸ For decades this remained a vision. Today it is our daily work.

The question is therefore not whether humans will still program in two years. The question is what engineering becomes when the machine takes over more of the accidental complexity and becomes a sparring partner for the essential one, while we focus on what remains ours: understanding problems, making judgments, taking responsibility, and learning together, humans and machines alike.

Synthesis: Digital engineering in 2026

So what is the role of an engineer today? Perhaps the first honest answer is that the old labels no longer fit. “IT engineer” describes a department. “Software engineer” was never just about code, and coding has always been only one part of the job. Yet the term is often reduced to exactly that. What remains is the word engineer: someone who solves real problems under real constraints and takes responsibility for the result. That has been true since 1968, and it will outlast every tool we use today. I therefore prefer to speak of digital engineers, to make visible what has always been the core.

Here is how I would describe the role:

The Digital Engineer

Bring the curiosity and the skills to create positive change in a hybrid environment of humans and machines. Communicate well in a digital world. Bring human empathy as well as what I would call cybernetic empathy: an understanding of how machines “think”, where they excel and where they fail. It goes beyond what Martin Thompson called mechanical sympathy, knowing the hardware your software runs on, because today’s machines learn and reason.⁹ Use both to understand and formulate human and digital problem statements, and to turn complex situations into elegant and fruitful solutions.

Ideally, you combine many of the following:

• Empathy and communication: You work well in diverse teams of humans, and you can explain, listen and negotiate across disciplines.
• Automation as a reflex: You are curious to hand over whatever can be automated to your digital colleagues and agents, and you know how to instruct, review and verify their work.
• Depth in at least two technologies: Breadth helps you navigate, but depth teaches you how things really work and lets you judge what the machines produce.
• A quality mindset: You always aim for the highest possible quality of the product at hand. Remember that quality means fulfilling requirements.¹⁰¹¹ The right outcome therefore depends on context: when fighting a fire or saving a life, speed matters far more than elegance.
• A scientific approach: You admit what you don’t know instead of pretending. You criticize low quality while staying open to criticism of your own work. Above all, you take joy in learning.
• Diversity as strength: You value differences in background, thinking and skills as team capability and as a chance to learn. This includes the differences between human and machine intelligence.
• Systems thinking: You see your work as part of a larger whole of products, organizations, customers and society, and you understand how a change in one place ripples through the others.
• Outcome over output: You care whether a solution creates value for real people, not how many lines, tickets or prompts it took.
• Responsibility: Machines can generate, but only humans can be accountable. You own the consequences of what you and your agents build, including their ethical and social impact.

Where does experience come from?

My colleague Philipp Homann read this list and pointed out two things. First, only a few of these skills are specific to software engineering in the traditional sense. Second, he would not have qualified for this role when he started his career, because most of it rests on experience. If we wrote this list into a job description today, there would be no juniors.

The first observation confirms the argument: the specific part shrinks as machines take over the craft, and what remains is the essential part. The second one exposes the real open question. Engineers have always built their experience on routine work: writing the hundredth form, fixing the next bug, struggling through a code base they did not understand. Exactly this work is now moving to the machines. The lower rungs of the learning ladder are disappearing, and we expect people to reach the top anyway.

There is no ready answer yet, but there are directions:

• Separate attitude from experience: Curiosity, a scientific approach and the joy of learning do not require years in the job. A junior can bring them on day one. Systems thinking, quality judgment and responsibility grow over time. Hiring should look for the first and invest in the second.
• Practice deliberately, without the machine: We still learn mental arithmetic before we use a calculator. Whoever is supposed to judge code must have written some. Building things by hand becomes a training method rather than a production method.
• Learn through review: In the future, much of the learning will come from reading, questioning and verifying what machines produce. This needs senior engineers who teach how to review, not only how to build.
• Give ownership earlier: Instead of years of small tickets, juniors can own a small product or feature end to end, supported by agents and guided by experienced colleagues.
• Rethink education: Universities, apprenticeships and companies need new curricula and entry programs. This is not a task for later. The engineers of 2030 are starting their studies now.

Eberhard Wolff challenged this view: which of these skills cannot be taught and learned systematically? He has a point. Not all of this needs years of experience. Juniors often bring what seniors lack: openness to new tools and fewer habits to unlearn. Seniors bring judgment built on experience. This is diversity as strength in its most practical form: the best teams will make learning flow in both directions.

Experience will not disappear as the foundation of good engineering. But it will no longer happen by itself. We have to create it on purpose.

Conclusion

Will humans still program in two years? Probably less than today, and differently. Will engineers still be needed? More than ever, because the essential complexity Brooks described in 1986 has not gone away. It has simply become the main part of the job.

---

Thanks to Philipp Homann and Eberhard Wolff for their thoughtful feedback.

References

Footnotes

1. Naur, P. & Randell, B. (eds.): Software Engineering: Report on a Conference Sponsored by the NATO Science Committee, Garmisch, 1968 ↩

2. Wolff, E. & Wayne, H.: Are We Engineers?, software-architektur.tv, 2024, https://software-architektur.tv/2024/03/27/are-we-engineers-with-hillel-wayne.html ↩

3. Brooks, F. P.: No Silver Bullet: Essence and Accidents of Software Engineering, IEEE Computer, 1987 (first presented at IFIP, 1986) ↩

4. Royce, W. W.: Managing the Development of Large Software Systems, Proceedings of IEEE WESCON, 1970 ↩

5. Brooks, F. P.: The Mythical Man-Month, Addison-Wesley, 1975 ↩

6. DeMarco, T.: Software Engineering: An Idea Whose Time Has Come and Gone?, IEEE Software, 2009 ↩

7. Beck, K. et al.: Manifesto for Agile Software Development, 2001 ↩

8. Licklider, J. C. R.: Man-Computer Symbiosis, IRE Transactions on Human Factors in Electronics, 1960 ↩

9. Fowler, M.: Mechanical Sympathy, martinfowler.com, https://martinfowler.com/bliki/MechanicalSympathy.html ↩

10. Crosby, P. B.: Quality Is Free, McGraw-Hill, 1979 ↩

11. ISO 9000:2015: Quality management systems – Fundamentals and vocabulary ↩