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 logs for a possible cause.

Honestly, it is remarkable how much time that can save. 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, automating something usually meant sitting down to write the script ourselves. We wrote the Terraform for infrastructure and the CI/CD configuration for deployments. When 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.

Within seconds, we may have something useful. That is a welcome starting point, but it still needs review.

The answer can look right and still be wrong

This is the part that worries me most: an AI answer can look completely reasonable. Imagine it creates a Terraform configuration for your application. Terraform accepts it, the application starts, and everything looks fine.

The database might still be exposed, the running costs higher than expected, or the backups misconfigured. The system might also fail under conditions it was meant to survive.

A successful deployment does not answer those design questions. Understanding the fundamentals helps us know what else to check.

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 investigate these questions, but we still need to understand why they matter and what a convincing answer would look like.

AI is great at giving us a starting point

Suppose I am working on a deployment pipeline. Instead of starting with a blank file, I can ask AI for a first version, then review it, change it, and test it against my actual environment. That is where I find it most useful: it gives me something concrete to examine.

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?

Imagine a production application suddenly becomes slow. There are thousands of log messages and metrics from several services. A deployment happened ten minutes ago, the database may be running out of connections, and a downstream service might be struggling too.

AI can help sort through that 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 is useful, provided we treat it as a possible cause. We still need to check the metrics, test the idea, and decide whether the evidence supports it.

This is where engineering judgment becomes important

I think AI makes engineering judgment more valuable. When it can generate ten possible solutions in a few seconds, we need to decide which one fits. That means asking:

• 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

They will also question the assumptions, test the result, and measure what happens. Using AI well includes knowing how to check its work.

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 can help throughout this process. We remain responsible for the outcome.

What should we learn now?

Programming, cloud infrastructure, and networking are still worth learning, even when AI can produce code and explanations for all three. We need that knowledge to recognize when an answer does not make sense.

You do not need to memorize every command or write every configuration file from scratch. You should understand what they do. And you do not need to read every log line manually, but you should know which 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.

That knowledge gives us the context to question a suggestion before we rely on it.

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 a first draft, explain an unfamiliar concept, suggest ideas, or help investigate a problem. Then take the time to understand and verify what it gave you.

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.