Remember the software craftsmanship movement? I used to walk around with those green “Clean Code” wristbands. Those were the days. But trying to hang on to a world that’s no longer there is futile. You and your senior engineers ought to come to terms with the new world. Yeah, we’re talking about AI again.

The Old Way

I feel like I need to “prove” I’m one of those who legitimately care about code. Even though I no longer write code for a living, I toiled over it for decades. Here in my office, I’ve got books autographed by Kent Beck and Uncle Bob. Half of the Agile Manifesto authors followed me on Ye Olde Twitter. I ran TDD workshops.

But just as we learned to trust compilers rather than look at machine code, embraced garbage collection instead of manually managing memory, and so on, it’s time to face the truth. The world has changed. I see it in the IDEs. I feel it in the PRs. I smell it in the sprint planning. Much that once was is lost. (Please tell me you get this reference.)

You, dear reader, should make sure that you and your team aren’t dragging your feet, trying to revive what’s already gone. Don’t be a luddAIte.

Confusing Means and Ends

I’ve recently come across several cases with clients where some of the senior engineers were, partly or wholly, opposed to coding with AI. For them, things were binary. Either you were coding it yourself and producing high-quality results, or AI was involved and letting slop pile up. No in-between, no grey zone.

I think that this stems from mixing up why you’re writing code in the first place. Truth is, the business is interested in what the code enables. Crafting it carefully was our best way to achieve that reliably. It wasn’t the objective itself.

Not All is Lost

You’ll see that many of these highly esteemed people I mentioned earlier have realized that coding with AI isn’t necessarily a bad thing. In fact, some are saying it’s more fun than they’ve had in decades. The choices aren’t no-AI or slop.

The best teams I’m seeing are working hard on harnessing these tools to do things previously impossible. It’s not a necessity that your coding agents have to produce low-quality code. You can codify clean code and SOLID principles, for example.

The code doesn’t have to be buggy. I came across a principal engineer complaining about bugs in a project another was working on. She was actually bemoaning the fact that a mammoth feature was completed in weeks as opposed to quarters, but also had some bugs. How many bugs would the team have produced in a quarter of coding this manually?

And, we can actually do things no one has done before. If you care about quality, it’s not easier than ever before to create all sorts of testing suites, quickly and without hassle.

I, for one, urge my clients to welcome our new AI overlords. Or, at least, understand that there’s a lot of benefit here. You can create good code faster. As a senior engineer, you can focus more on architecture and higher-impact decisions, upping your own value. Yes, we’ll be spending less time arguing over the perfect name for an interface. I’m not sure that’s really what matters.