The Case Against AI Coding Assistants: Why Writing Code by Hand Still Matters

The promise of AI coding assistants is seductive: faster development, less tedious work, and more time for "higher-level thinking." But what happens when these tools start to erode the very skills that make us effective software engineers?

I discovered this the hard way. After my third attempt with Claude Code, I found myself in a familiar spiral of depression and lethargy. My eyes darted between the AI's output and my phone, asking myself: "What's the point of it all?" LLMs can generate decent-ish and correct-ish looking code while I have more time to do what? Doomscroll?

This pattern repeated itself three times. Each attempt with Claude Code lasted 2-3 weeks before I deleted it, and each time I rediscovered the joy of coding. Yes, coding is not software engineering, but for me, it is a fun and essential part of it.

The Problem Space Problem

To be effective at software engineering, you must be familiar with the problem space, and this requires thinking and wrestling with the problem. You can't truly know the pain of using an API by just reading its documentation or implementation. You have to use it to experience it.

The act of writing code, despite being slower, was a way for me to wrestle with the problem space, a way for me to find out that my initial ideas didn't work, a way for thinking. Vibe coding interfered with that.

"If you're thinking without writing, you only think you're thinking." – Leslie Lamport

The Correctness Conundrum

The other major part of the job is to ensure correctness. For me, it is much harder to verify the correctness of code I didn't write compared to code I wrote. The process of writing code helps internalize the context and is easier for my brain to think deeply about it.

If I outsource this to an LLM, I skip over the process of internalizing the problem domain and I can't be certain that the generated code is correct.

The Dopamine Trap

By design, vibe coding has an addictive nature to it. You write some instructions, and code that looks correct is generated. Bam! Dopamine hit! If the code isn't correct, then it's just one prompt away from being correct, right?

Vibe coding also has the profound effect of turning my brain off and passively accepting changes. When it is time to use my brain, the inertia is much harder to overcome and it is easy to choose the lazy way out.

At my lowest point, I even asked it to do a find-and-replace in a file. Something that takes a few seconds, now took minutes and a network call.

Even if I generate a 1,000 line PR in 30 minutes, I still need to understand and review it. Since I am responsible for the code I ship, this makes me the bottleneck.

Tools That Shape Thought

The common view of vibe coding is that it is neither good nor bad, it is a tool. But tools shape your workflow and your thought process, and if a tool prevents you from thinking deeply, I don't think it is a good tool.

If you are a knowledge worker, your core competency is your ability to think, and if a tool interferes with that, be afraid, be very afraid.

A Controlled Approach

Now, I would be lying if I said I didn't use LLMs to generate code. I still use Claude, but I do so in a more controlled manner. I copy-paste files that I think are necessary to provide the context, and then I copy-paste code and ask it to make changes to it or write tests for it.

This friction has several benefits:

• I can't make changes that span multiple files, this means the generated diff isn't too large
• If I have to manually change other files I know how the code fits in
• Manually giving Claude the context forces me to be familiar with the codebase myself, rather than tell it to just "cook"
• It turns code generation from a passive action to a deliberate thoughtful action
• It also keeps my brain engaged and active, which means I can still enter the flow state

I have found this to be the best of both worlds and a way to preserve my happiness at work.

The Happiness Equation

Ultimately, life is too short to not optimize for happiness. Maybe (a big maybe) generating entire features would make me more productive, but if it causes existential dread and makes me depressed, I don't see it being productive in the long run.

Maybe you relate to some of the feelings. Maybe you don't. But don't be afraid to choose differently.

The question isn't whether AI coding assistants are "good" or "bad." The question is: what kind of developer do you want to be? One who thinks deeply and wrestles with problems, or one who passively accepts whatever the machine generates?

For me, the answer is clear. I am happier writing code by hand.