I think a lot of engineers are quietly wondering the same thing right now.
“If AI can write the code, what exactly am I worth?”
I wonder about it too.
For a long time, being an engineer meant becoming good at the thing computers could not do for us.
You learned the language.
You learned the framework.
You learned how to debug the strange thing that broke only in production at 2 a.m.
And little by little, that technical ability became part of your identity.
I was probably that kind of engineer too.
Which is why this moment can feel a little painful.
Because the part we worked hardest to acquire is also the part AI is getting good at surprisingly fast.
But I think there is an important distinction here.
AI is replacing some of the technology work.
That does not necessarily mean it is replacing the reason we use technology.
Those are different things.
Code Was Never the Final Product
Nobody wakes up in the morning thinking:
I wish somebody would write 800 lines of TypeScript for me today.
Well, maybe some of us do.
But most businesses certainly don't.
They want something else.
They want fewer mistakes.
They want a process that takes three hours to take ten minutes.
They want customers to stop leaving halfway through checkout.
They want their sales team to know which leads matter.
They want someone to understand the messy situation in front of them and somehow make it better.
Code happened to be one of the tools we used to do that.
And now AI is becoming very good at holding that tool.
So maybe the engineer's job is moving one level upward.
Not:
“Can you build this?”
But:
“What should we build, for whom, and why?”
That part still matters a lot.
My Own Job Is Already Changing
My main job is no longer just writing code.
More and more of my work looks like this:
- Working with business teams to figure out what a project actually needs
- Building AI skills and small tools that remove repetitive work
- Thinking about which features would create real value for users and the product
Of course, development is still part of the job.
But it feels less like the whole job.
Maybe coding is becoming a little like typing.
Being able to type quickly used to be a professional advantage.
Today, nobody hires you because you can type.
They hire you because of what you can create with the keyboard.
Software development may be moving in that direction.
If that's true, I think engineers have at least two interesting paths.
Path 1: Become an Engineer Who Knows a Domain Deeply
The first path is to become very good at understanding one particular industry.
Not just its software.
Its actual work.
Its strange rules.
Its vocabulary.
Its customers.
Its habits that make no sense from the outside but exist for very good reasons.
Finance has its own world.
Healthcare has its own world.
Logistics has its own world.
Manufacturing has its own world.
Every industry has invisible knowledge that rarely appears in a requirements document.
An engineer who understands those things can do something much more valuable than simply implement a ticket.
They can say:
“I understand why this problem exists in the first place.”
AI knows a great deal.
But it usually does not spend three years sitting next to the people doing the work.
It does not remember the strange exception that happens every March.
It does not notice that the official workflow and the real workflow are completely different.
That kind of context is valuable.
So one path is:
Don't just become a better engineer. Become the engineer who deeply understands this particular world.
Path 2: Become the Person Who Solves Whatever Is in Front of Them
The second path goes in almost the opposite direction.
Instead of becoming narrow and deep, become unusually broad.
Imagine working with a small business.
They may not need a “backend engineer.”
They may not need a “data engineer.”
They may not even know what those words mean.
They just know:
“Our inventory spreadsheet is a mess.”
“Customers keep asking the same questions.”
“We enter this data manually every morning.”
“Our website is old.”
“We want to use AI, but we have no idea where to start.”
In the past, one person probably couldn't handle all of that.
Today, with AI, the range of things one person can reasonably do has expanded dramatically.
You can write code.
You can automate spreadsheets.
You can build internal tools.
You can connect APIs.
You can create simple AI workflows.
You can improve a website.
You can help organize data.
You can prototype something in a weekend that once needed a small team.
This makes a new kind of engineer possible:
the person a company calls when something involving technology is annoying, expensive, slow, or confusing.
That role is especially interesting for small and medium-sized businesses.
In many regional companies, the problem is not that there are too many engineers.
The problem is that there is nobody to ask.
That feels like an opportunity.
Maybe the Best Answer Is to Do Both
Personally, I think an attractive combination is:
Work full-time inside a product company, while taking small client projects on the side.
The product job gives you depth.
You learn one business.
One industry.
One product.
One set of users.
You see what happens to software after it is released.
Client work gives you width.
You meet completely different businesses.
You discover completely different problems.
You learn how to talk to people who do not speak in engineering vocabulary.
And, importantly, you discover something engineers sometimes forget:
A problem does not need to be technically difficult to be valuable.
A five-line automation that saves someone two hours every Friday may be worth much more than an elegant system nobody needed.
That is a useful lesson.
For People Moving Into Engineering Now
There is one more group I think may actually have an advantage in this transition.
People coming from business roles.
Sales.
Operations.
Marketing.
Finance.
Consulting.
Customer success.
People sometimes think their previous career is something they have to leave behind when they become engineers.
I think the opposite may increasingly be true.
That previous experience could become the thing that makes them unusually valuable.
Because if AI keeps lowering the cost of implementation, then understanding what should be implemented becomes more important.
Someone who understands business and can also build things is a very interesting person.
Not half an engineer and half a business person.
Something new.
A person who can move from:
“Here is the problem.”
to:
“Here is what we should do.”
to:
“Here is the thing I built.”
That distance is getting shorter.
So, What Is an Engineer Worth Now?
Maybe this question:
“How valuable are my technical skills?”
is becoming slightly less useful.
A better question might be:
“What can I make possible because I understand technology?”
AI will almost certainly keep getting better at coding.
Faster than most of us would prefer.
So competing with AI on the amount of code we can produce seems like a difficult game.
But understanding people?
Understanding a business?
Finding the actual problem hidden behind someone's request?
Choosing what is worth building?
Taking responsibility for the result?
Those things still feel very human.
Maybe the future engineer is not the person who knows the most technology.
Maybe it is the person who can stand between technology and somebody's real problem and say:
“Ah, I think I know what we can do here.”
And then make it happen.
Top comments (0)