The Netherlands is a country that technically should not exist in its current form. Large portions of the land sit below sea level, and for centuries the Dutch had to collectively engineer systems capable of keeping water under control like dikes, canals, pumps, and barriers. None of these infrastructures were optional, they were necessary conditions for the country itself to exist.
From this continuous negotiation with constraints emerged what became known as the polder model, a cultural approach based on coordination, systems thinking, compromise, long-term planning, and collective problem solving. The Dutch understood very early that complex systems cannot survive just through isolated optimization, but also through coherence.
A polder in the south of the Netherlands. (Photo: Dutch Ministry of Infrastructure and Water Management)
I’ve been thinking about this idea as I approach the end of my university journey and consider the kind of person I want to become. Software engineering today feels like it’s entering a very similar phase. We are no longer operating in a world where the hardest part is simply producing technology. The tools are improving too quickly for that. Instead, the difficult part is understanding how to shape complexity into coherent systems that actually work for humans.
This is when I recognized something uncomfortable about myself.
Labels and Identity
After years of school and university, I began looking for a full-time job. With six years in the Apple ecosystem (iOS development), I naturally searched for iOS developer positions.
Finding something today is already difficult because the tech market is in a terrible state, particularly for new grads. But while reading job openings, I recognized something else: I didn’t want to spend my days just being any coder sitting in front of a computer receiving requirements, translating them into code, testing them, shipping them, and then repeating the cycle.
Looking at my side projects and how I felt reading those openings, I understood that what excites me isn’t just writing code. The product and the users matter more to me than the implementation itself.
Coding is still fun. I still enjoy scaffolding apps, designing systems, and building things from scratch. I get excited hearing about new frameworks, APIs and developer tools announced every year at WWDC. But what really keeps me engaged is the moment where something starts taking shape as a product. The moment where an idea becomes tangible and something just clicks. The moment where you stop thinking only about the architecture and start thinking about the people who will actually use what you are building.
I began struggling with labels. Not because they matter much (I’ve always disliked them) but sometimes you need them. The label “iOS developer” started to feel too narrow for the way I think about technology and products.
When Anyone Can Build
Over the past year, everyone started repeating the same sentence: software is becoming a commodity. At this point it almost sounds like a cliché. Still, there is truth behind it. Look at the tools we have today: Claude Code, Codex, local agents, MCPs, agent skills, autonomous workflows. If you actually understand what you are doing and you know how to work with these tools instead of blindly depending on them, the amount of leverage you gain is absurd.
I genuinely think people around my age are in a very unusual position historically. We entered technology at the exact moment where learning fundamentals still mattered deeply, before abstraction became dominant. We had to learn how things worked underneath the surface. We had to struggle with implementation details, architectures, debugging, documentation, constraints, even finding the right answer on Stack Overflow. And then, right after building those foundations, these tools arrived.
So now we exist in this strange middle ground. We still understand what happens behind the abstraction layers, but at the same time we can use these systems to compress enormous amounts of execution. That changes the economics of building software completely. Implementation is accelerating very quickly, execution is becoming cheaper, and the ability to produce software is no longer the rare thing.
The bottleneck is shifting somewhere else.
What Is Still Difficult
Identifying Meaningful Problems
I’m a heavy reader and a huge Stephen King fan. One of his most famous quotes is “A writer’s notebook is the best way to immortalize bad ideas.” Since I spend most of my time somewhere between development, reading and writing, I started wondering if the same concept also applies to software. Do product ideas work as story ideas?
Inside my Obsidian vault I have a list of app ideas collected over time, my writer notebook. When I migrated from Notion and reorganized everything, I revisited many of those ideas. Some felt much better on the surface than they actually were. Some sounded clever. Some looked aesthetically interesting. Some even had technically fascinating implementations. But once I explored them deeper, nobody actually needed them.
The hardest part today is not building something, but understanding whether something deserves to exist at all. There is a huge difference between a problem that feels intellectually interesting to solve, and a problem that people genuinely feel. That distinction matters more than ever.
Understanding Humans
In the last few weeks I started exploring what seemed like a great idea.
Because of where I am in life (upcoming changes, uncertainty, transition), I wanted to meet people more aligned with my mindset. I genuinely believe most social discovery and dating apps today fundamentally fail at creating meaningful connections. So I conceptualized a social discovery layer where people could meet others depending on life phases, interests, cities, or environments.
I spent time refining the solution. The flows. The interactions. The mechanics. I got excited even thinking about monetization strategy. Then I stopped and asked myself: do people actually experience this problem the way I do?
I was falling into one of the classic traps of solo developers and startup founders: becoming emotionally attached to the solution before validating the problem. So I paused the project and started researching. I tried understanding how this problem manifests itself for other people, especially students abroad, expats, or people moving frequently between cities and environments. And what I discovered was interesting: the problem existed, but not in the form I originally imagined.
That’s when it became clear: in a world where we can build almost anything quickly, understanding humans becomes exponentially more important. AI can help us build increasingly sophisticated systems, but sophistication alone is not value. Products succeed when they align with human behavior: what people desire, what frustrates them, what creates trust, and what makes an experience feel intuitive rather than exhausting.
Creating Coherent Experiences
One thing I strongly believe is that people immediately recognize coherence, even when they cannot explain why.
Look at products like the Apple ecosystem, or apps like Flighty, Craft, or Opal, or even Anthropic Claude’s suite. Even if you are not an engineer or a designer, you instantly feel when an experience is coherent. The interface, animations, navigation, sounds, typography, interactions, tone; none of these elements exist in isolation. They reinforce each other and move in the same direction.
That coherence is difficult to manufacture artificially because it requires taste, intentionality, and consistency across hundreds of small decisions. And those decisions rarely emerge from implementation alone. Even seemingly minor things like naming a product or choosing a specific color palette often require a level of intuition and understanding that AI still struggles to replicate.
Prioritizing
I learned the importance of prioritization during my master thesis project. My thesis involved a complex Web3 wallet system with multiple interconnected layers: the iOS app, a backend infrastructure, multiple smart contracts, and several other moving parts.
Initially, I wanted to attack everything at once. But meaningful systems are almost always assembled incrementally. You first identify what needs validation. Then you understand what unlocks the next layer. Then you decide what matters now and what can wait.
Prioritization is ultimately about sequencing uncertainty.
Building Emotional Resonance
A product can technically work perfectly and still feel empty. The products people truly remember are rarely just functional, they create emotional responses: calm, focus, understanding, safety.
I’ve always loved Apple’s philosophy around products. Beyond engineering quality, there was obsession with emotional experience. The feeling of interacting with something intentional. That resonance is not accidental. It emerges from hundreds of small product decisions interacting together.
Deciding What Should Exist
When building something, the question is no longer “Can I build this?” but “Should this exist?”
That is the core paradox of our time: the more software becomes easy to produce, the more difficult it becomes to build the right thing. In the next few years, the most valuable engineers will probably not be the ones capable of building everything manually, but instead the ones capable of understanding what is actually worth building, and actually building it with the help of AI.
Tools Decay
Most developers still organize their identity around specific technologies and stacks. I’ve done the same for years. I called myself an iOS developer because my skills were built around Apple platforms, Swift, SwiftUI, UIKit, Xcode, and the philosophy of that ecosystem. Someone else may identify as a frontend engineer because they love realizing stunning user interfaces and their experience revolves around React or Angular. Someone else works primarily on backend systems and infrastructure. Now we are even seeing entirely new labels emerging around AI engineering.
But tools decay extremely quickly, especially now.
AI is accelerating technological production at a pace we have never seen before. Frameworks evolve faster, abstractions multiply faster, learning barriers collapse faster. At the same time, these same tools are making implementation knowledge increasingly accessible. Learning how to build an app today is dramatically easier than it was ten or even five years ago. AI can already bridge many stack-specific gaps almost instantly.
The half-life of technical specialization is shrinking. Meanwhile, product thinking compounds over decades because human psychology changes slowly. Taste changes slowly. Judgment changes slowly. Understanding incentives, behaviors, ambiguity, and clarity remains difficult.
I’m not saying product engineering replaces engineering. The word “engineer” is still part of it and matters deeply. Technical depth still matters. What is changing is the layer at which value concentrates. Engineering is slowly moving upward, away from pure implementation details and closer to systems thinking, product judgment, and decision-making.
The Death of “Code as Identity”
Coming from the Apple ecosystem shaped the way I think about software. Historically, iOS development has always been one of the most craftsmanship-oriented areas of software engineering. Apple culture emphasized elegance, intentionality, UX sensitivity, coherence, and emotional design.
Because of that, transitioning toward product thinking felt natural. When I questioned my identity as “just” an iOS developer, uncomfortable questions followed.
- If AI can increasingly generate large portions of code, what remains uniquely mine?
- What is my value beyond implementation?
- What happens to the identity of the engineer when code itself becomes partially commoditized?
And when you strip away the implementation layer from software work, what remains are things like vision, synthesis, direction, systems thinking, and product intuition. I’m not using them as buzzwords, really, it’s an irreducible layer of value.
I’m not arguing that product engineers are simply generalists who know a little bit about everything. And I’m definitely not arguing that engineering fundamentals no longer matter. What I’m describing is not the disappearance of engineering depth, but a shift in where engineering value concentrates. These are two different ways of thinking.
Traditional software engineering emerged in a world where implementation itself was scarce. Writing robust systems, understanding infrastructure, managing complexity, and shipping reliable software required highly specialized knowledge. In that environment, technical execution naturally became the center of gravity.
But as implementation becomes increasingly accelerated and partially commoditized by AI systems, the scarcity begins shifting elsewhere. The differentiator is no longer just the ability to build systems correctly, but the ability to decide which systems deserve to exist, which tradeoffs matter, and which problems are meaningful. Product engineers still care deeply about engineering quality, they just approach engineering as one part of a much larger product process. That’s the shift.
And honestly, I increasingly feel that product engineers are already the people building many of the most innovative products we use today and changing the defining paradigms of interaction with technology, and that this tendency will only become stronger over the next few years.
Traditional engineering rewards certainty, while product work rewards ambiguity tolerance. AI is amplifying the distance between these two modes of thinking. As implementation becomes easier, the hardest problems become deciding, filtering, prioritizing, and simplifying.
So, perhaps, the future doesn’t just belong to people comfortable operating inside ambiguity. It belongs to the engineers who know how to build polders in a rising sea of code.