There are two confident takes on AI coding right now. One says it's about to replace programmers outright. The other says don't trust it to write anything real. Both are wrong in the same way: both are confidently generalizing from their frame of reference.
Here's a better model. Think of the space of things you might ask an AI to build as an archipelago. Some of it is solid land — islands of capability built up from an enormous amount of precedent. Some is open water — places where the composition you're asking for has never really been done before, by anyone, in a form the model could have learned from. And how you navigate the waters between the islands matters as much as how far apart they are, or how many, or how steep.
How to Tell Land From Water
You don't need a map ahead of time. You can tell almost immediately by how the first attempt goes.
Land feels like this: you ask, and the answer arrives fast, clean, and right — often on the first try. This is what happens when you ask for something with a lot of precedent behind it. Parsing a messy, inconsistently-implemented file format is a good example. These formats often have evolved, have backwards-compatibility issues, version issues, and have been parsed a thousand times, by a thousand different people, who have each personally been bitten by some quirk you've never heard of. None of that knowledge lives in a single person's head. It lives in the aggregate, and an AI trained on that aggregate can draw on all of it at once. You never got wet. There was no water to get wet in. You stayed on the land.
Water feels different. The first answer comes back fast and confident-looking — and it's wrong, sometimes badly wrong, in ways that aren't obvious until you actually try to use the result. If you ask it to code something that has never been done before, this might not be a shock. But if you are "just asking" for a genuinely novel combination of things — not a new physical principle, it feels like the AI should be able to handle it. It's "just a connection between two known ideas" that nobody has happened to wire together before, in a form anyone could have learned from. The pieces exist. The bridge between them doesn't. Just build a bridge. Bridges are tricky.
What Happens If You Don't Know the Geography
This is where the two confident takes come from, and they make the same mistake from opposite directions.
The "AI will replace programmers" crowd has, by sheer luck of what they happen to need, only ever asked for things sitting on dry land. Every request works, so they generalize: this just works, always, for everyone. They've never personally traveled beyond the shoreline, maybe didn't even notice there was one. That's fortunate geography mistaken for a general law.
The "don't trust it with real code" crowd hit water at least once — got something that looked complete and clean but turned out to be structurally wrong in a way that wasn't visible until much later — and concluded AI code is all wet, and there is water everywhere. They take zero ownership for having navigated into open water without adjusting their approach, and instead blame the boat. That's not skepticism. That's also fortunate, or unfortunate, geography mistaken for a general law, just landing on the opposite verdict.
Neither one ever asked the only question that actually matters: where am I, on this specific request, right now?
The Real Skill Is What You Do Once You're in the Water
Hitting open water isn't a dead end. It's a signal to change technique, not a verdict on the whole voyage.
Sometimes the fix is in how you frame the ask. Take spatial reasoning. Ask a model to reason about a complex three-dimensional shape directly, in prose, all at once, and you'll often get something subtly or badly wrong — edges flipped, axes confused, the digital equivalent of a shape turned inside out. A Klein bottle. Ask the same question by first establishing everything in two dimensions, flat, unambiguous, and only then introducing the third dimension as a deliberate next extrusion step — and the failure rate drops sharply. Same underlying problem. Same distance to cross. Different heading, and the crossing that was failing suddenly isn't.
Watch what happens to the tools, too. Framed as raw 3D reasoning, the model casts around. Framed as "flat shape, then extrude," it goes straight for a specific, well-worn handful of libraries — names you didn't know existed until it reached for them. No single person carries an index of every narrow-purpose library in an ecosystem this large. The model does, or close enough to it. That's not directing it to something familiar. That's it finding solid ground you couldn't have pointed to yourself, the moment the problem looked like something with a coding history.
Sometimes the fix is bigger than a better question. Sometimes there's no existing bridge between two islands, and the right move is to build one — not by writing it yourself, line by line, and not by demanding the model produce it whole and hoping. The third option is to argue it out with the AI. Describe what you need on one side, what you have on the other, and go back and forth until the right shape of connecting structure falls out of the conversation. Neither party could have placed that bridge alone. That's a different mode of working than either "do it yourself" or "let it do everything," and it's the one that actually closes gaps that have never been closed before.
Why does talking it through help, when the exact thing you need has no precedent? Because the exact combination you're after is genuinely new — but the individual pieces of reasoning needed to think it through usually aren't. They're scattered across material that looks nothing like your problem on the surface, sitting adjacent to it rather than inside it. A live conversation is what pulls those scattered, adjacent fragments into the specific shape your problem actually needs, in real time. Nobody had to have previously solved your exact problem before for this to work. They just had to have thought about pieces of it, somewhere else, in some other context entirely.
The Water Level Is Dropping, But You Don't Have to Wait for It
Here's the part that makes the metaphor more than just a prescription for coping: the tide is genuinely going out, industry-wide, over time. Capability keeps expanding. Compositions that needed real, painful iteration a couple of years ago increasingly just work now, on the first try. That trend is real, and it's not going to reverse.
And as receding waters often are, the reveal will not be uniform. Land bridges will appear, or not. Shallow seas will become terrain, or not.
But you don't have to wait for the sea to recede on its own. If you have a specific problem today that happens to sit in open water, you can build your own causeway right now — through the kind of deliberate, argued-out collaboration described above. The general tide rising in your favor over the coming years doesn't help you with the thing you're trying to ship this week. The bridge you build yourself does.
Novel Doesn't Mean Impossible, and Some Crossings Are Shorter Than They Look
There's a useful parallel in patent law. An invention can be built entirely out of existing, well-known components and still be genuinely novel — patent examiners specifically allow this — as long as the combination itself wasn't obvious to someone skilled in the field. Novelty lives in how the pieces fit together, not necessarily in any single piece. That's exactly the shape of most "open water" coding problems: each underlying technique might be perfectly well understood on its own. What's missing is a specific, unobvious connection between them, and once you see it that way, "novel" stops sounding like "impossible." It just means nobody's built this particular bridge yet — which says nothing about how long the bridge needs to be.
Sometimes it's short. A fix that looks intimidating on paper turns out to be one clean diagnosis away from solved, the moment the actual gap is correctly identified.
Sometimes it's not. You can do everything right — reasonable assumptions, sound logic, a sensible heading — and still discover there's a lot more open water than you expected, the way Columbus discovered an entire unmapped continent and the planet's largest ocean standing between him and where his calculations, not unreasonable for the time, said Asia should be. That's not a failure of planning. That's discovery. The only real mistake would be insisting the original map must have been right and refusing to adjust course once the actual coastline came into view. Which sounds kind of like how Columbus handled it.
The Actual Rule
So: don't let your AI code in open water. Not because it can't ever cross it — sometimes it can, especially once you've found the right heading. Not because you should never try. Because open water needs to be recognized for what it is before you can do anything useful about it, and pretending you're still on dry land — in either direction, either "it'll just work" or "it never works" — is the one move that guarantees you won't adjust when adjustment is exactly what's needed.
Know your geography. Steer harder when the terrain calls for it. Build your own bridges when it's worth your time rather than waiting for someone else's tide to do it for you. That's the whole rule, and it's not nearly as catchy as either extreme — but it's the only one that's actually true.