Den vertrauten Stack hinterfragen

TL;DR: Der beste Technologie-Stack ist nicht automatisch der, mit dem man am längsten gearbeitet hat. Für eine Anwendung mit vielen parallelen Aufrufen zu AI-Providern war .NET in meinem Fall der bessere Fit als Laravel. AI hat mir diese Entscheidung nicht abgenommen – aber sie hat den Wechsel deutlich einfacher gemacht.

Der vertraute Weg wäre Laravel gewesen

Wenn ich eine neue Webanwendung starte, liegt Laravel zunächst nahe. Ich habe viele Jahre mit PHP gearbeitet und kenne das Ökosystem. Mit Laravel kommt man unglaublich schnell vom Fleck. Viele Dinge, die eine Anwendung früh benötigt, sind bereits mitgedacht oder werden direkt mitgeliefert. Authentifizierung ist dafür nur ein Beispiel.

Laravel ist ein gutes und vielseitiges Framework. Trotzdem hatte ich mich mit einigen Entwicklungen im Ökosystem über die Jahre zunehmend unwohl gefühlt. Das Framework wird stark vermarktet. Manche ergänzenden Services wanderten hinter Paygates. Anderes fühlte sich für mich wie zusätzliche Infrastruktur an, die früh notwendig wurde, um Eigenheiten des klassischen PHP-Ausführungsmodells aufzufangen.

Das allein wäre noch kein Grund gewesen, einen vertrauten Stack zu verlassen. Für das neue Produkt kam aber eine technische Anforderung hinzu, die diese Zweifel wichtiger machte.

Wenn viele Prozesse hauptsächlich warten

Die Anwendung soll perspektivisch mit steigenden Nutzerzahlen umgehen können. Gleichzeitig kann sie zahlreiche und potenziell häufige Aufrufe an unterschiedliche AI-Provider auslösen.

Diese Aufrufe sind vor allem I/O-Arbeit: Eine Anfrage wird gesendet, anschließend wartet der Prozess auf eine Antwort. Wenn viele solcher Vorgänge gleichzeitig stattfinden, werden Nebenläufigkeit und ein sauberes asynchrones Modell schnell zu einem wichtigen Teil der Architektur.

Natürlich kann man auch mit PHP Queues, Worker und asynchrone Verarbeitung aufbauen. Die Frage war deshalb nicht: „Kann Laravel das überhaupt?“ Die bessere Frage lautete: „In welchem Stack lässt sich die erwartete Anwendung für mich möglichst natürlich, verständlich und langfristig tragfähig umsetzen?“

An diesem Punkt war der vertraute Weg nicht mehr automatisch der beste.

Ein Hinweis, der meine Perspektive verändert hat

In einem Gespräch brachte mich ein anderer Entwickler auf einen einfachen Gedanken: Wenn AI mich beim Einstieg in neue Technologien unterstützt, muss meine bisherige Erfahrung nicht mehr das stärkste Auswahlkriterium sein.

Die Sprache wird dadurch nicht bedeutungslos. Auch Erfahrung, Ökosystem und Betrieb verschwinden nicht aus der Entscheidung. Aber ich kann stärker danach fragen, welche Technologie am besten zu dem Problem passt, das ich tatsächlich lösen möchte.

Dieser Gedanke hat bei mir etwas ausgelöst. Die grundlegenden Programmier- und Architekturkonzepte waren mir vertraut. Auch das Daten- und Domain-Modell änderte sich durch die Sprache nicht grundlegend. Was mir fehlte, waren vor allem Details des neuen Technologie-Ökosystems – und genau dort konnte AI sehr gut unterstützen.

Warum es .NET wurde

Für .NET kamen in meinem Fall mehrere Vorteile zusammen:

• ein starkes Modell für asynchrone I/O und parallele Vorgänge,
• feste Typisierung,
• gute Möglichkeiten zur Generierung von API-Clients,
• eine für meinen Anwendungsfall attraktive Laufzeit,
• ein großes, langfristig getragenes Ökosystem,
• und architektonischer Spielraum.

Besonders angesprochen hat mich der aktuelle Trend zur Vertical Slice Architecture. Domain-Driven Design und Clean Architecture kannte ich bereits, empfand vollständige Ausprägungen davon für mein Vorhaben aber als zu komplex. Vertical Slices wirkten auf mich wie ein pragmatischer Sweetspot: genug Struktur, um das Produkt sauber wachsen zu lassen, ohne früh ein großes Architekturgebäude errichten zu müssen.

Ich hatte durch meine Arbeit bei MetaLevel außerdem bereits etwas Erfahrung mit .NET. Ich war kein alteingesessener C#-Entwickler, musste aber auch nicht bei null anfangen. Das reduzierte das Risiko des Wechsels deutlich.

Und ja: Dass ausgerechnet ein Microsoft-Stack für mich so attraktiv wurde, hätte ich früher vermutlich selbst nicht erwartet.

Warum nicht Go?

Go hätte auf eine andere Weise gut zu meinem Verständnis von Software gepasst. Mir gefällt, wie die Sprache unnötige Komplexität bewusst entfernt. Ihre Konstrukte bleiben vergleichsweise einfach, Testing ist von Anfang an mitgedacht und selbst die Unterscheidung zwischen privaten und öffentlichen Namen über Groß- und Kleinschreibung ist eine angenehm direkte Konvention.

Philosophisch war Go deshalb reizvoll. Praktisch kannte ich aber weder die Sprache noch ihr Ökosystem ausreichend. Bei .NET trafen technische Eignung und vorhandene Anschlussfähigkeit besser aufeinander.

Best Fit bedeutet für mich eben nicht, auf einer einzelnen Achse den theoretischen Sieger zu suchen. Es bedeutet, technische Anforderungen, vorhandenes Wissen, Ökosystem und Umsetzungsrisiko gemeinsam zu betrachten.

AI hat die Entscheidung ermöglicht, aber nicht getroffen

Ein AI-Coding-Assistent konnte mir bekannte Konzepte in C# und .NET übersetzen. Ich konnte beliebig oft nachfragen, mir unbekannte Sprach- oder Frameworkdetails erklären lassen und gezielt in einzelne Themen eintauchen. Gleichzeitig half mir der gemeinsame Projektkontext dabei, Implementierung, Recherche und Architekturüberlegungen zusammenzuführen.

Das funktioniert für mich ein wenig wie ein konsistenter Gesprächspartner, der unterschiedliche Rollen einnehmen kann: erklären, strukturieren, recherchieren oder einen ersten Output erzeugen.

Die Verantwortung verschwindet dadurch nicht. AI-generierter Code durchläuft bei mir ähnliche Prüfungen wie ein Pull Request:

1. Der Vorschlag muss zunächst plausibel aussehen.
2. Ich teste das Verhalten manuell.
3. Ich lasse mir Code und Entscheidungen erklären.
4. Ich gleiche die Erklärung mit meinem Wissen und dem konkreten Kontext ab.
5. Fehler und Unstimmigkeiten werden korrigiert.

AI war deshalb nicht der Grund, .NET zu wählen. Sie hat die Wissenslücke so weit verkleinert, dass ich eine fachlich sinnvolle Entscheidung auch mit begrenztem Risiko umsetzen konnte.

Der vertraute Stack ist nur eine Option

Ich würde aus meiner Entscheidung keine allgemeine Empfehlung für .NET ableiten. Laravel ist weiterhin ein sehr produktives Framework. Go bleibt für mich eine interessante Sprache. In einem anderen Projekt könnte die Abwägung anders ausfallen.

Die eigentliche Erkenntnis ist eine andere: Der Stack, den ich am besten kenne, muss nicht automatisch der beste Stack für die nächste Idee sein.

Wenn die grundlegenden Konzepte sitzen, kann AI den Transfer in ein neues Ökosystem erheblich erleichtern. Dadurch wird es realistischer, eine Technologie anhand des Problems auszuwählen – und nicht nur anhand der eigenen Gewohnheit.

Das ist kein Freifahrtschein für beliebige Technologieexperimente. Es ist eine Einladung, die vertraute Antwort gelegentlich noch einmal zu hinterfragen.