Testing turns ‘reactive’ as documentation lags

Michiel Willems
August 6, 2026

As AI accelerates software development across banking and financial services, QA and software testing teams are facing a familiar but increasingly urgent challenge: how to keep system knowledge accurate, accessible
and aligned with rapidly changing codebases.

In highly regulated environments where traceability, auditability and resilience are critical, outdated or incomplete documentation is no longer just an inconvenience, it is a material risk.

The faster teams ship, the harder it becomes to capture the context behind decisions, dependencies and defects in a way that testing teams can reliably use.

That tension is forcing a broader rethink of documentation itself: not just how it is written, but when and why it exists. Increasingly, the question for QA leaders is whether traditional documentation practices can keep up with AI-driven delivery cycles at all.

Avi Cavale, co-founder of Quarterback, argues they cannot. His answer is blunt: “Stop asking your team to write documentation.”

The longtime entrepreneur in the software development space is not arguing that documentation is irrelevant. Quite the opposite.

“Documentation as a deliberate activity doesn’t matter anymore,” he said. “But documentation, as knowledge, matters more than ever.”

The problem, he argued, is the process: teams are relying on outdated practices that cannot keep pace with modern development cycles.

“The people who know the most write the least,” Cavale explained. “The docs that get written are stale within weeks.”

For QA teams tasked with validating complex banking systems, that gap between reality and documentation can mean missed dependencies, misunderstood architecture changes, and ultimately increased operational risk.

Documentation ‘problem’ in QA

For QA and software testing teams at many banks, the issue is painfully familiar: documentation exists, but cannot always be trusted.

In environments where systems evolve rapidly and regulatory scrutiny is high, stale or incomplete documentation becomes a direct risk to quality and resilience.

Cavale described what many engineering and QA teams will recognise as a recurring pattern: initial enthusiasm for documentation, followed by gradual decay and eventual abandonment.

“I’ve watched this cycle play out on every team I’ve been part of,” he shared, outlining how documentation starts strong but quickly becomes obsolete. Over time, engineers begin to distrust it entirely. “Don’t trust the wiki” becomes team wisdom.

In banking environments, where auditability and traceability are critical, this breakdown has wider implications. QA teams rely on accurate system knowledge to design tests, validate changes, and ensure compliance.
When documentation cannot be relied upon, testing becomes reactive rather than proactive.

Knowledge decays faster than code

At the core of Cavale’s argument is a simple but critical point for QA: the most valuable knowledge is created during development, not after.

“The most valuable knowledge is generated during work, not after it.”

He highlighted how the key decisions, architectural trade-offs, performance considerations, hidden dependencies, are made in real time, often under pressure. By the time teams attempt to document them, the context has already faded.

“The knowledge is richest at the moment it’s created. Every hour after that, it decays,” Cavale stressed.

For testing teams in financial services, this has direct consequences. Missing context around why a system behaves a certain way can lead to incomplete test coverage, false assumptions, and gaps in resilience
testing.

Continuous knowledge capture

Cavale proposed a shift away from documentation as a manual task, toward knowledge capture as an automated byproduct of development.

“What if the system captured it at that moment?” he asked, referring to the decisions, patterns and fixes generated during coding sessions.

Rather than relying on static wiki pages, this model would create “structured, typed, searchable knowledge that stays current because it’s generated from the work itself.”

For QA teams, this could mean access to real-time, context-rich insights: why a service was designed a certain way, what constraints shaped a decision, or how a specific bug was diagnosed and fixed.

“The knowledge is richest at the moment it’s created. Every hour after that, it decays.”
– Avi Cavale

Cavale contrasted traditional documentation with what he calls a continuous stream of knowledge. “Traditional documentation is a snapshot… and it begins decaying immediately.” By comparison, “knowledge captured as a
byproduct of work is a stream.”

Over time, this creates a cumulative knowledge base that grows with the system itself. For banks managing large, distributed architectures, the implications are significant: faster onboarding, better-informed test
design, and more effective incident response.

“A new engineer joining the team has access to all of it from their first session,” he explained, describing a model where knowledge is not passively read but actively surfaced.

However, Cavale acknowledged that this approach introduces its own challenges, particularly around filtering what should be captured.

“This only works if the extraction is good. Capture too much and you get noise,” he pointed out.

The critical factor, Cavale argued, is that whatever is doing the work is also best placed to judge what is worth keeping. “The entity doing the work is the best judge of what’s worth capturing.”

If documentation continues to lag behind development, the risk for QA teams is clear: testing becomes less informed, less effective, and more reactive.

But if knowledge can be captured in real time, tied to decisions, context and system behaviour, it could provide a new foundation for continuous validation, stronger traceability, and more resilient systems.

As Cavale concluded: “Documentation is dead as a deliberate activity. As a side effect of working with an intelligent system? It’s never been more alive.”