The Missing Layer: Why Engineers Still Need to Understand What Is Beneath the Code
AI is changing how software is built, but it does not remove the need for engineers who understand systems, trade-offs, and the decisions behind the code. The challenge for engineering leaders is not only adopting new tools, but ensuring that the next generation of engineers develops the depth required to build and evolve complex systems.
Photograph by the author, Széchenyi Chain Bridge, Budapest, Hungary
The conversation around AI and software engineering has become increasingly focused on one question: Will engineers still be needed?
The answer depends on how we define the role of an engineer. If engineering is only about producing code, then AI will continue to automate more and more of that work. But engineering has never been only about writing code. It is about understanding systems, making decisions under uncertainty, managing trade-offs, and creating solutions that remain reliable as complexity grows.
The real risk is not that AI eliminates engineers. The real risk is that organisations stop investing in developing them.
The Layer Beneath the Abstraction
When I studied Computer Science, a significant part of the education focused on understanding the concepts beneath the tools we used.
It was not enough to know how to use a programming language. We learned about how languages evolved, how language interpreters work, how different paradigms influenced software design, and why certain approaches existed. It was not enough to store data. We needed to understand how databases were structured, how queries were optimised, and why certain design decisions affected performance. It was not enough to apply patterns. We needed to understand the problems that created those patterns in the first place.
The goal was never to memorise every detail. The goal was to understand at least one layer below the abstraction we were working with.
Because that layer is where engineering judgment comes from.
Tools change. Languages evolve. Frameworks disappear. But the ability to understand why something works, where it can fail, and what trade-offs exist remains valuable regardless of technology.
Today, AI is becoming another abstraction layer.
Engineers can ask AI to generate solutions, explain concepts, or accelerate implementation. This creates enormous opportunities. But the same principle still applies:
Engineers need to understand what exists beneath the abstraction they are using.
Without that understanding, AI becomes another source of dependency rather than a tool for increasing capability.
The Changing Role of Junior Engineers
This shift creates a difficult situation for people entering the industry.
Junior engineers are often told that AI will make them more productive. At the same time, they hear that entry-level positions are becoming harder to find because companies need fewer people writing code.
Many are left wondering:
"If AI can already do what I am learning, what is my role?"
This is where engineering leaders have an important responsibility.
The purpose of junior development was never to create people who only write code faster. It was to create future engineers who can understand systems, make decisions, and eventually guide others.
Senior engineers do not appear automatically. Every experienced engineer was once someone who needed guidance, feedback, and opportunities to grow. The knowledge that allows someone to make good technical decisions comes from years of exposure to problems, discussions, mistakes, and reflection.
Removing that development path because AI can handle more implementation work would create a long-term problem. Organisations would reduce the very mechanism that creates future technical leadership.
Development Is a System, Not an Expectation
Recently, while creating a 3–6–12 month development plan for a junior engineer who had completed the probation period, I started thinking about a broader question:
What does a good first year of engineering development actually look like?
The answer is not simply learning more technologies. A strong development path gradually increases the level of responsibility an engineer can safely handle.
The first stage is about building foundations. Not just learning syntax or tools, but understanding engineering principles, system behaviour, and why certain approaches are chosen. The goal is not independence yet. The goal is creating enough understanding to make independence possible.
The second stage is about confidence and ownership. The engineer begins moving from:
"How should I implement this?"
towards:
"I investigated different options, considered the trade-offs, and I recommend this approach because..."
This is a significant shift. The engineer is no longer only receiving solutions. They are learning how to create and evaluate them.
The third stage is about contribution. After building enough technical understanding and confidence, engineers can start owning meaningful areas of the system, participating in technical decisions, and supporting others.
This progression is not accidental. It follows a natural evolution:
Understanding → Confidence → Ownership → Contribution
A development plan is therefore not just a checklist of technologies to learn. It is a structured path that gradually expands an engineer's ability to operate independently and make better decisions.
Why Senior Engineers and Technical Leaders Still Matter
AI tools can provide answers quickly.
But engineering teams still need people who can ask the right questions.
They need people who can recognise when an answer is technically correct but operationally dangerous. People who understand business impact, system constraints, and long-term consequences.
This knowledge is rarely written in documentation. It exists in experiences: the production issue that revealed a hidden dependency, the architectural decision that created unexpected consequences, the trade-off between speed and sustainability, or the conversation where different perspectives shaped a better solution.
This is why knowledge transfer remains one of the most important responsibilities in engineering organisations.
Mentorship is not only about teaching technical skills. It is about transferring judgment.
And judgment is something that develops through interaction with experienced engineers, not through isolated consumption of information.
The Role of Engineering Managers
Developing engineers cannot be delegated entirely to individuals.
People need direction, feedback, and a structured environment where growth can happen. This does not mean creating rigid career plans or controlling every step. It means creating clarity.
A good development plan answers questions like:
- What should this engineer understand next?
- What responsibilities can they gradually take ownership of?
- Where do they need support?
- How will we recognise progress?
Without this clarity, junior engineers often optimise for completing tasks instead of building capability. They become faster at execution, but not necessarily better at engineering.
This is where another important concept emerges: Capability Building.
Engineering leadership is not only about improving today's performance. It is about building the capabilities that allow teams and individuals to handle greater complexity tomorrow.
A strong engineering organisation is not defined only by what its current engineers can deliver. It is defined by its ability to continuously develop new capabilities through learning, knowledge sharing, and increasing ownership.
Capability Building turns individual growth into organisational strength.
It transforms development from something that happens to people into something that strengthens the entire engineering system.
This is a key responsibility of engineering leadership.
Building Engineers for the Future
The future of engineering will likely look different from today.
Some tasks will disappear. Some roles will change. New responsibilities will emerge.
But one thing will remain constant:
Complex systems require people who understand them.
The engineers who create the most value will not necessarily be those who write the most code. They will be those who understand problems deeply, communicate effectively, make thoughtful decisions, and use AI as a force multiplier rather than a replacement for understanding.
This is why developing junior engineers remains critical.
Not because every junior engineer needs to become exactly what senior engineers are today.
But because every generation of technology requires people who understand the systems behind it.
Closing Thoughts
AI will change engineering. That change is already happening.
But the answer is not to reduce investment in engineers. It is to rethink what we develop them for. The future belongs to engineers who can combine the speed of AI with the depth of human understanding.
They will need to know not only how to create solutions, but why those solutions work, where they fit into larger systems, and what consequences their decisions create.
Leadership is not only about delivering today's systems. It is about building the people and capabilities that will evolve tomorrow's systems.
This is the foundation of Systemic Lead: creating environments where context flows, confidence grows, knowledge spreads, and teams continuously increase their ability to solve more complex problems.
And that starts by ensuring every engineer has the opportunity to understand the layer beneath the code.