AI Can Write the Code. But Who Is Doing the Thinking

AI can write code.

It can write documentation, generate tests, explain errors, create architecture diagrams, summarize meetings, and even suggest technical strategies.

And that is exactly why I’m becoming more concerned about something else:

Are we still doing enough thinking ourselves?

We are getting very good at asking AI for answers.

But software engineering was never just about producing answers.

It was about understanding the problem well enough to know which questions to ask in the first place.

The dangerous part isn't AI

I don't think AI is the problem.

The problem starts when we stop using our own judgment because AI has already given us something that looks reasonable.

A developer asks an LLM to design an architecture.

It produces a clean diagram.

The developer accepts it.

Another developer asks AI to review the code.

It produces ten recommendations.

They implement them.

A product manager asks AI to create a technical roadmap.

It produces a convincing document.

Everyone moves on.

Everything looks productive.

But somewhere in that process, we may have skipped the most important part:

Thinking.

AI can produce a very convincing answer without understanding your business, your users, your constraints, your history, or the consequences of getting the decision wrong.

And ultimately, you are still responsible for the result.

Code is not the hard part

Writing code has never been the entire job of a software engineer.

The harder questions are usually:

What should we build?

Why are we building it?

What problem are we actually solving?

What happens if this fails?

What are we willing to sacrifice?

What should we not build?

Those questions require judgment.

You can ask AI to generate a thousand lines of code in seconds.

But generating a thousand lines of code doesn't tell you whether those lines should exist.

That's an important distinction.

AI can accelerate implementation. It shouldn't replace engineering judgment.

The uncomfortable part: friction is useful

We often think friction is something we should eliminate.

If something takes three hours, and AI can reduce it to thirty minutes, that's obviously good.

Sometimes it is.

But not all friction is waste.

Some friction is how we learn.

Debugging a problem for hours teaches you how the system actually behaves.

Reading documentation teaches you the boundaries of a technology.

Writing something from scratch teaches you what the abstractions are hiding.

Arguing with another engineer forces you to defend your assumptions.

Getting something wrong teaches you what you misunderstood.

These experiences build something that is difficult to generate with a prompt:

judgment.

If AI removes every difficult part of the learning process, we might become faster without becoming better.

The junior developer problem

This worries me even more for developers who are starting their careers today.

Imagine learning software engineering in a world where you can ask AI:

"Explain this code."

"Fix this bug."

"Write this feature."

"Design this API."

"Summarize this documentation."

You can complete the task.

But did you understand it?

There is a huge difference between having an answer and understanding why the answer is correct.

A junior developer who struggles with a bug for three hours may learn something that stays with them for ten years.

A developer who immediately asks AI for the fix may solve the bug in thirty seconds—and learn almost nothing.

The goal isn't to make developers suffer.

The goal is to make sure we don't remove the experiences that create competence.

AI should be your copilot, not your judgment

I use AI.

I think developers should use AI.

There is enormous value in having something that can help you explore ideas, generate boilerplate, find alternatives, explain unfamiliar concepts, and accelerate repetitive work.

But there should be a line.

Let AI help you write the code.

Don't automatically let it decide what code deserves to be written.

Let it summarize the documentation.

But read enough of the original material to understand the important details.

Let it suggest an architecture.

But challenge the assumptions behind it.

Let it review your code.

But don't blindly accept every recommendation.

Use AI to make your thinking faster—not to avoid thinking altogether.

We still need to earn our judgment

The best engineers won't necessarily be the people who generate the most code with AI.

They may be the people who can look at AI-generated code and immediately ask:

"Why?"

Why this architecture?

Why this database?

Why this abstraction?

Why this trade-off?

Why do we need this feature?

What happens at scale?

What happens when the assumption is wrong?

What happens six months from now?

Those questions come from experience.

And experience comes from doing the work, making mistakes, debugging things, reading, discussing, disagreeing, and sometimes sitting with a problem longer than you'd like.

That process is slow.

But that's where judgment comes from.

Don't outsource the part that makes you an engineer

AI will probably continue to get better.

It will write better code.

It will understand larger codebases.

It will become better at planning and reasoning.

And we should use those capabilities.

But there is one thing I don't want to outsource:

my judgment.

Because if AI writes the code, reviews the code, explains the code, designs the architecture, creates the roadmap, and decides what we should build next...

What exactly are we practicing?

Software engineering isn't just the ability to produce software.

It's the ability to understand problems, make trade-offs, and take responsibility for decisions.

AI can help us do that better.

But it shouldn't do it instead of us.

The future of engineering isn't humans versus AI.

It's humans who still think, using AI extremely well.