Are We Becoming Too Dependent on AI?

I started coding at a time when writing code meant understanding the code.

Not just making it work.

If I wrote a function, I usually knew why it existed. I knew what the variables represented, what the algorithm was doing, which data structure I was using, and what could break if I changed a particular line.

When something went wrong, I didn't immediately ask an AI to fix it.

I opened the code.

I traced the logic.

I read the error.

I searched for documentation.

I experimented.

And eventually, I understood what was happening.

That process was slow sometimes.

But it taught me something.

The code wasn't just producing software. It was producing knowledge in me.

The Way We Used to Learn#

When I was learning programming, changing one line could force me to understand the entire chain of consequences.

Why is this function here?

Why is this data structure being used?

Why is this API designed this way?

What happens if this value is null?

What happens when the number of users increases?

Why is this query slow?

Those questions were part of becoming a developer.

You didn't just learn how to write code.

You learned how to think.

And that distinction matters.

Because programming has never really been about typing code.

It's about understanding problems deeply enough to turn them into systems.

Then AI Arrived#

Now things are different.

AI can write a function in seconds.

It can generate an API.

It can create database schemas.

It can write tests.

It can debug an error.

It can explain an unfamiliar codebase.

It can even build entire applications from a simple description.

And honestly?

That's incredible.

I've used AI extensively myself.

It makes me dramatically faster.

There are tasks that used to take hours that can now take minutes.

So I'm not arguing that we should go back to writing everything manually.

That would be like refusing to use a calculator because mathematicians once calculated everything by hand.

The problem isn't AI.

The problem is what happens when speed replaces understanding.

When "It Works" Becomes Enough#

One thing I've increasingly noticed is that some developers can produce surprisingly large amounts of code without necessarily understanding what that code is doing.

They can ask:

"Build authentication with JWT, Redis, PostgreSQL and refresh tokens."

AI generates it.

They copy it.

It works.

Next feature.

Another prompt.

Another 500 lines.

Another feature.

Another prompt.

And suddenly there's an entire application.

But ask:

"Why did you choose this architecture?"

Silence.

Ask:

"What happens if the refresh token is compromised?"

Uncertainty.

Ask:

"Why is this database query causing a performance issue?"

"Let me ask AI."

And this is where I think we need to pause.

Because there is a difference between using AI to accelerate understanding and using AI to avoid understanding.

The New Generation of Developers#

I don't think this is true for everyone.

There are many developers using AI extremely well.

They understand the fundamentals, use AI as a multiplier, review the output, challenge its assumptions, and learn from it.

But there is another pattern emerging.

Developers who learn the prompt before they learn the programming language.

Developers who know how to generate a solution but don't know how to debug it.

Developers who can build something quickly but cannot explain why it works.

And that creates a strange situation.

We may be producing more software than ever while, at the same time, producing fewer people who deeply understand the software they build.

That's concerning.

But Isn't Speed the Point?#

Someone might say:

"Why does it matter if I understand every line? If AI can do it faster, why not let AI handle it?"

That's a fair question.

And in many situations, you're right.

I don't need to manually implement every utility function anymore.

I don't need to remember every syntax detail.

I don't need to spend two hours searching Stack Overflow for something AI can explain in thirty seconds.

AI should absolutely remove unnecessary friction.

But there's a difference between not memorizing something and not understanding it.

I don't need to remember every SQL syntax rule.

But I should understand databases.

I don't need to manually write every API endpoint.

But I should understand APIs.

I don't need to implement every sorting algorithm from scratch.

But I should understand complexity and when different approaches matter.

I don't need to write every line.

But I need to know what the lines I ship are doing.

The Real Skill Is Changing#

Maybe the future of programming isn't about who can write the most code.

Maybe it will be about who can understand the most.

AI makes implementation cheaper.

So the value increasingly moves upward.

From:

"Can you write this code?"

to:

"Can you define the right problem?"

From:

"Can you build this feature?"

to:

"Can you design the right system?"

From:

"Can you fix this bug?"

to:

"Can you understand why this system keeps producing bugs?"

And perhaps most importantly:

"Can you tell when the AI is wrong?"

Because AI will be wrong.

Sometimes subtly.

Sometimes confidently.

And sometimes in ways that don't become obvious until your system is in production.

The Future: AI Agents Everywhere#

The next phase may be even more interesting.

We're moving from AI that generates code to AI agents that can actually operate software development environments.

An agent can inspect a repository.

Understand requirements.

Create files.

Run tests.

Fix errors.

Open pull requests.

Deploy infrastructure.

Monitor systems.

And potentially keep working with very little human intervention.

Imagine telling an agent:

"Build a SaaS product for this idea and deploy it."

And hours later, you have a working application.

That's not science fiction anymore.

But it creates a new question.

If AI agents build most of our software, what happens to the engineer?

I don't think engineers disappear.

I think the job changes.

The engineer becomes increasingly responsible for direction, architecture, verification, judgment, and accountability.

The ability to say:

"This is wrong, and here's why."

may become more valuable than the ability to type:

"Write this for me."

We Shouldn't Fight AI#

I don't think the answer is to stop using AI.

Quite the opposite.

Use it.

Use it aggressively.

Let AI write boilerplate.

Let it generate tests.

Let it explain documentation.

Let it review your code.

Let agents automate repetitive work.

But don't outsource your thinking.

Ask AI to explain the solution.

Ask it what assumptions it made.

Ask what could go wrong.

Ask for alternative architectures.

Ask it to challenge your approach.

Then review the result yourself.

Use AI as a pair programmer, not as a replacement for your brain.

Maybe the Biggest Risk Isn't AI#

The biggest risk isn't that AI will become smarter than us.

It might.

The bigger risk is that we become less capable because we stopped practicing the things AI does for us.

A calculator didn't make mathematics disappear.

But if you never learn basic mathematics and rely entirely on a calculator, you lose the ability to recognize when an answer doesn't make sense.

The same thing can happen with software.

If AI writes every piece of code, eventually we may lose the instinct to recognize bad architecture.

If AI debugs every problem, we may lose our debugging instincts.

If AI makes every technical decision, we may slowly lose our ability to make technical decisions.

And that's a dangerous dependency.

The Future Developer#

I don't think the best developers of the future will be the ones who refuse AI.

And I don't think they'll be the ones who blindly accept everything AI produces.

The best developers will probably be somewhere in the middle.

They'll understand fundamentals deeply.

They'll use AI extremely effectively.

They'll move faster than previous generations.

But they'll still know enough to question the machine.

They'll understand the architecture behind the generated code.

They'll know when an abstraction is unnecessary.

They'll recognize when a solution is insecure.

They'll know when a database design won't scale.

They'll know when an AI-generated answer simply doesn't make sense.

Because ultimately, AI can generate the code.

But someone still has to understand the system.

Someone still has to take responsibility.

Someone still has to decide whether the thing being built should exist in the first place.

So, Should We Be Worried?#

A little.

Not because AI is bad.

But because convenience is powerful.

The easier something becomes, the easier it is to stop learning how it works.

And perhaps that's the challenge of this generation of developers.

We have access to the most powerful programming assistant humans have ever created.

We can build faster than ever.

But we have to make sure that while AI is getting better at building software,

we don't get worse at understanding it.

Because the future probably won't belong to people who can code without AI.

And it probably won't belong to people who can code only with AI.

It will belong to people who know when to use AI, when to question AI, and when they need to understand things themselves.

AI should make us more capable—not less curious.