Introduction

The discussion around AI is often dominated by two extremes.

One side believes AI has arrived and that software engineering is finished.

The other believes AI has arrived, and learning software engineering is no longer necessary.

In my opinion, both perspectives are flawed.

Before discussing the extremes, it is important to understand something:

Technology rarely determines your future. Your perspective toward technology does.

The people who adapt usually outperform the people who resist change.

The people who understand a tool usually outperform the people who worship it.

AI is no different.

Perspective Matters More Than Technology

Every major technological shift creates uncertainty.

Some people see opportunity.

Some people see danger.

Most people see only one side.

The problem is that software engineering has never been about tools alone.

Programming languages changed.

Frameworks changed.

Cloud computing changed deployment.

Low-code platforms changed development workflows.

Now, AI is changing how software is built.

The engineers who survive are not the ones who memorize tools.

They are the ones who continuously adapt.

That ability to adapt is more valuable than any specific framework, language, or AI model.

Vibe Coding, AI-Assisted Coding, and Engineering

I believe many discussions about AI become confusing because people treat all AI usage as the same thing.

It is not.

Vibe Coding

The workflow is usually:

Prompt
↓
Generate
↓
Copy
↓
Deploy

The developer may not understand:

• architecture
• constraints
• tradeoffs
• security implications
• maintainability concerns

The code exists.

Ownership does not.

AI-Assisted Coding

The workflow is different.

Idea
↓
Requirements
↓
Architecture
↓
Constraints
↓
Tradeoffs
↓
AI Assistance
↓
Verification
↓
Production

The engineer remains responsible.

AI becomes a productivity tool.

This is fundamentally different from handing responsibility to a model.

How I Personally Use AI

I use AI extensively.

But not in the way many people imagine.

When I work on projects, the idea originates from me.

The problem statement originates from me.

The business objective originates from me.

Before writing code, I often spend hours discussing:

• architecture
• constraints
• tradeoffs
• scalability concerns
• implementation approaches

The objective is not:

"Build the project for me."

The objective is:

"Help me reason about the project."

The discussion itself often becomes more valuable than the generated code.

My Current Development Workflow

A practical workflow I follow looks something like this:

Idea
↓
Architecture Discussion
↓
Constraint Analysis
↓
Tradeoff Analysis
↓
Scaffolding
↓
Implementation
↓
Verification
↓
Refinement

For example:

• Claude may help scaffold backend components.
• Copilot may help accelerate frontend implementation.
• ChatGPT may help verify architecture decisions or review implementation choices.

However, scaffolding is not the destination.

It is only the starting point.

Generated code still needs to become production-quality code.

That responsibility remains with the engineer.

Be the Commander, Not the Passenger

A naval ship does not become intelligent because it has powerful engines.

The ship still requires a commander.

Software systems are similar.

AI can generate:

• code
• documentation
• tests
• architecture suggestions

But someone still needs to decide:

• what should be built
• why it should be built
• which tradeoffs are acceptable
• which risks are unacceptable

That responsibility belongs to the engineer.

Not the AI.

The First Extreme: Fear

The first extreme sounds like this:

AI has arrived.

Software engineering is finished.

This perspective assumes that AI removes the need for engineers.

I disagree.

Businesses do not merely need code.

Businesses need:

• systems
• reliability
• maintainability
• security
• compliance
• scalability

Code generation is only one piece of the puzzle.

The ability to leverage AI effectively will likely become more valuable than avoiding AI entirely.

The Second Extreme: Blind Trust

The second extreme sounds like this:

AI has arrived.

Learning logic is unnecessary.

This perspective is equally dangerous.

Without understanding:

• logic
• architecture
• execution flow
• debugging
• security

you cannot effectively evaluate AI-generated output.

You become dependent on a system you cannot verify.

The result is often:

• insecure code
• poor architecture
• hidden bugs
• incorrect assumptions

The engineer who cannot evaluate AI output is vulnerable to replacement.

Not because AI replaced them.

But because they never learned how to work with AI properly.

So, What Should We Do?

My answer is simple.

Own the system.

Own the architecture.

Own the constraints.

Own the tradeoffs.

Own the decisions.

Understand the code.

Verify the implementation.

Validate the output.

Use AI aggressively.

But never outsource responsibility.

The generated code should still reflect your intent.

The architecture should still reflect your decisions.

The system should still reflect your understanding.

Final Thoughts

I do not believe the future belongs to people who fear AI.

I also do not believe the future belongs to people who blindly trust AI.

The future belongs to engineers who know how to leverage AI while retaining ownership of the systems they build.

Be the engineer who understands the architecture.

Be the engineer who defines the constraints.

Be the engineer who evaluates the tradeoffs.

Be the engineer who verifies the output.

Do not become AI-dependent.

Do not become AI-fearful.

Become the mind behind the machine.