The Next Decade of Knowledge Engineering
By 2031 and 2036, AI may produce more knowledge structures automatically while shifting specialist work toward evaluation, coordination, and responsibility.
The record up to this point is history. From here, the verbs change. What follows is a conditional account of 2031 and 2036, not a forecast with a known number of jobs at the end of it.
Several trends are visible already. Language models can propose classifications, extract relationships, and draft explanations. Organizations also need to know which source supports an answer, which rule an agent applied, and who can correct a bad one. The extent to which AI will carry that work reliably remains uncertain.
The distinction matters. A machine that can generate a plausible ontology in minutes has changed the cost of a first draft. It has not necessarily changed the cost of discovering that two teams use the same term differently, or that an exception applies only to an older part version.
2031: less entry, more examination
By 2031, I expect AI assistance in knowledge construction to be ordinary. A practitioner may spend less time entering relationships one by one and more time examining proposed changes. They will need to ask whether an extracted claim is supported, whether a classification preserves an important distinction, and whether a revised concept would alter decisions elsewhere.
This can make the work more consequential without guaranteeing a larger occupation. Automation may remove repetitive tasks that once trained newcomers. It may also make it feasible to maintain knowledge resources that organizations previously left to decay. Which effect dominates depends on institutional decisions about quality, not capability demonstrations alone.
The practical division may become clearer: knowledge production creates or revises candidate records; knowledge assurance establishes whether those records are fit for a use. The same person may do both. The distinction helps a team avoid treating a fluent machine-produced record as an accepted fact.
2036: shared services and conflicting contexts
By 2036, the harder problem may be coordination across many systems. A procurement agent, design tool, compliance workflow, supplier system, and project archive might all use the phrase “approved component.” Do they mean the same thing? Which one has authority? What happens if approval changes while a project is under way?
I can imagine a maintained knowledge service that records such meanings and dependencies, proposes updates when evidence changes, and shows which decisions an update might disturb. Some organizations may own that service directly. Others may buy most of it from platform providers. Either arrangement creates a need to understand who can inspect, revise, and move the underlying knowledge.
There is a counter-scenario. General-purpose AI might become sufficiently dependable that organizations maintain fewer explicit models. Specialist work could concentrate in demanding domains and oversight. The technology alone will not settle the institutional choice.
The recursive question
Now suppose an AI system helps improve the process that builds the next system. It proposes a better evaluator, a richer knowledge model, or a new way of finding evidence. This is a bounded form of recursive improvement. Open-ended recursive self-improvement would be a much stronger claim, and its arrival is uncertain.
The knowledge question appears before any dramatic future does. How does the system establish that its proposed improvement is better? Which test cases count? What does the evaluator measure? Can it distinguish a novel discovery from a confident error? Can it preserve the conditions under which an older result was valid?
If a system changes the criteria by which its successors are judged, the loop becomes an epistemic problem as well as a software problem. This is why recursive self-improvement can be understood, in part, as recursive knowledge engineering: revising the mechanisms that acquire, represent, test, and apply knowledge. The point is not to claim that every such loop will become autonomous. It is to identify the questions any trustworthy loop must answer.
The most useful signposts are mundane. How often are machine-proposed changes accepted after review? How much time does review take? Can a team trace the effects of a changed definition? Does the knowledge move between providers? Who notices when a system keeps applying yesterday’s rule? Announcements about model capability matter less than those observed answers.
