For the best part of ten years I have described myself, more or less unprompted, as the architect who never really left engineering. In interviews, in team introductions, I used a throwaway line to put people at ease. I still deploy infrastructure, I still know my way around a terminal, I'm not one of those architects who draws boxes and disappears. I said it often enough that I believed it.
Then a landing zone project needed an extra pair of hands inside the IDE rather than inside a whiteboard, and the person available was me. Three months later we had a working AWS landing zone. I also had a new relationship with large language models, and a less flattering picture of how far I had actually drifted. This is the story of getting a little of that back.
Extra hands, not extra opinions
The ask itself was ordinary. A landing zone build needed more engineering capacity than the team had, and I had the AWS background and, on paper, the time. Nobody asked me to advise. Nobody asked me to review. They asked me to build: control tower guardrails, account vending, and the unglamorous plumbing that makes a multi-account AWS estate behave itself. I said yes before I'd properly registered what that meant for someone who spends most working days in diagrams rather than in an IDE.
Within the first few days, I reached for an AI coding assistant, the way I imagine most engineers now do. It felt like a shortcut back to a fluency I had assumed, without much evidence, that I still had.
Amazon Q, and learning to make it plan before it types
Amazon Q was the natural starting point, already available, already integrated, already the approved option. My first instinct was to describe what I wanted and let it write, which went about as well as it usually does. It produced functional-looking code that solved a slightly different problem to the one I actually had.
What worked better was refusing to let it type until it had planned, and Amazon Q will do this if you ask it to. Describe the approach first, list the files it intends to touch, flag the assumptions it's making, and only then produce code. A fair amount of that discipline can be pushed into a rules file. Coding conventions, naming patterns, the fact that this repository uses Terraform modules one way and not another, all belong there. What I couldn't do, at least not with the setup I had, was instruct it to go and find context it didn't already have. It worked only with what was already in its window, and nothing more. If the relevant file wasn't open, wasn't referenced, wasn't already part of the conversation, Amazon Q simply didn't know it existed. And it wouldn't tell you that with any real confidence, it would guess instead.
That produced a specific, uncomfortable kind of tunnel vision. The assistant would confidently extend a pattern from the one file it could see, while three other files in the same module quietly contradicted it. Catching that requires the thing I was supposed to have, enough hands-on familiarity with the codebase to notice when something felt off before it ran. More than once, I didn't notice.
That's not a tooling problem. That's a skill that had gone soft.
Kiro, and a tip worth stealing
Kiro helped, a little. Its planning step is more structured out of the box: you get an actual spec and task breakdown before any code appears. That's different from a plan you have to explicitly request and hope gets followed. The genuinely useful habit it taught me was this: never accept the first version of that plan. In every case I used it, the first draft of a spec contained an assumption I hadn't stated. Sometimes it was a small factual error about how a service actually behaved. Reading it critically and pushing back before implementation started saved more time than the tool itself ever did. Context awareness was a step better than what I'd had before. It still wasn't the change that mattered most.
Where Claude actually moved the needle
The real improvement came with Claude. Plan mode is built in and genuinely good, rather than something I had to coax into existing. It's the single biggest change in how I now work with an AI coding assistant. I used it on almost everything. I'd describe the change, let it read enough surrounding code to propose an approach, then argue with the plan before a single line got written. Context awareness kept improving with each tool I moved through. By this point it felt less like I was fighting the assistant and more like I was directing it.
What didn't improve, no matter which tool I was using, was my own tendency towards tunnel vision once a plan looked reasonable. A confident, well-structured plan is persuasive. It is also, occasionally, wrong in a way that only someone with real hands-on familiarity with the domain would catch. That gap didn't close as the tools got better. If anything it became more visible, because the tools got good enough that the remaining failures were almost entirely mine rather than theirs.
One smaller observation is the kind you only notice by watching closely over time. The less capable a model was, the more confidently it guessed at CLI flags and SDK method signatures it hadn't actually checked. The stronger models reached for documentation sooner and admitted uncertainty instead of inventing a plausible-looking API. That's a meaningful difference in a domain like infrastructure, where a plausible but wrong AWS CLI command doesn't fail loudly. It fails quietly, three steps later.
Infrastructure as code had quietly become software engineering while I wasn't looking
The bigger realisation had nothing to do with any specific tool. Infrastructure as code had turned into actual software engineering while I was mostly in diagrams: testing, modularity, dependency management, code review discipline, the works. I knew this in theory. I hadn't felt it in my hands for a long time.
It also taught me where AI assistants are the wrong tool, which is a less popular thing to say out loud than where they excel. At one point I asked one to reorder a list of resource names alphabetically. Instead of a clean reorder, it removed resources from the file and added others that had no reason to be there. If your only tool is a hammer, everything starts to look like a nail. After a few weeks of leaning on an AI assistant for nearly everything, I noticed the pattern in myself. I'd started reaching for it on problems that a sort command or a regular expression would solve faster, with zero ambiguity. Knowing when not to use the powerful new tool turned out to matter almost as much as learning how to use it well.
The click that wasn't just a click
The clearest proof that something had actually shifted came a few weeks later, back in an architecture conversation. I was listening to another architect wave off a development concern about deploying a service, dismissed with "just click the button." My first, genuine reaction was that it wasn't just a click. That button triggered a change set across accounts that needed sequencing, validation, and a rollback plan if it went sideways. Then, a beat later, came the second reaction. I would have said exactly that sentence myself, three months ago.
I'm not going to pretend three months hands-on turns an architect back into an engineer. It doesn't, and I'd be doing the actual engineers on my teams a disservice if I claimed otherwise. But I got some of the touch back, enough to know what I'd been missing. And enough to be more careful with what I say from the other side of the table.
Top comments (0)