What a wrong turn in Wayanad taught me about agentic coding
A couple of years ago we drove to Wayanad for a long weekend. Khushi, my indie girl, was with us, so the homestay had to be pet friendly; we found one, we packed the car, and we handed the rest to Google Maps.
The last two kilometers were the kind of Kerala road that makes you respect the people who drive it every day: narrow, steep, blind bends, a wall of green on one side, and nothing on the other. One kilometer from the homestay, the map said to continue straight. I stopped the car and got out, because straight ahead of the bonnet was a river.
The map was not lying. There had been a road. There was a route in the model. What the model did not know was what the ground knew. I called the homestay owner. He rode out on a bike, found us standing at the water’s edge, and led us back three hundred meters to a turn we had driven past twice.
I think about that river a lot now, because I watch the same thing happen to engineers every week.
The map is right until it isn’t
Give a coding agent a well-specified problem, and it is astonishing. It scaffolds the service, wires the contracts, writes the tests, and handles the cases you forgot to mention. Ninety-eight percent of the journey is faster and cleaner than anything a human would have produced at that pace.
Then comes the last mile. A change to how one legacy field is populated. A behavior that must be preserved because a customer built a workflow on top of a bug from 2011. A configuration whose reason lives in someone’s head, not in the repository.
And the agent starts going round and round.
It proposes a fix. The test fails. It proposes the opposite fix. The first test passes; another breaks. It reverts its own earlier change with complete confidence. The diff gets larger while the problem stays exactly the same size. You are now four thousand tokens and twenty minutes into a change you could have typed in ninety seconds.
This is not the agent being stupid. This is the agent being stale. Its model of your system is excellent in the middle and thin at the edges, exactly where the undocumented context lives. The map had a road. The road is now a river. The agent cannot see the water; it can only keep recomputing the route.
Name the thing: the manual-coding escape hatch
In our delivery process we now write this down as an explicit control rather than leaving it to individual judgment in the moment: the manual-coding escape hatch. When the agent will not converge, the human gets out of the car.
Calling it an escape hatch matters, because of what the alternative names do to people. If you call it “the agent failed,” engineers get defensive about the tooling. If you call it “I gave up on AI,” they quietly stop using it. If you call it a “designed control,” it becomes a professional act: a hatch is something you build into the vehicle on purpose, before you need it.
The escape hatch is not an admission that agentic development does not work. It is the mechanism that makes agentic development safe to run at speed. You go fast precisely because you know where the exit is.
Knowing when to pull it
The expensive failure is not pulling the hatch. It is pulling it too late, after you have paid for six rounds of hopeful re-prompting. Here are the signals I tell my teams to watch, and none of them require intuition:
The two-attempt rule. The agent has had two clean passes at the same last-mile change with full context, and the diff is not shrinking. Not “the tests aren’t passing yet”; the diff is not shrinking. Convergence has a shape, and this is not it.
Oscillation. The agent reverses a decision it made two turns ago and presents both versions with equal confidence. That is not reasoning; that is a search bouncing between two local minima.
Confidence rising while quality falls. The explanations get more articulate, and the code gets worse. Watch for this one. It is the strongest tell that the agent is now reasoning about its own output rather than about your system.
Blast radius creep. You asked for a change in one function, and the agent is now touching four files “to make this cleaner.” It is trying to reshape the terrain to match the map.
You already know the answer. This is the honest one. If you are sitting there watching the agent grind while the correct three-line fix is fully formed in your head, you are not supervising. You are waiting to be proven right and paying tokens for the privilege.
That is the moment to stop the car.
Intervening intelligently, not just manually
Here is where most teams get this wrong, and it is the whole point of the article.
Pulling the escape hatch is not “the AI could not do it, so I did it.” That is just you, coding, slower than before, with an expensive assistant idling in the passenger seat. If the intervention ends when the code compiles, you have solved today’s bug and preserved tomorrow’s.
The homestay owner did not just lead us to the door. He told us why the map was wrong. There was a landslide; the road had gone. The turn we needed was unmarked because everybody local already knew it. That explanation is worth more than the rescue because it is the thing that generalizes.
So the escape hatch has two halves, and the second half is not optional:
- Write the code yourself. Small, surgical, minimum blast radius. Do not try to teach the agent while you are bleeding.
- Write the road back onto the map. The context that the agent could not see must now exist in a form it can see next time: a line in the spec, a note in DESIGN.md, a test that locks the behavior so no future agent can quietly undo it, or a comment that says this is here because of a 2011 defect that three customers now depend on.
Skip the second half and you have not intervened. You have merely rescued yourself and left the river exactly where it was for the next driver.
Do it consistently, and something quietly compounds: every manual intervention makes the next agentic run better. The edges of the map get filled in by exactly the people who drove into the water. Your codebase stops being a place where agents perform well in the middle and fail at the boundaries, and starts being a place where the boundaries are documented because someone was disciplined about the day they got stuck.
The human is not the fallback; the human is the local
The framing I want to push back on is the one where the human is the backup system, the thing that takes over when the automation degrades. That framing makes the human’s role a residue, and it shrinks every year.
The better framing is the one from the road. The map is not less useful than the man on the bike; it got us four hundred kilometers from Bangalore to a hillside in Wayanad. But the man on the bike had something the map structurally cannot have: he had this morning. He knew what changed. He knew what was never written down.
That is the human’s permanent job in an agentic system. Not to code faster than the agent, which is a race you will lose and should want to lose. To hold the context that has not been captured yet, notice the moment the model has gone stale, get out of the car early, and then do the unglamorous work of writing the missing road onto the map so that the next journey is shorter.
The engineers who will thrive in this next decade are not the ones who can out-type an agent. They are the ones who know, one kilometer from the destination, that it is time to stop and ask.
Khushi, for the record, was unbothered by the river. She wanted to swim in it.