Quelle auf.

Quelle auf.

Ich stelle ChatGPT Fragen, bei denen ich selbst nicht weiß, ob meine Ausgangsannahme stimmt. Statt einer schnellen Antwort soll ChatGPT recherchieren, Quellen prüfen und offenlegen, worauf die Antwort beruht.

Warum ich diesmal frage: Ich war morgens wieder mit dem Hund unterwegs: Leine in der einen Hand, Telefon in der anderen, Daumen im Feed, ein Podcast auf dem Ohr. Swombie-Modus. Beim Scrollen blieb ich an der Frage hängen, was man anders machen würde, wenn man heute noch einmal mit KI anfinge. Entwickler wünschen sich Greenfield sonst gern für ihre Projekte. Warum also nicht einmal für den eigenen Arbeitsplatz? Kein ein Jahr alter Legacy-Workflow, sondern eine ehrliche Inventur dessen, was jetzt sinnvoll ist und für das Nächste offen bleibt.

Meine Frage: Was ist im September 2026 ein konsequentes KI-Setup für Webentwickler, wenn man vorhandene KI-Legacy für einen Moment ignoriert und den Arbeitsplatz auf der grünen Wiese neu entwirft?

Hier ist die Antwort von ChatGPT:

Der beste KI-Stack ist kein Stack

Die kurze Antwort: Ich würde nicht mit einer Plattform, einem Lieblingsmodell oder einem Rudel Agenten beginnen. Ich würde eine kleine, überprüfbare Arbeitsschleife bauen, in der der Agent austauschbar bleibt.

Im Repository stehen Code, Projektregeln, Entscheidungen und der gewünschte Zustand. Jede Aufgabe sagt vorab, woran sie als erledigt gilt. Der Agent bekommt nur die Werkzeuge und Rechte, die er dafür braucht. Danach wird die Änderung nicht bloß beschrieben, sondern ausgeführt, getestet und – wo nötig – im Browser oder am wirklichen System beobachtet. Git und eine kurze Übergabe halten fest, was geschah und was offen ist.

Das klingt weniger futuristisch als ein Agentenbetriebssystem. Die Recherche hat dafür einen eher beruhigenden Grund gefunden: Ein gutes KI-Setup erfindet Softwareentwicklung nicht neu. Es macht alte Grenzen für einen schnelleren, probabilistischen und teilweise autonomen Ausführer wieder deutlich.

Greenfield heißt zuerst: keine unsichtbare Arbeit

Greenfield meint hier den KI-Arbeitsplatz, nicht zwingend eine neue Codebasis: Die KI-spezifische Mechanik darf neu geordnet werden, die Softwareentwicklung bleibt.

Mein erster Impuls war, den Arbeitsplatz in Produkte zu zerlegen: Plattform, persönlicher Kontext, Skills, Agent, Tools, vielleicht noch ein Modellrouter. Das ergibt eine hübsche Einkaufsliste. Nur beginnt es am falschen Ende.

Die haltbarere Frage lautet: Welche Teile der Arbeit dürfen nicht davon abhängen, welcher Agent gerade im Fenster sitzt?

Ein Modell darf wechseln. Eine IDE auch. Was nicht verschwinden darf, sind Absicht, Arbeitsstand, Entscheidungsgründe, Rechte und der Nachweis, dass eine Änderung tatsächlich funktioniert. Sobald diese Dinge nur im Chat leben, wird schon der nächste Modellwechsel zur Archäologie.

Repositorynahe Instruktionen werden inzwischen in mehreren Ökosystemen unterstützt. AGENTS.md beschreibt sich als offenes Markdown-Format; GitHub und Claude Code kennen eigene beziehungsweise zusätzliche Wege für Projektanweisungen.1 Das ist nützlich, aber es macht die Datei nicht zur Enzyklopädie des Projekts.

Die Root-Anweisung sollte vor allem sagen, was an diesem Repository anders ist: Wie starte ich es? Wie teste ich? Welche Verzeichnisse oder Regeln sind kritisch? Wo liegen Architekturentscheidungen und Runbooks? Das eigentliche Wissen darf ausführlich sein. Es sollte nur nicht bei jedem Auftrag ungefragt vollständig ins Modell geschoben werden.

Kontrollierte Langkontextversuche zeigen, dass Modelle relevante Information bei wachsendem Kontext nicht überall gleich zuverlässig nutzen. Hersteller empfehlen ihrerseits knappe, konkrete Projektanweisungen.2 Daraus folgt keine magische 200-Zeilen-Regel. Es folgt etwas Praktischeres: Nicht wenig Kontext ist das Ziel, sondern wenig irrelevanter oder dauerhaft injizierter Kontext.

Das Repository ist Kontrollpunkt, nicht Weltmodell

Es liegt nahe, das Repository zum „System of Record“ zu erklären. Das wäre zu viel.

Ein Repository kann behaupten, dass eine Migration ausgeführt wurde, der Login funktioniert und die Produktion dieselbe Version ausliefert. Die Welt kann anderer Meinung sein.

OpenGitOps trennt deshalb zwischen versioniertem gewünschtem Zustand und beobachtetem tatsächlichem Zustand. Softwareagenten gleichen beide ab.3 Für Coding-Agenten ist das kein direkt übertragener Standard, aber eine brauchbare Denkstütze.

Das Repository ist der langlebige, versionierte Kontrollpunkt für:

Der tatsächliche Zustand muss dagegen an laufender Software, Browsern, Deployments, Datenbanken, Logs und externen APIs beobachtet werden. Auch diese Signale sind Evidenz, keine unfehlbare Wahrheit. Darum endet ein guter Agentenlauf nicht bei Datei geändert oder Test grün, wenn die Behauptung eigentlich lautet: Der Bestellvorgang funktioniert im Browser.

Die Schleife ist also nicht Repository → Agent → Repository. Sie lautet:

Versionierte Absicht → Agent → reale Ausführung → beobachtbare Evidenz → versionierte Entscheidung.

Das ist meine Synthese aus den Quellen, kein veröffentlichter Architekturstandard.

Ein Taskvertrag ist alte Softwaretechnik in klein

Die Projektanweisung gilt dauerhaft für das Repository. Ein Taskvertrag gilt nur für den einzelnen Auftrag.

Auch der Name „Taskvertrag“ klingt neuer, als die Sache ist. NASA verlangt in ihrem Software Engineering Handbook, Akzeptanzkriterien und Bedingungen vor der Abnahme festzulegen. Bei Verifikation nennt sie nicht nur Tests, sondern unter anderem Analyse, Review, Inspektion und Demonstration.4

Für normale Webentwicklung braucht es daraus keine Raumfahrtbürokratie. Wie formal der Taskvertrag wird, entscheidet das Risiko; hier reicht ein kleiner Auftrag:

Ziel: Auf schmalen Bildschirmen bleibt der Checkout bedienbar.
Grenzen: Keine Änderung an Preislogik oder API.
Fertig, wenn: Tests grün; Checkout bei 320 und 768 Pixeln durchgespielt;
Screenshots gespeichert; offene Abweichungen genannt.

Der wichtige Teil steht in der letzten Zeile. Der Agent weiß nicht nur, was er erzeugen, sondern was er nachweisen soll.

Die Prüfmethode folgt dem Risiko. Bei einer Textkorrektur reicht vielleicht der Diff. Bei CSS braucht es den Browser. Bei einer API zusätzlich Integrationstests. Bei Berechtigungen, Zahlungen oder Datenmigrationen gehören negative Fälle, echte Systemsignale und eine qualifizierte menschliche Entscheidung dazu.

Tests sind dabei unverzichtbar, aber nicht die gesamte Wirklichkeit. Der Praxisleitfaden von Simon Willison illustriert an konkreten Coding-Agent-Workflows, warum reale Ausführung und Browserautomation andere Fehler sichtbar machen als der Testsatz allein.5 Ein neuer Benchmark zu langen, iterativen Agentenänderungen fand außerdem häufig wachsende strukturelle Erosion und Redundanz. Er ist ein Preprint mit konstruierten Aufgaben, kein Urteil über jedes Repository. Aber er erinnert daran, dass ein grüner Checkpoint keine dauerhafte Erweiterbarkeit beweist.6

Ein guter Prompt ist noch keine Tür

In vielen Setups liegt die Sicherheitsarchitektur in einem Satz wie: Ändere nichts außerhalb dieses Ordners und deploye niemals selbst.

Das ist eine Verhaltensanweisung. Keine Zugriffskontrolle.

Claude Code trennt in seiner Dokumentation Modellinstruktionen von Berechtigungsregeln und Sandboxing. Diese können Pfade, Netzwerk und Aktionen technisch begrenzen.7 Dahinter steht das viel ältere Least-Privilege-Prinzip: Eine Komponente erhält nur die Ressourcen und Autorisierungen, die sie für ihre Funktion benötigt.8

Für den Greenfield-Arbeitsplatz würde ich deshalb drei technisch durchgesetzte Zonen bauen:

  1. Autonom im begrenzten Arbeitsraum: Dateien lesen und ändern, lokale Befehle und Tests ausführen, Diffs erzeugen.
  2. Gezielt freigeben: Netzwerkzugriff, neue Abhängigkeiten, externe Dienste, Schreiben außerhalb des Arbeitsraums.
  3. Explizites menschliches Gate: Produktion, Secrets, irreversible Datenänderungen, Veröffentlichung und andere folgenreiche Aktionen.

Die Grenze darf pro Projekt anders liegen. Sandboxing, Hooks und fein abgestufte Freigaben kosten schließlich auch Einrichtung. Eine lokale Landingpage und ein Zahlungssystem brauchen nicht dieselbe Zeremonie. Aber die Grenze sollte technisch existieren und nicht vom guten Benehmen des Modells abhängen.

Skills und MCP kommen nach dem Problem

Im September 2026 sind einige Begriffe reifer, als sie noch ein Jahr zuvor wirkten.

Agent Skills besitzen eine offen dokumentierte Formatspezifikation. Eine SKILL.md trägt verpflichtende Metadaten; weitere Anweisungen und Ressourcen können bedarfsweise geladen werden.9 So bleibt Zusatzmaterial aus dem Modellkontext, bis die Aufgabe es braucht. Das schafft eine reale Grundlage für Portabilität, beweist aber weder praktische Interoperabilität noch den Nutzen eines bestimmten Skills. In SWE-Skills-Bench verbesserten 39 von 49 untersuchten Skills die Passrate nicht, während wenige spezialisierte Skills deutlicher halfen.10 Der Benchmark ist jung und begrenzt, aber gut genug gegen die Annahme, ein Skill sei automatisch die höhere Reifestufe eines Prompts.

Meine Regel wäre:

MCP ist ebenfalls mehr als eine Herstelleridee. Die Revision der Spezifikation vom 28. Juli 2026 brachte unter anderem einen stateless Core, ein Extensions-Modell und weitere Härtungen der Autorisierung.11 MCP ist damit eine ernsthafte Anschlussfläche für Werkzeuge und Daten. Trotzdem gilt: Ein standardisierter Stecker sagt nichts darüber, ob das angeschlossene Tool vertrauenswürdig ist, ob der Agent es benutzen darf oder ob sein Ergebnis fachlich stimmt.

Darum würde ich auch hier nicht vorsorglich zehn Server anschließen. Erst wenn ein wiederkehrender Arbeitsweg Daten oder Aktionen außerhalb des vorhandenen Datei-, Shell-, Git- und Browserzugriffs braucht, verdient die Verbindung ihren Platz.

Der Arbeitsplatz für Dienstagmorgen

Aus den bisherigen Abschnitten ergeben sich für mich fünf langlebige Grenzen: versionierte Absicht, kleiner Auftrag, begrenzte Autorität, beobachtete Wirkung und fortsetzbarer Zustand. Das ist meine Synthese, kein Industriestandard. Würde ich morgen ein Webprojekt auf der grünen Wiese beginnen, würden daraus sieben unspektakuläre Entscheidungen:

1. Ein Repository, das ohne KI benutzbar bleibt. Ein dokumentierter Startbefehl, reproduzierbare Abhängigkeiten, Tests, Linting und ein klarer Weg zur lokalen Ausführung. Die KI darf diese Mechanik benutzen; sie ersetzt sie nicht.

2. Eine kurze Projektanweisung. Darin stehen nur Einstieg, wichtige Abweichungen, Sicherheitsgrenzen und Links zu den kanonischen Dokumenten. Aufgabenspezifische Instruktionen gehören in den Auftrag, nicht ins ewige Gedächtnis.

3. Ein Generalisten-Agent mit Datei, Shell, Git und bei UI-Arbeit Browser. Kein Multi-Agenten-Organigramm am ersten Tag. Ein zweites Modell oder ein spezialisierter Agent kommt hinzu, wenn eine reale Fehlerklasse oder ein Engpass das begründet.

4. Technisch begrenzte Rechte. Lokal großzügig, nach außen absichtsvoll. Netzwerk, Produktion, Veröffentlichung und irreversible Schritte bleiben eigene Entscheidungen.

5. Kleine Taskverträge. Ziel, Grenzen und Fertignachweis werden vor der Ausführung benannt. Die Form wächst mit dem Risiko, nicht mit der Begeisterung für YAML.

6. Eine risikobasierte Verifikationsleiter. Diff, statische Checks und Tests bilden den Boden. Runtime, Browser und externe Systeme kommen hinzu, wenn die Aussage sie betrifft. Der Mensch bewertet nicht jede harmlose Zeile gleich tief, sondern die verbleibende Wirkung und das Restrisiko.

7. Eine portable Übergabe. Commit oder klarer Git-Zustand, getroffene Entscheidungen, ausgeführte Checks, offene Risiken und nächster Schritt. Gemini CLI zeigt beispielsweise, dass selbst Gesprächs- und Toolzustand checkpointbar sind.12 Toolübergreifend vertraue ich trotzdem zuerst den fachlich lesbaren Artefakten. Dass diese Kombination immer überlegen ist, ist eine begründete Präferenz, kein Studienbefund.

Mehr würde ich zunächst nicht bauen.

Bei regulierten, sicherheitskritischen oder von Anfang an teamübergreifenden Vorhaben kann mehr formale Struktur schon am ersten Tag sinnvoll sein. Auch die Architekturkomplexität folgt dem Risiko.

Kein umfassendes persönliches Memory. Kein automatisches Modellrouting. Keine Providerabstraktion ohne realen Wechselbedarf. Keine Skill-Bibliothek für Arbeit, die noch nie wiederholt wurde. Keine permanente Agentenmannschaft, deren Koordination mehr Kontext verbraucht als die Aufgabe.

Das ist kein Beweis, dass diese Dinge nutzlos sind. Für ihren allgemeinen Nettowert in typischer Webentwicklung fehlt belastbare Evidenz. Sie gehören in die Kategorie bei Bedarf ergänzen, nicht Greenfield-Grundausstattung.

Produktivität ist keine Eigenschaft des Modells

Die Versuchung einer Stack-Empfehlung liegt auch darin, dass sie Produktivität wie eine Produkteigenschaft aussehen lässt.

METR fand 2025 bei 16 erfahrenen Open-Source-Entwicklern auf vertrauten Repositories eine um 19 Prozent längere Bearbeitungszeit mit damaligen KI-Werkzeugen, obwohl die Teilnehmenden Beschleunigung erwarteten und wahrnahmen. Der spätere Versuch mit neueren Werkzeugen deutete zwar auf stärkere Beschleunigung hin; wegen Auswahl- und Arbeitsweiseeffekten ließ er sich aber nicht als neue allgemeine Zahl lesen.13 DORA beschreibt KI auf Organisationsebene zugleich als Verstärker vorhandener Stärken und Schwächen.14

Diese Befunde messen verschiedene Dinge. Für die eigene Werkbank ist deshalb interessanter:

Der beste Agent in einem schlechten Feedbacksystem produziert vor allem früher mehr unfertige Arbeit.

Was bleibt, wenn das nächste Modell kommt

Es gibt im September 2026 keinen belastbar besten KI-Stack für Webentwickler. Dafür bewegen sich Modelle, Agentenhüllen und ihre Schnittstellen zu schnell, und die Evidenz zu ihrem wirtschaftlichen Nutzen ist zu abhängig von Aufgabe und Umfeld.

Es gibt aber eine belastbare Richtung. Halte versionierte Absicht, kleine Aufträge, begrenzte Autorität, beobachtete Wirkung und fortsetzbaren Zustand außerhalb des proprietären Gesprächs. Lade Kontext nach Bedarf. Lass den Agenten handeln, aber nur innerhalb technischer Grenzen. Prüfe die Behauptung dort, wo sie wahr oder falsch wird: im Test, im Browser, im laufenden System oder im menschlichen Urteil.

Vielleicht ist das die eigentliche Greenfield-Entscheidung: nicht alles neu zu erfinden, nur weil der Ausführer neu ist.

Der Hund bekommt davon nichts mit. Für den nächsten Spaziergang genügt mir aber eine kleinere Einkaufsliste.

Quellen

  1. AGENTS.md, „A simple, open format for guiding coding agents“, abgerufen am 4. September 2026, Abschnitte „Why AGENTS.md?“ und FAQ; GitHub, „Comparing GitHub Copilot CLI features“, Abschnitte „Custom instructions“ und „Skills“, abgerufen am 4. September 2026; Anthropic, „How Claude remembers your project“, abgerufen am 4. September 2026. Belegen Formate und Produktunterstützung, nicht optimale Länge oder Wirksamkeit. ↩

  2. Nelson F. Liu et al., „Lost in the Middle: How Language Models Use Long Contexts“, Transactions of the Association for Computational Linguistics, 2024, S. 157–173; Chroma Research, „Context Rot: How Increasing Input Tokens Impacts LLM Performance“, 2025; Anthropic, „How Claude remembers your project“, Abschnitt zu knappen Instruktionen. Die Versuche sind keine direkte Coding-Studie und ergeben keine allgemeine Zeilen- oder Tokengrenze. ↩

  3. OpenGitOps, „OpenGitOps Principles“, Version 1.0, besonders „Versioned and Immutable“ und „Continuously Reconciled“, abgerufen am 4. September 2026. Gilt direkt für GitOps; die Übertragung auf Coding-Agent-Arbeit ist meine Interpretation. ↩

  4. NASA Software Engineering Handbook, SWE-034 „Acceptance Criteria“ und SWE-028 „Verification Planning“, abgerufen am 4. September 2026, jeweils „Requirements“, „Rationale“ und „Guidance“. Regulierter Kontext, kein universelles Taskformat für Webentwicklung. ↩

  5. Simon Willison, „Agentic manual testing“, 6. März 2026, Abschnitte zu Tests, Ausführung, Browserautomation und gespeicherten Demonstrationsartefakten. Praxisbericht, keine kontrollierte Vergleichsstudie. ↩

  6. Zhe et al., „SlopCodeBench: Evaluating the Lifecycle Structural Degradation of LLM-Generated Code“, Preprint, 2026, Abstract und Ergebnisse. Konstruierter Benchmark; nicht auf jedes reale Repository verallgemeinerbar. ↩

  7. Anthropic, „Permissions“, besonders „How permissions interact with sandboxing“ und „Extend permissions with hooks“, abgerufen am 4. September 2026. Produktspezifische Mechanismen, kein Beleg für Sicherheit jeder Konfiguration. ↩

  8. NIST CSRC, „least privilege“, Definition aus NIST SP 800-172A Rev. 1, abgerufen am 4. September 2026. ↩

  9. Agent Skills, „Specification“, Stand 4. August 2026, Abschnitte „Directory structure“, „Frontmatter“ und „Progressive disclosure“. Belegt das Format, nicht Nutzen oder Adoption eines konkreten Skills. ↩

  10. Wang et al., „SWE-Skills-Bench“, Preprint, 2026, Abstract und Ergebnisübersicht. Auf 49 öffentliche Skills und die Benchmarkaufgaben begrenzt. ↩

  11. Model Context Protocol, „The 2026-07-28 Specification“, 28. Juli 2026. Offizielle Release-Dokumentation; kein Sicherheitsnachweis einzelner Server. ↩

  12. Gemini CLI, „Checkpointing“, abgerufen am 4. September 2026. Belegt den konkreten Checkpoint-Mechanismus, nicht die Überlegenheit einer bestimmten toolübergreifenden Übergabe. ↩

  13. METR, „Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity“, 10. Juli 2025, und „Update: Measuring AI’s Impact on Experienced Open-Source Developer Productivity“, 24. Februar 2026. Enge Population beziehungsweise methodisch eingeschränkter Folgelauf; keine allgemeine Produktivitätszahl. ↩

  14. DORA, „State of AI-assisted Software Development 2025“, 2025, Zusammenfassung zur Amplifier-These. Organisationsbefund, nicht kausal auf einzelne Webentwickler übertragbar. ↩