Don't be stupid. Be an engineer

Every so often, someone pops up to announce that "learning to code is pointless now" because AI can do it for you. Right. Also, let's stop learning how to cook because Uber Eats and DoorDash exist.

It might sound odd coming from someone who works at a company that sells AI adoption as an accelerator, but the problem with statements like that is they ignore a fundamental difference between software development and software engineering. And if, in your mind, they are the same, congrats-- you've just identified your first problem.

Software development vs. software engineering

Software development is writing code to make something work. It's the "first draft" of a feature or product that you might throw out or tweak later. It's tactical. It's the "works on my machine" stage.

Meanwhile, software engineering is designing systems that keep working—under load, under change, and under the inevitable chaos of real-world users (who, as we know, can find bugs the best QAs on Earth wouldn't). It's about architecture, scalability, maintainability, and making trade-offs that won't come back to haunt you six months later.

Why we need more engineers (and fewer keyboard heroes)

The industry is overflowing with people who can "get something working" but can't explain why it works (looking at you, copy-pasters from Stack Overflow who shout "it works!" without the faintest idea what's happening under the hood). We don't need more of those.

We need critical thinkers, long-term designers, and people who understand the trade-offs of their decisions. For all of the above, "it compiles" should never be the end goal-- it's just a means.

And here's the reality check: AI is not replacing engineers any time soon. What it is replacing—or at the very least, automating—is the repetitive, boilerplate-heavy part of development. The part I look at in Cursor and think, "Shoot, I don't want to do this now."

If you're an engineer, AI coding tools are like, as a good friend of mine puts it, "a really smart junior developer" on your team. One who works at the speed of light, never sleeps (looking at you, fancy Cursor with background agents), and doesn't complain about Jira tickets. But here's the catch-- let's see if you can guess it:

They're still juniors.

Being a junior isn't bad, but it's not the end goal. The end goal is to be good at what you do and provide value. And to be good, you need to architect and engineer things before typing cursor . in your terminal.

AI can misunderstand requirements. It may not have the full context. It won't know about the obscure rule a lead mentioned five years ago with the words, "Well, it's a long story, but..." AI can produce brilliant work, but it also makes mistakes-- sometimes generating something that looks fine until it explodes in production and you get that heartwarming phone call at 3 a.m.

If you're just a developer who ships whatever autocomplete suggests without understanding it... well, AI will eat your lunch, your dinner, your scones, and your job.

AI as a driver for change (and a mediocrity filter)

AI is a filter. But not the kind you waste time with on Instagram. It's the kind that draws a line between "good" and "bad", between people who comprehend and design systems, and people who just type things into a text editor.

In large organisations, and especially during the startup-to-enterprise transition (which is most of my experience), AI adoption will:

1. Speed up delivery if you know how to use it.
2. Improve quality if you know how to apply the right constraints.
3. Reduce costs if you know how to automate the tasks that weigh you down.

It can be your best mate-- but only if you know how to use it, and the people around you know not just how to leverage it, but especially what they can't do with it.

An engineer will use AI to generate scaffolding, refine for performance, security, and maintainability. An engineer will explore multiple architectural approaches before typing git commit. An engineer will automate tedious refactoring.

A developer, on the other hand, will ask AI, "write code for X, Y, Z," and ship it without reading it. A developer will introduce three security vulnerabilities and a memory leak in a snap. A developer will wonder why the system falls over in production, or how odd data got in—because they committed secrets without realising it, thanks to their AI copilot's suggestion.

Everything that matures requires--

A mindset shift (stop being a keyboard hero)

The best leaders I've had the pleasure to meet or work with have something in common: they stress the importance of not having heroes. They understand that a team of heroes means constantly putting out fires. Heroes put out fires, and if they're always putting out fires, they're not designing, preparing, or architecting.

It's not about the code. It's about the thought process that leads to the code.

Surviving in the AI era requires shifting from "someone who writes code" to "someone who solves problems by engineering solutions." And guess what-- coding is just part of the process.

By engineering solutions first, I mean:

• Understanding trade-offs and problems.
• Mapping out potential solutions, risks, and benefits.
• Knowing when to think about performance.
• Thinking about security, scalability, and maintainability.
• Using AI as a tool, not a crutch. If you weren't a good engineer before AI, it won't magically turn you into a rockstar.

AI won't fix your broken architecture.

AI won't fix your broken process.

AI won't save you from yourself.

---

In a world where AI can write code, the value engineers bring is not typing, but thinking (and manifesting it.) We can foresee problems. We can make decisions AI can't make for you. We can build systems that work not just today, but for years to come.

And no, I don't own the truth. This is my take, shaped by years of building, breaking, fixing, and building again.

You can call me names, you can disagree-- but if you do, show me your reasons.

That's what engineers do.