Doing GenAI in pure .NET: why I don't run a Python stack on the side
The 2026 default reflex for GenAI is 'a Python micro-service next door'. On most of my products I don't have it - RAG, embeddings, scoring and guardrails run in C#/.NET. Why that choice holds, and the one exception where I accept a Python sidecar.
Related projectVouch - security questionnaire automation with cited RAG answersEnglish summary
A Python sidecar means a second full stack to operate, secure, deploy and monitor. For the core of an enterprise GenAI product (RAG, embeddings, guardrails, orchestration) the .NET ecosystem is now enough - Microsoft.Extensions.AI, pgvector, ML.NET, ONNX Runtime. The single exception I own: specialized foundation models (e.g. time-series), where an isolated Python sidecar is justified - for the model only, never for business logic.
Key takeaways
The 'GenAI = Python service' reflex carries a real operating cost.
Pure .NET covers RAG, embeddings, guardrails and orchestration today.
Python stays a targeted tool for foundation models, not the default.
Original long-form article
The long technical article is available in French with code, context and detailed examples. The English page gives the recruiter-readable summary and the main engineering points.
Open the French articleNext step
Sounds like something you need shipped? Let's talk.
I take on critical technical work — from scoping to production, no debt or lock-in once it's handed over. Fastest way to see if it fits: a 30-minute call.
I reply within 24h — often sooner.