Perhaps the most significant change that AI will bring is not how work is produced, but how competence is demonstrated.

Today, we typically evaluate only the final outcome. We review the report, the presentation, the software, the analysis, or the recommendation. If the outcome appears correct, we often assume the individual who produced it is competent.

In an AI-assisted world, that assumption becomes increasingly difficult to make.

Two people can generate remarkably similar outputs using AI. One may have deep domain expertise and carefully guided the AI through a structured reasoning process. The other may simply have accepted the first response the AI produced.

The outcome alone no longer tells us who demonstrated greater competence.

What differentiates them is the quality of the questions they asked, the context in which those questions were asked, and the professional perspective from which they originated.

This suggests that organisations should begin documenting not only what was produced, but how the outcome was reached.

Questions Become Evidence of Thinking

Imagine a software developer using AI to generate a new application feature.

Traditionally, a manager reviews the final code. However, that review reveals little about the developer's reasoning.

Now imagine reviewing the sequence of questions that guided the AI.

Instead of asking:

"Generate a customer authentication module."

An experienced developer might progressively ask:

• Which authentication approach best balances security, usability, and maintainability?
• What security vulnerabilities should this implementation protect against?
• How should authentication integrate with our existing architecture?
• Which industry standards and compliance requirements must this solution satisfy?
• What are the performance implications under high user loads?
• How should failed authentication attempts be monitored and logged?
• What automated tests should validate the implementation?

These questions reveal far more than the generated code. They reveal architectural thinking. They reveal security awareness. They reveal experience. They reveal professional judgment.

The code is the outcome. The questions are evidence of competence.

Context Gives Meaning to Questions

A question cannot be evaluated in isolation. Its quality depends on the context in which it is asked.

Context includes factors such as:

• The business objective
• The industry
• Regulatory obligations
• Organisational priorities
• Technical constraints
• Available resources
• Acceptable levels of risk
• Customer expectations

Consider the question:

"How should we implement customer authentication?"

For a banking platform, the context demands questions about fraud prevention, regulatory compliance, encryption, auditability, and identity assurance.

For a university student portal, the emphasis may shift toward usability, cost, and ease of integration.

The technical problem appears similar. The context is fundamentally different.

Without context, AI generates generic answers. With context, AI generates relevant solutions.

Perspective Reveals Competence

Context explains where the problem exists. Perspective explains how professionals interpret the same problem.

Consider the same authentication feature:

A Software Developer may ask:

• Which framework should we use?
• How should exceptions be handled?
• What unit tests should be written?

These questions demonstrate implementation expertise.

A Technical Lead approaches the same feature differently:

• Will this architecture scale as the platform grows?
• How will this integrate with existing services?
• Are we introducing unnecessary technical debt?
• Can other development teams easily maintain this solution?

These questions demonstrate technical leadership rather than coding ability.

A Security Architect asks another set of questions:

• What attack vectors are possible?
• Which authentication standards should be adopted?
• How should credentials be protected?
• What audit trail is required?

These questions demonstrate risk mitigation and regulatory compliance awareness.

A Product Owner sees a different problem entirely:

• Does this improve the customer experience?
• What business value does this deliver?
• Which customer needs are being addressed?
• Is this the highest priority feature?

These questions demonstrate value alignment and strategic prioritization.

Every professional is looking at the same outcome. Each asks different questions because each carries different responsibilities.

The AI-generated code may be identical. The questions reveal entirely different forms of competence.

This suggests that professional maturity is not demonstrated simply by producing better answers. It is demonstrated by asking better questions from the appropriate perspective.

The Chain of Inquiry Behind Every Outcome

Every meaningful outcome is preceded by a chain of inquiry.

The sequence of questions determines:

• What information is gathered
• Which assumptions are challenged
• Which alternatives are explored
• Which risks are identified
• Whose perspectives are considered
• And ultimately, which decisions are made

Rather than evaluating only the deliverable, organisations could evaluate the reasoning process that produced it.

This does not mean exposing an individual's private internal thought process. Instead, it means documenting the explicit questions that framed the problem, guided the interaction with AI, and influenced the final outcome.

Such a record provides professional accountability. It allows colleagues to understand why decisions were made, enables others to learn from the reasoning, and improves transparency when AI is used in decision-making.

Questions as a New Organisational Asset

Knowledge management has traditionally focused on preserving documents, reports, software, models, and decisions.

Perhaps organisations should also preserve the Question Trail that led to those outcomes.

Imagine opening a design document and seeing not only the final architecture but also the key questions that shaped it.

Imagine reviewing a business strategy together with the questions that challenged assumptions, explored alternatives, and evaluated risks.

Imagine examining AI-generated code alongside the questions relating to architecture, security, maintainability, performance, and testing that guided its creation.

These Question Trails would become valuable organisational knowledge. They would preserve expertise that is often lost when only the final deliverable is retained. More importantly, they would help explain why a particular solution was chosen rather than simply documenting what was delivered.

Measuring Competence Through Question Trails

If Question Trails become part of the deliverable, organisations gain a richer way to evaluate competence.

Instead of asking:

"Did this employee produce a good solution?"

They could also ask:

• Were the questions appropriate for the business context?
• Did the questions reflect the responsibilities and perspective of the individual's role?
• Were assumptions identified and challenged?
• Was evidence requested before conclusions were drawn?
• Were alternative solutions explored?
• Did the questions reduce uncertainty?
• Did they improve the quality of the final decision?

These questions suggest that the quality of inquiry can itself be assessed.

A Question Trail could be evaluated using dimensions such as:

The quality of the outcome remains important. But the quality of the questions provides a much deeper insight into the quality of the thinking.

In the Age of AI, answers may become increasingly similar. Question Trails will reveal the difference between someone who merely used AI and someone who exercised expertise, judgment, and professional responsibility.

Perhaps that is the future of competence—not simply evaluating what people create, but understanding the context, perspective, and questions that guided them there.