Reflection serialization for private internal SDKs
03 Mar 2026
Elyse Holladay, host of the “On Theme: Design Systems in Depth” podcast, had Noelle Lansford on the 2026 predictions episode as they tried to work out what it’d look like for a nondeterministic programming assistant to help you build out of deterministically executable design system component source code libraries and such. I frantically searched a bigger question about private internal SDKs in general (of which a design system component library is one such example):
“Crud. What are enterprises gonna do about internal, private SDKs? Context is small, tokens are expensive, and because they’re internal, models aren’t trained on them as part of their corpus like models are trained on public SDK APIs. I feel like models are gonna have to do so much effort to make good use of internal SDKs like design system component libraries.”
After much arguing with the LLM where it suggested some insanely too-complicated DIY abstraction layers, ultimately it used the phrase “reflection” when talking about the concept of making it easy to “introspect” about the nature of a codebase written in a given programming language.
Reflection – I’d forgotten about that word!
“Serialization” is another handy one – the act of taking something that’s in-memory and saving it off into a file that can be transferred around.
And guess what? It turns out that the “Compodoc” Node.js library for automatically generating easy-for-humans-to-read HTML documentation about Angular codebases also has an --exportFormat 'json' flag available.
For documenting reusable libraries/SDKs, getting an LLM to be able to read the importable SDKs’ documentation might be a bit of jumping through authentication and authorization hoops to get an LLM to be able to read the importable docs.
But within a codebase, a person could, theoretically, have CI/CD do a secondary commit after push or something – or maybe a pre-commit hook – that runs npx compodoc ... --exportFormat 'json' and writes it straight into the codebase. Kind of like some teams let CI/CD pipelines auto-clean-up their root README.md file for them with fresh diagrams, etc. That would probably really improve the performance and accuracy when trying to let an LLM take a look at the “whole codebase at a glance” before setting about having the LLM help you fix it up, wouldn’t it? (Compared to having it actually read every file starting at the root of the repository. I mean, you could do that, too, if you needed to for a weird issue, but theoretically this would be almost like an OpenAPI spec but for the code you’ve written within a programming language rather than the web HTTP API URLs you’ve published as microservices.) It’d be a sort of “readme for machines,” just like an OpenAPI spec.
Now I wonder what other programming languages have documentation generation frameworks with a mode that publishes the results stripped-down-for-efficiency (no visual HTML styling) in a single-file format.
