Coming from a diploma background and later pursuing Computer Engineering, I spent a lot of time learning programming the traditional way — writing Java, solving DSA problems, debugging errors, searching documentation, and building projects line by line.

Back then, if I didn't know how to implement something, I had to figure it out.

Today, I can describe a feature to an AI coding agent and watch it modify multiple files, create APIs, connect the frontend, write SQL, and sometimes even debug its own implementation.

That change has been fascinating — but also slightly uncomfortable.

The World Before Coding Assistants

Before AI coding assistants became part of everyday development, building a project was a much more manual process.

At least, that's how I experienced it.

When starting a project, the first challenge wasn't opening an AI agent and asking it to build the application. We had to think about the system ourselves.

What are the components?

What should the backend look like?

What APIs do we need?

What database tables are required?

How will the frontend communicate with the backend?

Sometimes this meant drawing the architecture on paper, using diagrams, or simply trying to visualize the flow in our heads. Tools such as draw.io existed, of course, but as a student, I wasn't even exposed to many of these tools initially.

Then came the actual implementation.

We relied on what we had learned through academics, tutorials, documentation and practice. If we were writing Java, we needed to know the syntax. If we were working with SQL, we needed to understand SQL.

And when something broke, we had to debug it.

An error would appear.

Copy the error.

Search Google.

Open a few results.

Maybe find a matching Stack Overflow question.

Follow the solution manually.

Sometimes it worked.

Sometimes the accepted answer was from 2017 and had absolutely nothing to do with our version of the framework. 😄

And sometimes we could spend an hour finding out that the problem was a missing semicolon, a wrong dependency, or one variable named differently in another file.

It sounds inefficient now.

But there was something valuable about that process.

We were forced to understand what we were doing.

If I wanted to implement something, I had to learn enough to implement it.

If something broke, I had to understand enough to fix it.

Development was slower.

But the person writing the code was much closer to the implementation.

Then something changed.

Then AI Entered Development

Towards the end of my second year, especially in the fourth semester, AI started becoming something different for us.

Not AI in the abstract.

Not some futuristic technology.

ChatGPT.

And honestly, the first reaction was mostly:

Wait... it can actually do this?

At first, it was simple.

We asked it questions.

We asked it to explain concepts.

We gave it errors.

We asked it to generate small pieces of code.

And slowly, our relationship with it changed.

Instead of only asking:

"What does this error mean?"

we started asking:

"How should I design this API?"

Then:

"What should my database schema look like?"

Then:

"Can you help me design the architecture?"

AI was no longer just answering questions.

It was becoming part of the development process.

Previously, the process was something like:

Think → Search → Learn → Implement → Debug

Now it started becoming:

Think → Ask AI → Refine → Implement

And because the answers were so fast, it was very easy to start depending on them.

At first, AI was something we used when we were stuck.

Then we started using it before starting a task.

Eventually, it became part of almost every development session.

But even then, we were still the ones moving the code around.

We would ask AI for the implementation, copy it, paste it into the project, run it, modify it and continue.

The AI was helping us write code.

But the next shift was much bigger.

The AI wouldn't just give us the code. It would start working inside the codebase itself.

The Jump to Agentic AI

This is where, for me, the change stopped feeling incremental.

With a normal chatbot, the interaction was still:

Me → Prompt → AI → Code → Me

I still had to take the output and integrate it.

Coding agents changed that.

Now it was closer to:

Me → Give the goal → Agent → Inspect → Implement → Run → Debug → Modify

The important difference wasn't simply that AI could generate better code.

It could take actions.

I could describe what I wanted to build, explain the constraints, point the agent toward the existing project, and let it work through multiple files and multiple steps.

That was a very different experience for someone who had learned development by writing those pieces manually.

And then this wasn't limited to coding.

Tools started appearing that could generate interfaces from descriptions. The whole development process started feeling faster.

Instead of:

Idea → Design → Code → Build UI → Connect backend → Debug

it was increasingly becoming:

Idea → Describe → Generate → Refine

And suddenly, writing the code wasn't always the biggest bottleneck anymore.

It was deciding what should be built.

At the same time, AI was becoming impossible to ignore outside our editors too.

Image generation exploded. AI-generated content was everywhere. The conversation around AI shifted from simply being impressed by what it could do to asking what it meant for jobs and careers.

The question became:

Is AI going to replace us?

And for someone still learning software development, that question felt much more personal.

Because if AI can increasingly build the things I'm learning to build...

what exactly should I be getting better at?

That was the question that stayed with me.

If AI Can Code, What Am I Learning?

This was probably the most uncomfortable part of the transition.

At some point, I started wondering:

Am I becoming a better developer, or am I simply becoming better at telling AI what to do?

Because the things I was learning to build were increasingly things AI could already generate.

CRUD APIs?

AI can build them.

React components?

AI can generate them.

SQL queries?

AI can write them.

A bug?

Give it the error.

A feature?

Describe it.

And when you're still learning software development, that's a strange feeling.

You spend years learning how to write code, understand syntax and debug problems — and suddenly, a large part of the implementation can be produced in seconds.

So where does the value of a developer move?

I don't think the answer is that developers become useless.

I think the answer is more uncomfortable:

The parts of development that require understanding become more important.

What AI Actually Made Cheaper

Looking back, I don't think AI made software engineering cheap.

It made implementation cheaper.

There is a difference.

Boilerplate became faster.

CRUD APIs became faster.

Basic UI became faster.

SQL became easier to generate.

Documentation became easier.

Debugging got a much faster starting point.

Refactoring became easier to explore.

But if an AI generates a Spring Boot controller in ten seconds, it doesn't mean building the entire system became a ten-second problem.

The controller was never the whole problem.

The real questions are:

Should this endpoint exist?

Who should be allowed to use it?

How should the data be stored?

What happens when something fails?

Is the architecture correct?

Is it secure?

AI can help answer these questions too.

But someone still needs to evaluate those answers.

And that's where I started looking at my own projects differently.

What Became More Important

While building my AI Workflow Management Engine, I started noticing that getting an endpoint implemented wasn't necessarily the hardest part anymore.

The harder part was deciding what the system should actually do.

How should workflows be represented?

How should nodes and edges be stored?

How should execution move between nodes?

What happens when a node fails?

AI can help implement these pieces.

But I still need to understand why those pieces exist and how they fit together.

SecureVault made this even more obvious.

I could ask AI to create a file-upload endpoint.

That's relatively easy.

But the important question wasn't:

"Can we upload a file?"

It was:

"Can we upload a file without giving the server access to the plaintext?"

That question changes the architecture.

The file is encrypted on the client.

The encryption keys need to be handled carefully.

Private keys shouldn't be sent to the backend.

Different users may need access to the same encrypted file.

Revoking someone's access shouldn't require decrypting and re-encrypting the entire file.

Authorization also needs to work together with the encryption model.

Suddenly, the difficult part wasn't typing the code.

It was understanding the system well enough to tell the AI what the code was supposed to accomplish.

That was an important realization for me.

AI can generate implementation.

But architecture is a set of decisions.

And someone has to own those decisions.

AI Can Make You Faster — But It Can Also Make You Weaker

There is another side to this.

AI can make a developer dramatically faster.

But if used incorrectly, it can also make a developer weaker.

The biggest danger isn't necessarily that AI writes bad code.

It's that AI can write code that looks good enough for you to stop asking questions.

You can accept an architecture without understanding it.

You can copy a solution without understanding the problem.

You can fix an error without understanding why it happened.

And eventually, you can have an application that works — without really understanding the application.

That's especially dangerous in areas like security.

A generated authentication flow might work.

A generated encryption implementation might compile.

A generated authorization check might pass the happy path.

But:

"It works" and "it is secure" are not the same statement.

Working on SecureVault made me much more conscious of this.

When dealing with encryption, key management, access control and Zero Trust authorization, blindly accepting generated code isn't enough.

You need to be able to ask:

Why is this key here?

Who can access it?

What happens when access is revoked?

Can this resource be accessed in a way I didn't intend?

These aren't syntax questions.

They're engineering questions.

So What Should I Learn Now?

My conclusion isn't:

"Don't use AI."

That doesn't make much sense to me.

AI is already becoming part of software development.

Instead, I think the fundamentals matter even more.

For me, that means continuing to build depth in:

DSA, Java, databases, operating systems, networking, backend architecture, security and distributed systems.

Not because I expect to manually write every line forever.

But because I want to understand what those lines are doing when AI writes them.

At the same time, I don't want to spend three hours manually writing repetitive boilerplate just to prove that I can.

I'll let AI help with implementation, debugging, testing, documentation, refactoring and repetitive work.

The distinction is simple:

Let AI accelerate the implementation.

Don't outsource the understanding.

Where I Am Now

Today, when I use an AI coding agent, I don't want it to replace my understanding of the project.

I want it to replace the repetitive parts of implementation.

My role is increasingly becoming:

Understand the requirements → design the system → make technical decisions → instruct the agent → review → test → debug → understand → improve.

And ironically, AI has made me realize that knowing how to write code and knowing how to build software aren't exactly the same thing.

The first is about implementation.

The second is about understanding the entire system.

What I Don't Know Yet

I don't know exactly what software development will look like five years from now.

Maybe agents will write most of the implementation.

Maybe they'll handle testing, deployment and debugging too.

Maybe the definition of a developer will change again.

I'm still figuring out what that means for me.

But after experiencing the transition from writing code manually, to asking ChatGPT for help, to using coding assistants, and now to working with agents across an entire project, I've become convinced of one thing:

The less expensive code becomes, the more valuable understanding becomes.

I don't want to compete with AI at typing code faster.

I want to become better at understanding what should be built, why it should be built, and whether what was built is actually correct.

Maybe that's what being a developer will increasingly mean.

Not writing more code than AI.

Understanding the systems that AI helps us build.