I've spent a lot of time lately thinking about the difference between software that looks like progress and software that's actually built to last.
Part of that came from watching how AI tends to behave when the assignment is too open.
For a while, I was doing what a lot of us do. I'd describe the kind of application I wanted and let the AI start building. I might guide the process. I might push it toward a certain look or workflow. I might know that I wanted a clean workspace or a certain kind of navigation or a particular feel to the interface. But underneath all that, I was still leaving a lot of the rules open.
The AI filled that vacuum exactly the way AI tends to do.
It improvised.
It built layouts. It adjusted spacing. It created little one-off behaviors. It solved interface problems one by one. And because the results were visible, it felt productive. Sometimes it even felt exciting. You could watch the thing taking shape.
The problem was that I was spending too much time tuning those local decisions and not enough time building the mechanics that actually mattered.
That's when the sailing metaphor clicked for me.
AI is very good at helping you build the software equivalent of a daysailer. It can get you something that floats, something that looks appealing, something that will take you around the bay on a nice day.
And sometimes that's enough.
But if what you really need is a blue water product, something that can survive change, scale over time, and stay coherent as the work grows, then you can't let the AI make up the rules.
You have to decide what kind of vessel you're building before you hand over the work.
That was the real shift for me.
The breakthrough wasn't some magic prompt. It was deciding that the AI didn't get to invent the standards as it went. It had to work inside a system on purpose. If something needed to go outside that system, that wasn't supposed to happen quietly. That was supposed to be a deliberate decision.
Once I started thinking that way, a lot of things got clearer.
I could see that some of what had looked like progress was really drift. I could see that some of what felt like helpful speed was just postponed cleanup. I could see that the problem wasn't always that the AI was writing bad code. A lot of the time, the deeper problem was that it was making design decisions nobody had really approved.
That's a very different kind of mistake.
And it's one that can hide for a while, because what the AI gives you often looks good enough in the moment. It works. It demos. It moves. It feels like momentum.
But "it floats" is not the same thing as "it's seaworthy."
That distinction has changed the way I think about AI-assisted development.
I still want speed. I still want help. I still want the AI doing real work. But I want it doing that work inside boundaries that were chosen on purpose instead of invented on the fly.
That's a much better collaboration model.
The AI still moves fast. It still helps with implementation. But now it's operating inside an intentional system instead of quietly redesigning the system as it goes.
That may be one of the biggest practical shifts in serious AI work. The breakthrough isn't always a better prompt. Sometimes it's realizing that the AI should stop being the rule-maker.
Anyone can help build something that floats.
If you want to cross oceans, start with a blue water design.
Where this goes next
This is the broader workflow issue behind the companion guide, The Blue Water Design.
That guide steps back from my own experience and looks at the bigger question: when should you stop letting AI improvise the rules and start defining the system it has to work within?
-- Charles