I've been thinking about how much the way we learn programming has changed over the last decade.
If you started developing 10 or 15 years ago, you probably remember what solving a programming problem looked like. You would search Google for the error or problem you were facing, open a few Stack Overflow results, read the accepted answer, and then go through the comments. Quite often, the comments were just as useful as the answer itself. Someone would mention that the solution only worked with an older version of the framework, another developer would suggest a different approach, and someone else would explain a performance or security issue with the original solution.
You would then try one of those approaches in your own application. Sometimes it worked immediately. Sometimes it didn't. You would modify it, search for another example, read some documentation, and keep experimenting until you understood what was actually happening.
It was slower than what we have today, but there was an important side effect: you were constantly learning while solving problems.
Today, we have AI assistants that can give us a working solution in seconds. Need an ASP.NET Core endpoint? Ask AI. Need a SQL query? Ask AI. Getting an exception? Paste it into the chat. Need to build an entire feature? Describe what you want and let the model generate it.
That's incredibly useful, and I use these tools myself. I don't think developers should avoid them. The question is what happens when getting the answer becomes more important than understanding the answer.
What We Learned From the Old Workflow
One thing I think we sometimes forget about the old way of developing is that searching for answers forced you to evaluate what you found.
Suppose you had a problem with Entity Framework. You might find several Stack Overflow answers showing different approaches. One might use a particular LINQ query, another might recommend changing the database query entirely, and someone in the comments might explain why one of the approaches would perform badly with a large dataset.
You had to think about those answers. You had to understand your own situation and decide which solution made sense.
That process was valuable because programming isn't just about knowing how to implement something. A big part of being a good developer is learning how to judge different implementations.
The same was true when working with documentation. If a library didn't have an example for exactly what you wanted to build, you had to understand its APIs well enough to create your own solution. You would read the documentation, look at related examples, experiment with the available methods, and eventually put something together.
Over time, you developed a mental model of the technology. You started to understand not only what worked, but why it worked and where it might stop working.
AI Makes It Very Easy to Skip That Process
This is where I think junior developers have a particular challenge.
A junior developer today can ask AI to create authentication, database models, API endpoints, validation, tests, Docker configuration, and even an entire application structure. The generated result can look surprisingly professional.
The problem is that the code can become more sophisticated than the developer's understanding of it.
Imagine a developer who has generated a fairly complex API with the help of AI. Everything works locally, the endpoints return the expected responses, and the tests pass. Then someone asks why a particular query is slow when the database contains millions of records.
Or they ask what happens if two users update the same record at the same time. Or what happens when the external service the application depends on becomes unavailable. Or why a particular caching strategy was chosen.
At that point, generating another piece of code isn't really the problem. The developer needs to understand the system and make an engineering decision.
This is what I mean when I use the term "vibe coding." I'm not talking about using AI to write code. I'm talking about accepting generated code because it looks reasonable and seems to work without developing enough understanding to evaluate and maintain it.
Senior Developers Use AI Too
This isn't an argument that senior developers should ignore AI and go back to writing everything by hand. In reality, experienced developers are using AI as well, and they can get enormous value from it.
A senior developer might use AI to generate boilerplate, create a first version of a test suite, review an implementation, identify edge cases, explain an unfamiliar API, compare different approaches, or investigate a problem.
The important difference is that the senior developer already brings experience and context to the conversation.
For example, instead of asking, "Build this feature," they might ask AI to propose three approaches and compare their performance, maintainability, testing requirements, and complexity. They can then look at those options and decide which one fits the application.
They might already have an implementation and ask AI to find potential problems with it. They might have a theory about a production issue and ask AI to challenge that theory.
In that situation, AI is helping the developer think faster and work faster. It isn't making the engineering decision on their behalf.
The Difference Becomes Obvious in Production
It's relatively easy to generate a working application. Production is where the difficult questions start appearing.
What happens when the database is unavailable? What happens when an external API becomes slow? What happens when thousands of requests arrive at the same time? What happens when a request is retried? What happens when two processes modify the same data? What happens when the database grows from a few thousand records to millions? What happens when a deployment fails?
These are the kinds of questions that experienced developers have usually encountered in one form or another. They know that a solution which works in a small development environment may have very different characteristics in production.
AI can help you think through these scenarios, but someone still has to understand the consequences and decide what should actually happen.
That's one reason experience matters.
Documentation Still Matters
I also don't think documentation has become irrelevant because of AI.
AI can be a great way to find your way through documentation. It can explain a complicated API, summarize a concept, or help you figure out which part of the documentation you need to look at.
But when you're working with a framework or third-party library, there is still a lot of value in going to the source.
APIs change. Versions change. Recommendations change. Libraries deprecate old methods and introduce new ones. An AI-generated example might be based on an older version or might simply be unsuitable for your particular situation.
An experienced developer knows when an AI answer is good enough and when it is worth checking the official documentation.
That ability to verify information is becoming more important, not less.
Debugging Is Another Area Where Experience Matters
Consider a simple exception.
A developer can paste the exception into an AI assistant, get a suggested fix, apply it, and see the error disappear. That's convenient, but it doesn't necessarily mean the underlying problem was understood.
A stronger learning process is to first investigate the problem. Read the exception and stack trace, reproduce the issue, inspect the relevant code, and form a theory about what is causing it. Then use AI to help test that theory or identify things you may have missed.
The difference might seem small, but over hundreds of problems it adds up.
If AI solves every problem before you have had the opportunity to investigate it, you may become very good at getting solutions without becoming equally good at diagnosing problems.
And debugging is one of the skills that tends to separate developers with experience from developers who have simply been writing code for a long time.
You Can't Become Senior by Prompting Better
This is probably the controversial part.
Becoming better at prompting AI can make you more productive, but it doesn't automatically give you the judgment expected from a senior developer.
Senior developers have to make decisions when there isn't a perfect answer. They have to understand trade-offs, recognize unnecessary complexity, think about maintainability, consider performance and security, and understand the consequences of technical decisions.
They also need to be able to look at a piece of code and ask whether it belongs in the application at all.
That's difficult to outsource.
You develop that judgment by building things, breaking things, debugging them, reading other people's code, reviewing implementations, studying documentation, making mistakes, and seeing what happens when an apparently good solution meets real-world requirements.
AI can accelerate that learning process, but the learning still has to happen.
So Should Junior Developers Stop Using AI?
Absolutely not.
If anything, juniors should use AI extensively as a learning tool.
Ask it why a particular approach works. Ask it to explain the alternatives. Ask what could go wrong. Ask it to point you toward the relevant documentation. Take the generated code apart and understand each important piece. Modify it yourself. Try a different implementation and compare the results.
Instead of always asking, "Fix this," try explaining what you think is wrong and asking AI to challenge your reasoning.
That way, you're still doing the thinking while using AI as another source of feedback.
It's very similar to having an experienced developer available to discuss a problem with you, except you still need to decide whether the advice actually makes sense.
The Best Developers Will Probably Be the Ones Who Can Do Both
I don't think the future belongs to developers who refuse to use AI, and I don't think it belongs to developers who let AI make every decision for them.
The valuable combination is understanding software engineering deeply while knowing how to use AI effectively.
You can still read documentation, but use AI to find the relevant section faster. You can still debug a problem, but use AI as another pair of eyes. You can understand architecture while asking AI to challenge your design. You can write code yourself when the problem requires careful reasoning and let AI handle repetitive work when it doesn't.
That's a much better use of the technology.
AI can remove a lot of the boring work from development. It can also dramatically shorten the time between having an idea and having something that works.
That's a good thing.
But there's a difference between removing unnecessary work and removing the learning that makes you a better engineer.
The Real Goal
I don't think junior developers are doomed to become vibe coders. The tools are simply making it easier to skip steps that used to be unavoidable.
When you could spend an hour searching Stack Overflow, you naturally learned from the answers and comments. When you had to read documentation to build something custom, you naturally learned the APIs. When you had to debug an issue yourself, you developed debugging instincts.
We can now skip much of that work.
So we have to be more deliberate about keeping the valuable parts.
Use AI. Let it write the boilerplate. Let it suggest solutions. Let it review your code. Let it help you learn something unfamiliar and speed up the parts of development that don't require much thought.
But make sure you're still learning how the software works.
Because the goal isn't to become a developer who can generate code faster than everyone else.
The goal is to become the developer who understands the code well enough to know what should be built, why it should be built that way, what could go wrong, and how to fix it when it does.
That's still what makes someone a senior developer.
And AI doesn't change that. If anything, it makes it even more important.
Top comments (0)