For most of software history, configuration was framed as freedom. The more settings a system offered, the more capable it was assumed to be. You could adapt it to your organisation, account for edge cases, shape it to fit how you worked. Complexity was presented as optional, and optionality as power.

That framing is starting to break down.

Configuration has become one of the largest sources of technical debt inside modern organisations, not because teams configure systems poorly, but because configuration itself does not age well. Every rule, workflow, and integration encodes a specific understanding of how work happens at a point in time. That point passes. Work changes. The configuration remains.

What begins as flexibility slowly hardens into obligation.

Most teams encounter this as friction rather than failure. A system that once felt helpful starts requiring explanation. Someone has to remember why it was set up that way. Exceptions accumulate. Documentation grows. Over time, people begin routing work around the system instead of through it. The software still exists, but it no longer reflects reality. It describes a version of the organisation that has quietly moved on.

This is technical debt, but not in the conventional engineering sense. It is not bad code or flawed architecture. It is contextual drift. A widening gap between how a system believes work happens and how work actually happens.

The underlying issue is that configuration assumes stability. It assumes processes can be described accurately upfront and then reused with minimal revision. In practice, most work environments do not behave this way. Teams change. Priorities shift. Exceptions become routine. Work evolves faster than any configuration layer can keep up with.

Despite this, many systems still require users to explain themselves comprehensively before anything useful can occur.

Onboarding flows demand definitions that do not yet exist. Dashboards expect schemas for work that is still in motion. AI tools ask for prompts that encode nuance users themselves only understand intuitively. Each step is framed as a one-time setup. In reality, it is an ongoing commitment. Someone must notice when reality has changed and translate that change back into the system.

This is why configuration debt accumulates quietly. It rarely fails dramatically. Instead, it erodes trust incrementally. The system is accurate often enough to keep, and inaccurate often enough to stop relying on. It remains for record-keeping or compliance, while meaningful work migrates elsewhere.

Much of this debt emerges from a reasonable intention to give users control. But control that requires continuous explanation is not empowering. It shifts the burden of adaptation onto people who already have limited attention.

The alternative is not less capable software. It is software that learns differently.

Systems do not need more upfront description. They need greater exposure to how work actually unfolds. They need to observe patterns, repetition, hesitation, and workaround. Context acquired through observation degrades more slowly than context extracted through configuration, because it updates as behaviour updates.

This is the difference between configurable systems and adaptable ones. Configurable systems wait to be told that something has changed. Adaptable systems notice.

As work becomes more fluid and less predictable, this distinction matters more. The most costly technical debt is no longer buried in codebases. It sits in assumptions made during setup and never revisited. Rules that once fit and now mislead. Workflows that describe an organisation that no longer exists.

Reducing that debt does not require removing features. It requires designing systems that tolerate ambiguity, evolve with use, and demand less precision from people at the outset.

The future of software is not unlimited configuration. It is systems that require less explanation over time, not more.

When a system needs a dedicated person to remember how it works, it has usually already crossed the line from asset to liability.