I’ve been building infrastructure for 10 years. I’ve watched Kubernetes go from exotic to default. I’ve watched Terraform become the assumed baseline for any cloud engagement. I’ve watched CI/CD go from a competitive advantage to table stakes.
Each of these transitions produced the same reaction in the engineering community: anxiety, then adaptation, then a new normal.
AI feels different in scale. But I don’t think it’s different in kind.
The Question People Are Asking
Most conversations I hear about AI and engineering center on one question: “Will AI replace engineers?”
I understand why people ask it. GitHub Copilot writes code. Claude explains architecture. AI can now scaffold a Terraform module, write a migration script, generate a runbook, and identify misconfigured IAM policies — all things I’ve spent years learning to do.
But I think this question is the wrong one.
The Question That Actually Matters
The right question is: “What does good engineering look like when AI handles the mechanical parts?”
Because here’s what AI can’t do — at least not yet, and maybe not for a long time:
Understand what the business actually needs. A migration project doesn’t start with a Terraform plan. It starts with understanding why the migration is happening, what the real constraints are, what failure looks like for this particular organization, and what “success” means beyond the technical deliverables.
Build trust with humans who are scared. I’ve sat with application teams who’ve never done a zero-downtime migration, who are terrified of breaking their service, and who need to be shown — not told — that the process is safe. That’s not a prompt. That’s a relationship.
Make judgment calls under ambiguity. Every complex migration reaches a moment where the runbook doesn’t cover what’s happening. You’re in a cutover window, something unexpected is occurring, and you have to decide: push through or roll back. That decision requires judgment built from experience, not just pattern matching.
Own outcomes. AI produces outputs. Engineers — the good ones — own outcomes. The distinction matters enormously.
What I’ve Changed
I use AI tools in my work now. Claude helps me draft architecture documentation faster. Copilot writes boilerplate I don’t want to write. I use it to think through edge cases and poke holes in my own reasoning.
What I’ve found is that AI makes me better at the parts of my job that don’t disappear — the judgment parts, the communication parts, the ownership parts — by freeing up cognitive bandwidth from the mechanical parts.
The engineers I see thriving are the ones who’ve embraced the tool and redirected their energy toward the things it can’t replace.
The Honest Part
I don’t know what engineering looks like in 10 years. Neither does anyone else.
What I do know is that the response to uncertainty isn’t to pretend it isn’t there. It’s to be the engineer who’s thinking about these questions honestly, adapting early, and building the human skills that compound over time — rather than the purely mechanical skills that are getting automated.
The engineer who isn’t afraid isn’t the one who thinks AI is overhyped. It’s the one who’s already figured out how to use it, thinks clearly about what it can’t do, and is building toward that.