Reverse engineering has always fascinated me. There's something intriguing about examining an existing system and working backwards to understand how it was built.
Recently, I came across Reverse Engineer Anything (REA), an open-source project featured in a video by Low Level. It explores how AI agents can help developers understand and reconstruct existing software.
Impressive stuff. But it also made me wonder about something beyond software.
What if the thing we're reverse engineering isn't a program, but someone's expertise?
Reverse engineering beyond code
Organisations accumulate technical reports, architectural decisions, troubleshooting guides, and years of documented experience. These aren't merely documents. They're the results of human reasoning, refined through trial and error.
Imagine hundreds of technical assessments, each containing observations and recommendations shaped by experienced specialists. An AI examining them might identify recurring patterns and infer parts of the methodology behind them.
In a sense, that's reverse engineering too: reconstructing professional methods from their results.
There is research exploring something similar. Beyond codification, published in 2026, draws on interviews across 52 organisations. It describes AI learning patterns in how experts respond to different situations, without requiring every part of their knowledge to be written down first.
That goes beyond reading finished reports. It involves learning from practice, where some of the knowledge missing from a document may still be visible. The findings suggest possibilities for sharing expertise more widely, with limits that depend on the setting.
The output isn't the understanding
Working backwards from a finished result has a limitation: you don't necessarily know why it turned out that way.
An AI might discover that a particular metric consistently leads to a certain recommendation, without knowing that the original decision reflected an incident years earlier, an undocumented exception, or a deliberate compromise.
The result might be correct. The reasoning behind it might be incomplete.
The same distinction appears in software engineering. Two solutions may behave identically under normal circumstances, yet diverge when permissions change, systems fail, or unexpected situations arise.
AI-assisted solutions may also improve on the original or reveal inconsistencies that humans overlooked. But reproducing the results of expertise isn't necessarily the same as reproducing the expertise itself.
As working implementations become easier to produce, we'll need to distinguish what a system demonstrably does from what we assume it understands.
Standing on invisible shoulders
Almost everything we build rests on something that came before it. Developers rely on languages, libraries, and contributions from people whose names they may never know. Professional knowledge evolves similarly: someone develops a methodology, others refine it, and eventually someone automates part of it.
But AI introduces an interesting paradox.
The more successful the automation becomes, the less visible the work that made it possible may become.
New employees might learn to use an assessment system without encountering the original methodology. Eventually, the automation becomes the reference point, while its history, assumptions, and limitations become harder to trace.
The 2026 paper Towards scaling expertise with generative AI proposes design principles for capturing and passing on expertise. It emphasises expert involvement, verification, and helping successors develop their own judgement. Its feasibility checks also distinguish mechanisms that prompts can approximate from safeguards requiring persistent state or platform integration.
That distinction matters. Preserving expertise should help the next person learn to reason, rather than simply become dependent on a tool's answers.
Building upon existing work is how progress happens. I'd like us to preserve enough of the trail that people can question it, understand its limits, and carry it further.
Bringing existing knowledge into the AI era
Before AI can work with existing knowledge, it needs access to it. That knowledge is scattered across documentation, source code, databases, conversations, and countless other systems. Making it accessible creates opportunities, but access must remain subject to appropriate permissions and organisational control.
This feels particularly relevant for organisations using Confluence Data Center. Atlassian is increasingly focused on cloud and AI, with Data Center approaching end of life in 2029. But while the technology has a lifecycle, the knowledge accumulated within it does not necessarily lose its value. Years of decisions, explanations, and lessons learned remain worth preserving and building upon.
With that in mind, we've developed MCP for Confluence Data Center, a native Java plugin that connects compatible AI agents to existing Confluence content through the Model Context Protocol (MCP). It respects the authenticated user's permissions, with administrator controls over space access and content changes.
Teams can then use AI agents to explore their existing Confluence knowledge without first migrating it elsewhere.
Making knowledge accessible isn't the same as understanding it. How reliably AI can reconstruct and apply the expertise behind that knowledge remains a separate challenge.
Remembering what made it possible
I'm enthusiastic about what AI-assisted reverse engineering might enable. Experience that would otherwise disappear when people leave could become more accessible, and work that takes days might eventually be completed reliably in minutes.
That's progress worth embracing. But I hope we become equally good at preserving the understanding behind the results: why a method works, where it breaks down, and when its recommendations deserve trust.
Perhaps the greatest promise is that we can build upon knowledge that might otherwise remain inaccessible or eventually be lost.
The future will undoubtedly be built on the work of the past. The question is whether we'll still remember what we're building on.