On Using Claude and Not Losing the Plot

The Speed Is Real

I use Claude Code. I use it daily. Things that would take an afternoon take an hour. Things that would take an hour take minutes. The iteration loop contracts to a degree that changes the nature of prototyping entirely.

This site was built with Claude assisting. The CV templates I use were refined with it. Parts of my embedded Rust project have scaffolding generated by it. I am not going to pretend otherwise.

But there is a distinction I think matters, and it is one I see people getting wrong in both directions.

The Trap

The obvious risk with AI-assisted development is that you stop learning. Claude writes the code, you ship the code, and six months later you cannot explain what it does or why it works. You become a prompt engineer with a GitHub profile full of code you do not understand.

This is a real risk. I have seen it in myself — the temptation to accept the first output, move on, and call it done. The velocity feels productive. But velocity without comprehension is not productivity. It is accumulating debt you cannot see until something breaks and you have no mental model to debug it.

What happens when Claude goes down? What happens when the output is subtly wrong and you do not have the understanding to catch it? These are not hypothetical questions. They are Tuesday.

How I Actually Use It

The way I use Claude is deliberate. For my Oxiflight project — an embedded Rust rewrite of Betaflight firmware — Claude generates stubs and phase outlines. I implement them. Claude writes documentation and test scaffolding. I write the driver code, the SPI register sequences, the filter implementations.

The reason is simple. If Claude writes the BMI270 gyro driver for me, I finish faster. But I do not learn why the chip needs a dummy byte on SPI reads, or how Embassy’s executor handles interrupt-driven task scheduling. Understanding is the point. The firmware is the proof that I understand.

For prototyping, iteration, and boilerplate — Claude is exceptional. For code I need to own, maintain, and debug at 3am — I write it myself, with Claude as a reference rather than an author.

Where It Goes Wrong

Claude is not perfect. The common failure modes I have noticed:

Default case assumptions. Claude often generates code that handles the happy path well but makes assumptions about edge cases that are not grounded in the actual codebase. It will add error handling for scenarios that cannot happen while missing the one that can.

False confidence in stale context. If the conversation is long or the codebase has changed since the context was loaded, Claude will confidently assert things about code that no longer exists. It does not know what it does not know.

Over-engineering. Ask for a simple function and you might get an abstraction layer, a trait hierarchy, and a configuration system. Sometimes a function is just a function.

That said, these are fixable. Review the output, spot the issue, explain the context, and the correction is usually immediate. The feedback loop is fast. The key is that you have to be capable of spotting the issue in the first place.

The Conservative Approach

For more complex or legacy work, I have started using a more conservative workflow. A CLAUDE.md file that instructs the tool to be cautious — plan before implementing, create checklists, require review before proceeding. This slows the iteration speed but reduces the rate of subtle errors that slip through in fast-moving sessions.

For greenfield prototyping, the default speed is fine. For production systems or firmware that controls a physical object, the conservative approach is not optional.

The Point

AI tools are not going away. Refusing to use them is not principled, it is slow. But using them without understanding what they produce is not efficient, it is reckless.

The line is somewhere in between, and it moves depending on what you are building. Know where yours is.