The Art of Being an Engineer in the AI Era

Why problem-solving, technical judgment and adaptability matter more than knowing a particular framework.

There is a quote attributed to Abraham Maslow that I keep coming back to:

"If the only tool you have is a hammer, you tend to see every problem as a nail."

I think this describes a lot of what happens in software development.

We often become so familiar with particular technologies that we unconsciously start looking at every problem through the lens of the tools we know.

A developer who has spent years working with AWS might naturally recommend AWS for almost every infrastructure problem. Someone who has built everything with React might instinctively reach for React whenever a new interface needs to be built.

But is that necessarily the best solution?

I don't think so.

We are engineers before we are framework users

React was created by engineers. Laravel was created by engineers. AWS was built by engineers.

None of these technologies existed before someone identified a problem, explored possible solutions and decided to build something that would make solving that problem easier.

At some point, we started learning how to use these tools. That's perfectly fine. But somewhere along the way, some of us started defining our entire professional identities around them.

We became React developers, Laravel developers, WordPress developers, and so on.

There is nothing wrong with specialization. Deep knowledge of a particular technology is valuable. However, knowing how to use a framework and understanding the engineering principles behind it are two different things.

Frameworks will evolve. New programming languages will emerge. Today's popular technologies might become tomorrow's legacy systems.

The underlying engineering principles will continue to matter.

Your knowledge determines the solutions you can imagine

Here is an example.

How many developers automatically think about AWS when they need object storage, serverless computing or a database?

Probably quite a lot.

But did you know that Cloudflare offers an entire developer platform that can cover many of these needs?

• Cloudflare Workers: Serverless compute for running application logic.
• Cloudflare R2: S3-compatible object storage.
• Cloudflare D1: A serverless SQL database built on SQLite.
• Workers KV: Globally distributed key-value storage.
• Durable Objects: Stateful compute and coordination.
• Cloudflare Queues: Background job processing and messaging.

These are not theoretical alternatives. They are actual services developers can use to build applications.

Now, this doesn't mean Cloudflare is always better than AWS. They have different architectures, limitations and use cases.

The interesting part is something else.

A developer who has never explored these services might never consider them when designing an application. Not because they are unsuitable, but simply because they don't know they exist.

You cannot consider a solution you don't know exists.

This is why I believe continuous exploration is an essential part of engineering. Don't just learn how to use your current tools. Explore what else is available, understand the trade-offs and expand the number of solutions you can consider.

The ability to choose is an engineering skill

Writing code is one part of software engineering.

Before writing that code, someone needs to understand the requirements, evaluate the available technologies, consider performance, estimate costs, think about scalability and make architectural decisions.

Sometimes the best solution is a sophisticated cloud architecture.

Sometimes it is a small VPS running a simple application.

Sometimes you don't need a database. Sometimes you don't need a framework. Sometimes the problem can be solved with a few lines of code.

This is where profiling, experimentation and technical judgment become important.

Instead of assuming that something is slow, profile it. Instead of assuming that a particular technology will solve the problem, evaluate it. Instead of choosing the most popular tool, choose the one that makes the most sense for the requirements.

The goal isn't to use the most sophisticated technology. The goal is to solve the problem efficiently and correctly.

What does AI change?

AI is making it increasingly easy to write code, generate components, create APIs and learn unfamiliar frameworks.

This is a good thing.

But it also raises an important question: if AI can help almost anyone generate code, what makes a good software engineer?

I believe the answer lies increasingly in the things surrounding the code.

Understanding the problem. Asking the right questions. Knowing which technologies are worth considering. Evaluating generated solutions. Identifying security risks. Understanding architectural trade-offs. Profiling performance. Knowing when a proposed solution is unnecessarily complicated.

AI can suggest an implementation, but someone still needs to understand whether that implementation makes sense in the context of the actual problem.

And the more technical knowledge you have, the better equipped you are to evaluate what AI produces.

You cannot effectively challenge a solution you don't understand.

Be a problem solver, not just a tool operator

I personally enjoy being a generalist. I like working across frontend, backend, infrastructure, databases and product development.

Not because I believe everyone should know everything, but because understanding different parts of a system helps me make better decisions.

I can approach a problem without immediately committing to a particular framework or service. I can explore alternatives, learn something new when necessary and decide what makes the most sense.

I also think this should influence how we approach hiring.

Rather than looking exclusively for someone who knows a particular framework, we should pay attention to their ability to understand problems, reason about solutions and adapt to unfamiliar technologies.

A company might need someone experienced with React today. Tomorrow, it might need someone to work with an entirely different ecosystem.

Technical experience matters, but the ability to learn and transfer knowledge matters too.

Specialization and general engineering knowledge aren't mutually exclusive.

Final thoughts

I don't think the AI era makes software engineering less important. I think it makes the distinction between coding and engineering even more important.

Tools will keep changing. Frameworks will come and go. AI will continue improving the way we build software.

But the ability to understand problems, explore possibilities, make informed decisions and take responsibility for the solutions we build will remain valuable.

Don't limit your professional growth to learning how to operate a particular tool.

Learn the principles behind it. Explore alternatives. Understand the trade-offs. Be curious about technologies outside your usual ecosystem.

And most importantly, before reaching for your hammer, make sure the problem is actually a nail.

Be an engineer first. The tools are there to help you.