When I talk with software developers about AI, resistance comes up often. And most of the time, the resistance isn’t really about the tools.
The Pride in the Craft
Some developers identify deeply with the act of writing code. The craft of it: clean syntax, curly braces in the right spots, tabs versus spaces, semicolons placed with intention. That’s what they do. That’s who they are. When AI starts producing the code for them, it can feel like something is being taken away.
I understand that. I’ve given plenty of talks on clean code and software craftsmanship. People who’ve seen those talks sometimes ask me: “You don’t write code anymore? You just let AI do it all?”
I never wrote code because it made me feel smart, or because the act itself was the point. My lens was always solving a human problem, and solving it well. I cared about clean code because if someone ever looked under the hood, I wanted them to find something tidy. Whether I wrote every line myself was never what mattered.
That distinction is important.
Carburetors and Fuel Injection
I remember cars before fuel injection. Carburetors needed constant attention: cleaning, adjusting, tuning. They generated real costs, both in money and in time. When fuel injection arrived, most of that went away. More reliable, less maintenance, lower cost of ownership.
Did carburetors disappear entirely? No. There are still people who want them. They’ll seek out carbureted bikes and cars, spend their weekends tuning and adjusting. They get satisfaction from it. Some even get better performance through careful tweaking. That’s fine.
But it’s a niche pursuit now. For someone who just needs a reliable vehicle to commute, a carburetor adds friction without adding value. It makes you slower, not faster.
I think manual, line-by-line coding is heading the same direction. It won’t disappear. There will always be contexts where deep, hands-on control matters, and developers who find genuine satisfaction in that work. But for most software being built today, it’s like fine-tuning a carburetor for bumper-to-bumper traffic. The optimization doesn’t match the situation.
Looking at the Pedals
Driving works as another lens here.
When you’re learning to drive, you watch your feet on the pedals. You track every input. You glance down constantly. You’re aware of a few feet of pavement in front of you, and not much else.
As you get comfortable, you start looking further ahead. Eventually you’re barely thinking about the pedals at all. You’re looking at the road, the intersections ahead, where you’re going.
Writing code line by line is like watching the pedals. If you’re also prompting AI to write code but watching every line it produces because you don’t trust what comes out, you’re still watching the pedals. You won’t go any faster.
To move faster, you have to shift your focus from the syntax to the destination. What story do we want our customers to tell? What problem are we solving and how well? Those become the things you’re looking at, not whether a semicolon landed in the right place (But for that to work, we need to trust that it will happen.)
The Motorcycle Racing Lesson
Watch MotoGP or World SuperBike, or really any motorcycle racing. Pay close attention to how early the riders begin preparing for a corner. They don’t wait until they’re at the apex to shift their body. They start moving well before. They already have their weight shifted, their line chosen, their braking distance calculated, before they’re anywhere near the turn.
At 180 to 200 miles per hour, the margin for error is zero if you wait too long.
Building software with AI feels similar. You can move much faster now. That’s real. But moving faster means you need to develop new instincts about when to slow down, when a direction shift is coming, and how early you need to start preparing.
If you’re deep in a sprint moving quickly with AI and the requirements shift, the real question is: how long have we been going the wrong way, and how expensive is it to correct? Like the motorcycle racer watching the apex approaching at speed, the longer you wait to react, the fewer good options you have.
What Speed Requires
Moving fast with AI requires practices and signals that help you course-correct early.
That means clear intent at the start. Good test coverage so you know quickly when something’s off. Regular check-ins with stakeholders, not at the end of a long sprint, but along the way. It means designing the work so that when you’re moving fast, you’re also getting early feedback on whether you’re headed where you think you are.
And it means being diligent to do the work necessary to trust the tools enough to look up from the pedals.
The identity shift required here is real. Craftsmanship still matters. What’s changing is which craft matters most. The developers who thrive with AI will be the ones who redirect their skill from writing code to guiding it: setting direction, reading signals, and knowing when to lean into the corner before they get there.
Leave a Reply