Originally published on Naveed Ahmed Tech Blog https://blog.naveedkumbhar.com/the-conversation-that-changed-my-view-on-ai/.
I almost didn’t ask the question.
I had been carrying it around for months—quietly, the way you carry a worry you don’t want to say out loud because speaking it somehow makes it real.
We were at our annual company conference at the Marriott Hotel. Dinner was winding down, glasses were clinking, and people were mingling. I found myself standing
near my engineering manager with a drink in hand and a knot in my stomach that wouldn’t dissolve.
The conversations that truly matter in tech rarely happen during scheduled conference presentations. They happen in the hallways, between sessions, late in the
evening when people let their guard down.
I pulled my manager aside.
Me: “I need to ask you something I’ve been thinking about for a while.”
──────
## The Fear I Couldn’t Stop Thinking About
Over the past two years, I quietly watched AI start doing things I had spent a decade learning to do with my own hands. And it wasn’t small helper scripts—it was
the core of my daily work as a Senior DevOps Engineer:
• 🐧 Linux Commands: Muscle memory built over years of late-night production outages—now typed by AI in seconds.
• ☸️ Kubernetes YAML: Multi-container Pods, StatefulSets, Ingress, and NetworkPolicies I used to write from memory—now generated by describing what I need in plain
English.
• ⚙️ Ansible Playbooks: Hours of careful role structuring and idempotency testing—now drafted in a single prompt.
• 🏗️ Terraform Code: Complex AWS infrastructure modules I used to craft manually—now assembled faster than I can open an empty file.
I worked hard for 10 years to build those skills into my fingertips. The kind of tacit knowledge where you don’t think—you just type. That took years of midnight
pages, broken deployments, and hard-won scars.
And now I was looking at AI doing the exact same thing in seconds.
Worse: I was actively using it.
I was asking AI to write the code I used to write myself. Every time I accepted a completion, a small voice in the back of my mind whispered:
│ Am I losing something? Is this making me weaker?
So at that conference dinner, I finally looked at my manager and asked the question directly:
Me:
│ “Will AI replace the actual skillset I’ve spent 10 years building? I’m relying on it to write code I used to write by hand. Am I losing my real skills—or am I
just
│ being paranoid?”
──────
## What My Manager Said
My manager listened intently. He didn’t dismiss the worry. He didn’t offer a platitude like “AI is just a fad.”
He thought for a moment, looked at me, and said words that permanently rewired how I view my entire career:
Naveed Sanghera (Engineering Manager):
│ “Use AI as a tool. Do not 100% rely on it.”
│
│ “Think of yourself as an architect—you’re not replaced by your tools, you’re the one giving them direction. You are the one who commands AI to do your task. That
│ is the role.”
│
│ “Always check the work yourself afterwards. Cross-check manually when you have time. Understand what AI has suggested, and ask yourself:
│
│ What more can be improved?
│
│ That’s where your 10 years still lives. In that exact question.”
──────
## Why That Answer Hit Differently
I’ve read dozens of hot takes on AI and tech careers. Most are either dismissive (“AI will never replace real engineers”) or apocalyptic (“Everything will be
automated by next year”). Both feel dishonest.
What Naveed Sanghera said hit differently because it was grounded in engineering reality:
He didn’t promise that things would stay the same. He said: Your role is changing, and the way you engage with AI determines whether that change makes you stronger
or weaker.
The architect analogy was the key:
A master architect doesn’t lose their engineering genius because they use modern CAD software instead of a physical drafting board and pencil. The software doesn’t
understand structural integrity, wind loads, soil mechanics, or aesthetic harmony. It simply removes the mechanical friction between thought and blueprint.
AI does the exact same thing for software and infrastructure engineering:
│ The real skill was never memorizing kubectl flags.
│ The real skill is knowing which flags matter, in which production emergency, for which architectural reason. AI can generate the command syntax in seconds. Only
│ battle-tested experience knows when to run it—and when not to.
──────
## How I Actually Changed My Workflow After That Conversation
I stopped feeling guilty about using AI. I started using it deliberately. Here is what my day-to-day workflow looks like now:
### 1. I use AI for the first draft, never the final answer
When I need a Kubernetes manifest or a Terraform module, I let AI generate the initial scaffolding. Then I review every single line with trained eyes:
• Does this match our internal security baseline?
• Are resource requests and limits realistic for our node pool?
• Could this fail during a rolling node drain?
That rigorous review is where my 10 years of experience does its most valuable work.
### 2. I always verify manually—especially under incident pressure
This is the piece of Naveed Sanghera’s advice I treat as law. AI hallucinates with absolute confidence. It will suggest configurations that look correct in theory
but fail silently in our specific production environment. Manual verification is not optional—it is the job.
### 3. I treat “What could be improved?” as a non-negotiable question
AI gives you the average solution. Experience finds the resilient solution. After every AI-generated snippet, I ask:
• What edge case was missed?
• What happens if the downstream API returns HTTP 503 with a 2-second timeout?
• Is this stateful or idempotent?
That question is where your hard-earned knowledge creates irreplaceable leverage.
### 4. I test business logic myself, even when AI writes the tests
AI can generate unit test suites. But AI does not understand your company’s domain logic, compliance rules, or customer failure modes—only you do. You define what
“correct” looks like.
──────
## The Mindset Shift: From Threat to Leverage
The most valuable engineer in the AI era is not the one with the cleverest prompt.
It is the engineer who can evaluate what comes back with skeptical, trained eyes, catch the subtle failure modes, elevate the architecture, and take full
accountability for the outcome in production.
──────
## A Note to Anyone Carrying This Same Worry
If you’ve been carrying this anxiety quietly—the feeling that AI is replacing something you sacrificed years of nights and weekends to build—I want you to know you
are not alone.
The change is real. But the answer is neither to hide from AI nor to blindly surrender your brain to a prompt window.
You are not the person who types YAML. You are the architect who knows how systems fail, how traffic behaves under duress, and how to keep production alive.
AI cannot learn the intuition born from real production fires out of a training set. That intuition has to be lived.
And you’ve lived it. That knowledge isn’t worth less today—it is worth more than ever, because real human judgment is becoming the rarest asset in tech.
──────
Written by Naveed Ahmed https://naveedkumbhar.com — Lead DevOps Engineer @ DigitalOcean.
Original article published on my engineering blog https://blog.naveedkumbhar.com/the-conversation-that-changed-my-view-on-ai/.
Special gratitude to Naveed Sanghera for a corridor conversation that reframed a career.
──────
### Let’s Discuss:
• Have you felt that quiet guilt or worry when relying on AI to generate code you used to write by hand?
• How are you and your team balancing AI speed with maintaining deep foundational knowledge?
Drop your thoughts in the comments below—I read and reply to all of them.
──────