The buzz around AI-powered coding tools is hard to avoid, and I get asked about them a lot. Instead of continuing to repeat myself I figured it was time to write down exactly why I don’t use them, and why that decision isn’t about being for or against AI in some grand ideological sense. This is just a practical take based on how I work, what I value, and what actually helps me get things done.
The core issue is speed—or the lack of it. If AI tools helped me move faster, I’d consider them. But they don’t. The idea of having an AI assistant write code for me sounds nice. A little robot fixing bugs while I sip coffee? Sure. But it doesn’t work like that. Any code that goes into my projects has to meet a standard, and that means reviewing it line by line. I have to understand what it’s doing, why it’s doing it, and feel confident I can tweak it later. Otherwise, it’s a liability.
Reviewing someone else’s code already takes effort. Reviewing AI-generated code adds another layer of uncertainty. What looks clean on the surface might hide assumptions or shortcuts that blow up down the line. It’s not faster—it’s slower. You’re still the one who has to be accountable when that code misbehaves. The AI isn’t signing your contracts or taking the heat when a production bug hits.
Some people argue that AI is a great help when working with unfamiliar languages or frameworks. That’s not my experience. Learning new languages is one of the things I actually enjoy about software development. I didn’t need AI for that, and I wouldn’t want to skip the learning curve even if I could.
Others say AI is a productivity booster, a “multiplier” that lets them handle more complex tasks faster. But when you ask for real evidence, it’s usually just personal anecdotes. I suspect the gains come from cutting corners, not better workflows. Skimming AI code or skipping review altogether might feel like a time-saver, but it’s a risky tradeoff. That’s not a gamble I’m willing to take.
One question I get a lot is why I’m okay accepting open source contributions from other people, but not from AI. The short answer is: I’m not just looking for working code—I’m looking for collaboration. When people take the time to engage with my projects, report bugs, suggest features, or submit fixes, it sparks ideas. Their involvement improves the project beyond the code itself. That kind of back-and-forth adds value. Even if reviewing those contributions takes just as much effort, it’s worth it.
With AI, the dynamic is different. I’ve seen users submit quick, machine-generated change suggestions and as soon as I read them, something feels off, like a bad translation. The code works, maybe, but there’s no thought behind it. I usually ask questions about the odd parts. Those people almost never respond, because they didn’t write the code and can’t explain it. It just showed up in their editor. That’s not collaboration, it’s noise.
There’s also the comparison people like to make between AI tools and interns. In theory, your AI “helper” is like a junior dev who just needs guidance. In practice, it’s like working with someone who forgets everything you’ve ever taught them. Real interns learn. You spend time mentoring them, and they grow into independent contributors. AI doesn’t. Every prompt is a reset. Every mistake has to be caught again. You don’t build a relationship, and you don’t build trust.
For the kind of work I do—where quality matters, contracts are signed, and mistakes cost money—AI tools don’t save me time. They cost me time. That’s the simple truth of it. And unless the tools change in a very fundamental way, I don’t expect that truth to shift anytime soon.
