> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/de/2026/w16-nocode-rapid-iteration-and-new-engineering-constraints.md).

# W16-nocode, schnelle Iterationen und neue technische Grenzen

Vergangene Woche veröffentlichte HR eine Vlog-Aktion zum zehnjährigen Bestehen von Financial Services. Unser Praktikant Luo Huayu baute das gesamte Projekt mit nocode. Ich sah mir den Code an und machte einige interessante Beobachtungen.

Erstens überraschen mich bei solchen Projekten Produktivitätsgewinne um ein Mehrfaches oder sogar einige Dutzend Male durch no-code nicht. Überraschend war, dass im gesamten Ablauf 268 Versionen entstanden. Wir wissen, dass KI Softwareauslieferung weiter beschleunigt. Produktive Projekte dürften künftig ebenfalls mehrfach schneller iterieren. Was danach passiert, zeigt dieses Projekt recht gut.

Bei ähnlichen Gewinnspielaktionen arbeiteten früher meist ein Frontend- und ein Backend-Entwickler. Für etwas mehr als zwei Wochen Zeit bauten sie zunächst über eine Woche lang mühsam ein MVP. Kunden sahen es, machten Vorschläge, die Entwickler überarbeiteten es und zeigten zwei Tage später die nächste Fassung. Oft waren die Kunden noch unzufrieden. Es folgte eine weitere Runde. Am Ende fehlte die Zeit, und es hieß: „Lassen wir es erst einmal so.“ Tatsächlich sahen Kunden vielleicht drei oder vier Versionen. Der Iterationsspielraum war schnell erschöpft.

nocode verkürzt den Weg von Anforderung zu Umsetzung stark. Kunden erhalten schneller Rückmeldung und entwickeln schneller neue Ideen. In derselben halben Monatsfrist entstanden nun über zweihundert Versionen. Iterationen, die früher nie stattgefunden hätten, werden möglich. Deshalb werden Zeit- und Ressourcenaufwand nach Produktivitätssteigerungen nicht unbedingt deutlich sinken. Eher könnte das Jevons-Paradoxon gelten: Eine niedrigere Umsetzungshürde erzeugt mehr Ideen und mehr Iterationen. Bedarf kann sich dem Unendlichen nähern. Nicht unbedingt die Arbeit verschwindet. Vielmehr wird bisher unmögliche Weiterentwicklung freigesetzt.

Zweitens hatte ich beim Lesen des Codes stark das Gefühl, dass Menschen selten freiwillig so programmieren würden. Der vollständige Webdienst hat keinen eigenen Server. Das Frontend greift direkt auf die Datenbank zu und verwendet insgesamt sechzehn gespeicherte Prozeduren. Es ist eine typische Frontend-only-plus-BaaS-Architektur. React und Vite bauen eine SPA. Alle Datenoperationen laufen im Browser über supabase-js direkt gegen Meituans private Supabase-Installation mit PostgreSQL darunter.

Die Geschäftslogik ist zweigeteilt. Einfache Prüfungen und Frequenzbegrenzungen liegen im Frontend in worksApi.js. Kernlogik mit Nebenläufigkeits- und Konsistenzanforderungen wie Abstimmen, Liken und Löschen ist in PostgreSQL-Funktionen gekapselt und wird über supabase.rpc() aufgerufen. Berechtigungen sichern vor allem RLS-Regeln in der Datenbank ab. Das ist schnell zu entwickeln und spart den Betrieb eines eigenen Backends. Die Nachteile sind ebenso klar: Geschäftslogik verteilt sich auf JavaScript im Frontend und PL/pgSQL in der Datenbank. Die Wartbarkeit ist mäßig. Manche sensiblen Informationen wie Administratorlisten landen sogar fest codiert im Client.

Der Wert dieses Projekts liegt nicht nur darin, dass nocode eine Aktionsseite schneller baut. Es zeigt konkret eine neue Normalität der Softwareauslieferung mit KI. Es gibt mehr Versionen, schnellere Rückmeldungen und Architekturen, die zunächst den kürzesten Umsetzungsweg wählen. Für Teams liegen darin reale Produktivitätschancen und neue technische Grenzen. Knapp wird künftig vielleicht weniger die erste funktionsfähige Umsetzung sein als die Fähigkeit, bei extrem schneller Iteration Architekturgrenzen, Wartbarkeit und langfristige Entwicklung zu bewahren.