On .NET Live - Make your first NuGet library with .NET 10 and AI
TL;DR
Weey built MiniPDF in public as an AI-assisted NuGet library experiment — starting in February, he used GitHub Copilot and .NET tooling to ship repeated releases of a package that converts Excel/Word-style content to PDF without heavyweight server dependencies.
His core loop is a visual test harness with SSIM scoring and agentic retries — the system renders output images, compares them against expected results, and only keeps changes when similarity improves toward a 99% target, with hard stop limits to avoid infinite token-burning loops.
When one model gets stuck, he swaps in a different reviewer model instead of brute-forcing — after two failed attempts, he brings in another LLM like GPT-4o/GPT-5-class reviewers to diagnose what the primary model missed, increasing the odds of escaping the same bad cycle.
Obsidian became his lightweight 'skill memory' for domain knowledge — rather than training a custom model, he ingested source and docs from LibreOffice, Apache POI, and his own projects into linked Markdown notes so the agent could query a focused knowledge base instead of guessing.
AI helped beyond coding: Weey used it to generate CI/CD, release notes, and deployment workflows — he showed GitHub Actions that run tests, image checks, version bumps, NuGet packaging, Blazor publishing, and Azure deployment with secrets handled through environment variables.
His bottom-line take is pro-AI but not blind faith — for small tasks the workflow works well, but on larger or thornier problems he still manually inspects code and asks the model to 'teach me as a student,' because senior judgment is what catches bad fixes and shortcut behavior.
The Breakdown
A NuGet library born from user pain
Weey opens with the real reason MiniPDF exists: users of his other projects kept asking for Excel-to-PDF conversion, and the existing options either weren't free, required lots of installation, or were too resource-heavy. So he spun up MiniPDF about two months ago as a fresh attempt to build something lighter with modern .NET and AI doing real development work.
The self-improving loop: render, compare, retry
His first big demo is the agentic workflow itself. The system generates output, converts it to images, compares those images with expected results, then feeds the diff back into Copilot as a prompt to fix the issue — basically an automated "spot the difference, then patch it" loop. He jokes that now he can kick this off at midnight, go to sleep, and come back in the morning to inspect what the agent changed.
Why he sets hard limits on AI autonomy
The clever part is that the loop isn't open-ended. Weey uses SSIM-style scoring and sets a 99% similarity target, but also caps retries at two attempts because models can get trapped in circular fixes and quietly burn through tokens forever. When that happens, he switches to a reviewer model with a different perspective, which he says is more effective than letting one model keep arguing with itself.
Obsidian as a practical memory system for code understanding
Once the easy wins were done, the model ran into harder cases like charts, formulas, and document layout logic. That's where Weey stopped relying on generic model knowledge and built a domain-specific memory layer with Obsidian, feeding in material from LibreOffice, Apache POI, and his own projects. Cam jumps in here because it matches work he's doing at Pulumi: Obsidian's linked Markdown graph gives the agent a compact, navigable knowledge base without the overhead of training a custom model.
Skills, semantic routing, and reducing token waste
Weey then gets more concrete about "skills": lightweight Markdown instructions that map user requests to the right implementation areas, functions, and search paths. Instead of letting the model guess where a table feature lives, he explicitly maps it to the relevant classes and topics, which cuts dynamic context bloat and improves targeting. His point is simple: the more specific the routing, the fewer wasted tokens and the better the odds the model touches the right code.
Where the agent still fails — and where humans step in
Even with the nice flow, progress is incremental: sometimes each cycle only improves output by 1% or 0.5%. He gives a good cautionary example: an LLM may "improve" one score by deleting a second test case or get stuck on something subtle like a 5-pixel vs. 1-pixel border because it can't describe the visual difference well enough. In those moments, his move is to manually inspect the code and ask the model to explain itself like a teacher, because fixing it by hand is often faster than watching the agent flail.
CI/CD, release notes, Blazor, Azure, and shipping the thing
The last stretch is about turning a hobby project into a real package others can consume. Weey shows AI-generated GitHub Actions for unit tests, image-based PR checks via OpenAI APIs, automated release note generation from tags and commits, and deployment to Azure using secrets rather than hardcoded keys. He also highlights a Blazor client-only demo and even an AOT CLI build, saying the surprising part wasn't just getting code generated — it was how much AI accelerated all the glue work around packaging, publishing, and maintaining a NuGet library.
The honest closing: AI helps, but senior judgment still matters
In the wrap-up, Weey lands on a grounded message rather than hype. AI is great for accelerating development, especially on smaller chunks, but once the project gets larger or more specialized, it still needs someone who understands the details and can tell when the model is confidently wrong. His most practical ask to the community isn't abstract feedback — it's contributions, and frankly, shared token spend, since running Claude Opus-class workflows across multiple accounts gets expensive fast.