AI Can Help Us Move Faster, But It Can't Replace Good Engineering

AI has become part of everyday software development.

We can ask it to write code, create a Dockerfile, explain an error, generate Terraform, write tests, or look through a bunch of logs and tell us what might be going wrong.

Honestly, this is pretty amazing.

Things that used to take hours can sometimes be done in minutes.

But there is something I keep coming back to:

AI can help us do the work faster. It doesn't mean we can stop understanding the work.

And I think this matters a lot in DevOps.

What exactly is changing?

A few years ago, if we wanted to automate something, we would usually sit down and write the script ourselves.

If we needed infrastructure, we wrote the Terraform.

If we needed a deployment pipeline, we created the CI/CD configuration.

If something broke, we opened the logs, checked the metrics, searched through documentation, and started investigating.

Today, AI can help with almost all of this.

For example, we can say:

Create a Dockerfile for my application.

Or:

Why is my application returning these errors?

Or:

Create Terraform for this AWS architecture.

And within seconds, we may have something useful.

That's a huge productivity boost.

But there is a catch.

The answer can look right and still be wrong

This is probably the part that worries me the most.

AI doesn't always give us an obviously bad answer.

Sometimes it gives us an answer that looks completely reasonable.

Imagine AI creates a Terraform configuration for your application.

It runs.

Terraform doesn't complain.

The application starts.

Everything looks fine.

But perhaps the database has been exposed in a way it shouldn't be.

Or the setup is going to cost much more than expected.

Or backups aren't configured properly.

Or the system won't survive the failure you were expecting it to handle.

Nothing immediately looks broken.

But the design is still wrong.

This is why knowing the fundamentals still matters.

DevOps is more than writing scripts

When people hear "DevOps", they sometimes think about CI/CD pipelines, Docker, Kubernetes, Terraform, and cloud platforms.

Those tools are important.

But DevOps is really about something bigger:

How do we build, deliver, and operate software reliably?

That means understanding things like:

• What happens when a server goes down?
• What happens when a database becomes slow?
• What happens when one service is working and another isn't?
• How do we know something is broken?
• How quickly can we recover?
• How do we prevent the same problem from happening again?

AI can help us answer these questions.

But we still need to understand the questions.

AI is great at giving us a starting point

This is where I think AI is incredibly useful.

Suppose I am working on a deployment pipeline.

Instead of starting with a blank file, I can ask AI for a first version.

It gives me something to work with.

I can then review it, change it, test it, and make it fit my actual environment.

That is very different from blindly copying the answer.

The first approach is:

AI gives me a starting point
        ↓
I understand it
        ↓
I test it
        ↓
I improve it

The second approach is:

AI gives me an answer
        ↓
I copy it
        ↓
I hope it works

The first one makes us faster.

The second one can make us dependent.

What about troubleshooting?

This is another area where AI can be really helpful.

Imagine a production application suddenly starts becoming slow.

There might be thousands of log messages.

There could be metrics from multiple services.

Maybe there was a deployment ten minutes ago.

Maybe the database is running out of connections.

Maybe a downstream service is slow.

Maybe the network is having problems.

AI can help us look through all of this information and suggest possible causes.

For example:

Possible cause:
The application may be running out of database connections.

Why:
- Database connection usage increased.
- Request latency increased at roughly the same time.
- The application started showing timeout errors.

That's useful.

But notice the wording:

possible cause.

It's a starting point, not proof.

We still need to check the metrics.

We still need to investigate.

We still need to test the idea.

And we still need to make the final decision.

This is where engineering judgment becomes important

I think AI is actually making one engineering skill more valuable:

judgment.

If AI can generate ten possible solutions in a few seconds, the valuable skill isn't necessarily knowing how to type the solution.

The valuable skill is knowing:

• Which solution makes sense?
• Which one is unnecessarily complicated?
• Which one is unsafe?
• What assumptions is it making?
• How can I test it?
• What happens if it fails?
• Is this actually solving the problem?

These are engineering questions.

The future isn't humans versus AI

I don't think the useful question is:

"Will AI replace DevOps engineers?"

A better question is:

"What will good DevOps engineers do differently when AI is available?"

My guess is that the strongest engineers will use AI heavily.

They will use it to:

• write the first version of code
• create tests
• explain unfamiliar technologies
• summarize logs
• suggest troubleshooting steps
• draft infrastructure
• improve documentation
• automate repetitive work
• explore different solutions

But they won't blindly trust it.

They will verify.

They will test.

They will question.

They will measure.

They will understand.

A simple way to think about it

For me, the workflow looks something like this:

Understand the problem
        ↓
Think about the possible solution
        ↓
Use AI to accelerate the work
        ↓
Review what AI produced
        ↓
Test it
        ↓
Run it
        ↓
Observe what actually happens
        ↓
Fix what is wrong
        ↓
Learn from the result

AI becomes a very powerful assistant in this process.

But it isn't the person responsible for the outcome.

We are.

What should we learn now?

This is probably the most important question.

If AI can write code for us, should we still learn programming?

Yes.

If AI can create Terraform, should we still understand cloud infrastructure?

Yes.

If AI can explain networking, should we still learn networking?

Absolutely.

Not because we need to compete with AI at typing commands.

We need the knowledge so that we can tell when the answer doesn't make sense.

You don't need to memorize every command.

But you should understand what the command is doing.

You don't need to write every configuration file from scratch.

But you should understand what the configuration means.

You don't need to manually investigate every log line.

But you should know what evidence matters.

AI makes learning fundamentals more valuable

This might sound strange.

If AI is becoming better at implementation, why spend time learning fundamentals?

Because fundamentals give us a way to judge the output.

If I understand networking, I can question an AI-generated network design.

If I understand databases, I can question a proposed database architecture.

If I understand Linux, I can investigate what is actually happening on a machine.

If I understand distributed systems, I can recognize when a "simple" solution isn't actually simple.

Knowledge gives us context.

Context gives us judgment.

And judgment lets us use AI safely.

The rule I want to follow

I don't want to become an engineer who knows how to ask AI for everything.

I want to become an engineer who knows when to ask AI, what to ask, and how to verify the answer.

So my simple rule for the AI era is:

Use AI to move faster. Build the judgment to know when it's wrong.

Let AI write the first draft.

Let it explain things.

Let it suggest ideas.

Let it help investigate problems.

But don't outsource your understanding.

Because when something goes wrong in production, nobody asks:

"What did the AI say?"

They ask:

"What happened, and how are we going to fix it?"

That's still our job.