Jede Generation wählt den falschen Tech-Stack. Vibe Coder sind da keine Ausnahme.

6 min read

Jetzt kannst du Apps bauen, ohne zu verstehen, was darunter läuft.

Klar, solange es funktioniert, funktioniert es... Aber wenn du mehr Ambitionen hast als ein simples Heimwerkzeug, wenn du es weiterentwickeln, skalieren und irgendwann verkaufen willst, musst du dir früher oder später die Hände schmutzig machen. Die No-Code-Welle sagte, du musst nicht programmieren. Die Vibe-Coding-Welle sagt, du musst die Architektur nicht verstehen. Beides stimmt, bis es nicht mehr stimmt. Und wenn es aufhört zu stimmen, schreibst du alles neu.

LLMs eliminieren dieses Muster nicht. Sie beschleunigen es.

Geteilter Büro-Arbeitsplatz mit zwei Entwicklern mit gegensätzlichen Tech-Ansätzen: einer überfordert von komplexer Architektur und Dependencies, der andere entspannt mit minimalem Setup, getrennt durch einen Roboter-Hummer auf einem USB-Kabel.
Dein Tech-Stack ist nicht falsch. Er ist nur nicht so cool wie ihrer.

Das gleiche Drehbuch, 3 Mal

Irgendwann in den 80ern kam BASIC mit einem simplen Versprechen: Du musst keine Pointer verstehen oder Speicher verwalten, schreib einfach die Logik. Und eine Zeit lang war das völlig real. Du konntest echte Programme bauen, ohne jemals die Low-Level-Details anzufassen, was für viele Leute, die einfach nur etwas Funktionierendes wollten, wirklich befreiend war. Das Problem war nicht das Versprechen. Das Problem war, was das Versprechen unsichtbar hielt. Als dein BASIC-Programm komplex genug wurde, kam die Kopplung pünktlich wie bestellt. UI-Logik und Business-Logik verhedderten sich ohne saubere Trennlinien und ohne Möglichkeit, etwas zu testen, ohne alles andere anzufassen. Das Neuschreiben war kein Versagen von BASIC. Es war von Anfang an Teil des Deals.

Irgendwo in einer Schublade habe ich noch eine Diskette von 1993 mit einem BASIC-Programm, das die Geburtstagskartenliste meiner kleinen Schwester automatisierte. Adressierte Umschläge, 47 Stück, gedruckt auf einem Nadeldrucker etwa so schnell wie Kontinentaldrift. Ich habe absolut keine Ahnung, warum ich gerade daran denke.

Visual Basic verlängerte den gleichen Deal bis Mitte der 2000er, nur mit Formularen und Event-Handlern statt Zeilennummern. Dann tauchte No-Code mit einer noch saubereren Version des Versprechens auf: Du musst gar nicht programmieren. Wieder wahr, bis du ein Feature brauchst, das die Plattform nicht unterstützt, oder du die Preisobergrenze erreichst, oder du Daten irgendwohin verschieben musst, wo die Plattform nicht hinkommt. Die Obergrenze von No-Code ist genau der Rand der Plattform. Du findest sie im denkbar schlechtesten Moment, wenn am meisten auf dem Spiel steht.

Vibe Coding ist der dritte Akt. Das Versprechen ist aufgerüstet, aber darunter fast wortgleich: Du musst die Architektur nicht verstehen. Beschreib einfach, was du willst, der Agent erledigt den Rest. Wahr, für viele Fälle, für eine Weile. Was bei allen 3 Wellen konstant bleibt, ist nicht das Tool. Es ist die Fußnote, die das Versprechen weglässt: "Du musst X nicht verstehen, außer wenn dein Problem die Form von X hat." Und diese Bedingung kann der Anfänger im Moment der Entscheidung nicht sehen. Das lässt das Versprechen real wirken, bis das Neuschreiben beginnt.

Dein Agent kennt das populäre Problem

Ich habe diese Woche Threads gelesen darüber, was man um AI-generierten Code orchestrieren sollte. State Management, Retry-Logik, Rollback, all die Rohrleitungen, die das umgeben, was Agents produzieren. Die Tools in diesen Threads sind technisch korrekt. Sie lösen echte Probleme. Aber die echten Probleme, die sie lösen, wurden upstream geschaffen, durch frühere Entscheidungen: eine vollständige React SPA, ein dicker Client, komplexer State verteilt über mehrere Services. Wenn du diese Probleme nicht hast, brauchst du diese Lösungen nicht.

Und wann immer jemand fragt, wie man die Orchestrierungskomplexität handhaben soll, sagt mindestens 1 Kommentar in jedem Thread: "Sag einfach deinen Agents, dass sie das handhaben sollen." Was völlig wahr ist. Und auch die nützlichere Frage umgeht, nämlich warum diese Agents die Komplexität überhaupt erst produziert haben. (Es läuft auf meiner Maschine. Die Maschine braucht nur zufällig 14 Services in Docker, um zu funktionieren.)

Wenn du einen Agent bittest, eine App zu bauen, produziert er die statistisch wahrscheinliche Antwort für den Problemtyp, auf den er am häufigsten trainiert wurde: nicht die Antwort, die zu deinen tatsächlichen Constraints passt, sondern die Antwort, die am wahrscheinlichsten korrekt ist über alle Male hinweg, wo diese Art von Frage gestellt wurde. Der Agent optimiert für die modale Antwort, was in der Praxis das dominante Muster im Ökosystem bedeutet. Du fragst nach einer App und bekommst den Standard-Stack: React mit einem Bundler, eine State-Management-Schicht, das ganze Setup. Der Agent macht genau das, was er soll, denke ich. Er kann nur nicht wissen, dass dein spezifisches Problem nichts davon braucht.

Ich bin die gleiche Übung für Tooling durchgegangen, nicht Code: ob CLI oder MCP tatsächlich zu Production-Agents passt. Die populäre Option hat das gleiche Problem.

Bevor ich den Prompt öffnete

Ich habe gerade 2 Projekte laufen, gebaut in etwa der gleichen Zeit, gleicher Entwickler, gleicher AI-assistierter Workflow.

Das erste ist ein leichtgewichtiges Tool. Server-gerendert, Hono JSX, null Frontend-Bundler. Der erste Durchgang meines Agents kam mit 23 Runtime-Dependencies zurück. Ich brauchte 1. Die Extras waren nicht falsch im absoluten Sinne. Jede löst ein echtes Problem in einem echten Kontext, aber keiner dieser Kontexte war meiner. (Claude Code schlug immer wieder React Query für eine server-gerenderte App mit null Client-State vor. Ich widersprach 3 Mal. Beim 4. Prompt ließ es den Vorschlag endlich fallen.) Es gibt keine State-Komplexität, die der Rede wert wäre, und keinen Flow, der komplex genug ist, um eine State Machine zu rechtfertigen. XState wäre Engineering für ein Problem gewesen, das nicht existiert.

You Died.

Das zweite Projekt ist eine SaaS mit zahlenden Kunden und einem mehrstufigen Import-Flow, wo Fehlermodi tatsächlich wichtig sind. Wenn Schritt 2 fehlschlägt, läuft Schritt 3 nicht. Wenn der Import mittendrin stirbt, sieht der User den exakten Fehlerzustand, nicht einen generischen Fehler. Dieses Projekt nutzt React 18 und XState v5, aber nur 1 Machine, für genau diesen 1 Flow. Der Rest der App berührt XState nicht. Muss er auch nicht. Ein Produkt hat normalerweise viele Oberflächen, die einfach sind, und 1 Oberfläche, die tatsächliche State-Komplexität hat, und der Fehler ist, das ganze Produkt so zu behandeln, als hätte es die Komplexität des schwierigsten Teils.

Bevor ich einen einzigen Prompt für beide Projekte schrieb, stellte ich mir 1 Frage: Hat dieses Problem unterschiedliche benannte Zustände mit expliziten Übergängen und separaten Fehlermodi? Für das Tool: nein. Für den SaaS-Import-Flow: ja, aber nur für diesen spezifischen Flow.

Der Agent kann diese Frage nicht beantworten. Er kennt dein Problem nicht gut genug, um sie zu stellen.

Dein Agent optimiert für das populäre Problem. Stell sicher, dass deins tatsächlich eins ist.

Die Constraint, die sich nicht delegieren lässt

Die Fähigkeit, die jede Welle intakt überlebt hat, ist zu wissen, welche Komplexität dein Problem tatsächlich erfordert.

Keine der 3 Wellen baute sie auf, weil keine von ihnen musste. Jede Welle überzeugte genug Leute lange genug, dass die Fähigkeit nicht gebraucht wurde. BASIC machte es zuerst, dann verpackte No-Code das gleiche Versprechen in Drag-and-Drop, und jetzt spielt Vibe Coding den gleichen Zug in natürlicher Sprache. Die Obergrenze ist jedes Mal die gleiche.

Vibe Coding beschleunigt beide Seiten der Gleichung: das Bauen und die Schulden. Das erste Neuschreiben kommt schneller, nicht niemals. Die Architekturfrage verschwindet nicht. Sie wird auf einen Moment verschoben, wo mehr Code zu entwirren ist und mehr Entscheidungen bereits eingebacken sind, die jetzt etwas kosten zu ändern.

Das, was sich nicht delegieren lässt, ist nicht das Programmieren. Es ist die Diagnose. Bevor du den Prompt öffnest, bevor du die App dem Agent beschreibst: Kannst du in einfacher Sprache erklären, warum du X in diesem Projekt NICHT brauchst? Der Agent weiß bereits, dass X im Allgemeinen nützlich ist. Die Frage ist, warum dein spezifisches Projekt mit seinen tatsächlichen Constraints es gerade nicht braucht. Wenn du das beantworten kannst, kannst du den Agent auf den angemessenen Stack beschränken statt auf den modalen. Wenn du es nicht kannst, defaultet der Agent auf populär, und es wird technisch nicht falsch sein, nur nicht richtig für dich.

Ich habe den exakten Mechanismus dargelegt in wie Prompt Contracts tatsächlich einen Agent beschränken. Die Constraint ist der 1 Schritt, den der Agent nicht für dich machen kann. Alles andere handhabt der Agent ziemlich gut.

Es ist auch die Fähigkeit, von der BASIC, Visual Basic und No-Code alle sagten, du müsstest sie nicht lernen. Bemerkenswert.

Wenn du dein Auto in die Werkstatt bringst, ohne etwas darüber zu wissen, was unter der Haube ist, ist die Rechnung immer eine Überraschung. Der Mechaniker kennt seinen Job. Du weißt nur nicht, was du hinterfragen oder wogegen du dich wehren sollst. Genauso mit deiner App. Du findest heraus, was darunter läuft, in dem Moment, wo du etwas ändern willst oder es an jemand anderen weitergeben willst. Die Rechnung passt meistens dazu.

Quellen

Dieser Post kann Affiliate-Links enthalten. Wenn du sie anklickst, verdiene ich möglicherweise eine kleine Provision, kostet dich nichts und hilft mir dabei, weiterhin täglich qualitativ hochwertige Artikel für dein Lesevergnügen zu liefern.