I’m Martin, CTO at Integrated Worlds GmbH in the Stuttgart region. I’ve been writing production .NET code since Framework 2.0 — back when SOAP was still considered modern and ORMs were a heated debate. A lot has changed since then. My opinions have changed too, usually because I was wrong about something.
Before Integrated Worlds, I was Director of Consulting Services at CGI, leading teams through architecture decisions and digital transformation projects across multiple industries. These days I set technology strategy and stay close enough to the code to feel the consequences of those decisions firsthand.
I’m a Microsoft Certified Trainer and IHK-certified instructor, maintain several open-source NuGet packages, and write about what I’ve actually learned rather than what sounds good in theory.
Nearly two decades of production work leaves marks. Here’s where I’ve built up depth and, frankly, strong opinions:
.NET and C# — I’ve tracked this ecosystem from the framework era to .NET 10. Source generators, Roslyn analyzers, performance engineering, testing strategies, static analysis. I know what actually improved over the years and what just changed names.
Cloud-native architecture on Azure — AKS at scale, multi-cluster networking, zero-downtime upgrade strategies, cost governance, observability. I’ve spent enough time in Azure to know the gap between what it can do and what you should actually use.
DevOps and supply-chain security — GitHub Actions, dependency management, container security, Bicep-based infrastructure compliance. The organisational side matters as much as the tooling.
Application security and privacy — Azure Key Vault, managed identities, GDPR-relevant .NET patterns, data minimisation, AI coding tool content exclusions. Security that works in practice, not just in architecture diagrams.
Engineering culture — What AI coding assistants actually change about software quality (less than the hype, more than the skeptics admit), how to introduce static analysis without poisoning team morale, and when “best practices” are earned principles versus cargo-cult repetition.
As CTO I stay close to the code. I write, review PRs, debug production issues, and mentor — because technology leadership that operates purely from a distance eventually loses touch with the real cost of decisions.
As a trainer I focus on fundamentals that outlast the current framework cycle. Static analysis, testing discipline, performance patterns, maintainable architecture. The things that prevent fires, not just the things that look good in a job posting.
As an open-source maintainer I publish packages that solve problems I’ve hit repeatedly. Knowing that strangers depend on your code is one of the better ways to raise your standards.
I’ve over-engineered systems that should have been simple. I bet on Silverlight and WCF. I built “flexible” architectures that were really just complicated ones. I’ve shipped code I’m not proud of.
Here’s what held up after all that:
Quality isn’t optional — analyzers find bugs in milliseconds, tests prevent regressions, and neither is slower than a production incident
Fundamentals outlast frameworks — the patterns and principles stick around long after the tools are deprecated
Context beats dogma — “best practices” always depend on your team, domain, and actual constraints
Evidence beats intuition — measure, benchmark, validate; don’t just decide
Pragmatism wins — architecture that ships beats architecture that’s perfect on paper
Everything here comes from production systems and real teams, not documentation rewrites. I’m skeptical of buzzword-driven development and allergic to advice that’s never been tested under load or deadline. If something doesn’t hold up, I’ll say so.
The topics I keep returning to: .NET and C# performance and evolution, Azure and AKS architecture decisions, DevOps and supply-chain risk, application security and GDPR implementation, what AI coding tools actually change (and what they don’t), and the economics of technical debt and code quality.
I write for developers, architects, and operators who maintain production systems and care about getting it right — not just getting it shipped.
The code you create is a valuable legacy, so it’s important to build it carefully.
Your [Authorize] attributes give you a false sense of security. ISO 27001 auditors see right through it.
I’ve reviewed dozens of ASP.NET Core apps that authenticate flawlessly — then scatter role strings across business logic, skip audit logs, and wonder why they fail compliance. Here’s the pattern that kills audits, and how to actually fix it.
ISO/IEC 27001, 27017, and 27701 compliance used to be something you handed off to a compliance team. Now you write the infrastructure, configure the secrets store, and decide what the API returns — and those decisions are the compliance. This series translates nearly 30 controls across three standards into working .NET code and Azure configuration, because the gap between certified and actually compliant lives in your codebase.
Cloud-native .NET development has transformed ISO/IEC 27001, 27017, and 27701 from abstract compliance requirements into concrete daily coding decisions. This guide shows .NET developers how security standards directly map to Azure Key Vault integration, Azure AD authentication, and proper logging—with real code examples demonstrating compliant vs. non-compliant implementations.
Throughout this series, we’ve established that AI-generated code without understanding creates productivity illusions that collapse in production (Part 1), and that the feedback loop between code and reality—compilation, testing, profiling, production—sharpens thinking in ways AI can’t replicate (Part 2). Now we confront the practical question: What defines professional software engineering when code generation becomes trivial? This final part examines the irreplaceable skillset: understanding execution characteristics (recognizing allocation patterns that cause GC pressure before deployment), asking questions AI can’t formulate (What’s the failure mode when this service is unavailable?), recognizing when plausible AI solutions diverge from correct ones, debugging production failures AI has no execution model to reason about, and evaluating maintainability for code that becomes tomorrow’s burden. We explore why prompt engineering optimizes for speed while architecture optimizes for survival, why “AI productivity” often means faster technical debt accumulation, and why the economic reality favors organizations that measure system reliability over lines of code generated. The feedback loop can’t be automated because closing it requires learning from production failures and applying that knowledge to prevent future ones—the irreplaceable discipline that defines real professionals in 2026 and beyond.
A Swabian habit teaches a DevOps lesson: open windows fully and often, or invisible decay accumulates. Stoßlüften isn’t about comfort—it’s about forcing systems to prove they’re healthy. Regular restarts, infrastructure-as-code, and reproducibility checks catch the problems that green metrics miss.