A year ago, if you'd told me an AI agent would write most of my code, I'd have been skeptical. Not because I doubted the technology, but because I'd spent 30 years getting good at writing code myself.
After building a full production app this way, the realization is simpler than I expected. Instructing an AI agent is essentially another programming language. The core loop has not changed: describe what you want in precise terms, the computer executes, you check the result and iterate. That has always been the job.
What is new is the feedback speed. I describe what I want. AI builds it. I review. What used to take a day takes a fraction of the time. Months in, I'm still impressed by it.
The shift on day two
The mindset shift came in the first week. My first day using Claude Code, I had it in my head that we would pair program. I'd write code, Claude would help review and test. By day two, I'd flipped it. I was wasting time dictating every implementation detail when my actual value was in the architecture and the decisions. I stopped writing code and started writing specs.
The uncomfortable part was letting go. After three decades as an IC, watching something else write the code felt strange. I've been hands-on-keys my entire career. This wasn't like leading a team of devs, where I could still drop into the editor and write the thing myself. I was disconnected from the part of the work that had defined me.
Free from writing code, my full attention went to the parts that separate good engineering from adequate: architecture and code quality. I could be more rigorous than I'd been with any human team, because I didn't have to manage the social cost of being demanding. Claude never complains.
Input determines output
AI tools take the blame for a lot of output problems that aren't necessarily a problem with the tool, but how it's being used.
AI agents are pattern-matching machines, and what they pattern-match against first is the code already in your project. An inconsistent, undisciplined codebase gets mirrored back to you. Vague instructions get vague results.
The same things that made engineers valuable before AI still make them valuable now. Knowing what good looks like. Being able to describe it. Spotting when something's off. Senior engineers who can do all three are getting the most out of it. Not because AI is easy, but because they have decades of standards to apply.
The Flash era vibes are back
I built Flash applications in the early 2000s, before anyone had written the rulebook on web development. No gatekeeping, no best practices, no rules. A lot more "what can I build just because I can?" Sandbox energy.
Claude Code didn't just make me faster. It made me remember why I love building software.
The cost of building software has dropped far enough that creative playtime is back. You can explore ideas you'd never pitch to a product team. You can build something niche just because it solves a problem you have.
What you've been training for
If you're a senior engineer still on the fence: your experience isn't a liability next to AI. It's the point. The feedback loop on judgment is faster now than it's ever been, which means the people with decades of knowing what good looks like are the ones getting the best output.
Getting fluent in directing AI agents makes everything you already know more valuable, not less.