I am writing this from the cockpit of a sailboat somewhere off the Norwegian coast. Laptop open, sails up, Garmin chartplotter to my left. Starlink doing its thing.

A few months ago I wrote about how vibe coding is a faster way to make expensive mistakes. That post resonated — probably because it was honest about something the hype cycle was glossing over.

But I want to go further now. Because I have kept building — from offices, from airports, and apparently from boats. And what I have learned since is more nuanced than "AI coding is dangerous."

The truth is: Claude Code is genuinely useful in production. And it is also genuinely risky in ways that most tutorials do not cover. Here is what I actually found.

First, what "production" means to me

I am a solo founder. I build and ship real products — FollowTheSun, Worth Wearing, oklo — products that real users interact with, that have real data, and that need to keep working when I am not watching. Including when I am on a boat with no one else on call.

That context matters. A prototype you demo once has a very different bar than an app that processes bookings, stores user data, or needs to stay live while you sleep. When I say production, I mean the latter.

What Claude Code is genuinely good at

Let me start with the honest positives, because there are real ones.

  • Speed on greenfield work. Starting a new feature from scratch? Claude Code is remarkably fast at getting you to a working first draft.
  • Boilerplate and repetition. CRUD operations, API integrations, form validation, test scaffolding — Claude handles these cleanly. This is time you get back.
  • Explaining unfamiliar code. I use it constantly to understand libraries I have not used before. It is a remarkably good documentation reader and synthesizer.
  • Debugging with context. Full error, relevant component, clear description — Claude Code's debugging suggestions are accurate more often than not.

Where it breaks in production

Now the part that matters more.

  • It does not know what it does not know. Claude Code will confidently generate code that looks right but makes subtle architectural decisions you did not ask for — decisions that create technical debt you will not notice until much later.
  • Security is not a default concern. I have caught generated code with exposed API keys in client-side logic, missing input sanitisation, and overly permissive database queries. None were obvious at first glance. All would have been serious in production.
  • State management gets messy fast. For complex state — multi-step flows, real-time updates, optimistic UI — the AI-generated code tends to solve the immediate case and create subtle edge cases that only surface when real users do unexpected things.
  • It has no memory of why decisions were made. Human developers leave comments, commit messages, architecture notes. AI-generated code just exists. When something breaks six weeks later, there is no trail.

The workflow that actually works

After a lot of trial and error — some of it done at sea — here is how I now use Claude Code on real projects.

I stay the architect. Claude implements. I define the structure, the data model, the key interfaces before I start prompting. The clearer the spec, the less cleanup afterward.

I review everything at the boundary. Any code that touches authentication, payments, data storage, or external APIs gets a proper read before it goes anywhere near production. Not a skim — a real review. Non-negotiable.

I write the tests first. Describing what the code needs to do in test form forces me to think clearly about edge cases before the AI generates anything.

I commit with intention. Every meaningful chunk of AI-generated code gets a commit message that explains the decision, not just the change. That trail has saved me more than once.

The honest summary

Claude Code has made me meaningfully faster. Not by removing the need to think — by removing the need to type out the thinking I have already done.

The fact that I can ship production code from a boat in the middle of the ocean is not the point. The point is that the workflow is robust enough that location does not matter. That only happens when the foundations are solid.

The builders who are struggling with AI coding tools are mostly trying to skip the thinking part. That is where the expensive mistakes come from.

The builders who are thriving have learned to stay in the seat as the engineer, use AI as the implementation layer, and be ruthless about what they review before it ships.

That balance is learnable. It is also exactly the kind of thing that separates a useful AI-assisted codebase from one that quietly accumulates risk.

If you are building something that needs to work — really work, in production, for real users — and you want a second pair of eyes on how you are using these tools, that is exactly the kind of work I take on. Get in touch.