Blog

Much of the discussion about AI and software development focuses on whether AI will replace developers.

A different risk may be emerging.

Organizations may use AI to automate precisely the work through which people traditionally developed the understanding required to become senior.

Senior developers did not enter organizations as senior developers. Their expertise accumulated over time.

They implemented small changes. They investigated defects. They read unfamiliar code. They made mistakes. They observed production failures. They asked why something had been designed in a particular way. They discovered that apparently strange implementations sometimes existed for good reasons — and sometimes for reasons that had stopped being good years earlier.

Through repeated exposure, they acquired more than technical skill.

They acquired context.

They learned not only what the system does, but increasingly why it became the way it is.

The Efficiency Paradox

AI can remove substantial amounts of routine work from software development. That can be valuable.

A junior developer may no longer need to spend hours writing relatively straightforward implementation code, searching documentation, constructing tests, investigating logs or performing other work that an AI system can complete much faster. Measured as delivery efficiency, this looks like progress.

But some apparently inefficient work may have performed another function:

It created experienced people.

The work product was not its only output.

Learning was another.

If we automate the activity while measuring only whether the immediate deliverable can still be produced, we may overlook the organizational capability that the activity was helping to create.

Work Has More Than One Outcome

This suggests a more general distinction.

An activity may produce an explicit outcome and one or more implicit outcomes.

For example:

Explicit outcome:
– A developer fixes a defect.

Implicit outcomes:
– The developer learns how the system behaves.
– They discover relationships between components.
– They understand why a particular design decision matters.
– They encounter a business rule that was previously invisible to them.
– They become better able to recognize similar problems in the future.

An AI system may produce the explicit outcome extremely efficiently while reducing some of the implicit outcomes.

The defect still gets fixed. But who learned from fixing it?

The Succession Problem

This becomes particularly important when experienced people leave.

Organizations already struggle to preserve understanding across personnel changes. Documentation may preserve requirements, architecture, code and decisions while much of the reasoning connecting them remains in people’s heads.

AI could introduce a second continuity problem. It may not only change how existing knowledge is preserved.

It may change how new people acquire enough understanding to become future custodians of that knowledge.

If today’s senior developers retire or leave, organizations cannot simply replace them with today’s juniors plus more capable AI.

The question is whether those juniors have had opportunities to develop the contextual and causal understanding that made the departing developers senior in the first place. This is therefore not merely a staffing pipeline problem.

It is a succession of understanding problem.

Expertise Is More Than Accumulated Information

It would be tempting to solve this by giving future developers better access to documentation and AI-generated explanations. That will help, but it may not be sufficient.

Experienced practitioners possess more facts, but they also have developed judgment.

They recognize when something looks suspicious before they can necessarily explain exactly why. They know which questions to ask. They recognize recurring causal patterns. They understand where apparently local changes may have wider consequences. Much of that ability was developed through interaction with real problems.

The challenge is therefore not simply to transfer everything a senior developer knows to a junior developer.

It is also to preserve opportunities through which less experienced people can develop their own understanding and judgment.

AI Changes the Learning Path

This does not imply that organizations should preserve inefficient manual work simply because previous generations learned through it. That would confuse the practice with the function it served.

The important question is instead:

Which learning functions did the old way of working provide, and how will those functions be preserved when AI changes the work?

Perhaps some learning can happen faster with AI. AI can explain unfamiliar code, expose dependencies, challenge assumptions, simulate alternatives and make organizational knowledge easier to interrogate.

Used deliberately, it may accelerate the development of understanding rather than diminish it.

But that requires designing AI-supported work for more than immediate productivity.

The objective cannot only be:

How can AI help this developer produce the result faster?

It must also include:

How does this developer become capable of understanding, questioning and eventually owning the results?

Implication for Continuity of Understanding

Continuity of understanding therefore has at least two dimensions.

The first is preservation:

Can the organization retain enough of its existing understanding when people leave, systems change and structures evolve?

The second is regeneration:

Can new people develop enough understanding to extend, challenge and eventually replace the understanding held by today’s experts?

A reference model can help with the first by connecting fragmented knowledge and preserving relationships, rationale and intent.

But it may also support the second. If important relationships between intent, requirements, decisions, implementation, evidence and outcomes are made accessible, a less experienced person does not have to reconstruct all of them accidentally over years of work.

They can explore them deliberately.

AI may make that exploration dramatically easier.

The opportunity is therefore larger than preserving the old apprenticeship model.

It is to create a better one.

Working Proposition

AI should not only increase the productivity of today’s experts. It should help create tomorrow’s experts.

When evaluating AI-supported ways of working, organizations should therefore assess not only:

• whether work is completed faster,
• whether fewer people are required,
• whether output quality remains acceptable,

but also:

• whether practitioners continue to develop contextual understanding,
• whether reasoning and rationale remain accessible,
• whether people learn from the work AI performs with them,
• whether judgment and ownership continue to develop,
• and whether the organization is creating the people who will be capable of carrying its understanding forward.

Otherwise, AI may solve today’s capacity problem while quietly creating tomorrow’s capability problem.

There is a recursive quality to the question why that I find fascinating.

Suppose we are automating regression testing. Why are we doing that? Perhaps because we want confidence that changes have not broken existing behavior. But that answer can itself become the subject of the next question. Why do we need that confidence? Perhaps because we want to release changes without creating unacceptable risk. Why do we want to do that? Perhaps because the product needs to respond quickly to changing needs.

Something interesting happens as we move through these questions. The answer to why at one level becomes the what at the level above it.

Automated regression testing is a What whose Why is confidence in changes. Confidence in changes is then itself a What whose Why is the ability to release safely. The ability to release safely becomes another What, connected to another Why.

The Why of one layer is the What of the layer above it.

This suggests that Why is not simply an explanation attached to something. It is a connection between levels. The higher level gives purpose to the level below it, while the lower level is one way of contributing to what the higher level is trying to achieve.

Perhaps this is also an important part of what we mean by understanding.

We can know a great deal about something without necessarily understanding it. We can know what a system does, what requirements it has, what decisions were made, what processes people follow, and what technologies are used. But if we can no longer move from those Whats toward the Whys that give them meaning, something important has been lost.

A requirement without its Why becomes an isolated statement. A design decision without its Why becomes an historical fact. A process without its Why becomes a sequence of activities that may continue long after anyone can explain what capability those activities were intended to provide.

The information may still be there. The understanding is not.

This also means that Why has no obvious natural endpoint. Every answer can potentially become the subject of another Why. Eventually we stop, but perhaps not because we have reached some ultimate Why. We stop because we have reached a boundary that is sufficient for what we are currently trying to understand.

That makes the choice of boundary important. If we draw it too narrowly, the Why may sit outside it. We can then describe the subject in extraordinary detail while remaining unable to explain its purpose. We may even optimize it successfully according to its internal logic while losing sight of whether it still contributes to what matters at the level above.

Perhaps understanding, then, does not primarily reside in the individual pieces of information we preserve.

It resides in the connections between them.

And perhaps one of the most important connections we can preserve is the one that allows us to keep asking:

Why?

Come to think of it, Why? may be the most frequently asked question in the universe. After all, every answer gives us something new to ask Why? about.

Earlier Practice Notes use the term Assessment Model to describe the way an assessment is structured and performed.

I have come to think that Assessment Approach is a better term.

The distinction matters because a Reference Model and an Assessment Approach are not the same kind of thing.

A Reference Model describes what we assess against. It makes explicit our understanding of the subject: its purpose, expected qualities, characteristics, relationships, constraints, or other aspects relevant to judging it.

An Assessment Approach describes how we perform the assessment. It determines how we investigate the subject, what evidence we seek, how we collect and interpret that evidence, and how we arrive at justified judgments.

Put simply:

Reference Model = what we assess against.

Assessment Approach = how we assess.

Calling both of these things models creates an unnecessary symmetry between them. The Reference Model represents an understanding of the subject. The Assessment Approach is the means by which we investigate reality in relation to that reference.

This Practice Note therefore introduces a terminology change.

From this point onward, I will use Assessment Approach rather than Assessment Model.

Earlier Practice Notes will remain unchanged. Where they use Assessment Model in this sense, it should generally be understood as what I would now call an Assessment Approach.

This is not a change to the underlying ideas in those notes. It is a refinement of the language used to express them.

And perhaps there is a broader principle here as well.

A developing body of knowledge does not need to rewrite its past every time its language improves. Earlier thinking can remain visible while later notes clarify, refine, or supersede it.

The history of the terminology then becomes part of the history of the understanding.

In The Death of the Document?, I explored a simple possibility: perhaps documents are no longer always necessary as the primary way in which knowledge is transferred.

Traditionally, a document has to be created before somebody knows exactly what they will want from it. An author decides what matters, how the material should be structured, how much detail should be included and in which order it should be presented. The reader then works through that predefined representation in order to extract whatever understanding is relevant to the question they actually have.

The sequence is familiar:

Knowledge → Publication → Reading → Understanding

AI makes another sequence possible:

Knowledge → Question → Synthesis

The answer no longer necessarily has to be published before the question exists. A representation can be created because somebody asks for it.

At first, this appears to be a question about documents. But once the idea is taken seriously, the same pattern starts appearing elsewhere.

A Dashboard Is Also a Predefined Answer

Consider a dashboard. A dashboard is an attempt to anticipate future questions. Someone decides that users will probably want to know how much was sold today, whether sales are rising or falling, which regions are underperforming, how margins are developing, and perhaps a dozen other things. Measures are selected, charts are designed, filters are added and drill-down paths are created. If the resulting dashboard cannot answer a particular question, somebody may eventually build a custom report. All of this happens before the user actually asks anything.

Now imagine that the user can simply say:

How much did we sell today?

The system answers.

Why is that lower than yesterday?

It investigates.

Is Sweden causing it?

It investigates again.

Then what is causing it?

The next answer is synthesized from whatever data is relevant.

The important change is not merely that the dashboard has become easier to use. The sequence of questions no longer has to be designed in advance. Each new question can emerge naturally from the answer to the previous one.

In some situations, that makes the predefined dashboard unnecessary.

Sometimes the Right Answer Is “Show Me”

Of course, not every answer is best expressed in words.

Sometimes an explanation immediately creates a different need:

Show me.

Show me the sales trend.

Show me where the customers are.

Show me what changed.

Show me how these components interact.

Show me the evidence behind that conclusion.

At that point, the system can create or retrieve a visualization appropriate to that particular question.

The visualization still matters. What changes is that it no longer has to exist permanently because somebody once imagined it might be useful. It can be created at the moment it becomes useful.

The same underlying information can also be consumed differently depending on the situation. Someone sitting at a desk may want a detailed written explanation. Someone preparing for a management meeting may want a few diagrams. Someone driving may simply want to talk. Someone investigating a difficult problem may move continuously between forms:

Tell me what is happening.

Why?

Show me.

Show me the evidence.

Explain that part.

The knowledge remains the same. The representation changes with the need.

This suggests that documents, dashboards, reports, presentations and visualizations may increasingly become temporary views over more durable knowledge and data.

The Command Prompt Returns

There is an interesting historical irony here.

The command line allowed users to tell computers what they wanted, but only if they knew how to speak the computer’s language. Commands, parameters, paths and syntax had to be learned.

Graphical interfaces made computers easier to use by reversing the relationship. Instead of requiring users to know the command, the computer exposed possible actions through menus, buttons, forms, folders, dashboards and navigation structures.

AI seems to bring us strangely close to the command prompt again. The user can once more simply express intent:

How much did we sell today?

What do we know about this customer?

Why was this architecture chosen?

What changed overnight?

Show me the trend.

The difference is that the command language is now ordinary human language.

The user does not necessarily have to know which application contains the answer, which report to open, which dashboard to inspect or which sequence of operations will produce the result. The system can determine which sources, calculations and representations are required.

The command prompt has returned. It just learned to speak human.

When the System Asks for Our Attention

There is another step beyond this. Sometimes the user should not have to ask at all. A dashboard assumes that somebody will look at it frequently enough to notice when something important changes. An intelligent agent can continuously interpret the underlying information instead.

Rather than displaying a graph and waiting for a human to notice an undesirable trend, it can say:

You may want to look at this.

Or, less formally:

Psst. You have a problem.

The human can then ask why.

The system explains.

Show me.

A visualization appears.

What changed?

The relevant history is retrieved and synthesized. The dashboard has not disappeared completely. It has become an on-demand representation inside a conversation. What used to be a permanent interface becomes something that materializes only when it helps us understand the situation.

What Should Actually Be Permanent?

This leads to a more fundamental question.

What actually needs to be durable?

We currently spend considerable effort maintaining representations. Documents have to be updated. Dashboards have to be redesigned. Reports have to remain current. Presentations are recreated. Diagrams gradually become obsolete. Interfaces are maintained because somebody may need to navigate through them in the future. Perhaps these are increasingly the wrong things to make permanent.

What needs to remain durable is the material from which trustworthy representations can be produced: knowledge, data, evidence, sources, provenance, decisions, assumptions, relationships and expectations.

Above that durable layer, representations can increasingly be generated according to the need of the moment. A document when a document is useful. A chart when a chart is useful. A spoken explanation when somebody wants to listen. A dashboard when somebody wants an overview. A detailed evidence trail when somebody wants to challenge a conclusion.

The representation can be generated, consumed and discarded. The knowledge remains.

The Death of the Predefined Representation?

This does not mean that documents will disappear. Nor will dashboards, reports, presentations, diagrams or graphical interfaces. We may actually create more of them than ever.

What may disappear is the assumption that these representations have to be designed, published and maintained before we know what somebody actually wants to know.

Instead, the sequence becomes:

Knowledge and data → Intent → Representation

The representation is created at the moment of need, for the person who needs it, for the question they are actually asking and in the form most appropriate to the situation. Read it. Listen to it. Look at it. Interact with it. Then ask the next question.

Perhaps the document was only the first thing we noticed becoming ephemeral. The more fundamental change may be the death of the predefined representation.

Understanding debt accumulates when the reasons behind a product gradually disappear. Requirements remain. Architecture remains. Test cases remain. Backlogs remain. Decisions may be scattered across meeting notes, presentations, emails, issue trackers, source repositories and documentation. The artifacts survive, but the understanding that connects them becomes increasingly difficult to reconstruct.

The conventional response is to organize the information. Inventory the documentation. Classify it. Clean it. Standardize formats. Define a taxonomy. Migrate information into appropriate repositories. Establish ownership and maintenance processes. This is sensible.

It is also a considerable undertaking, which may explain why understanding debt is so rarely addressed systematically.

There may be a more pragmatic starting point.

Make Everything Accessible

Suppose all surviving artifacts concerning a product are made accessible within a single knowledge environment. They do not necessarily have to be moved into one physical repository. They may remain in document management systems, issue trackers, source repositories and other locations, provided that they can be accessed together. Their formats do not have to be standardized either.

The important requirement is simpler:

AI must be able to reach them, interpret them and identify their provenance.

The resulting knowledge environment may initially be messy. That may be good enough.

Instead of asking a person to navigate the information structure, we can ask the question we actually want answered.

Why was this architecture chosen?

Why does the product behave this way?

Why does this requirement exist?

What problem was this feature intended to solve?

Why was this alternative rejected?

AI can search across the available artifacts and synthesize an answer from whatever relevant information survived. The person no longer has to know where the answer lives.

The White Gaps

Making existing information accessible does not recover understanding that was never recorded. This is not a reason for the approach to fail. It may be one of its greatest benefits.

When asked a question, AI may discover several different situations. The answer may be explicitly supported by available sources. The answer may not be stated explicitly but may be reasonably reconstructed from several sources. Available sources may contradict each other. Or there may simply be insufficient information to answer the question. These are different states of organizational understanding.

AI should distinguish between them. An educated guess can be useful, but it must remain an educated guess. If available evidence suggests a likely explanation, AI can present that explanation as a hypothesis together with the evidence from which it was inferred.

It should also be able to say:

I don’t know.

The unanswered question reveals a white gap in the knowledge body. That gap is itself valuable information.

Let Questions Reveal the Debt

Understanding debt therefore does not have to be identified through a comprehensive documentation program. It can reveal itself through use.

Someone asks why a component has a particular constraint. AI cannot establish the reason from the available information. It finds some indications that performance may have been involved, but confidence is low. An experienced engineer remembers that the real reason was compatibility with a customer’s legacy interface. Perhaps that recollection leads to an old procurement specification that confirms it. Perhaps no documentary evidence survives.

Either way, the organization has learned something about the state of its understanding. The answer, its source and the remaining uncertainty can now be preserved. The next person who asks the question starts from a better position.

A simple learning cycle emerges:

Question → Synthesis → Gap → Investigation → Understanding → Capture

The knowledge body improves because people use it.

From Retrieval to Continuity

This suggests two related but different objectives.

The first is recoverability.

Make surviving organizational information accessible so that AI can reconstruct as much existing understanding as possible.

The second is continuity.

When questions expose missing, uncertain or conflicting understanding, investigate where worthwhile and preserve what is learned. Over time, the knowledge environment becomes more than a searchable collection of artifacts. It becomes a living body of organizational knowledge.

AI then performs a role beyond enterprise search. It helps the organization distinguish between what it knows, what it can infer, what it disagrees with itself about, and what it no longer knows.

The white gaps become a map of understanding debt.

Start With the Mess

There will still be reasons to improve documentation, establish authoritative sources, manage provenance and confidence, remove obsolete material, protect sensitive information and structure important knowledge explicitly.

But these activities do not necessarily have to precede useful knowledge recovery. A pragmatic first step may be much simpler:

Make the surviving knowledge accessible.

Then ask questions. Let AI synthesize what can be synthesized. Let it identify what cannot. Use real questions to discover which missing understanding actually matters. And preserve the answers as they emerge.

Instead of first organizing the mess so that people can search it, perhaps we should begin by making the mess interrogable.