Greenfield-Entwicklung für Microsoft .NET mit GPT‑5.6 in ChatGPT und Codex

Greenfield ist die günstigste Ausgangslage für einen Coding-Agenten

Bei einer Neuentwicklung muss ein Agent weniger historische Ausnahmen erraten. Es gibt keine seit Jahren gewachsenen Kompromisse, keine impliziten Abhängigkeiten zu längst abgelösten Plattformen und noch keine Benutzer, deren eingeübte Umwege unbemerkt zum Bestandteil des Produkts geworden sind. Architektur und Konventionen können von Anfang an lesbar gemacht werden.

Stephen Toub hat diesen Unterschied im März 2026 anhand realer Pull Requests aus dotnet/runtime und dem neueren MCP C# SDK untersucht. Im Greenfield-Projekt lag die Erfolgsquote des Coding-Agenten bei 77,3 Prozent, im über Jahrzehnte gewachsenen Runtime-Repository bei 67,9 Prozent. Der Median bis zum Merge betrug 17,4 statt 50 Stunden, und es waren deutlich weniger menschliche Eingriffe erforderlich. Toub weist ausdrücklich darauf hin, dass dabei auch Größe, Spezifikation und fachliche Komplexität eine Rolle spielen. Seine knappste Schlussfolgerung ist trotzdem sehr brauchbar: „The lesson is that task scope matters more than size.“¹

Das ist kein Versprechen, dass Neuentwicklung automatisch gelingt. Es zeigt, welchen Wert ein klar begrenztes System, eine verständliche Spezifikation und moderne, einheitliche Muster für einen Agenten haben. Genau diese Voraussetzungen lassen sich bei einem neuen .NET-Projekt bewusst herstellen.

Das Konzept entsteht im Gespräch

Am Anfang steht kein Lastenheft, das ein Agent wortgetreu in Klassen übersetzt. Wir beginnen mit dem Problem, den zukünftigen Benutzern und den Entscheidungen, die die Anwendung unterstützen soll. ChatGPT kann dabei die Rolle eines hartnäckigen Gesprächspartners übernehmen. Es fragt nach Ausnahmen, widersprüchlichen Erwartungen, Zuständigkeiten, Datenquellen, Sicherheitsgrenzen und dem Zustand, der nach einem abgebrochenen Vorgang erhalten bleiben muss.

Dieses Gespräch sollte nicht möglichst schnell zu einer fertigen technischen Lösung führen. Sein Wert liegt darin, Begriffe zu klären und Zusammenhänge sichtbar zu machen. Mittlerweile können dabei direkt Mermaid-Diagramme entstehen. Ein Ablaufdiagramm macht einen Benutzerweg prüfbar, ein Zustandsdiagramm legt fehlende Übergänge offen und ein Komponentendiagramm zeigt, wo ein zunächst einfach klingender Wunsch mehrere Verantwortungsbereiche berührt. Die Diagramme gehören anschließend zum Projektwissen und werden mit dem Konzept weiterentwickelt.

Ein gutes Konzept beschreibt den Zweck, die Benutzer, die wichtigsten Abläufe, die Fachobjekte, Systemgrenzen, Qualitätsanforderungen und bewusste Nicht-Ziele. Es darf offene Fragen enthalten. Klassen-, Methodennamen und jede einzelne Bibliothek müssen in dieser Phase noch nicht festgelegt werden. Diese Entscheidungen hängen häufig von Mustern ab, die der Coding-Agent im vorbereiteten Repository besser beurteilen kann als in einem abstrakten Gespräch.

Kein neues Projekt startet im luftleeren Raum

Eine leere Projektmappe wirkt neutral. Tatsächlich verschiebt sie viele Grundsatzentscheidungen in die ersten Implementierungsaufträge. Jeder Agent muss dann neu entscheiden, wie Konfiguration, Fehlerbehandlung, Protokollierung, Navigation, Validierung, Datenverträge, Tests und plattformspezifischer Code organisiert werden. So entstehen früh Unterschiede, die später nur mit Aufwand wieder zusammengeführt werden können.

Wir bereiten deshalb eine Projektmappe mit Framework-Code vor. Sie enthält die wiederkehrenden technischen und fachlichen Grundlagen, ohne die konkrete Fachanwendung vorwegzunehmen. Dazu gehören die Schichten und ihre Referenzregeln, gemeinsame Build-Einstellungen, einheitliche Paketversionen, ein Start- und Konfigurationsmodell sowie überprüfbare Beispiele für typische Bedien- und Fehlerfälle.

Die Microsoft .NET-Komponenten von APLICONUS sind für diesen Zweck entstanden. Fachmodelle, Codelisten, Formulardefinitionen und kontrollierte Bedienaktionen geben neuen Anwendungen einen gemeinsamen Ausgangspunkt. Für den Agenten werden Konventionen dadurch zu vorhandenem Quelltext, Tests und Verträgen. Er muss sie nicht aus allgemeinen Empfehlungen ableiten.

Aus dem Konzept wird ein Arbeitsauftrag

Das Konzept beschreibt das System. Für einen Coding-Agenten wird daraus ein Arbeitsauftrag, der die Umsetzung über mehrere Sitzungen hinweg zusammenhalten kann. OpenAI verwendet dafür den Begriff ExecPlan. Ein solcher Plan ist kein einmal erzeugtes Pflichtenheft. Er ist ein lebendes Dokument mit Ziel, Ausgangslage, Grenzen, Entscheidungen, Arbeitsschritten, offenen Fragen und überprüfbaren Erfolgskriterien.²

Der ExecPlan muss in sich verständlich sein. Ein neuer Agent soll erkennen können, warum eine Entscheidung getroffen wurde, welcher Stand bereits erreicht ist und wie er eine Änderung prüfen kann. Bei längerer Arbeit werden Fortschritt, überraschende Erkenntnisse und bewusst verworfene Wege direkt im Plan ergänzt. Damit bleibt das Projekt auch dann anschlussfähig, wenn das Kontextfenster der ursprünglichen Unterhaltung längst nicht mehr verfügbar ist.

Wir lassen den ersten ExecPlan aus dem Konzept erzeugen und prüfen ihn anschließend wie einen Architekturentwurf. Besonders wichtig sind die Stellen, an denen der Plan stillschweigend Produktentscheidungen trifft. Der Agent darf einen technischen Weg vorschlagen. Über fachliche Bedeutung, Schutzbedarf, Verantwortungsgrenzen und die spätere Betriebsform entscheidet weiterhin der Mensch.

AGENTS.md macht die Projektregeln dauerhaft verfügbar

Der ExecPlan gehört zum Vorhaben. AGENTS.md gehört zum Repository. Dort stehen die Regeln, die für viele Arbeitsaufträge gelten: Aufbau der Projektmappe, wichtige Verzeichnisse, Build- und Testbefehle, Architekturgrenzen, Formatierung, Umgang mit generierten Dateien und die Bedingungen, unter denen eine Änderung als fertig gilt. Codex lädt diese Datei automatisch als Projektkontext. Liegt in einem Unterordner eine spezifischere AGENTS.md, gelten dort deren präzisere Regeln.³

Die Datei sollte kurz genug bleiben, um wirklich gelesen zu werden. Ausführliche Architekturentscheidungen gehören in eigene Markdown-Dateien, ebenso ein wiederverwendbares ExecPlan-Muster, die Beschreibung der Schichten, Testkonventionen oder die Regeln für Veröffentlichungen. AGENTS.md verweist auf diese Dokumente und erklärt, wann sie einzubeziehen sind.

Diese Markdown-Dateien sind kein Begleittext für den Agenten. Sie sind ein Teil der Entwicklungsumgebung. Menschen, Codex und andere Coding-Agenten arbeiten dadurch mit derselben Beschreibung dessen, was das Projekt unter einer korrekten Änderung versteht.

Anbieter-Skills bringen die Plattformkenntnis in das Projekt

Ein leistungsfähiges Modell kennt C# und verbreitete .NET-Muster. Für konkrete Plattformarbeit reicht dieses allgemeine Wissen nicht immer aus. APIs verändern sich, Projektvorlagen werden angepasst und UI-Frameworks besitzen Regeln, die leicht mit einem verwandten Vorgänger verwechselt werden. Anbieter-Skills liefern dafür gezielte Arbeitsanweisungen, aktuelle Beispiele und teilweise eigene Prüfwerkzeuge. Sie werden nur für die Technologien eingebunden, die in der Projektmappe tatsächlich vorkommen.

Microsoft .NET

Das Repository dotnet/skills enthält die vom .NET-Team kuratierten Skills und Agenten für C#, MSBuild, NuGet, Tests, ASP.NET Core, Blazor, Datenzugriff, Diagnose und weitere Bereiche. Für Codex können einzelne Skills aus dem Repository installiert werden. Eine neue Anwendung benötigt selten den gesamten Katalog. Die Auswahl sollte aus den vorhandenen Projekten und ihren Aufgaben folgen.⁴

.NET MAUI

Für eine plattformübergreifende App bietet davidortinau/maui-skills einen breiten Satz spezialisierter MAUI-Skills. Sie behandeln unter anderem aktuelle APIs, Handler, Navigation, Barrierefreiheit, Performance, plattformspezifische Aufrufe und hybride Web-Oberflächen. Gerade bei MAUI ist diese Spezialisierung wertvoll, weil eine scheinbar gemeinsame API auf Android, iOS, macOS und Windows unterschiedliche Voraussetzungen haben kann.⁵

WinUI 3

microsoft/win-dev-skills führt einen Agenten durch den gesamten WinUI-3-Arbeitsweg von der Projektvorlage über Fluent Design, Build und Start bis zu UI-Tests und MSIX-Paketierung. Das Projekt ist derzeit ausdrücklich als Preview gekennzeichnet. Für eine neue Windows-Anwendung ist es trotzdem eine wichtige Quelle, weil es WinUI 3 und Windows App SDK klar von UWP und WPF trennt und echte Prüfwerkzeuge in den Ablauf einbezieht.⁶

Angular für hybride .NET-Desktop-Anwendungen

angular/skills ist für hybride .NET-Desktop-Anwendungen mit Web-UI besonders interessant. Der Angular-Skill beschreibt Komponenten, Reaktivität, Routing, SSR, Barrierefreiheit, Formulare, Tests und CLI-Werkzeuge als zusammenhängende Plattform. Damit erhält die Web-Oberfläche eine klar definierte Grundlage, während .NET die Desktop-Integration, Fachlogik und lokale Infrastruktur übernehmen kann. Diese Ausführlichkeit macht Angular derzeit zu einer sehr gut vorbereiteten UI-Technologie für die agentengestützte Entwicklung.⁷

OpenAI-Dokumentation

Der Skill openai-docs aus dem offiziellen OpenAI-Katalog sorgt dafür, dass Fragen zu Codex, Modellen und APIs gegen aktuelle OpenAI-Dokumentation geprüft werden. Das ist sinnvoll, weil sich Fähigkeiten, Konfiguration und empfohlene Arbeitsweisen schneller verändern als die meisten Projektlaufzeiten. Der Skill führt den Agenten deshalb zuerst zur heutigen Dokumentation und erst von dort zur Antwort.⁸

Projektspezifische Skills übersetzen Architektur in Arbeitsabläufe

Anbieter-Skills kennen eine Technologie. Sie kennen nicht die Entscheidungen der neuen Anwendung. Deshalb entstehen im Projekt eigene Skills für wiederkehrende Arbeiten, bei denen allgemeine Empfehlungen regelmäßig zu falschen Ergebnissen führen.

Ein Skill kann beispielsweise festlegen, wie plattformübergreifender Code von MAUI-, WinUI- oder Web-spezifischem Code getrennt wird. Ein weiterer beschreibt die Ordnerstruktur eines C#-Projekts und verhindert, dass fachliche Verträge zufällig im ersten Projekt landen, das sie benötigt. Ein Architektur-Skill kann die erlaubten Projektreferenzen prüfen und erklären, in welcher Schicht ein neuer Dienst tatsächlich zu Hause ist.

Besondere Aufmerksamkeit verdient die Fehlerbehandlung. Coding-Agenten neigen noch immer dazu, einen erfolgreichen Hauptpfad sauber auszuarbeiten und Fehlerfälle mit einer allgemeinen Ausnahmebehandlung abzuschließen. Für eine Enterprise-Anwendung reicht das nicht. Ein projektspezifischer Skill sollte festlegen, welche Fehler fachlich behandelt werden, welche technischen Ausnahmen protokolliert werden, wie Korrelation und Kontext erhalten bleiben, welche Meldung der Benutzer sieht und wie ein fehlgeschlagener Ablauf getestet wird. Wo eine Regel zuverlässig maschinell geprüft werden kann, gehört die Prüfung in ein Skript oder einen Architekturtest und nicht nur in Prosa.

Skills sind damit die ausführbaren Teile der Projektkonventionen. Codex lädt sie, wenn ein Auftrag zu ihrer Beschreibung passt oder wenn sie im Arbeitsauftrag ausdrücklich genannt werden. OpenAI beschreibt dafür eine progressive Offenlegung: Zunächst kennt der Agent nur Name und Zweck; die vollständigen Anweisungen werden erst bei tatsächlicher Verwendung in das Kontextfenster geladen.⁸

Architekturgrenzen und Gestaltungsspielraum gehören zusammen

Die Architektur muss früh entschieden und technisch abgesichert werden. Ein Agent soll nicht bei jedem Feature neu verhandeln, welche Schicht auf welche andere zugreifen darf, wo Plattformcode liegt oder wie Fehler das System verlassen. Diese Grenzen schützen die langfristige Form der Anwendung.

Innerhalb dieser Grenzen braucht der Agent Gestaltungsspielraum. Ein Arbeitsauftrag sollte das fachliche Ziel, die betroffenen Benutzerwege, die relevanten Verträge und den erwarteten Nachweis beschreiben. Wenn er zusätzlich jede Hilfsklasse, jede Methode und jeden einzelnen Umsetzungsschritt vorgibt, verhindert er häufig die Verwendung eines Musters, das besser zur vorhandenen Plattform passt. Die Aufgabe wird scheinbar präziser und technisch zugleich schwächer.

Die richtige Enge hängt von der Art der Entscheidung ab. Architektur, Sicherheit, Datenhoheit und Abnahmekriterien benötigen klare Vorgaben. Bei einer lokalen Implementierung gibt es häufig mehrere gute Wege. Dort sollte der Agent den vorhandenen Code untersuchen, einen passenden Weg wählen und seine Entscheidung am Ergebnis messen lassen.

Codex richtet die Visual-Studio-Projektmappe ein

Nach Konzept, Arbeitsauftrag und Regeln kann Codex die Projektmappe anlegen. Dazu gehören die eigentlichen Projekte und Tests ebenso wie global.json, gemeinsame Build-Einstellungen, Analyzer, Formatierung und die Lösungsmatrix. Central Package Management hält Paketversionen an einer Stelle. Directory.Build.props und Directory.Build.targets machen gemeinsame Eigenschaften und Architekturprüfungen verbindlich. Launch Settings bilden die vorgesehenen Startkombinationen ab, damit lokale Dienste, Desktop-Anwendung und gegebenenfalls Web-UI reproduzierbar gemeinsam gestartet werden können.

Diese Einrichtung sollte nicht nur Dateien erzeugen. Codex baut die gesamte Projektmappe, startet die vorgesehenen Einstiegspunkte und führt einen ersten schmalen End-to-End-Weg aus. Gerade eine neue Projektmappe kann formal korrekt aussehen und trotzdem bereits widersprüchliche Plattformziele, fehlende Assets oder einen unbrauchbaren Startablauf enthalten. Der erste funktionierende Weg ist die Referenz für alle folgenden Arbeiten.

Danach beginnt die iterative Entwicklung

Die Umsetzung erfolgt in überschaubaren Arbeitsaufträgen. Ein Detailauftrag beschreibt einen Benutzerweg oder eine fachliche Fähigkeit, nennt die geltenden Architektur- und Skill-Regeln und legt fest, wie der fertige Zustand geprüft wird. Codex untersucht den betroffenen Teil, implementiert, baut, testet und zeigt das Ergebnis in der tatsächlichen Anwendung.

Danach folgt der Benutzertest. Der Mensch prüft Vorhandensein, Verständlichkeit und Passung zur tatsächlichen Arbeitssituation. Dieses Feedback wird zum nächsten Auftrag. Bei einer sichtbaren Abweichung sollte die Rückmeldung so konkret wie möglich sein: betroffene Seite, Zustand, erwartetes Verhalten und gegebenenfalls ein Screenshot. Der Agent kann den Ablauf dann reproduzieren, die Ursache im Code suchen und erneut prüfen.

Dieses Wechselspiel ist keine Notlösung für einen unvollständigen ersten Prompt. Es ist der eigentliche Entwicklungsprozess. Auch eine von Menschen entwickelte Oberfläche entsteht selten in einem einzigen Entwurf. Mit Codex werden die Schleifen schneller, und dadurch gewinnt die Qualität des Feedbacks noch mehr Bedeutung.

Kleine Projektmappen helfen dem Kontextfenster ‒ und erzeugen eine spätere Aufgabe

Heutige Coding-Agenten arbeiten mit großen, aber begrenzten Kontextfenstern. Eine kleinere Projektmappe reduziert die Zahl gleichnamiger Typen, möglicher Einstiegspunkte, Build-Varianten und historischer Beispiele. Der Agent findet schneller den relevanten Code und verbraucht weniger Kontext für Strukturen, die mit dem aktuellen Ziel nichts zu tun haben.

Für eine effiziente Neuentwicklung entstehen deshalb häufig mehrere kleine Projektmappen. Im besten Fall sind sie nur verschiedene Sichten auf dieselben Projekte. In der Praxis entstehen zusätzlich Prototypen, Technologieversuche und temporäre Derivate. Das lässt sich kaum vollständig verhindern, weil ein isolierter Versuch oft schneller und sicherer ist als eine frühe Veränderung des gemeinsamen Fundaments.

Diese Arbeitsteilung braucht einen geplanten Abschluss. Vor dem Übergang in die Wartung werden die tragenden Projekte in einer Gesamtprojektmappe zusammengeführt. Paketversionen, Build-Regeln, Startprofile, Architekturtests und gemeinsame Komponenten werden vereinheitlicht. Temporäre Derivate werden entweder zu ausdrücklich gepflegten Varianten oder wieder entfernt. Ohne diesen Schritt würde die günstige Greenfield-Phase den nächsten gewachsenen Bestand bereits vorbereiten.

Der Übergang in die Wartung beginnt vor der ersten Freigabe

Wartung ist keine neue Arbeitsweise. Detailauftrag, Umsetzung, Test, Benutzerfeedback und die Pflege der Projektregeln bleiben erhalten. Neu ist vor allem der Ausgangspunkt: Statt einer vorbereiteten Greenfield-Struktur liegt nun ein lebendes System mit Benutzern, Daten, Betriebserfahrungen und ersten historischen Entscheidungen vor.

Spätestens jetzt müssen ExecPlan, Architekturentscheidungen und Skills aufgeräumt sein. Temporäre Hinweise werden entfernt, wiederkehrende Fehler in dauerhafte Regeln oder Tests überführt und die Gesamtprojektmappe wird zur verbindlichen Sicht auf das Produkt. Wie diese Arbeit mit wachsendem Bestand fortgesetzt wird, beschreibt unser Leitfaden Wie plane ich eine App-Modernisierung?.

Unser Fazit im Juli 2026

GPT‑5.6 in ChatGPT und Codex ist besonders leistungsfähig, wenn eine neue Anwendung einen klaren fachlichen Rahmen und einen technisch vorbereiteten Anfang erhält. Das Konzept kann im Dialog entstehen. Der ExecPlan hält die längere Arbeit zusammen. AGENTS.md, Anbieter-Skills und projektspezifische Skills machen Plattformwissen und Projektregeln für jeden neuen Arbeitsauftrag verfügbar. Eine eingerichtete Visual-Studio-Projektmappe übersetzt diese Regeln schließlich in Quelltext, Builds und Tests.

Die entscheidende Gestaltungsaufgabe bleibt beim Menschen. Er legt Architekturgrenzen, Verantwortungen und Qualitätsmaßstäbe fest. Bei der konkreten Lösung sollte er dem Agenten so viel Spielraum lassen, dass dieser die bewährten Methoden der Plattform tatsächlich einsetzen kann. Greenfield-Entwicklung mit einem Coding-Agenten ist damit keine automatische Codeproduktion. Sie ist die bewusste Vorbereitung eines Systems, in dem Mensch und Agent schnell arbeiten können, ohne die spätere Wartbarkeit bereits am ersten Tag zu verbrauchen.