Available for new assignments from September 2026
AI integration in .NET landscapes
Dutch enterprise runs on .NET. The AI wave comes from the Python and startup world — and doesn't know the enterprise reality of legacy, compliance and release processes. I work exactly at that intersection: building LLM functionality inside existing .NET systems, in a way that survives production.
The fourth transition
I have guided transitions like this before: from WebForms to MVC, from SVN to Git, from a release every two weeks to continuous deployment. The same recipe every time: first prove it works with one concrete piece of software, then set up the programme to bring the entire landscape along. AI is the fourth — and biggest — step in that series.
During my sabbatical I immersed myself in it: from how LLMs and BERT work and are (post-)trained, to building my own system with vector search, local Whisper transcription, structured-output extraction and BERT classification. That deep-dive continues — including Semantic Kernel and the Microsoft Agent Framework, the go-to frameworks for agentic workflows in .NET.
What I build
LLM functionality that takes work off your hands, within your existing systems and processes:
Triage & categorisation
Automatically assessing, routing and prioritising incoming e-mails, tickets or requests — with a small, fast classification model (BERT) where that is cheaper and more consistent than an LLM call.
Data extraction with structured output
Turning unstructured text — documents, conversations, forms — into typed, validated data that your systems can process directly.
RAG over company data
Question answering and summarisation over your own documentation and data, built on vector search. Retrieval-augmented generation in .NET, within your own walls.
Agentic workflows
Multi-step AI processes that call tools and complete tasks. I offer this as an approach under construction: I use the patterns and tooling daily, and a public demo project in modern .NET is in development.
No demos, but production — as a way of working
That is a promise about how I build, not a claimed track record: my first LLM feature at a client has yet to go live, my production discipline is 18 years old. Systems I built have been carrying order fulfilment at a telecom provider for years; I set up the test suites and CI/CD pipelines that make that possible myself. I hold AI functionality to that same standard:
- Making structured output robust instead of hoping the answer parses correctly
- Small, cheap models (classification) alongside LLM calls where cost, latency or consistency call for it
- Testable and manageable: AI behaviour you can validate before it goes to production
- First one working proof in your landscape, then scale up — just like every previous transition
The enterprise reality is part of that: many organisations won't or can't send data to public AI services. I know that story from the inside — at my most recent assignment (Odido) the use of AI was prohibited, and my own knowledge system runs on local transcription for exactly that reason. In practice, the road to "secure within your own walls" runs through Azure OpenAI and the Azure AI stack; that is where my deep-dive is focused.
Bringing teams along in AI
Building AI functionality is half the story; the other half is a team that uses AI tooling effectively and responsibly. As a team lead I have guided quality and process transformations through teams before, and Copilot and Claude Code are my daily tools. Within an assignment I take that adoption along: from working agreements and review practice to guarding the architecture of AI-generated code.
Proof: my own R&D instead of promises
My knowledge system — honestly labelled as my own R&D project, not a client assignment — shows the full pipeline: audio → local Whisper transcription → LLM extraction with structured output → a knowledge graph with vector search. The architecture choices and trade-offs are described in the case.