nokode – Wenn ein LLM alles erledigen kann, warum sollte man dann noch Code schreiben? (Web-App-Experiment)

• Experiment zum Aufbau eines Webservers ohne jegliche Anwendungslogik, bei dem ein LLM alle Anfragen verarbeitet
  • Der Server nimmt lediglich HTTP-Anfragen entgegen und fragt das LLM „Was ist zu tun?“, alles Weitere übernimmt das LLM
• Der Server nutzt nur drei Werkzeuge für CRUD-Funktionen: database, webResponse und updateMemory
• Das LLM übernimmt selbst SQL-Schema-Design, HTML-/JSON-Erzeugung und die Einbindung von Feedback und implementiert so eine grundlegende Kontaktverwaltungs-App
• Die Antwortzeit liegt bei 30–60 Sekunden, die Kosten sind 100- bis 1000-mal höher als bei einer traditionellen Web-App, zudem gibt es Probleme mit UI-Konsistenz und Erinnerungsvermögen
• Trotzdem zeigt das Experiment, dass sich eine vollständige CRUD-App ohne Code realisieren lässt, was darauf hindeutet, dass Code selbst ein Übergangskonzept sein könnte

---

Hintergrund

• Ausgangspunkt war die Gedankenspiel-Idee (Shower Thought): „Irgendwann werden wir keinen Code mehr schreiben müssen“
  • In der Zukunft könnten LLMs Eingaben in Echtzeit verarbeiten und 120-fps-Video ausgeben, wodurch rein absichtsbasierte Datenverarbeitung ohne Apps und ohne Code möglich würde
• In der Realität ist das noch immer Science-Fiction, aber als Wochenendexperiment wurde getestet, „wie weit man mit der heutigen Technik kommen kann“
• Die Hypothese des Experiments ging zunächst von einem Scheitern aus
  • Während sich die meisten KI-Systeme auf Codegenerierung konzentrieren (z. B. Claude Code, Cursor, Copilot usw.),
    sollte mit dem Projekt eine andere Perspektive geprüft werden: „Was wäre, wenn man die Codegenerierung komplett weglässt?“
• Das Ergebnis war ein HTTP-Server ganz ohne Routen, Controller oder Business-Logik, der bei jeder Anfrage das LLM einfach fragt: „Was ist zu tun?“
• Ziel des Experiments war es zu zeigen, „wie weit entfernt diese Zukunft tatsächlich ist“

Projektüberblick

• nokode ist ein Experiment, das einen „Webserver ohne Anwendungslogik“ aufbaut, um eine Architektur zu testen, in der ein LLM alle Anfragen verarbeitet
  • Der Server nimmt lediglich HTTP-Anfragen entgegen und fragt das LLM „Was ist zu tun?“, alles Weitere übernimmt das LLM
• Ziel ist zu prüfen, ob ein LLM Anwendungslogik direkt ausführen kann, ohne Code zu generieren
• Als Versuchsobjekt dient eine Kontaktverwaltungs-App (contact manager) mit grundlegenden CRUD-Funktionen (Anlegen, Lesen, Bearbeiten, Löschen)

Systemaufbau

• Das Backend besteht aus nur 3 Werkzeugen
  • database: Führt SQL in SQLite aus; das LLM entwirft das Schema selbst
  • webResponse: Erzeugt Antworten im passenden Format wie HTML, JavaScript oder JSON
  • updateMemory: Speichert Nutzerfeedback als Markdown, damit es bei der nächsten Anfrage referenziert werden kann
• Zum Beispiel wird bei einer Anfrage an /contacts eine HTML-Seite erzeugt, bei /api/contacts eine JSON-Antwort
• Jede Seite enthält ein Feedback-Widget, das Anfragen wie „Mach die Buttons größer“ oder „Wechsle zu einem Dark Theme“ sofort umsetzt

Versuchsergebnisse

• Funktional hat es erfolgreich funktioniert
  • Formularübermittlung, Datenspeicherung, UI-Anzeige und API-Antworten funktionieren alle ordnungsgemäß
  • Das LLM erzeugt auch ohne Beispiele ein geeignetes Datenbankschema, sicheres SQL, eine REST-artige API, responsive Layouts, Formularvalidierung und Fehlerbehandlung
• Leistungsprobleme
  • Pro Anfrage werden 30–60 Sekunden benötigt und damit ist das System im Vergleich zu herkömmlichen Web-Apps (10–100 ms) 300- bis 6000-mal langsamer
  • Mit $0.01–0.05 pro Anfrage ist es 100- bis 1000-mal teurer
  • Inkonsistente UI-Farben und Layouts, kein Erinnern früherer Zustände und sofortige Fehler bei falsch erzeugtem SQL
  • Prompt-Optimierungsversuche wie „⚡ THINK QUICKLY“ führten im Gegenteil sogar zu geringerer Geschwindigkeit

Fazit und Implikationen

• LLMs besitzen grundsätzlich die Fähigkeit, Anwendungslogik direkt auszuführen
• Das Problem sind die Leistungsgrenzen bei Geschwindigkeit, Kosten, Konsistenz und Zuverlässigkeit
• Diese Grenzen liegen jedoch eher im Bereich quantitativer Verbesserungen als qualitativer Probleme
  • Die Inferenzgeschwindigkeit verbessert sich jährlich um etwa das Zehnfache
  • Die Kosten befinden sich im Sinkflug
  • Längere Kontextfenster könnten das Erinnerungsvermögen verbessern
  • Die Fehlerrate zeigt eine sinkende Tendenz
• Dadurch könnte die Ära, in der „KI direkt ausführt“, näher sein als die Ära, in der „KI Code schreibt“
• Derzeit bleibt nur noch Code auf Infrastrukturebene wie HTTP-Konfiguration, Werkzeugdefinitionen und DB-Anbindung übrig,
  langfristig deutet das auf einen möglichen Übergang zu einer „Datenverarbeitung, in der nur noch Absicht und Ausführung existieren“ hin

Ausführung

• Nach npm install in der Datei .env den LLM-Anbieter und den API-Schlüssel festlegen
• npm start ausführen und dann http://localhost:3001 aufrufen (die erste Anfrage dauert 30–60 Sekunden)
• Durch Bearbeiten von prompt.md lassen sich App-Typ oder Funktionen ändern
  • Verschiedene Pfade wie /game, /dashboard oder /api/stats können ausprobiert werden
  • Feedback wie „make this purple“ oder „add a search box“ wird sofort übernommen
• Die Kosten pro Anfrage liegen je nach Modell bei $0.001–0.05
• Veröffentlicht unter der MIT-Lizenz

[aer0700]

Die Frage ist wohl, wie schnell und günstig Computing noch werden kann.
Wenn es eine Zukunft gibt, in der ein durchschnittlicher Server 100.000-mal schneller ist als heute, die Betriebs- oder Installationskosten aber gleich bleiben, dann wäre auch das vermutlich ein sinnvoller Ansatz.
So wie wir mit günstiger werdendem Computing von Maschinensprache zu C und von C weiter zu Node.js oder Python gewechselt sind, könnten wir künftig vielleicht zu LLMs übergehen.
Vieles wird sich ändern, und auf seine Weise dürfte das ziemlich spannend sein. Es werden sich auch viele Chancen ergeben.

[GN⁺]

Hacker-News-Kommentare

• Ich hatte ähnliche Gedanken

  1. Wenn die Codegenerierung vollständig automatisiert wäre und jede Google-Suche in Echtzeit eine maßgeschneiderte Seite erzeugen würde, müsste dann überhaupt noch jemand Websites bauen? An diesem Punkt wäre „Webentwicklung“ wohl weniger Programmieren als vielmehr Intent-Gestaltung (intent-shaping)
  2. Außerdem stimme ich der Behauptung nicht zu, dass Chat die ideale Benutzeroberfläche sei. Natürliche Sprache ist flexibel, aber langsam, mehrdeutig und kognitiv belastend. Wahrscheinlich brauchen LLM-basierte Systeme ein neues UI-Modell, das Konversation mit strukturierten Interaktionen kombiniert

• Als ChatGPT 3.5 erschien, hatte ich diesen Gedanken zum ersten Mal
  Vielleicht kann KI eines Tages Programme vollständig ersetzen, aber der eigentliche Kern ist, die richtige Abstraktion (abstraction) zu finden
  So wie etwa der Wechsel von CVS zu Git das Zeitalter der Microservices eröffnet hat, haben gute Abstraktionen die Kraft, Probleme grundlegend zu verändern
  Damit ein LLM solche Abstraktionen selbst entdecken kann, muss es lange mit der realen Welt interagieren und daraus lernen

• Wenn man dem LLM Werkzeuge hinzufügt, mit denen es Code-Dateien direkt bearbeiten kann, würden sich Reaktionsgeschwindigkeit und Konsistenz wohl stark verbessern
  Der Code würde dann gewissermaßen als Speicher (memory) fungieren
  Direkte HTTP-Anfragen an ein LLM zu schicken ist ähnlich wie ein Cache-Miss, und man könnte auch einen Feedback-Mechanismus beibehalten, der Code-Updates auslöst

  • Das war nur ein einfaches Experiment und sollte zeigen, dass es noch viele Flaschenhälse gibt
    Es gibt viel Spielraum für Optimierung, aber realistisch gesehen dürfte klassisches Coding weiterhin effizienter sein
  • So eine Struktur ist wie das Pflanzen eines Samens (seed): Man definiert Wachstumsrichtung und Grenzen
  • Ich würde das gern selbst bauen

• Das klingt wie die Frage: „Wenn nichtdeterministisches (non-deterministic) Verhalten möglich ist, warum sollte man dann unbedingt deterministisch sein?“
  Aber die meisten Menschen wollen vermutlich keine Web-App, die jedes Mal anders funktioniert

  • Eigentlich wollen Menschen nicht die „Web-App“ selbst, sondern eine Lösung (solution) für ihr Problem
    Deterministischer Code hat Grenzen, wenn es um komplexe Probleme geht, und ein flexiblerer, menschenähnlicher Ansatz könnte besser geeignet sein
  • Heutige LLMs sind größtenteils auf Textausgabe beschränkt und haben kaum Langzeitgedächtnis
    In Zukunft werden LLMs aber wohl reichhaltigere Ausgabe- und Speicherfähigkeiten haben
    Ein LLM könnte zum Beispiel selbst Links erzeugen, die beim Anklicken intern neue Abfragen auslösen, oder eine temporäre Datenbank verwalten
  • Meine Absicht ist nicht zu sagen, dass nichtdeterministisches Verhalten gut sei, sondern die Lücke zwischen heute und einer Post-Code-Ära (post-code) zu zeigen
  • Tatsächlich ist auch heutige Software nicht vollständig deterministisch
    Durch automatische Updates, A/B-Tests, UX-Änderungen usw. verändert sich die Nutzererfahrung laufend
  • Setzt man die Temperatur auf 0 und lässt das LLM Einstellungen in lokalen Dateien speichern, könnte man auch eine deterministische App bauen

• Interessanterweise funktioniert dieser Ansatz auch allein mit dem Kontextfenster, ganz ohne zusätzliche Tools
  Im Juli 2025 habe ich dazu einen PoC gebaut

• Dieses Experiment zeigt gut, wie sich das Konzept von Boilerplate-Code verändern könnte
  Wenn mehrere Instanzen parallel in einer Sandbox laufen und per interner Bewertung das beste Ergebnis ausgewählt wird, entsteht eine Art Meta-Reinforcement-Learning
  Allerdings ist es schwierig, die Absicht des Nutzers in deterministische Ausgaben zu übersetzen, während traditionelle Apps umgekehrt zu wenig flexibel sind
  Letztlich ist entscheidend, wie man Intent-Auswertung (intent evaluation) stabil implementiert

  • Allerdings besteht das Risiko, dass das Modell auf die interne Bewertungsmethode überfitten könnte
    Eine gute Evaluierungsmethode zu entwickeln ist an sich fast so komplex wie das Entwickeln eines KI-Modells

• Anfragen auf traditionelle Weise zu verarbeiten ist kosteneffizienter, als direkt ein LLM dafür zu verwenden
  Um mit einem Modell mit etwa 7 Milliarden Parametern 10 Tokens zu erzeugen, braucht man grob über 100 GFLOPs
  Das ist eine enorme Energieverschwendung

  • Aber sollte man nicht auch die Energiekosten menschlicher Arbeit mit einbeziehen?
    Wenn man im Enterprise-IT-Bereich arbeitet, sieht man schnell, dass menschliche Ineffizienz ebenfalls beträchtlich ist
  • Die Richtung einer Branche stimmt nicht immer mit Optimierung überein
    Sogar Ineffizienz kann zum Trend werden
  • Trotzdem ist der Ansatz sinnvoll, mit einem LLM schnell einen Prototypen (V1) zu bauen, den Product-Market-Fit zu prüfen und erst danach mit traditionellem Code zu optimieren

• Vielleicht könnte man einfach ein LLM auf Port 443 setzen und ihm sagen: „Du bist ein HTTPS-Server und ein App-Server“ ;)

• Braucht man überhaupt eine Web-App? Könnte man nicht einfach per Sprache mit dem Computer sprechen?
  „Zeig mir die Fotos vom Urlaub letztes Jahr, entferne die Wolken und schick sie meinem Freund.“
  „Stell einen Workout-Timer ein und lass Jumping Jacks weg.“
  „Erzeuge mir einen Detroit-Style-Techno-Beat.“
  „Finde mir für heute Abend ein Date, ich bevorzuge schwarze Haare.“
  Ich stelle mir eine Welt vor, in der alles auf diese Weise per Sprache erledigt wird

  • Aber so eine Automatisierung könnte die Handlungsfähigkeit (agency) des Menschen schwächen
    Letztlich wird sich die Menschheit wohl in diejenigen teilen, die das akzeptieren, und diejenigen, die es ablehnen
    Vorboten davon sieht man schon an Phänomenen wie der Rückkehr der Vinyl-Schallplatte
  • Sprachinterfaces sind nicht die Antwort auf jede Form von Kommunikation
    Selbst Menschen bevorzugen oft Text
  • Ich habe diese Woche auch mit WebSpeech eine persönliche Wissensmanagement-App gebaut, die Spracheingaben annimmt und org-mode- sowie logseq-Dateien liest und bearbeitet
    Sie verwaltet To-dos, Einkaufslisten und Termine und ist vollständig auf meine Bedürfnisse zugeschnitten
  • Diese Zukunft wurde in der Science-Fiction oft behandelt
    Komplexe Aufgaben lassen sich per Sprache gut ausdrücken, aber für einfache, repetitive Aufgaben ist eine UI effizienter
    Wenn man zum Beispiel sagt „Kauf mir eine Hose“ und dann unter 30 Ergebnissen eines auswählen muss, braucht man am Ende doch eine visuelle Oberfläche

• Ich habe ein ähnliches PoC auch auf GitHub hochgeladen
  Anfangs wird mit einem langsamen „Design-Modell“ das App-Theme und das DB-Schema erstellt, danach verarbeitet ein schnelles Modell die Anfragen
  Ich habe mit PostREST versucht, die Logik in die DB zu verlagern, aber Schema-Erstellung scheiterte oft und es wurden häufig falsche Queries erzeugt
  Mit einer CSS-Bibliothek habe ich die Konsistenz der UI gewahrt und dafür gesorgt, dass vorherige Seiten erinnert werden
  So ein Ansatz könnte als App Bench dienen, um zu bewerten, ob ein LLM in einem Durchgang eine vollständige App erstellen kann