I've watched good engineers lose their jobs.
Not all because of AI. Some because of budget cuts, restructuring, products that never found a market, or companies changing direction overnight.
But it left me with an uncomfortable question:
If you're excellent at writing code, does that automatically make you valuable to a business?
I don't think it does. At least, not anymore.
And before anyone gets defensive: this isn't another "AI will replace developers" article. Coding isn't dead. Engineering isn't dead. The idea that our value begins and ends with implementation, however, is getting harder to defend.
The future of software engineering isn't about writing less code. It's about understanding what deserves to be built in the first place.
The gap between building something and solving something
Imagine two engineers get the same request:
"Add an export button so the operations team can download a CSV."
Engineer A implements the endpoint, adds the button, writes tests, and closes the ticket.
Good work. The requirement is done.
Engineer B asks why the team needs the export.
After a few conversations, they discover that people download the CSV every morning, clean the data manually, compare it against another system, and send the results to someone else. The export button isn't the real problem. It's just the workaround people have learned to live with.
So Engineer B investigates the workflow and proposes a better solution.
That solution might involve a scheduled integration, data validation, an auditable processing pipeline, retries, and a clear way to handle records that don't match. It may take more engineering—not less.
The difference isn't that Engineer B writes better code.
It's that Engineer B understands what the code is supposed to change.
That's the gap between completing a ticket and solving a problem.
The bottleneck moved. Engineering didn't disappear.
For a long time, implementation was a major constraint. Turning an idea into a working feature took time, specialized knowledge, and a lot of repetitive effort.
Tools now make some parts of implementation faster. That includes code generation, scaffolding, tests, prototypes, and routine integrations.
But faster implementation doesn't magically answer the difficult questions:
- Is this the right problem to solve?
- Does the proposed solution fit the customer's actual workflow?
- What happens when the input data is incomplete or wrong?
- How will the system behave under retries, failures, or unexpected load?
- Can we secure it, observe it, maintain it, and roll it back?
- Did the solution improve anything after it shipped?
A demo can look impressive and still fail in production. A feature can pass every test and still solve the wrong problem.
The work hasn't vanished. The bottleneck is shifting toward judgment, context, integration, reliability, and adoption.
That's still engineering. It's just engineering that starts before the first line of code.
Look at the roles appearing around us
The rise of roles like Forward Deployed Engineer (FDE) is one signal of this change.
An FDE works close to customers: understanding their problems, shaping a technical solution, building it, deploying it, and helping make it useful in the customer's environment.
You can see that customer-to-production responsibility in the FDE role descriptions from OpenAI and Anthropic.
Other titles point in a similar direction:
- Product Engineer: connects product decisions with implementation and user outcomes.
- Applied AI Engineer: turns AI capabilities into reliable systems people can actually use.
- Solutions Engineer: works across technical design, customer needs, and adoption.
These jobs aren't identical, and not every company uses the titles consistently. The common thread is more interesting than the labels:
The engineer is expected to own more of the journey from problem to outcome.
You don't need to become an FDE. But you should pay attention to why this kind of work is valuable.
What we risk losing along the way
There are two bad directions engineers can take.
The first is becoming a ticket-taking machine.
You receive a requirement, implement it, move to the next one, and never learn whether the feature helped anyone. You might become very efficient at producing code while remaining disconnected from the product.
The second is outsourcing your engineering judgment.
You accept generated code you can't explain, skip the debugging because the tool says it fixed the issue, and measure productivity by how quickly something appears to work.
Both paths weaken the same thing: ownership.
Good engineering requires more than producing an implementation. It requires understanding trade-offs, questioning assumptions, anticipating failure, and being accountable for what reaches production.
If you stop practicing those skills, faster tools won't make you a stronger engineer. They'll just make you faster at accepting decisions you don't understand.
How to become more valuable without abandoning engineering
You don't need to reinvent your career or collect ten new job titles. Start by expanding the context in which you work.
1. Learn to investigate before you implement.
When someone gives you a requirement, ask:
- Who has this problem?
- How do they handle it today?
- How often does it happen?
- What does it cost in time, money, or errors?
- What would a successful outcome look like?
You don't need to run a six-week discovery process for every button. You do need to know when the ticket is describing a solution instead of the actual problem.
2. Understand the system beyond your component.
Learn how your work affects data, APIs, infrastructure, security, operations, and other teams.
A feature isn't finished just because the happy path works. Think about idempotency, retries, observability, access control, data consistency, migrations, and failure recovery.
These are not boring details around the "real" work. They are the work.
3. Learn the business language of your product.
You don't need an MBA. Understand the few outcomes your product is supposed to improve: time saved, fewer errors, lower operating costs, higher conversion, better retention, or increased revenue.
Then connect your engineering decisions to those outcomes.
"I added caching" describes an implementation.
"Requests that were slowing down the checkout flow now complete reliably under peak traffic" explains why the work matters.
4. Use AI tools without outsourcing your thinking.
Let tools help you explore options, generate boilerplate, write tests, or investigate unfamiliar code. But review the critical changes. Understand the architecture. Verify edge cases. Test failure paths. Be able to explain what you're shipping.
The responsibility doesn't move to the tool when the code is generated.
Stop building portfolio projects nobody asked for
Developers love building things. That's a strength—but it can also become a comfortable way to avoid talking to actual users.
Before starting your next side project, try this:
- Find a frustrating task someone repeatedly deals with.
- Talk to three to five people who experience it.
- Write down how they solve it today and what the problem costs them.
- Build the smallest solution that could improve that workflow.
- Put it in front of users and measure what changes.
Don't begin with "I'm going to build an app with Next.js, Supabase, and whatever tool is trending this week."
Begin with "People are wasting time doing this. Can I make it meaningfully better?"
And don't treat GitHub stars as proof that you've built something valuable. A real user who depends on your tool can teach you more than a hundred imaginary users in your README.
You don't have to turn every side project into a business. But you should practice taking something from an observed problem to a solution someone chooses to use.
Please, don't stop being an engineer
This isn't an argument for replacing technical depth with meetings, pitching, or endless product discussions.
We still need engineers who understand databases, distributed systems, networking, security, performance, testing, architecture, and infrastructure.
In fact, those skills become even more important when teams can produce implementations faster. Someone still has to know whether the implementation is correct, safe, reliable, and maintainable.
The goal isn't to write the least code, attend the most customer calls, or become a salesperson with a terminal.
It's to combine engineering depth with enough product context to make better decisions.
Some engineers will specialize deeply. Others will move closer to customers or product strategy. Both paths can be valuable.
But whichever path you choose, don't confuse being busy with being useful—and don't confuse shipping code with solving the problem.
The question I'd ask every engineer
If your job title disappeared tomorrow, could you clearly explain:
- Which painful problem does your work solve?
- Who benefits from the solution?
- How do you know it actually helped?
- What makes your solution reliable enough to trust?
If you can answer those questions and still have the technical depth to deliver, you're building a much stronger career than one based on a framework, a title, or the number of tickets you close.
The future of software engineering isn't about writing less code. It's about understanding what deserves to be built in the first place.
And I'm curious where you stand:
Should companies expect software engineers to understand customers and business outcomes, or should that responsibility stay with product managers and leadership?
I'd especially like to hear from senior engineers, architects, product people, and developers who have worked directly with customers. Where should the line be?
