Knowing how to code is no longer enough.
That sentence will probably bother some developers.
Programming still matters. Technical depth still matters. The ability to build reliable software still matters.
But if the only value I can offer is writing code, artificial intelligence is not just a tool that helps me.
It is also my competition.
I have worked in software development for more than fifteen years. I have built hospital systems, worked with private companies and digital products, joined startups, and created projects of my own.
For most of that time, becoming a better developer meant going deeper into the technical work.
Learn the language.
Master the framework.
Understand the edge cases.
Write better code, faster.
That path made sense because producing software was expensive. Developer time was scarce, and organizations were designed to protect it.
Now the cost of producing code is falling.
The difficult part is moving somewhere else.
When code becomes easier to produce, choosing what deserves to be built becomes more valuable.
The ticket was never the problem
For years, many developers inside large organizations worked several levels below the actual business problem.
By the time a task reached us, someone else had already spoken to the users. Someone had defined the priority. A product manager had removed the ambiguity. A designer had thought through the interaction.
Then the developer received a ticket:
Change this button.
And we changed it.
There was a good economic reason for organizing the work this way. Developer hours were expensive, so it was cheaper to let other people process the uncertainty and deliver a precise technical task.
But that system also created developers who could be excellent at implementation without understanding much about the business they were building for.
They knew how to change the button.
They did not always know why it needed to change.
That gap is becoming harder to ignore. When teams get smaller and AI absorbs part of the implementation work, fewer people are available to prepare the perfect ticket.
The developer has to help discover what the ticket should say.
That means asking different questions:
- Why does this need to change?
- What behavior are we trying to create?
- How will we know it worked?
- Is the button actually the problem?
Clayton Christensen and his coauthors described this shift through the Jobs to Be Done framework. Customers do not choose a product only because of its features. They effectively “hire” it to make progress in a specific situation.
The same principle applies to software work.
A feature is not valuable because it exists. It is valuable because it helps somebody accomplish something that matters.
The job is not to implement the request. The job is to understand the progress behind it.
The result matters more than the output
Moving beyond the ticket requires a broader view of the problem.
I may not know the industry I am entering. That used to be a serious barrier. Today, AI can help me build an initial map.
I can investigate how the industry creates value, which problems appear repeatedly, what solutions already exist, where those solutions fail, and which risks I should understand before proposing anything.
That does not replace speaking with someone who has spent twenty years in the field.
It does not replace interviewing users.
It does not replace observing the real process.
It helps me arrive at those conversations better prepared.
Instead of starting with a blank page, I can start with questions:
- What is the customer trying to accomplish?
- What do they use today?
- Where does that alternative break down?
- What solution fits their budget and constraints?
- How long would it take to implement?
- How could we prove that it worked?
- Why should they invest in this rather than something else?
Not long ago, each question might have belonged to a different team.
Now one developer may need to consider all of them.
In a 1993 WIRED interview, Peter Drucker discussed knowledge as the critical factor of production. His distinction was simple and still useful: in knowledge work, the first question is not how to do the work. It is what work should be done.
Producing the wrong thing efficiently is not productivity.
It is well-executed waste.
AI makes this distinction more important because it makes implementation easier. I can generate more code, more prototypes, and more variations than before.
But volume is not the same as value.
The priority is no longer the code. The priority is the result the code is supposed to produce.
Specialization needs something around it
Software encouraged many of us to build an identity around a very narrow technical niche.
Not just “I am a developer.”
“I am a React developer.”
“I only work on the backend.”
“I specialize in this framework and this particular set of tools.”
That specialization had real advantages. It allowed people to go deep, build sophisticated systems, and solve difficult technical problems.
It will continue to have value.
But a narrow identity also becomes fragile when a tool can perform more of the task on which that identity depends.
In Range: Why Generalists Triumph in a Specialized World, David Epstein argues that generalists often have an advantage in complex and unpredictable environments. They can connect ideas across domains, adapt when conditions change, and see possibilities that a person confined to one field may miss.
The lesson is not to abandon expertise.
It is to build around it.
If I learned to master a difficult technology, I have already developed the ability to learn, abstract, test, and revise. I can apply that ability elsewhere.
I can learn how a business works.
I can learn to interview customers.
I can learn about costs, sales, and proposals.
I can learn to measure outcomes.
None of that is necessarily harder than becoming a good developer.
It is different.
And that difference can feel like a threat because it asks me to leave an identity in which I became comfortable.
Technical depth remains valuable, but it becomes stronger when it is surrounded by range.
Human skills are part of the technical job
There is another uncomfortable part of this change.
For a long time, developers were difficult to find. Companies paid well for our time and often tolerated behavior they would not accept elsewhere.
Some technically brilliant people never learned to communicate, listen, or make the people around them better.
I saw this more than once.
That kind of developer usually reached a ceiling. Sometimes the business considered their knowledge too critical to challenge them. In other organizations, their growth stopped much earlier.
Today, we can afford that behavior even less.
The World Economic Forum’s Future of Jobs Report 2025 makes the combination clear. Among surveyed employers, 69% identified analytical thinking as a core skill. Resilience, flexibility, leadership, and creative thinking also ranked near the top. Empathy and active listening, along with curiosity and lifelong learning, were each identified by 50%.
Programming appeared much lower, at 17%.
That does not mean programming is disappearing. The report covers the broader workforce, not developers alone.
But it does show what organizations value around technical work.
The ability to analyze is not enough without the ability to adapt.
Technical literacy is not enough without curiosity.
Problem-solving is not enough without listening to the people who live with the problem.
If I want to enter an organization and help improve it, I first need to understand what its people experience.
What costs them money?
What wastes their time?
What frustrates them?
What keeps them from moving forward?
In sales, people often call this finding the customer’s pain. The phrase can sound cold, but the underlying idea is human: understand what another person is going through and help them make progress.
Human skills are not separate from the work. They are what make the technical work useful.
We thought we would work with machines
There is something almost ironic about all of this.
Many of us entered software because we thought we would spend our careers working with machines.
Now we have to become better at working with people.
The job is no longer limited to writing a correct function. It includes understanding an organization, finding a problem that may not be clearly expressed, speaking with people who have competing interests, prioritizing, negotiating, explaining, and building something that creates a real change.
Developers have an advantage here.
We tend to be analytical. We know how to learn. We are used to entering unfamiliar systems, identifying patterns, and testing assumptions.
Not knowing an industry can even create a useful kind of openness. I do not have to begin with, “This is how everyone has always done it.” I can observe the problem, question inherited processes, and combine technical knowledge with a different perspective.
Then I have to validate that perspective with the people who hold real experience.
AI does not give me permission to arrive with all the answers.
It gives me a way to arrive with better questions.
The future belongs to developers who can connect technical possibility to human progress.
The value beyond code
So, does the future of the developer depend on programming better or on becoming more than a programmer?
My answer, for now, is both, but technical ability alone will not be enough.
We will need to become better at solving problems.
Better at understanding businesses.
Better at communicating.
Better at listening.
And, above all, better at working with other people.
For years, many of us believed our value came from knowing the right language, framework, or tool.
When writing code is no longer scarce, that value has to appear somewhere else.
In the questions we ask.
In the problems we choose.
In our ability to understand another person.
In the outcomes we can produce.
The uncomfortable question is not whether AI can do our work.
It is this:
How much of our work was truly valuable before AI arrived?
