I recently watched a video by Hussein Nasser discussing AI in software engineering. One of the points that stood out to me was his belief that the value of engineering often lies in the struggle itself—the process of debugging, experimenting, failing, and eventually understanding why something works.
That got me thinking about a tension that exists in our industry today.
The Business Perspective
Businesses, clients, and managers generally care about one thing: results.
They want features shipped faster. They want products launched sooner. They want ideas turned into reality.
And honestly, that's perfectly reasonable.
Most businesses are not paying engineers to write elegant code. They are paying engineers to solve problems and generate business value. If AI allows a feature that once took three days to be completed in three hours, many organizations will happily take that trade.
From a business perspective, speed is often a competitive advantage.
The Engineer's Perspective
The problem is that businesses and engineers are optimizing for different things.
A business optimizes for outcomes.
An engineer should optimize for both outcomes and capability.
Businesses are not responsible for your career growth. They are responsible for growing the company.
You are responsible for growing yourself.
That's where I think many developers are making a mistake.
Shipping More Doesn't Always Mean Learning More
With modern AI tools, it is possible to build things today that would have seemed impossible just a few years ago.
Need a CRUD module?
AI can generate it.
Need an API integration?
AI can generate it.
Need tests, documentation, migrations, and frontend components?
AI can generate much of that too.
As a result, developers can ship more features than ever before.
But there is an important question:
Are you actually becoming a better engineer while doing it?
Shipping more software and growing as an engineer are not always the same thing.
If every difficult problem is immediately delegated to AI, you may end up producing more code while learning less about software engineering.
The Hidden Cost of AI Dependency
Imagine spending years building products almost entirely through AI assistance.
Every architectural decision is suggested by AI. Every bug is fixed by AI. Every optimization comes from AI. Every design choice is generated by AI.
Projects get completed.
Clients are happy.
Managers are satisfied.
But then one day you're sitting in front of a whiteboard during a system design interview.
Or you're troubleshooting a production outage where the AI's suggestion doesn't work.
Or you're asked to design a system from scratch.
Suddenly there is no autocomplete. No prompt. No generated solution.
Just you and the problem.
Can you still think through it?
Can you explain the tradeoffs?
Can you reason about performance bottlenecks?
Can you identify the root cause?
If not, then the productivity gains may have come at the cost of your long-term engineering growth.
The Skills That Actually Create Senior Engineers
Senior engineers are not defined by how quickly they can generate code.
They are defined by judgment.
That judgment comes from:
- Debugging complex issues
- Understanding system failures
- Investigating performance problems
- Reading and maintaining existing code
- Evaluating tradeoffs
- Designing systems
- Learning from mistakes
These skills are difficult to develop because they require struggle.
And struggle is exactly what many AI workflows attempt to eliminate.
Businesses Won't Protect Your Skills
This is perhaps the most important point.
Businesses care about delivering value.
They don't wake up every morning wondering whether your problem-solving abilities are improving.
They don't measure whether your architectural thinking is getting stronger.
They measure outcomes.
That's their job.
Protecting your skills is your job.
If you blindly optimize for short-term productivity, you may eventually find yourself becoming dependent on tools that are doing most of the thinking for you.
AI Is Not the Problem
To be clear, this is not an argument against AI.
I use AI.
Most developers use AI.
AI is an incredible tool.
The problem is not using AI.
The problem is outsourcing your thinking to AI.
There is a huge difference between:
- Using AI to accelerate learning
- Using AI to replace learning
The first makes you stronger.
The second makes you dependent.
The Future Belongs to Engineers Who Can Think
I don't believe the future belongs to developers who refuse AI entirely.
I also don't believe it belongs to developers who blindly accept every AI-generated response.
The future belongs to engineers who can do both:
- Think independently
- Use AI effectively
They understand the fundamentals. They can reason from first principles. They can solve problems without AI when necessary.
Then they use AI as an accelerator, not as a substitute for engineering judgment.
Final Thoughts
The business world will continue pushing for faster delivery, and AI will continue making software development more productive.
That's not going to change.
What should not change is our responsibility to keep learning.
If AI helps you ship a feature faster, that's great.
But don't let it take away the opportunities that help you grow.
Because at the end of the day, businesses care about the product.
You should care about the person you're becoming while building it.
And no AI model can build that for you.