The Best Developer Is No Longer the One Who Writes the Best Code

For most of my career, I had a simple way of thinking about what makes a good developer.
Look at the code.
Is it clean? Are the names clear? Is the architecture reasonable? Does it work? Does the developer think about things that might go wrong?
I still think these things matter.
But lately, I have started to wonder if they are enough.
AI has changed quite a lot about software development. Today, you can ask an AI assistant to build a function, write a SQL query, create an API endpoint or even generate a complete small application. In many cases, the result is surprisingly good.
Sometimes it is even better than what I would have written myself when I am tired and trying to finish something before the end of the day.
So the question I keep coming back to is:
If AI can write good code, what becomes more important for a developer?
After working for many years across IT, research, data science and machine learning, I think the answer is not another programming language or another framework.
It is understanding.
Understanding the problem.
Understanding the data.
Understanding the system.
And, perhaps most importantly, understanding whether the solution produced by AI is actually correct.
Code is becoming easier. Judging code is not.
One of the things that has surprised me about using AI for programming is how quickly it can produce something that looks right.
The code usually looks reasonable.
The variable names are fine. The functions are structured properly. There are comments. Sometimes there are tests too.
But "looks right" and "is right" are not the same thing.
A small mistake in a date calculation might only appear once or twice a year. A database join might duplicate some records without immediately causing an error. A timezone conversion might work most of the year and fail when daylight saving time changes.
These are not necessarily problems that AI will notice by itself.
The same thing happens in data science.
For example, one of the most dangerous problems in machine learning is data leakage. You can accidentally give a model information that would not actually be available when making a real prediction.
The result can look excellent.

Your model has a very good MAE. Your graphs look good. Your code is clean.
But the model is cheating.
This is something I have become more conscious of through my own work with forecasting. A model is not useful simply because it produces a good number in a notebook. You have to ask whether that number could realistically have been produced at the time the prediction was made.
This is where I think experienced developers and data scientists still have a very important role.
The value is not only in producing the code.
It is in knowing when to question it.
Maybe the most important skill is asking the right question
There is another change that I find interesting.
When writing code was more time-consuming, a vague requirement naturally created some resistance. You had to stop and ask questions because implementing something took time.
Now you can give a vague instruction to an AI assistant and get an implementation almost immediately.
That sounds like progress.
And it is.
But it can also create a new problem.
We can now solve the wrong problem much faster.
Before asking AI to build something, I think we need to spend more time understanding what we actually want.
What is the problem?
What data do we have?
What can go wrong with the data?
What does a successful result look like?
What are the limitations?
What should the system never do?
These are simple questions, but they are becoming more important.
For me, this is one of the biggest changes in software development.
The developer is moving a little bit away from being only the person who writes the implementation and more towards being the person who defines and controls the problem.
You could almost think of AI as a very fast junior developer.
It can write a lot of code.
It can try different approaches.

It can work very quickly.
But it doesn't automatically understand your company, your customers, your old systems, your data problems or the reason something was designed in a particular way ten years ago.
Someone still has to provide that understanding.
Testing becomes even more important
If we are going to let AI generate more of our code, then we need better ways to check the result.
This is where testing and monitoring become extremely important.
And I don't mean only unit tests.
For data and AI systems, we also need to check the data, the assumptions and the model itself.
In a forecasting system, for example, I would want to know:
Did the data arrive correctly?
Did the upstream API change?
Are there missing values?
Did the model start behaving differently?
Is the model still performing well?
Did something change in the market?
These questions are sometimes more important than whether a particular function has 95% test coverage.
A model can be technically running perfectly and still be giving increasingly bad predictions.
That is why I like the idea of treating monitoring and evaluation as part of the system itself, not something we add later.
AI actually makes this more interesting.
If I have good tests and good evaluation methods, I can allow AI tools to make changes much more quickly.
If something breaks, I can detect it.
Without those checks, I am basically trusting the AI.
And I don't think that is a good engineering practice.
The whole system matters
Another thing I have learned over the years is that the most interesting problems are usually not inside one function.
They are between the components.
A database.
An API.
A scheduler.
A machine-learning model.
A server.
A data pipeline.
A user interface.
Each component can work perfectly on its own and the complete system can still fail.
Maybe a job runs before another job has finished.
Maybe an API starts returning a slightly different data format.
Maybe a database table becomes too large.
Maybe a pipeline has been failing for three days and nobody noticed.
This is where knowledge of the whole system becomes very valuable.
AI is very good at solving local problems.
"Write this function."
"Fix this SQL query."
"Create this API."
It is much harder for AI to understand all the history and operational details surrounding a real system.
Someone on the team usually knows these things.
And that knowledge is often not written anywhere.
It exists in people's experience.
Domain knowledge matters
I think this is one of the areas where AI might actually make domain knowledge more valuable.
AI knows Python.
It knows SQL.
It knows pandas.
It knows XGBoost.
It knows almost every popular framework.
But knowing the technology is not the same as understanding the problem.
In my own work with energy data and forecasting, I have seen how important the domain can be.
You need to understand what the data represents.
You need to understand when it becomes available.
You need to understand the market.
You need to understand the terminology.
You need to understand what a prediction is going to be used for.
A technically correct model can still be useless if it doesn't fit the actual business problem.
This is why I would give a slightly different piece of advice to someone starting a career in technology today.
Don't only learn AI.
Learn something else deeply as well.
Energy. Finance. Manufacturing. Healthcare. Logistics. Whatever interests you.
Learn how that world works.
Because when you combine domain knowledge with technical skills, AI becomes much more useful.
You have a better chance of knowing when its answer makes sense and when it doesn't.
Communication is not a "soft" skill anymore
Something else has become quite obvious to me.
The better you are at explaining a problem, the better you usually are at using AI.
You need to provide context.
You need to explain what you want.
You need to explain the constraints.
You need to give examples.
And you need to explain what a successful result looks like.
Interestingly, these are exactly the same things you need when working with another person.
So perhaps prompting AI is not really a completely new skill.
It is partly an extension of something developers have always needed to do: communicate clearly.
And this becomes even more important when you are working with AI systems whose output other people need to trust.
If I build a forecasting model and nobody understands what it is doing, what its limitations are, or when it might fail, then the model will probably not be very useful.
Even if the accuracy is good.
But coding still matters
There is one thing I don't want to get wrong with all of this. I don't think developers should stop learning how to code. Quite the opposite. If you don't understand programming, it is much harder to recognise bad AI-generated code.
You need to experience bugs.
You need to write systems yourself.
You need to make mistakes.
You need to debug them.
You need to understand why one solution is better than another.
Otherwise, there is a risk that we become very good at accepting AI output without really understanding it.
That would be a problem.
So perhaps coding is becoming less of a differentiator and more of a foundation.
You still need it.
You just don't need to write every single line yourself.
So what makes a good developer now?
I don't think there is one simple answer.
But I do think the definition is changing.
A good developer still needs strong technical skills.
But they also need to understand the problem they are solving.
They need to understand the data.
They need to understand the system around the code.
They need to know how to test and verify what they build.
They need some understanding of the domain.
And they need to communicate.
For me, this is probably the biggest change.
The keyboard is no longer necessarily the bottleneck.
Understanding is.
AI can help us write code faster.
It can help us explore ideas.
It can help us learn.
It can help us build things that previously would have taken much longer.
But someone still has to decide what should be built.
Someone has to decide whether it is correct.
And someone has to take responsibility for the result.
Maybe that is what the role of the developer is becoming.
Not the person who writes every line of code.
But the person who understands the problem well enough to know what should be built, how to verify it, and when it can be trusted.
And honestly, I find that change quite interesting.