..and where the real value is.

In November 2022, I first encountered ChatGPT.

It felt like a dream coming true. I could finally have an interactive conversation with a machine, and the machine could answer back convincingly enough to make the Turing test seem almost irrelevant.

From day one, I saw the enormous potential for software development.

Four years later, it feels like an eternity has passed. Today, we can orchestrate multiple AI agents, each playing a different role across the software development lifecycle: gathering information, formulating hypotheses, prototyping, implementing, testing, reviewing, and iterating.

And inevitably, we keep hearing the same prediction: this is the end of software engineering.

Well, yes, but not really. It depends on what we mean by software engineering.

If we’re talking about armies of anonymous developers doing repetitive, low-value work, copying and pasting solutions without really understanding the problems they’re solving, then yes, that model is going to have a very hard time surviving. And frankly, that’s probably a good thing.

I’ve also watched non-technical people build surprisingly sophisticated applications using coding agents, Replit, Lovable, and similar tools. They can accomplish things in a way that would have been unthinkable for a non technical person just a few years ago, and sometimes even manage to get their applications into production.

Of course, we’ve also seen the horror stories: deleted production databases, exposed personal information, compromised payment data. Without a solid understanding of software engineering, it’s remarkably easy to build something that works until it doesn’t. As these tools become more capable, I imagine that many of those risks to diminish.

But I believe we’re missing something more fundamental in this conversation.

Software engineering is about much more than writing code. It’s about understanding systems and problems well enough to conceive the right solutions.

That requires understanding constraints, questioning established approaches, recognizing opportunities that others might overlook, making architectural trade-offs, and designing solutions that fit a specific context while minimizing complexity, cost, and resource consumption.

I have an example to give from my own experience.

I’ve spent eight years working in the large-scale events industry, and for most of that time, indoor navigation has been one of those notoriously difficult problems that everyone agrees would be great to solve, but for which every available solution seems to introduce a new set of compromises.

There are several established approaches, each with its own limitations.

Wi-Fi positioning platforms, such as Cisco Spaces, depend on infrastructure that can be expensive and don’t necessarily deliver the precision you need. Wi-Fi RTT offers much better accuracy, but isn’t supported on iOS. Bluetooth Low Energy beacons require physical deployment and ongoing operational effort, and their accuracy can suffer in crowded environments. Geomagnetic fingerprinting requires detailed environmental mapping and can be affected by temporary structures, such as the metal elements exhibitors bring into their booths.

These limitations become particularly relevant in the events industry, where venues can be enormous, exhibitions are temporary, the physical environment changes constantly, and any additional infrastructure introduces cost and operational complexity.

A few years ago, after studying the available technologies, I decided to experiment with Wi-Fi positioning myself.

I built an Android prototype that used the signal strength and channel frequencies of nearby Wi-Fi access points to estimate the phone’s position through trilateration. It worked surprisingly well, delivering accuracy that was almost sufficient for practical indoor navigation (depending on the APs density, which can be a problem of its own)

Unfortunately, the approach wasn’t viable across platforms. Android allowed me to access the necessary Wi-Fi information, while Apple’s restrictions on access to the underlying Wi-Fi hardware made an equivalent implementation on iOS quite impractical (unless you get a special permission from Apple, but ok it would be faster to walk on the moon without a space suit).

So I kept thinking about the problem.

Then, one Sunday afternoon many years ago, while lazily lying on the couch, I had a radically different idea.

What if indoor navigation didn’t require any of those positioning technologies in the first place?

I had spent so much time looking at ways to determine a phone’s position inside a building that I had been approaching the problem through the same assumptions as everyone else.

But something I’d observed over years of working in exhibition environments suggested an entirely different approach.

I started experimenting, and eventually developed a solution that needs only two things: an existing floor plan and an ordinary smartphone.

You feed the floor plan into the software, open the application on your phone, and get accurate, real-time, point-to-point navigation directions, much like Google Maps, but indoors.

And Wi-Fi positioning infrastructure, Bluetooth beacons, magnetic fingerprinting, calibration, external hardware, additional licenses or on-site configuration happily become unnecessary.

A genuinely zero-setup indoor navigation system.

And it works remarkably well.

What makes this story relevant to AI-assisted coding is how I arrived at the solution.

Recently that idea resurfaced, but first I experimented with multiple AI coding agents, including Codex, Claude Code, Antigravity, and Gemini CLI, to see what approaches they would propose for the same problem.

None came remotely close to the idea I had developed.

They were very good at discussing the known positioning technologies, their respective trade-offs, and the possible ways to implement them. But they kept approaching the problem within the boundaries of those established solutions.

My idea emerged from something different: years of direct observation of the physical environment, an understanding of the operational realities of large-scale events, and a connection between details that had initially seemed unrelated.

That context wasn’t sitting in a technical paper or a software library waiting to be retrieved. It came from being there, seeing how things actually work, and eventually realizing that the problem could be approached from a completely different angle.

At the same time, AI-assisted coding has been tremendously useful in turning the idea into working software. It has accelerated experimentation, prototyping, implementation, and testing in ways I could hardly have imagined a few years ago.

And this is where I think the discussion about AI replacing software engineers often goes wrong.

The ability to generate functional code is becoming increasingly accessible, and that’s a remarkable development. But producing code is only one part of engineering, and often not the part where the most valuable intellectual work happens.

The real challenge can be recognizing that a problem has been framed incorrectly, that an assumed constraint isn’t actually a constraint, or that something you’ve observed in the real world opens up an entirely new way of solving it.

In my case, years of looking at indoor positioning technologies had led me to build a working prototype using one of them. Yet the breakthrough came when I realized I could approach the entire problem differently.

I don’t think the growing capabilities of AI diminish the importance of that kind of engineering judgment. If anything, they make it more consequential, because the distance between having a good idea and building a functioning product is shrinking dramatically.

The value of of software engineers has never been the code written. It was the problems they could understand, the assumptions they could challenge, and the solutions they could imagine.

AI hasn’t made that less valuable. It has made everything else cheaper.