Over the last year, I’ve been forcing myself out of old habits. In startups, we say: what got us here won’t get us there. I’ve started to feel that in how I build software. The patterns that served me for 20 years: DRY Code, API-first designs. etc, still work, but they’re also limiting. Especially with AI.

Seasoned developers get to a kind of “steady state”. We know what works for our brains, our teams, and our preferred tools. We’ve figured out how to deliver. That confidence is earned, but it can also lock us in. I’ve noticed I default to the same patterns, the same IDE, the same plugins. If I’m not careful, I’m coding like it’s five years ago. With AI in the mix, that’s a real risk. The hard part hasn’t been learning new tools—it’s been making space to question the old ones.

What works, but can be improved with a pattern shift.

I’ve also seen this play out with teams I’ve worked with. Recently, I was helping a group of developers at a company in distress. In situations like that, I try to be careful—like a doctor, I aim to do no harm. I’m not there to overhaul everything. So I asked a few simple, low-friction questions: “Hey, have you heard of vibe coding?” and “How much AI do you have in your IDE?” These questions don’t provoke stress because they’re safe and easy to use in any coaching conversation.

Behavior change in teams requires a supportive rather than dictatorial approach.

The responses felt familiar. “I use what I know.” “I’ve got enough AI in my process.” What I heard was: I’m good…let’s move on. That was me, too, not long ago.

It took me a while to process both my own habits and what I was hearing from others. I think it comes down to the cost of investment. We’ve spent years getting good. We’ve worked hard to build reliable processes. And investment, a real investment, takes time, focus, and risk. We all have deliverables. Changing how we work is a risk in itself.

I recently read Thinking, Fast and Slow, and it helped something click. I’ve spent years shaping my process into a kind of rapid-response mode. I need my patterns hardwired. I need repeatability, so I can move fast under pressure. If I have to rewire every decision path, I lose speed.

That might be why I still reach for older libraries. Why I default to Axios instead of using native Node.js fetch. It’s not that the old way is better; it’s that I’ve already paid the cost to get fast with it. Re-investing takes more than just time; it takes breaking working habits.

My final thought was this: ideas have a cost. We all have personal budgets, limited attention spans, finite energy, and too little time. We’re all resource-limited in some way. So we pick and choose where to invest. What to double down on. What to leave alone. It’s not laziness. It’s become a strategy, even if it’s unconscious.

I keep going back to the idea that ignoring a productivity gain is not a strength. I am amazed at how often seasoned coders and builders discount or ignore new tools or approaches.

All of this led to a question I got from a few developers on LinkedIn:
“What’s your personal tooling approach to AI?. “How are you getting these personal gains. They sounds like LI AI hype..”

They were hitting a ceiling. Most of them were using Claude or OpenAI. And like me, they’d made early gains, with better autocomplete and faster prototyping, but it had plateaued. Some weren’t sure there was more to be gained.