The week that changed how I work forever
Few weeks ago my CTO handed me a refactoring plan and a Claude account. The ask was simple: investigate whether AI-assisted development was actually viable for our codebase. This refactoring plan, put together by an external consultant, promised 66% performance improvements, everything prompt-driven. Take a week, see what you can actually do with it.
I spent two days going down the rabbit hole. By the end of it I was messaging him at midnight.
I’ve been writing backend code for twenty years. PHP mostly, then the full stack that comes with running distributed systems: Kafka, Postgres, event-driven architectures, the works. Twenty years of building instincts: what breaks under load, where the edge cases hide, how to read a stack trace at 3am and know immediately which layer is lying.
Those instincts are real. They took a long time to build. And some of them are genuinely useful when working with AI. But some of them were in the way, and I didn’t see it coming.
What twenty years prepared me for
The thing AI can’t give you is domain knowledge. Not the Wikipedia kind, the tribal kind. The knowledge that one specific provider returns availability data in a format that’s technically valid XML but will silently truncate results if you don’t handle a specific edge case that isn’t documented anywhere. The knowledge that a certain type of error at 2am on a Friday before a long weekend is almost always a timeout cascade, not an actual bug.
That knowledge is a filter. When an AI-assisted refactoring produces code that looks clean and passes tests, experience is what tells you “this hasn’t been tested against an unexpected scenario that only surfaces in production with real data.” The model can’t know that. You have to.
Systems thinking is the other thing. Knowing that a 200ms improvement in one place can create a bottleneck three services downstream. Knowing what to measure and why. Knowing the difference between a benchmark and a production load. None of that gets replaced.
The shift
At some point during those two days something cracked open.
I wasn’t just moving faster. I was thinking differently. Problems I had been carrying around for months, not because I didn’t know how to solve them but because solving them felt expensive, suddenly felt tractable. The cost of trying something had dropped so far that the calculation changed completely.
There’s a specific moment I keep coming back to. I described a tricky piece of logic out loud, the kind of thing I would normally sit with for a while before touching, and watched a working draft appear in seconds. Not perfect. But good enough to react to, which is a completely different starting point than a blank file.
I realized I had spent twenty years optimizing for writing code. Building the speed, the pattern recognition, the muscle memory. And those skills still matter. But the constraint had shifted. The bottleneck was no longer writing. It was thinking clearly enough to describe what I actually wanted.
That’s not a small change. That’s the whole job, reorganized from scratch.
The first day I kept reaching for the keyboard out of habit. Second day less so. By the end I was moving faster than I had in years, and the thing slowing me down was no longer “how do I implement this” but “do I actually understand what I want well enough to say it out loud.”
The other thing
The plan that started all this was, honestly, not very good. The performance numbers were speculative, the approach ignored a lot of domain complexity, and some of the suggestions would have caused real problems in production. I told him that.
But it put a Claude account in my hands. And I never really stopped.
Sometimes the wrong plan is the right catalyst.