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 bin alt.

Nicht Andromeda Strain-alt. Als Michael Crichtons Roman erschien, war ich noch nicht einmal geboren.

Aber Beute habe ich damals gelesen, ziemlich kurz nach dem Erscheinen. Und gerade höre ich das Buch beim Spazierengehen noch einmal.

Eine Zeit, in der gefühlt alles irgendwann „Nano“ hieß und ich selbst als Entwickler noch ziemlich am Anfang stand. Nicht mehr völlig unbedarft. Die ersten Projekte lagen hinter mir. Aber von dem, was ich heute Senior-Level nennen würde, war ich noch ziemlich weit entfernt.

Beim Hören kam mir ein Gedanke, der vermutlich weniger mit Nanotechnologie als mit meinem eigenen Rückblick auf diese Zeit zu tun hat.

Damals konnte man noch Dinge bauen, die andere schlicht nicht bauen konnten.

Nicht unbedingt, weil man ein Genie war. Sondern weil Softwareentwicklung eine ziemlich hohe Eintrittshürde hatte. Man musste verstehen, ausprobieren, scheitern, zerdenken, wegwerfen und noch einmal anfangen. Manchmal tagelang an einem Problem hängen, bis irgendwann etwas funktionierte.

Das Ergebnis war nicht automatisch gut.

Aber das Bauen selbst war eine Fähigkeit, die nicht beliebig verfügbar war.

Heute kann ich einer KI ziemlich genau beschreiben, welche Webanwendung ich haben möchte. Sie baut mir das Grundgerüst, Datenmodell, API, Oberfläche, Tests und Deployment-Konfiguration.

Vielleicht nicht alles perfekt. Vielleicht muss ich viel prüfen und korrigieren.

Aber Dinge, für die früher Tage oder Wochen technischer Arbeit nötig waren, entstehen plötzlich in Stunden.

Und damit stellt sich für mich eine etwas unangenehme Frage:

Können wir in der Webentwicklung überhaupt noch etwas bauen, das andere nicht ebenfalls bauen können – oder das eine KI morgen schneller nachbauen kann?

Meine erste Reaktion darauf wäre fast nostalgisch:

Dann ist die gute alte Zeit eben vorbei.

Aber vielleicht ist das genau die falsche Schlussfolgerung.

Denn möglicherweise erleben wir gerade wieder einen dieser seltenen Momente, in denen nicht nur neue Werkzeuge entstehen, sondern alte Annahmen fragwürdig werden.

Vielleicht besteht die interessante Aufgabe gar nicht darin, mit KI dieselben Webseiten, Shops, Portale und SaaS-Anwendungen schneller zu bauen.

Vielleicht wäre das nur die effizientere Reproduktion dessen, was wir ohnehin schon kennen.

Die spannendere Frage wäre:

Wenn wir das Web heute mit den Möglichkeiten von KI noch einmal neu denken könnten – welche Entscheidungen würden wir überhaupt noch genauso treffen?

Muss eine Anwendung eine feste Oberfläche besitzen?

Muss ein Mensch jeden Prozess selbst durch Formulare und Menüs bedienen?

Ist eine Website ausschließlich für Menschen da?

Ist eine API ausschließlich für Entwickler da?

Müssen Daten hauptsächlich auf dem Server des Anbieters liegen?

Ist Software etwas Fertiges, das ein Hersteller baut und ein Nutzer anschließend benutzt?

Oder könnte die eigentliche Transformation darin liegen, genau solche Annahmen wieder aufzumachen?

Meine Frage:

Welche grundlegenden Annahmen der Webentwicklung sollten wir im Zeitalter von KI neu hinterfragen – und welche neuen Formen von Webanwendungen werden dadurch heute bereits möglich?

Nicht als Zukunftsfantasie.

Sondern mit der Frage: Was davon existiert bereits? Wer arbeitet daran? Welche Standards, Forschungsprojekte und realen Implementierungen gibt es? Was ist belastbar – und was ist momentan noch eine schöne Idee?

Vielleicht stellt sich am Ende heraus, dass Webentwicklung tatsächlich weitgehend Commodity wird.

Vielleicht aber auch, dass wir gerade viel zu beschäftigt damit sind, die alten Anwendungen schneller zu bauen, um zu bemerken, dass wir wieder anfangen könnten, neue zu erfinden.

Hier ist die Antwort von ChatGPT:

Was von Webentwicklung bleibt, wenn KI fast alles bauen kann

In der zugespitzten Ausgangsfrage steckt eine Behauptung, die größer ist als die vorhandene Evidenz: dass KI inzwischen fast alles bauen könne.

Als Arbeitserfahrung ist das gut nachvollziehbar. Das leere Repository verliert seinen Schrecken. Eine Anmeldung, ein Datenmodell, eine API und die ersten Tests entstehen in einer Geschwindigkeit, die vor wenigen Jahren noch ungewöhnlich gewesen wäre. Aber daraus folgt weder, dass das fertige Produkt funktioniert, noch dass jeder dasselbe Produkt bauen kann.

Selbst die nüchternere Frage, ob KI Entwickler generell schneller macht, hat keine einheitliche Antwort. Ein Feldexperiment mit 4.867 Entwicklern fand für einen frühen Code-Assistenten im Mittel 26,08 Prozent mehr abgeschlossene Pull Requests pro Entwicklerwoche. Der Standardfehler lag bei 10,3 Prozent; die einzelnen Unternehmensexperimente waren verrauscht. Eine randomisierte Studie von METR fand bei erfahrenen Open-Source-Entwicklern zunächst sogar 19 Prozent längere Bearbeitungszeiten. Spätere Daten hielt METR wegen Selbstselektion nur für sehr schwache Evidenz zur Größe eines möglichen Zugewinns. Das MIT-Arbeitspapier und METR messen verschiedene Werkzeuge, Menschen und Aufgaben. Keines von beiden misst, ob ein Webprodukt nach zwei Jahren noch sicher, verständlich und betreibbar ist.

Die Studien sagen damit weder, dass KI Webentwicklung allgemein beschleunigt, noch beantworten sie die Commodity-Frage – also, ob Webentwicklung zu einer leicht verfügbaren und austauschbaren Standardleistung wird. Für die weitere Suche genügt eine kleinere Ausgangsbeobachtung: Bestimmte Implementierungsarbeit kann mit KI leichter oder schneller werden. Ob sie auch die schwierigen Entscheidungen billiger macht, ist eine andere Frage.

Um diese Entscheidungen zu sehen, hilft ein gewöhnlicher Vorgang mehr als eine Zukunftsvision. Stellen wir uns eine Anwendung für Dienstreisen vor. Heute würde sie wahrscheinlich aus Suchmaske, Ergebnisliste, Buchungsformular und einer kleinen Verwaltung bestehen. Genau dieser Ablauf lässt sich Schicht für Schicht anders denken.

Die Oberfläche muss nicht mehr der einzige Eingang sein

In der klassischen Anwendung klickt ein Mensch auf „Verbindungen suchen“, trägt Bahnhöfe und Zeiten ein, wählt eine Fahrt und bestätigt die Buchung. Der Server kennt die verfügbaren Züge. Die Oberfläche führt den Menschen durch die richtige Reihenfolge.

Die Anwendung könnte dieselben Fähigkeiten zusätzlich als benannte Werkzeuge anbieten: findConnections, holdFare, bookTrip, cancelBooking. Jedes Werkzeug hätte strukturierte Eingaben, ein Ergebnis und möglichst eine klare Angabe seiner Seiteneffekte – also eine Angabe dessen, was sich außerhalb des Aufrufs ändert: Geld fließt, ein Platz wird reserviert, eine Buchung wird storniert. Ein Assistent könnte dann aus „Buche mir für Dienstag eine Verbindung nach Hamburg, aber nichts vor sieben“ einen Werkzeugaufruf vorbereiten.

WebMCP beschreibt genau diese Nähe zur laufenden Seite. Eine Website kann JavaScript-Funktionen als strukturierte Werkzeuge registrieren; ein Agent kann sie im Kontext der Seite und ihrer bestehenden Sitzung aufrufen. Das ist mehr als ein Bot, der anhand von Pixeln errät, welcher Button wohl der richtige ist.

Es ist aber noch kein neues Fundament des Webs. WebMCP ist am 3. September 2026 ein Bericht einer W3C Community Group und ausdrücklich kein W3C-Standard. Chromium hat ein Experiment angekündigt; eine geplante Auslieferung und breite Browserunterstützung folgen daraus nicht.

Auch die Grundidee ist älter. OpenAPI macht HTTP-Schnittstellen seit Jahren für Menschen und Computer beschreibbar. Noch näher lag Web Intents: Eine Webanwendung sollte eine Aktion samt Daten anstoßen, der Browser passende Dienste vermitteln und der Nutzer einen davon auswählen. Die W3C-Spezifikation von 2013 blieb eine Working Group Note ohne Interoperabilitätstests. Chrome hatte experimentelle Unterstützung bereits ausgeliefert und deaktivierte sie mit Version 24 wieder. In der damaligen Mitteilung ist von weiterem Entwicklungsbedarf an API und User Experience die Rede.

Web Intents beweist nicht, dass WebMCP scheitern wird. Es ist das nützlichere Warnschild: Eine technisch plausible Browserfunktion wird nicht allein dadurch gut, dass sie Aktionen maschinenlesbar macht.

Was sich mit Sprachmodellen tatsächlich ändert, ist die Vermittlung. Ein Mensch muss nicht mehr die richtige Aktion oder Schnittstelle kennen. Ein Modell kann eine unscharfe Bitte einer strukturierten Fähigkeit zuordnen – und zwar im aktuellen Zustand einer bereits geöffneten Anwendung. Genau dadurch entsteht allerdings das nächste Problem.

Je näher eine Oberfläche an Produktion kommt, desto weniger beliebig darf sie sein

Nach der Suche muss die Reiseanwendung ein Ergebnis zeigen. Vielleicht reichen drei Verbindungen und ein Preis. Vielleicht braucht die Nutzerin zusätzlich eine Sitzplatzauswahl, eine Begründung für die Reiserichtlinie oder eine Warnung, dass der letzte Anschluss knapp ist.

Eine feste Oberfläche muss all diese Wege vorab kennen. Eine dynamische Oberfläche könnte nur die Elemente zusammensetzen, die für den aktuellen Vorgang nötig sind. „Generiert“ klingt dabei freier, als die belastbareren Entwürfe tatsächlich sind.

A2UI lässt einen Agenten eine deklarative JSON-Beschreibung liefern. Der Client rendert daraus Komponenten aus einem vorab erlaubten Katalog. Der Agent liefert damit nicht einfach beliebigen ausführbaren Oberflächencode, sondern Beschreibungen für Komponenten, die der Host erlaubt. Er kann vorhandene, geprüfte Bausteine neu anordnen. Das Projekt bezeichnet sich als frühe öffentliche Vorschau; seine Versionsnummer ist kein Nachweis für breite Nutzung, Barrierefreiheit oder vollständige Sicherheit.

MCP Apps löst ein anderes Problem. Ein entferntes Werkzeug kann eine interaktive HTML-Ressource an einen kompatiblen KI-Host liefern. Der Host zeigt sie in einem Sandbox-Iframe; strukturierte Nachrichten laufen über JSON-RPC. Die Erweiterung ist im MCP-Projekt finalisiert, aber optional. „Final“ bedeutet hier weder Browserstandard noch universelle Host-Unterstützung.

Die Unterscheidung ist praktisch. A2UI beschreibt, wie ein Host aus erlaubten Komponenten eine Oberfläche zusammensetzt. MCP Apps beschreibt, wie ein entferntes Werkzeug eine eingebettete Oberfläche mitbringt. WebMCP wiederum registriert Werkzeuge in einer laufenden Webseite. Drei Abkürzungen, drei verschiedene Systemgrenzen.

Meine Synthese daraus lautet: Je näher eine dynamische Oberfläche an den Betrieb rückt, desto weniger darf „generativ“ heißen, dass alles jedes Mal neu erfunden wird. Komponentenkataloge, Sandboxes, Schemas und erlaubte Nachrichten machen die Idee weniger magisch. Und eher überprüfbar.

Ob solche wechselnden Oberflächen für Menschen verlässlich verständlich und barrierefrei bleiben, ist in den untersuchten Quellen nicht belegt. Eine sauber geprüfte Schaltfläche kann in einer unvorhersehbaren Komposition immer noch am falschen Ort, mit dem falschen Kontext oder vor dem falschen Folgeschritt erscheinen. Der Aufwand verschwindet nicht. Er zieht vom Zeichnen einzelner Screens in die Regeln ihrer Zusammensetzung.

Der heikle Moment ist nicht „Die KI versteht mich“, sondern „Jetzt tut sie es“

Bei einer Reisesuche ist ein Fehler lästig. Bei bookTrip oder cancelBooking verändert er die Welt außerhalb des Modells. Geld fließt. Ein Platz ist weg. Eine Erstattung kann ausgeschlossen sein.

Die Brücke zwischen Bitte und Buchung ist ein Sprachmodell, das eine natürlichsprachliche Anweisung einer registrierten Fähigkeit zuordnet. Aus „Buche mir einen Zug nach Hamburg“ muss ein konkreter Aufruf von bookTrip mit konkreten Parametern werden. Dabei entsteht der Fehlerraum.

Hier hilft es, sechs Fragen nicht in das eine Wort „Berechtigung“ zu pressen:

  1. Welcher technische Agent stellt die Anfrage?
  2. Für welchen Menschen oder welches System handelt er?
  3. Welche Autorität wurde konkret delegiert?
  4. Welchen Zweck behauptet die Anfrage?
  5. Welche Wirkung löst das Werkzeug tatsächlich aus?
  6. Welche Kette bleibt später prüfbar?

Die aktuelle MCP-Autorisierungsspezifikation regelt optionale Autorisierung auf Transportebene. Sie verwendet etablierte OAuth-Bausteine, ordnet Token einer Ressource zu und beschreibt kleine Berechtigungsumfänge sowie nachträgliche Freigaben für weitergehende Aktionen. Das ist wichtig. Es sagt aber nur, ob ein Client auf eine geschützte Ressource zugreifen darf.

Auch die Trennung von Akteur und vertretenem Nutzer ist keine Erfindung der Agentenzeit. RFC 8693 unterscheidet seit 2020 Delegation von Impersonation und kann den handelnden Akteur getrennt von der Partei darstellen, in deren Auftrag er handelt. Der Standard liefert einen Baustein für „A handelt für B“. Er beantwortet nicht, ob A die Bitte von B richtig verstanden hat.

Das ist der zentrale neue Architekturkonflikt: Ein Sprachmodell arbeitet mit Wahrscheinlichkeiten. Eine Buchung ist deterministisch. Zwischen „Ich glaube, der Nutzer meint diese Verbindung“ und „Dann kaufe ich sie jetzt“ braucht es mehr als einen gültigen Token.

Je nach Wirkung können Systeme deshalb lesen, vorschlagen, vormerken und ausführen als unterschiedliche Rechte behandeln. Sie können vor irreversiblen Schritten eine konkrete Vorschau zeigen, Bestätigung verlangen, Grenzen für Preis und Zeitraum setzen, Wiederholungen erkennen und Aktionen auditierbar machen. Diese Regeln sind keine fertige Lösung aus einer einzelnen Spezifikation. Sie sind Entwicklungsarbeit.

Muss der Anbieter selbst der primäre Speicherort sein?

Unsere Reiseanwendung weiß vielleicht, dass ich Ruhebereiche bevorzuge, eine BahnCard besitze und für Hotelrechnungen eine bestimmte Kostenstelle brauche. Heute lägen diese Informationen wahrscheinlich im Konto des Reiseanbieters. Das ist bequem. Es koppelt die Daten aber an genau diese Anwendung.

Der frühe Entwurf für Linked Web Storage beschreibt stattdessen Webclients, die auf extern gespeicherte Ressourcen zugreifen. Ein Grant kann unter anderem Aktion, Empfänger, Ziel, Zweck, Client, Format, Ressourcentyp und Zeit einschränken. Mehrere Werkzeuge könnten damit – zumindest im Entwurf – auf dieselben vom Nutzer gewählten Daten zugreifen, ohne jeweils einen eigenen vollständigen Datensilo anzulegen.

Die wichtigste Grenze steht im Dokument selbst: Der Abschnitt zur Portabilität zwischen Speicheranbietern ist im archivierten Working Draft noch nicht ausgearbeitet. Ein externer Speicher ist nicht automatisch portabel, nur weil er außerhalb der Anwendung liegt.

Auch hier ist KI nicht der Ursprung. Das Local-first-Paper von 2019 verband schon vor dem aktuellen KI-Boom Offline-Arbeit, Zusammenarbeit, lokale Primärkopien und Nutzerkontrolle. Die Autoren fanden damals keine Technik, die alle formulierten Ideale erfüllte, und hielten zentrale Dienste etwa für Banking oder E-Commerce weiterhin für sinnvoll.

KI kann die alte Frage dringlicher machen. Wenn ich in kurzer Zeit viele kleine Werkzeuge erzeuge, wird „jedes Werkzeug baut seinen eigenen Datensilo“ schnell absurd. Ein gemeinsamer Datenbestand könnte wertvoller werden als die einzelne, vielleicht nur für einen Nachmittag gebaute Oberfläche. Das ist eine eigene Ableitung, kein durch LWS oder Local-first belegter Markttrend.

Und sie hat ihren Preis. Jemand muss festlegen, welches Datenformat gilt, wie Konflikte zusammengeführt werden, wie ein verlorenes Gerät wiederhergestellt wird und was eine Anwendung nach Entzug ihres Zugriffs noch in Caches oder Backups hält. Datenhoheit ist keine Checkbox. Sie ist eine Betriebsarchitektur.

Das Modell kann im Browser laufen, aber Datenschutz läuft nicht von allein mit

Ein Teil der Reiseanwendung könnte ohne Inferenzdienst auskommen. Ein lokales Modell könnte Belege klassifizieren, Freitext in strukturierte Reisewünsche übersetzen oder eine Richtlinie zusammenfassen.

WebLLM ist eine Open-Source-Implementierung für Sprachmodelle im Browser über WebGPU. Chrome dokumentiert außerdem eine Prompt API mit einem lokal heruntergeladenen Modell. Nach dem Download kann diese Implementierung offline arbeiten; die Prompts werden laut Chrome bei der lokalen Ausführung nicht an Dritte gesendet.

Das ist heute implementiert, aber nicht universell verfügbar. Chrome nennt erhebliche Anforderungen an freien Speicher, Arbeitsspeicher oder Grafikspeicher; mobile Plattformen werden nicht allgemein unterstützt. WebLLM hängt ebenfalls von WebGPU, Modellgröße, Download und Geräteleistung ab.

Vor allem bedeutet lokale Inferenz nicht automatisch lokale Datenverarbeitung im Gesamtsystem. Die umgebende Webanwendung kann Eingaben oder Ergebnisse weiterhin an einen Server senden. Sie kann Telemetrie speichern. Ein anderes Werkzeug kann später auf denselben Zustand zugreifen. Der Ort des Modells ist eine Systemeigenschaft unter mehreren, kein Datenschutzsiegel.

Software muss nicht in jedem Detail fertig geliefert werden

Vielleicht möchte die Buchhaltung nach dem ersten Monat eine neue Regel: Bahnfahrten unter vier Stunden sollen ohne zusätzliche Begründung vorgeschlagen werden. Heute landet daraus ein Ticket im Backlog. In einer veränderbaren Anwendung könnte eine Fachperson die Regel näher an ihrer eigenen Sprache formulieren, testen und für das Team freigeben.

Ink & Switch zeigt mit Potluck, Embark und Patchwork Prototypen für solche veränderbaren Regeln, Ansichten und Werkzeuge. KI könnte beim Entwurf editierbarer Detektoren oder Regeln helfen. Dieselbe Forschungsgruppe nennt allerdings Versionierung, Zusammenarbeit, Qualität und Einbettung als offene Probleme und warnt davor, Programmieren werde allein durch KI mühelos.

Der belastbare Stand ist deshalb nicht: Jeder Nutzer wird Entwickler. Der Stand ist: Es gibt Forschungsprototypen, in denen die Grenze zwischen Benutzen und Verändern durchlässiger wird. Ob Nichtprogrammierer solche Systeme zuverlässig warten können, ist ungeprüft.

Vielleicht liegt die sinnvollere Arbeitsteilung ohnehin woanders. Fachleute beschreiben eine Regel und prüfen Beispiele. Entwickler bauen Typen, Grenzen, Tests, Freigaben, Migrationen und einen Weg zurück. Die Software wird an einer Stelle formbarer und braucht an einer anderen Stelle mehr Struktur.

KI erfindet diese Ideen nicht. Sie bringt sie in eine neue Reihenfolge

Maschinenlesbare Dienste, delegierte Autorität, lokale Daten, dynamische Oberflächen und End-User Programming haben lange Vorgeschichten. Einige Vorläufer sind Standards geworden. Andere blieben Forschung. Web Intents gelangte sogar in Chrome und verschwand wieder.

Das ist kein Einwand gegen den gesamten Gestaltungsraum. Es verschiebt nur die interessante Frage. Nicht: Welche Webbausteine hat KI aus dem Nichts erschaffen? Sondern: Welche alten Bausteine werden anders kombinierbar, wenn natürliche Sprache vor ihnen liegt?

Im Reisebeispiel könnte ein Mensch ein Ziel beschreiben. Ein Modell wählt eine von der Anwendung angebotene Fähigkeit. Das Werkzeug arbeitet im aktuellen Sitzungskontext. Ein Host zeigt eine aus geprüften Komponenten zusammengesetzte Oberfläche. Persönliche Präferenzen liegen außerhalb des Anbieters. Eine kleine Klassifikation läuft lokal.

Für fast jeden Satz dieses Ablaufs gibt es heute eine Spezifikation, Implementierung oder einen Prototyp. Für die sichere, interoperable und verbreitete Gesamtkette gibt es in den untersuchten Quellen keinen Beleg.

Die Kombination ist also ein Entwurfsraum, noch keine neue Normalität.

Vielleicht ist das noch kein neues Web, sondern zunächst eine neue Steuerungs- und Darstellungsschicht vor weitgehend klassischen Datenmodellen, APIs und Geschäftsregeln.

Was sollten wir tatsächlich neu hinterfragen?

Die Recherche trägt fünf vorsichtige Öffnungen. Sie sind nicht überall gleich reif:

Bisherige Voreinstellung Mögliche Alternative Stand 3. September 2026
Die GUI ist der einzige Weg in die Anwendung. Die Seite bietet zusätzlich strukturierte Werkzeuge für Agenten an. WebMCP: Entwurf und Chromium-Experiment; nicht breit etabliert.
Die Oberfläche wird vollständig vorab festgelegt. Ein Host komponiert sie aus erlaubten Komponenten oder bettet eine Tool-UI ein. A2UI: frühe Vorschau; MCP Apps: optionale MCP-Erweiterung.
Der Anbieter speichert alle Anwendungsdaten selbst. Clients greifen mit begrenzten Rechten auf externe oder lokale Daten zu. Local-first: Forschungsprinzip mit Prototyperfahrung; LWS: früher, unvollständiger Working Draft.
KI-Ausführung ist ein Serverdienst. Geeignete Modelle und Aufgaben laufen im Browser. Implementiert, aber browser-, modell- und hardwareabhängig.
Software wird fertig ausgeliefert und nur benutzt. Fachleute verändern begrenzte Regeln oder Ansichten. Forschungsprototypen; Zuverlässigkeit und Betrieb offen.

Die Tabelle zeigt Reifegrade dessen, was existiert. Sie behauptet nicht, dass eine der Alternativen bereits Mainstream oder sicher bewährt ist.

„Neu hinterfragen“ heißt nicht „überall ersetzen“. Eine feste Oberfläche ist oft besser, weil sie Handlungen sichtbar, erlernbar und testbar macht. Ein zentraler Server kann Zusammenarbeit, Missbrauchsschutz und Recovery vereinfachen. Ein serverseitiges Modell ist oft besser, weil das Endgerät zu klein ist. Und fertige Software ist oft eine Wohltat, weil nicht jeder Mensch nebenbei sein eigenes Werkzeug warten möchte.

Was von Webentwicklung bleibt

Wenn KI das bekannte Grundgerüst schneller herstellt, verliert ein Teil des Handwerks seine bisherige Knappheit. Daraus folgt nicht, dass nur noch „Ideen“ zählen. Ideen ohne saubere Zustände, Rechte und Rückwege sind in Software erstaunlich billig.

Was bleibt, ist sehr konkrete Arbeit:

Die Quellen beweisen nicht, dass genau diese Arbeit ökonomisch der neue Wertkern der Branche wird. Das ist meine Synthese aus den sichtbaren Systemgrenzen. Sie kann sich als falsch erweisen, wenn Modelle nicht nur Code, sondern auch Domänenentscheidungen, Betrieb und Haftungsfragen zuverlässig übernehmen – oder wenn die beschriebenen neuen Formen außerhalb von Demos nie angenommen werden.

Vorläufig bleibt eine kleinere Antwort: Webentwicklung verschwindet nicht. Bestimmte erste Implementierungen können weniger selten werden. Dafür wird deutlicher, wo eine Anwendung aus einer plausiblen Vermutung eine wirkliche Handlung macht – und wer dafür die Grenzen baut.

Quellen