Tooling Contingency

Context

You’ve maintained a codebase primarily or exclusively with AI assistance, accepting code that would be cognitively expensive to read and modify by hand because the AI handles the cognitive cost. This is rational — until the assumption breaks.

Cost type

Primarily cognitive, deferred. The cognitive cost has been moved off the present author and onto the contingency: future-you-without-the-tool, a colleague picking up the project, an auditor, your future self in a context where you can’t paste code into a remote service.

What goes wrong

• The model you depend on is deprecated, repriced, or behaves differently. The codebase that was maintainable becomes laborious or impossible to evolve at the same pace.
• A professional context (regulated industry, security-sensitive client work, offline environment) prevents you from using the tool you’d rely on. The cognitive cost reasserts.
• The project changes hands. The new maintainer doesn’t have your tooling, your context, or your sense of what each piece does. They face the original cognitive cost in full.
• An incident requires fast diagnosis and the tool is unavailable, slow, or producing bad answers under load. The cognitive cost is acute and time-pressured exactly when you can least afford it.

Prospective indicators

• “I’d never write this by hand, but Claude can deal with it.”
• 500+ line files with no clear seams, justified by “I just ask the LLM where to make the change.”
• No tests, justified by “if it breaks I’ll just have it regenerated.”
• Names, naming conventions, and structure that the LLM produces but no human would choose for memorability.

Retrospective indicators

• The project has shipped and is in use. Picking it up after a long break, you find yourself asking the LLM “what does this file do?” rather than reading it.
• A maintainer change has stalled because the new person can’t get oriented.
• A change you used to make in five minutes now takes an hour because the LLM is unavailable or slow.

Prevention

• Keep the cognitive cost manageable enough that some future human can recover, even if it’s slower than current-you-with-LLM. Not zero — that’s paying the full cost — but bounded.
• Periodically attempt a small change without the LLM. Treat the difficulty as a measurement of how much contingency risk you’ve accumulated.
• Test coverage at the application boundary functions as insurance. Whatever the LLM produces, the boundary tests certify; if you have to read the code unaided someday, the tests at least tell you what’s supposed to happen.
• Documentation written for the human contingency, not for the LLM. The LLM doesn’t need the README; you, three years from now, do.

When this isn’t a failure mode

• The project is genuinely throwaway. A break-timer used by one person for 18 months and then forgotten doesn’t have a contingency to plan for.
• The cognitive cost is contained to a small surface (one file, one component, one prototype) and the rest of the system is normal.
• You have made an informed bet that the tooling regime is durable enough for your time horizon. It might be. The bet should be conscious, not implicit.

Note

This failure mode is new — emergent in the AI-collaboration era — and the field doesn’t have settled practices for managing it yet. Most existing software-engineering literature implicitly assumed unaided humans as the maintenance audience and didn’t need to name this. Worth writing about explicitly.