The Complacency Gap: What Switching AI Coding Tools Taught Me About Vigilance

A few weeks ago I switched from Claude Code to Codex for a project. Not because either was broken. Just to try something different.

The first thing I noticed was that I was more careful. I read outputs more closely. I questioned what the model was doing instead of approving it. I felt the friction of not knowing what to expect next.

My first instinct was to frame this as overhead — cognitive load I would eventually shed as I got comfortable with the new tool. Then I caught myself and thought: no. That load is exactly what I should have been carrying all along.

Automation Complacency Is a Real Thing

There is a well-documented phenomenon in aviation and surgical robotics called automation complacency. The more reliable a system, the less actively a human monitors it. The cognitive load does not disappear — it stops being applied. The operator is present but not watching.

This is not carelessness. It is biology. Sustained vigilance is expensive. When a system rarely fails, the brain down-regulates the monitoring effort. This is normal. It is also dangerous in high-stakes contexts.

AI coding tools are reliable enough, and pleasant enough to work with, that the same effect kicks in. You stop reviewing outputs and start approving them. The distinction sounds minor. It is not.

What Actually Gets Lost

When I examined what complacency had cost me with Claude Code, it was not code quality — at least not obviously. The outputs were still mostly correct. What degraded was something subtler:

First: triage. I stopped knowing which parts of an output deserved scrutiny. Security-sensitive logic, architectural decisions, third-party integrations — these got the same shallow pass as boilerplate. The calibration between high-stakes and low-stakes disappeared.

Second: context. Code was accumulating without a trail of why. Decisions the model made were not documented. Tradeoffs were not surfaced. Six months later, neither I nor anyone else could reconstruct the reasoning behind a non-obvious choice.

Third: uniform vigilance. Everything started getting rubber-stamped. No triage, no questions, just approval.

All three collapsed together, and each made the others worse.

Competence Becomes the Enemy of Oversight

Here is the uncomfortable part: the complacency gets worse as the tool gets better. A junior developer working with a weak model stays alert because the output requires correction. A senior developer working with a capable model gets complacent precisely because the output rarely needs correction. The tool earns your trust and that trust becomes the problem.

The Codex switch was a temporary reset. I reinstated a junior-developer posture — not because the model was less capable, but because I did not yet know what it would do. The unfamiliarity was doing real epistemic work.

But that vigilance was contingent on novelty. Once Codex becomes as familiar as Claude Code, the complacency returns. The tool does not sustain the discipline. The unfamiliarity does. And unfamiliarity is a depletable resource.

The Shared Gap Neither Side Honors

The deeper issue is that context preservation is a shared responsibility — and neither side currently honors it.

The developer trusts the model to produce good output, so they stop documenting the decisions behind it. The model is optimized to produce output that looks decided, so it does not flag uncertainty or narrate the tradeoffs it made. Neither side is lying. But the context that would make the codebase understandable six months from now falls through the gap between them.

This gap widens as the tool improves. The better the model, the more the developer is incentivized to trust it. The more trusted it is, the less the context gets captured. The code is correct. The why is gone.

What the Ideal Tool Would Do Differently

If you designed an AI coding tool with this in mind, it would look different from what exists today. Not in the model, but in the interface and the contract.

It would surface decisions, not just code — narrating what tradeoffs it made and what it assumed, for every non-trivial output. Not as a log no one reads, but as a first-class artifact alongside the code.

It would flag its own uncertainty explicitly. Not confidence scores — those are too abstract. Specific markers: "I was not sure about this authorization logic. You should verify it." Force the developer to own the uncertain parts rather than silently inheriting them.

It would require intent before generation. Not always — boilerplate should stay fast. But for architectural decisions, it would push back: what are you trying to accomplish, and why this way? Context capture at the entry point, not as an afterthought.

It would run periodic audits: here is what I think we have built and why. Is this still accurate? A forced changelog, surfaced automatically.

None of these exist as designed behaviors in any current tool. They are all on the developer to impose externally. Most do not.

What You Can Do Right Now

The honest answer is that no workflow change fully solves the biology. Any system you engineer can be overridden. Discipline fades. Tool rotation helps temporarily but you adapt. There is no clean solution.

What there is: practices with low activation energy and high signal cost if skipped.