Anand Naidu is a pioneer in the intersection of agentic workflows and software architecture. As we navigate the complexities of 2026, his work with XMLUI and Model Context Protocol servers has redefined how we view the relationship between code and documentation. He treats every failed AI search not as a minor annoyance, but as a critical bug that demands a testable fix, bringing a new level of rigor to the development lifecycle. This conversation explores the transition from passive documentation to active, testable assets designed for both humans and AI agents. We discuss the technical debt of missing “How To” guides, the use of MCP logs to measure documentation efficacy, and the paradigm shift where agents help build the very instructions they need to function.
When an AI agent fumbles a seemingly simple task—like converting a select widget to a radio group—what does that tell you about the current state of your technical documentation, and how do you address that failure?
In our work with Bram, a desktop app built on the XMLUI framework, we witnessed Claude attempt a simple conversion from a select widget to a radio group and stumble because it couldn’t find a verified “How To” example. To me, that fumbled task isn’t just a minor delay; it’s a documentation bug that needs a rigorous fix, just like a broken line of code. We immediately file an issue and direct an agent to write the missing document to bridge that gap. When I see an agent missing a document that should exist, I feel that friction personally, and I know we have to expand our catalog to ensure the system remains reliably learnable. This process transforms documentation from a literary exercise into a systematic discipline where the absence of a document is treated with the same gravity as a functional error in the software.
How are you leveraging Model Context Protocol logs to transform documentation from a static resource into a measurable, testable software component?
The MCP logs are our primary diagnostic tool because you simply cannot improve what you cannot measure. For instance, we analyzed logs from an agentic session where two specific searches occurred at 21:12, both of which were misses that returned irrelevant “form-adjacent noise” with a low relevance score of 0.7. After we treated this as a bug and added the necessary “How To” document, we ran the same searches and saw the relevance score skyrocket to 4.2, which is exactly six times higher than the original result. This ability to pin versions of the documentation and conduct direct A/B comparisons allows us to prove that a fix is working. It turns the act of writing into a verifiable engineering task, ensuring that our catalog of hard-won patterns is actually discoverable by the agents who need them most.
You’ve mentioned the idea of reverse-engineering patterns from existing application code; could you explain the process of using subagents to identify what a developer—or another agent—might need to search for?
We treat a portfolio of real applications as a living inventory of patterns that someone has already spent time discovering and implementing. To scale our documentation discipline, we fan out subagents across these applications—sometimes five or more at a time—to identify the top patterns a developer would likely search for in a “How To” catalog. The agent analyzes the code to find these successful recipes and then runs synthetic MCP searches to see if the existing documentation would have actually led them to that solution. If the search returns a weak match or a miss, we know exactly where the documentation gap lies. It’s a proactive way to build out the library by looking at what was actually built, rather than just guessing what users might want to read.
Tracking the “struggle” between a developer and an AI agent seems like a high-level challenge; what are the signals you look for in session logs to identify when a team is hitting a dead end?
A missing document only becomes a critical problem when a human-agent team flails and hits a dead end doing something that should have been easy. We attempt to correlate session logs with MCP logs by timestamp to surface these moments of frustration, though doing this reliably is still a significant technical hurdle. I haven’t yet reached a point where agents can perfectly surface every episode of struggle, but the signals we do find in the logs are incredibly useful for pinpointing where the search for “choose one of two options” or “horizontal selector” failed to yield results. When we see a team rephrasing queries moments apart, attacking the problem from the UX side instead of the component side, we know we have a usability gap in our metadata. Making full-text search available to agents in apps like Bram is a step toward making these moments of flailing more visible and, ultimately, fixable.
What is your forecast for the future of technical writing as a discipline now that documentation is being treated with the same systematic rigor as application code?
I believe we are entering an era where the distinction between a software engineer and a technical writer will continue to blur, as documentation is now an integral software component rather than a post-script. We are moving away from docs as “literary works” and toward docs as functional modules that we direct agents to build, requiring both editorial precision and engineering chops. In the coming years, I expect to see the “How To” catalog become the most valuable asset in any framework, continuously expanded and verified by automated subagents that measure search relevance in real-time. For the reader, this means that the “struggle” of learning a new tool will be drastically reduced, as the documentation will have been pre-tested against the very agentic workflows you use to build your apps. This shift makes the role of the writer far more impactful and, frankly, more fun, as we finally bring scientific rigor to the way we communicate technical knowledge.
