Preface
This essay is a reflection on my professional journey as a software engineer. Over the years, I have worked with many technologies, projects, colleagues, and customers. Some experiences were successful, others taught valuable lessons.
I originally wrote these notes as a way to preserve ideas and insights that I may wish to explore further in future writing.
I dedicate this essay to Martini on the occasion of his graduation from NTNU in June 2026. As he begins the next stage of his own journey, I hope that some of these experiences may be useful to him and perhaps to future generations of our family.
Papi
-----------------------------------------------------------------------------------------------------------------
For decades, software engineering was closely associated with writing code. A software engineer was often imagined as someone sitting in front of a computer, typing thousands of lines of instructions in C, C++, Java, Python, or another programming language.
Today, that picture is beginning to change.
Artificial Intelligence can now generate functions, classes, database schemas, API endpoints, documentation, and even unit tests. Some observers have concluded that software engineers may soon become obsolete.
I believe the reality is quite different.
AI is changing software engineering, but it is not eliminating the need for software engineers. Instead, it is shifting the center of gravity of the profession from coding toward architecture, design, testing, validation, and human judgment.
AI Can Write Code, But It Still Needs a Blueprint
In many ways, software development resembles the construction of a house.
Before construction begins, someone must determine why the building is needed. Someone must understand the requirements, create the blueprint, and ensure that the structure will be safe, useful, and adaptable.
The construction workers follow the blueprint.
If the blueprint is flawed, even the most skilled builders will produce a flawed building.
AI is becoming an increasingly capable builder of software. It can generate code faster than most humans and can automate many repetitive programming tasks.
But AI still requires direction.
The software engineer increasingly becomes the architect.
Software Engineering Was Never Just About Coding
Throughout my career, I worked in several different industries.
My master's thesis focused on image processing. My first professional position involved seismic data processing at Schlumberger, where our team participated in developing the Geoframe platform. Later, I worked in Silicon Valley with enterprise middleware technologies and eventually joined Kongsberg Defence & Aerospace, where I worked on airborne surveillance and defense systems.
Although the technologies were different, the underlying challenges were remarkably similar.
The difficult problems were rarely about syntax.
The real challenges involved questions such as:
- What problem are we solving?
- How should the system be structured?
- How should different components communicate?
- How can new functionality be added later?
- How do we integrate legacy systems with new systems?
- How do we ensure reliability and maintainability?
These are architectural questions.
They remain architectural questions in the age of AI.
From Programmer to System Architect
As AI becomes increasingly capable of generating code, the value of architecture becomes more visible.
Architecture determines how a system is organized. It defines boundaries, interfaces, communication patterns, data flows, and responsibilities.
A well-designed architecture allows a system to evolve gracefully as requirements change. A poor architecture creates technical debt that accumulates year after year.
Many experienced software engineers discover that as their careers progress, they spend less time writing code and more time designing systems.
This trend is likely to accelerate in the AI era.
The future software engineer may spend more time defining requirements, designing architectures, reviewing AI-generated code, and validating results than manually writing every line of implementation.
The Lego System Philosophy
One of my proudest engineering achievements involved designing an object-oriented framework that integrated multiple sensors and both new and legacy systems.
The architecture was first modeled using UML before implementation began.
The objective was to create a flexible framework where components could be added, removed, or replaced with minimal impact on the rest of the system.
I often think of this approach as a Lego system.
Each component behaves like a Lego block. It has a well-defined interface and a specific responsibility. The internal implementation can change, but the connection to the rest of the system remains stable.
This approach allows systems written in different programming languages and developed by different teams to work together.
The goal is not merely to solve today's problem.
The goal is to build a system that can adapt to tomorrow's problems as well.
Design Patterns: Reusable Engineering Wisdom
Software architects have long relied on design patterns to solve recurring problems.
Design patterns are similar to architectural patterns in building design. Architects do not reinvent doors, windows, staircases, or roofs every time they design a house. Instead, they reuse proven solutions.
Software engineers do the same.
Patterns such as Adapter, Factory, Observer, Strategy, and Facade represent accumulated engineering knowledge gained through decades of experience.
Programming languages change. Technologies evolve. Frameworks come and go.
Yet many design patterns remain relevant because they solve fundamental organizational problems.
AI may generate code that implements these patterns, but engineers still need to understand when and why each pattern should be used.
Testing Becomes More Important, Not Less
A common misconception is that AI will reduce the need for testing.
In reality, the opposite may occur.
When AI can generate large amounts of code rapidly, the bottleneck shifts from implementation to validation.
The engineer must still determine:
- Does the code satisfy the requirements?
- Does it handle edge cases correctly?
- Is it secure?
- Is it maintainable?
- Does it integrate properly with the rest of the system?
- Does it fail safely under unexpected conditions?
AI-generated code may look convincing, but appearance is not the same as correctness.
Testing, verification, and validation become increasingly valuable skills.
The future engineer may spend less time typing code and more time evaluating whether the generated code is trustworthy.
Prompting Becomes a Core Engineering Skill
One of the most important new skills for software engineers may be AI prompting.
A prompt is not merely a question. In many cases, it resembles a miniature software specification.
A weak prompt might say:
Build a customer management system.
A stronger prompt might say:
Design a customer management module that supports customer profiles, order history, validation, audit logging, and future integration with external payment systems. Explain the architecture before generating code.
The difference is clarity.
Good prompting requires the same discipline that good software engineering has always required:
- Define the objective clearly.
- Provide relevant context.
- Specify constraints.
- Describe the expected output.
- Review and refine the result.
Prompting is becoming a communication skill between the engineer and an intelligent coding assistant.
From Waterfall to Continuous Evolution
Traditional engineering often viewed projects as having a clear beginning and end.
Software is different.
A software system is rarely finished.
Requirements change. Markets change. Regulations change. Technologies change. User expectations change.
Modern software systems evolve continuously.
This reality led to the rise of Agile development methodologies, which recognize that change is not an exception but a normal part of software development.
AI systems themselves evolve in a similar way.
Software engineers increasingly work in environments where both the software and the tools used to build the software are continuously changing.
The ability to learn, adapt, and iterate becomes more important than mastering a particular programming language or framework.
The Human Role Remains Essential
Despite the remarkable progress of AI, software engineering remains fundamentally a human activity.
Someone must understand the business problem.
Someone must communicate with stakeholders.
Someone must evaluate trade-offs.
Someone must make architectural decisions.
Someone must take responsibility for the final result.
AI can assist with implementation.
AI can accelerate development.
AI can generate code.
But AI does not own the responsibility for the system.
The engineer does.
Final Thoughts
The future of software engineering is not a story of humans versus AI.
It is a story of collaboration between human judgment and machine capability.
The engineer who focuses solely on coding may feel threatened by AI.
The engineer who understands architecture, system design, testing, communication, and problem-solving will likely become even more valuable.
AI can build parts of the house faster than ever before.
But someone still needs to design the blueprint, inspect the structure, verify the safety, and decide whether the building truly serves its purpose.
That responsibility remains with the software engineer.
In the age of AI, the software engineer evolves from being primarily a coder into becoming an architect, reviewer, tester, communicator, and trusted decision-maker.
The tools will change.
The technology will advance.
But the ability to transform human intent into reliable systems will remain one of the most valuable skills in the profession.
No comments:
Post a Comment