MY FIRST MONTH WITH CLAUDE CODE: AN INFRASTRUCTURE ENGINEER'S HONEST TAKE ON AI-ASSISTED DEVELOPMENT_
I've spent 19 years building infrastructure, mostly in PowerShell and Terraform. Now I'm exploring AI-assisted development with Claude Code. Here's what's working, what's not, and what this means for infrastructure engineers.
Why now, after 19 years
I didn't pick this up because of hype. I picked it up because I kept noticing a gap.
Infrastructure engineers are increasingly expected to write software, not just configure systems. The line between "ops" and "dev" has been blurring for years. I can write a solid Terraform module or a PowerShell automation pipeline in my sleep. But when a project needs a Python service, a REST API, or an event-driven workflow — I slow down. Not because I can't do it, but because I'm not fluent. I know enough to be dangerous and not enough to be fast.
That gap costs time. And time is the one thing I don't have more of.
So when Claude Code started getting serious attention from engineers I respect, I decided to actually use it — not just read about it. I gave myself a month of real work, not toy projects. Here's what I found.
What I actually built
I wasn't doing hello-world demos. I was building things I needed.
The main project was an agent runtime on AWS Bedrock AgentCore — a persistent AI assistant with long-term memory, multi-agent routing, and a set of custom skills. Think: a system where different specialist agents handle different domains (infrastructure, code review, brand content, security scanning), and a central orchestrator routes work between them.
That's not a simple project. It involves Python, CDK, IAM policies, Lambda, S3, Secrets Manager, and a fair amount of custom protocol work. It also involves designing agent behavior, writing governance rules, and building skills that agents can invoke — things like deployment pipelines, notification systems, and memory management.
I also built automation workflows: a Telegram notification skill, a remote invocation skill for cross-agent communication, a vulnerability scanner, and a deployment gate system with approval tiers.
None of this was trivial. And Claude Code was involved in most of it.
Where it actually accelerates you
The honest answer: boilerplate and pattern repetition.
If I need a Python class that follows a pattern I've already established, Claude Code produces it in seconds. If I need a CDK construct that looks like the three I already wrote, it writes the fourth one. If I need a Bash script that does something I've done before in PowerShell, it translates the logic without me having to look up Python subprocess syntax for the fifteenth time.
That's real. That's not nothing. I'd estimate it cuts my time on scaffolding and repetitive implementation by 60–70%.
It's also genuinely good at explaining unfamiliar territory. When I was working with the Bedrock AgentCore SDK — which is new enough that documentation is sparse — Claude Code helped me understand the API surface, identify the right method signatures, and reason through the session management model. It's like having a peer who's read the docs more recently than you have.
Error messages are another win. I paste a stack trace, it usually identifies the root cause correctly on the first try. Not always. But often enough that it's my first move now instead of my third.
Where you still need to actually know things
Here's where I'll push back on the hype.
Complex infrastructure state management is not something you can hand off to an AI and walk away from. Terraform state drift, dependency ordering in CDK, IAM policy evaluation logic — these require you to understand what's actually happening in the system. Claude Code can write the code. It cannot tell you whether the code is safe to apply against your production state.
I learned this the hard way. Early on, I let Claude Code generate a CDK stack modification without fully reviewing the resource replacement logic. It was technically correct code. It would have replaced a stateful resource I didn't want replaced. I caught it in review. But I caught it because I knew what to look for — not because the AI flagged it.
The same applies to IAM. Claude Code will write you a policy. It will even write you a reasonably least-privilege policy if you ask. But it doesn't know your threat model. It doesn't know which principals are over-permissioned in your account already. It doesn't know that the role it's attaching that policy to has a trust relationship you set up six months ago that you've half-forgotten about.
That context lives in your head. Or it should.
The other failure mode I hit: large, interconnected codebases. When a project gets complex enough — multiple agents, shared libraries, cross-cutting concerns — Claude Code starts losing the thread. It gives you code that's locally correct but globally inconsistent. It'll introduce a pattern in one file that contradicts the pattern in another. You have to be the one holding the architecture in your head and catching the drift.
How my day-to-day has actually changed
I write less boilerplate. I spend more time reviewing.
That sounds like a good trade. It mostly is. But it requires a discipline shift. When you write every line yourself, you're forced to think through it. When an AI writes it, you have to consciously choose to think through it during review — because the path of least resistance is to skim it and move on.
I've started treating AI-generated code the way I treat code from a junior engineer I trust but haven't fully calibrated yet. I read it. I ask questions about it. I push back when something feels off. Sometimes I'm wrong and the code is fine. Sometimes I'm right and there's a subtle issue that would have cost me an hour later.
The other change: I'm writing more. Not just code — documentation, specs, governance rules, agent behavior definitions. Claude Code is genuinely useful for drafting structured text. I describe what I want, it produces a first draft, I edit it into shape. That's faster than starting from a blank page.
What skills still matter
Deep understanding of the systems you're building on. Full stop.
If you don't understand how Terraform manages state, Claude Code will not save you from a botched apply. If you don't understand IAM evaluation logic, you will ship insecure policies. If you don't understand how your cloud provider handles resource dependencies, you will hit ordering errors that look mysterious until they don't.
Debugging still requires you. When something fails in a way that's genuinely novel — not a pattern the AI has seen before — you're on your own. The AI will give you plausible-sounding suggestions. Some will be right. Some will be confidently wrong. You need the judgment to tell the difference.
Architecture judgment still requires you. Claude Code will implement whatever architecture you describe. It will not tell you that your architecture is wrong. It will not tell you that you're solving the wrong problem. That's your job.
What might matter less going forward: syntax memorization, boilerplate writing, looking up standard library methods. The things that used to slow you down when switching languages or frameworks. Those are increasingly table stakes that the AI handles.
The mental model I've landed on
Force multiplier is the right frame, but it needs a caveat.
A force multiplier amplifies what you bring to it. If you bring deep understanding, good judgment, and clear thinking — the AI makes you significantly faster. If you bring shallow understanding and hope the AI fills the gaps — you will ship bugs with more confidence than before. That's worse, not better.
The engineers I've seen struggle with AI tools are the ones treating it as a replacement for understanding. The ones I've seen thrive are the ones using it to move faster on the things they already know how to do, while staying rigorous about the things that require judgment.
After 19 years, I have a lot of accumulated judgment about infrastructure. That judgment is what makes the AI useful to me. Without it, I'd be generating plausible-looking code I couldn't evaluate.
That's the honest take. It's a good tool. It's not a shortcut past the hard work of actually knowing your domain.
One month in
I'm not going back to working without it. The productivity gain on the right tasks is real enough that it would feel like giving up a power tool.
But I'm also not under any illusions. The 19 years still matter. Maybe more than before — because now the bottleneck isn't writing code, it's knowing what code to write and whether the code you got is actually correct.
If you're an infrastructure engineer sitting on the fence about this: try it on something real. Not a tutorial. A project you actually need to finish. You'll find out quickly where it helps and where you're still the one who has to know things.
That's probably the most useful thing I can tell you.
Joe Gajeckyj is a founder and infrastructure engineer with 19 years in IT, currently building AI-assisted development workflows at JRGWorkshop.