Are we becoming better engineers, or just faster at producing code?

Originally published on Medium.

I have been thinking about this a lot lately.

A few years ago, when I was learning to code, writing the code myself was a big part of the learning process.

You would try something, get an error, search for it, change something, break something else, and eventually figure out what was actually happening.

Sometimes you could spend half a day on a problem that probably could have been solved in five minutes.

Looking back, that sounds inefficient.

But those hours taught you things.

Today, things are very different.

I can describe a feature to an AI tool and get a working implementation in seconds.

• Need an API? It can write it.
• Need a database schema? It can suggest one.
• Need tests? It can generate them.
• Need to refactor something? Give it the code and it will happily rewrite half the project before you have even finished your coffee.

And honestly, I like this.

I don’t think we should pretend that using AI makes us less of an engineer.

We have always tried to remove unnecessary work from software development.

We moved from machine code to assembly, from assembly to higher-level languages, from manually managing servers to cloud platforms, and from building everything ourselves to using frameworks and managed services.

Nobody complains that we are not “real engineers” because we don’t write assembly anymore.

So why should AI be different?

The problem, at least for me, is not AI writing the code.

The problem is when writing the code becomes easier than understanding the code.

You can now build something without really knowing how it works.

And that is where I think things get interesting.

Suppose I ask AI to build an authentication system.

It can probably give me something that looks perfectly reasonable.

But do I understand why it made those choices?

Do I know:

• what happens when a token expires?
• what happens when a user logs out?
• what happens when someone steals a token?
• what happens when two requests update the same resource at the same time?
• what happens when Redis goes down?
• what happens when the database becomes slow?

The code might work.

But software engineering isn’t just about making the happy path work.

It’s about understanding what happens when things don’t.

And I think that is where we still need to spend our time.

This makes me think about junior developers even more.

When I was learning, I didn’t have the option to ask an agent to build an entire feature for me.

I had to struggle through it.

And honestly, sometimes I hated it.

But that struggle forced me to build a mental model.

• I had to understand what an HTTP request was.
• I had to understand databases.
• I had to understand why something was slow.
• I had to debug errors instead of simply asking for another implementation.

Today, beginner can skip a lot of that struggle.

That is incredibly useful when you already understand the fundamentals.

But it can also become a trap when you don’t.

If AI always gives you the answer, you might never develop the ability to find the answer yourself.

And I don’t think the solution is to tell beginners to never use AI.

That would be unrealistic.

Instead, I think there is still value in deliberately doing some things the hard way.

• Build something without AI.
• Read the documentation.
• Try to fix the bug yourself.
• Write the database query.
• Design the API.

Then ask AI to review your approach.

That feels very different from asking AI to build everything from the beginning.

Maybe the role of an engineer is slowly changing.

Less time writing repetitive code. More time understanding problems, making architectural decisions, reviewing implementations, and thinking about edge cases, performance, security and failure.

And hopefully, more time solving problems that actually deserve our attention.

And hopefully, more time solving problems that actually deserve our attention.

I don’t think we need to protect the act of manually writing code just because that is how many of us learned.

But I also don’t think we should lose the learning that came from doing it.

There is something valuable about struggling with a problem until you finally understand it.

Learning slowly isn’t necessarily a disadvantage. Sometimes it’s the part that stays with you.

So yes, I will use AI.

• I’ll use it to remove boilerplate.
• I’ll use it to explore ideas.
• I’ll use it to debug.
• I’ll use it to move faster.

But sometimes, especially when I’m learning something new, I still want to close the AI tab and figure it out myself.

Not because I want to prove that I can write more code than a machine.

Just because I want to make sure I still understand what I’m building.

I’m still figuring this out myself.

But one thing I’m trying to remind myself is that using AI to move faster shouldn’t mean skipping the part where I actually learn.