Watch the Water, Not Just the Map

There was once a village of sailors who lived by one rule: “Watch the water, not just the map.” The map would show them where they wanted to go, but the water told them what was actually happening.

One day, they built a mirror that would always show them the safest path before they chose a route. At first, they used it as a tool. They looked at the mirror, then the crew checked it against the water. But because it was right almost every time, looking at the water slowly started to feel unnecessary. They slowly stopped practicing the one rule they had: “Watch the water, not just the map.”

Then came a morning the mirror had not seen before: fog, strange currents, and rocks just beneath the surface. The mirror still showed a clean path forward, but the water was telling a different story.

All the signals were still there — the smell of kelp, the pull of the current, the sound of surf breaking too close — but the sailors had forgotten how to read those signals.

As the story goes, the ship struck the rocks and sank not because the mirror was useless, but because the sailors had forgotten how to read the water.

In the last few years, software engineering has started building its own version of this mirror — agentic coding. It helps us move from intent to implementation faster than ever before.

Before, getting to the destination was expensive. Implementation took time, so teams were forced to slow down, to plan better, think about trade-offs, and look for signals before moving too far. The friction was painful, but it also created discipline.

Now that implementation is no longer the bottleneck, and it’s cheaper than ever to create software, a feature that used to take weeks can take a couple of hours. However, what most people do not realize is that the bottleneck does not disappear. It moves elsewhere.

The mirror didn’t make sailing obsolete; it made the sailors forget which parts of sailing still mattered. Agentic coding creates the same risk. It does not remove the need for engineering judgment; it makes it easier to forget where that judgment is still needed.

Implementation friction allowed exactly that. It acted as a forcing function to make better judgment. What that judgment entails is different across organizations. Specifically, in my experience of building an early-stage startup, that judgment meant reviewing the existing codebase, asking where a feature actually belonged, and thinking through the boundaries of the domain before implementation. I have fallen into this trap many times. A feature works in the demo, but the logic lives in the wrong place. The agent creates a new abstraction that passes the test, but nobody has clarified whether the feature belongs in that domain.

This is the question every software team should be asking: if implementation friction used to be the forcing function for better judgment, what replaces that friction when implementation becomes cheap?

Without a proper answer, it becomes easy to confuse shipping faster with building better — and you’re letting AI steer your software instead of you steering it. From the outside, everything will look like progress: features take days instead of weeks. But inside the codebase, the cost just moves somewhere else: weaker abstractions, duplicated logic, unclear boundaries, and features that “work” but don’t fit the system. The code works, but the system gets weaker.

This is why principles matter: not because they sound good, but because they make judgment repeatable.

They give a team a shared way to make decisions on what belongs where, the reusability of the codebase, the guardrails they need to set up, and what needs to be mapped out before a single line of code is written.

Every organization’s playbook will look different — the judgment at an early-stage startup is different from the judgment inside a large engineering organization — but the need for a playbook is bigger than ever. Teams need to decide where judgment lives before they hand more implementation to agents.

In the next few blogs, I will share some of the coding principles I have started to follow religiously within my team while heavily leveraging agentic coding, and how we’re using it not to slow down but to preserve the judgment that actually allows us to move faster.

The next software engineering team that wins is not the one that maximizes “token count” to reach a vanity metric. Rather, it’s a team that leverages tokens to steer the direction of the ship.

Remember: tokens are not the leverage; judgment is. And principles are not for decoration — they’re a steering mechanism.