Ich komme vom Code.

Ich war DevOps, auch wenn das damals noch nicht so hieß. Ich war Entwickler. Ich war Softwarearchitekt. Und dann habe ich mich Schritt für Schritt von diesen Berufen entfernt: Entwicklerteams führen, Projekte, Agilität, Product Management.

Von einem Tag auf den anderen aufgehört zu coden habe ich nicht. Am Anfang schrieb ich noch selbst ein paar Python-Skripte, um eine Aufgabe zu automatisieren, Dateien zu sortieren, ein Format umzuwandeln, mir ein kleines Werkzeug zu bauen. Dann habe ich angefangen, einen Teil davon an ChatGPT abzugeben, im Chat. Danach bin ich nach und nach zu Claude Code gewechselt. Aber es blieben immer kleine Code-Stücke für Werkzeuge — keine Produktentwicklung im vollen Sinne.

Bis hierhin war alles eng gefasst. Ein Python-Skript, eine Funktion. Eine klar umrissene Aufgabe. Eine saubere Art der Delegation: Statt das LLM die Dateien selbst in seinem Kontext sortieren zu lassen, ließ man es ein Skript schreiben. Es führte eine Operation aus, man prüfte, man ging weiter.

Aber seit ein paar Tagen ist es damit vorbei.

Seit vier Tagen entwickle ich wieder. Oder besser: Ich lasse Claude Code entwickeln. Und diesmal geht es nicht um ein Hilfsskript. Es geht um ein echtes Produkt, bei null angefangen, mit Oberflächen, internen APIs, anspruchsvollem Verhalten, Datenänderungen, Architekturentscheidungen, Tests, aus dem Code erzeugter Dokumentation.

Dieser Text ist kein Schlusswort zum vibe coding. Dafür fehlt mir der Abstand. Vier Tage sind zu kurz, um daraus eine Lehre zu bauen. Vielleicht ist genau das der wichtigste Punkt: Ich stecke noch mittendrin. Ich dokumentiere eine Überfahrt.

Die Flitterwochen

Das Erste, was auffällt, ist das Tempo.

In vier Tagen ist etwas entstanden, für das ich zu meiner Entwicklerzeit wohl einen Monat gebraucht hätte. Vielleicht zwei. Und das sage ich nicht, damit es gut klingt. Ich habe bei null angefangen. Ich habe über 180 Commits gemacht. Ich habe gebaut, kaputt gemacht, korrigiert, umgeräumt, getestet, Verhalten ergänzt, das Produkt vorgeführt, Änderungswünsche bekommen, weitergemacht.

Das ist berauschend.

Es gibt diesen Moment, in dem man denkt: Das ist unglaublich. Ich habe eine Idee, ich formuliere sie, ich lasse sie von Claude umsetzen, ich teste, ich justiere, ich fange wieder an. Ich schreibe keine Spezifikation mehr und stelle mir dabei vor, wie das Produkt später einmal aussehen wird. Ich bin schon drin.

Und das ändert einiges.

Mit einem Mockup kann man schon iterieren. Man sieht eine Oberfläche, einen Ablauf, eine Absicht. Man denkt: Der Button sitzt doch falsch, dieser Anwendungsfall ist unklar, da fehlt eine Information. Aber mit einem Produkt, das läuft — und sei es unvollkommen —, wird das Iterieren noch unmittelbarer. Man benutzt es wirklich. Man sieht es wirklich. Man spürt, wo es hakt.

Bei mir kam der Umschwung ganz von selbst. Anfangs sah es aus wie ein Mockup. Dann fing das Mockup an zu funktionieren. Dann habe ich es vorgeführt. Dann wollte man Erweiterungen. Dann fragte man mich, ab wann man es benutzen könne.

Genau da fängt die Gefahr oft an: wenn das Wegwerfding nützlich wird.

Die kalte Dusche

Das Zweite, was auffällt: Wenn man Claude Code allein lässt, kann er wirklich alles Mögliche anstellen.

Nicht in dem Sinne, dass nichts funktioniert. Fast im Gegenteil. Meistens funktioniert es. Die Oberfläche zeigt sich. Die Daten kommen an. Der Button tut etwas. Die Demo läuft durch. Und genau deshalb ist es gefährlich.

Claude neigt dazu, Vollgas zu geben. Er codet. Er ergänzt. Er lässt wachsen. Er beginnt mit einer vernünftigen Datei, und dann bläht sich diese Datei auf, und auf, und auf, bis sie ein Klotz ist, der ein bisschen alles macht. Wenn man sie ändern muss, verliert man Zeit. Wenn man die Absicht dahinter verstehen will, wird es schwierig. Wenn ein Bug auftaucht, weiß man nicht mehr genau, wo man hinschauen soll.

Ein erfahrener Entwickler denkt ziemlich schnell an die Trennung der Zuständigkeiten. Er fragt sich, wohin die Fachlogik gehört, wo der Transport isoliert wird, wo das Rendering hinkommt, wie man die Begriffe benennt, wie man verhindert, dass alles mit allem gekoppelt ist. Claude kann das auch, aber er tut es nicht von allein und nicht durchgehend. Man muss ihn führen.

Bei den Datenmengen ist es dasselbe.

In meinem Projekt geben manche APIs ein paar Hundert Elemente zurück. Andere Zehntausende. Das sind zwei völlig verschiedene Welten. 200 Elemente zu laden und auf einer Seite anzuzeigen, ist nicht dasselbe, wie 20.000 oder 30.000 Elemente zu laden und dann zu hoffen, dass Browser, Nutzer und Backend guter Laune bleiben.

Aber wenn man ihm nichts sagt, lädt Claude ohne Weiteres alles, reicht alles an die Webseite durch, filtert alles im Frontend und hält das Problem damit für erledigt. Im Test, mit wenigen Daten, sieht das aus, als würde es laufen. Im echten Einsatz fliegt es auseinander. Oder schlimmer: Es geht nicht klar kaputt, es wird einfach langsam, zäh, unverständlich.

Ein Bug ist nicht immer eine rote Fehlermeldung in der Konsole. Manchmal ist es einfach ein Produkt, das nicht mehr reagiert, weil still und leise 5.000 Elemente geladen wurden — ohne Log, ohne Paginierung, ohne klare Strategie. Und dann versteht ein PM ohne technischen Hintergrund möglicherweise nicht, was da passiert.

Einen sehr schnellen Junior-Entwickler führen

Die Zusammenarbeit mit Claude Code hat mich stark an die Führung eines extrem schnellen Junior-Entwicklers erinnert.

Er kann enorm viel liefern. Er kann sich auch absurde Freiheiten nehmen. Man gibt ihm einen Screenshot einer Komponente, und er macht nicht genau das, was verlangt war. Er deutet. Er vereinfacht. Er läuft in eine Richtung los. Manchmal muss man ihm ganz grundlegende Dinge noch einmal erklären: warum diese Datei nicht alles enthalten darf, warum diese Schicht jene andere Schicht nicht kennen soll, warum man nicht die kompletten Daten lädt, warum man die Tests schreiben muss, warum man die Tests erneut laufen lassen muss.

Und manchmal versteht er es nicht sofort.

An sich ist das nicht schlimm. Menschliche Entwickler machen auch Fehler. Auch von Entwicklern gebaute Dinge gehen manchmal in Produktion und halten der Last nicht stand. Die technischen Schulden sind nicht mit den PM entstanden, die vibe coding betreiben.

Aber die KI bringt ein Tempo ins Spiel, das das Problem verändert. Sie erlaubt es, sehr schnell sehr viel mittelmäßigen Code zu produzieren. Wenn der Rahmen nicht stimmt, sind die technischen Schulden schnell da. Sehr schnell.

Mir hilft meine technische Vergangenheit. Ich verstehe die groben Linien der Architektur. Ich sehe, wenn eine Datei zu groß wird. Ich sehe, wenn die Schichten sich vermischen. Ich spüre, wenn etwas später bei den Datenmengen oder bei der Wartbarkeit Ärger machen wird.

Aber ich beherrsche nicht alles. Es gibt Stellen im Code, die ich nicht auf Anhieb erklären könnte. Wenn ich mir Zeit nehme, verstehe ich sie. Aber ich kann nicht behaupten, den Code so zu beherrschen, wie wenn ich jede Zeile selbst geschrieben hätte.

Bei diesem Produkt nehme ich das in Kauf. Bei anderen Produkten würde ich es nicht tun.

Und dieser Unterschied ist entscheidend.

Der eigentliche Punkt: Kompetenz mal Risiko

Man könnte die Frage so stellen: Können jetzt alle PM mit KI Software entwickeln?

Meine spontane Antwort wäre: nein.

Oder besser: Es kommt darauf an.

Aber dieses „Es kommt darauf an“ ist kein Ausweichen. Es geht nicht allein um individuelle Kompetenz. Es geht um das Verhältnis zwischen dem Kompetenzniveau und dem Risiko des Produkts.

Es ist genau wie bei einem Junior-Entwickler. Öffnet man einem Junior sofort das komplexeste, kritischste, geschäftlich folgenreichste Repository? Eher nicht. Gibt man ihm Zugang zu allen Repositories, allen Daten, allen Rechten? Auch nicht.

Bei einem PM, der vibe-codet, ist es dasselbe.

Es geht nicht darum zu sagen: PM dürfen das oder dürfen das nicht. Es geht darum festzulegen, was sie tun können, in welchem Rahmen, mit welchen Grenzen, je nach Niveau und je nach Risiko.

Mir gefällt der Vergleich mit dem Führerschein. Man fährt nicht jedes beliebige Fahrzeug ohne Führerschein, weil man sonst gefährlich wird. Und selbst mit Führerschein fährt man nicht alles. Vielleicht darf ein eingerosteter PM eine 125er fahren. Das heißt nicht, dass er sich auf eine schwere Maschine setzen und bei Regen auf die Autobahn soll.

Wenn ich von „PM-Code“ spreche, ist das keine Beleidigung. Ich sage nicht, dass der Code eines PM zwangsläufig schlecht ist. Ich sage, dass er von jemandem stammt, der Code nicht besonders gut beherrscht — oder nicht mehr besonders gut. Also muss man Einschränkungen akzeptieren. Und vor allem: Man muss akzeptieren, sie zu definieren.

Grün, Orange, Rot

An ein allgemeingültiges Raster glaube ich nicht.

Jedes Unternehmen wird seine eigene Politik festlegen müssen. Aber das Prinzip scheint mir klar: Je mehr ein Produkt sensible Daten berührt, je mehr Schreibzugriffe es hat, je kritischer die Abläufe, je näher an Sicherheit, Abrechnung und Berechtigungen, desto höher müssen die Anforderungen sein.

Ein kleines internes Werkzeug, persönlich, kurzlebig, mit begrenzter Wirkung, kommt vermutlich mit wenig Formalismus aus. Wenn es kaputtgeht, ist es nicht schlimm. Man wirft es weg, man repariert es, man macht etwas anderes.

Ein geteiltes internes Werkzeug, mit anspruchsvollem Verhalten, begrenzten Schreibzugriffen, fachlichen Abhängigkeiten, ist schon etwas anderes. Da muss man sich mehr Fragen stellen.

Und sobald es um kritische Produktion geht, um sensible Kundendaten, um Berechtigungen, um unumkehrbare Schreibvorgänge, um Abläufe mit starker Wirkung auf Kunden oder Geschäft, wechselt man noch einmal die Kategorie.

Die Sicherheit zum Beispiel scheint mir nicht verhandelbar. Über das nötige Testniveau eines kleinen Wegwerfwerkzeugs kann man diskutieren. Über das Review kann man diskutieren. Über den Grad der Dokumentation kann man diskutieren. Aber die Sicherheit sollte nicht von der Tagesform abhängen.

Zum Glück haben die Entwickler dafür längst viel Werkzeug: Continuous Integration, Scanner, Regeln, Praktiken, Kompetenzen, manchmal sogar interne Prompts oder Skills. Es geht also nicht darum, für die PM alles neu zu erfinden. Es geht darum, die KI-gestützten PM an das anzuschließen, was schon da ist.

Nein, an das systematische Review glaube ich nicht

Man könnte antworten: Es reicht doch, wenn Entwickler alles gegenlesen.

Dieser Antwort traue ich nicht so recht.

Das systematische Review ist zum Reflex geworden, aber man darf darüber ruhig streiten. Es stammt vor allem aus der Open-Source-Welt, und das aus vielerlei Gründen: Qualität, Sicherheit, Wissensweitergabe, Governance, Vertrauen zwischen Beitragenden. Aber dass in einem Unternehmen wirklich jede Art von Code in jeder Lage systematisch gegengelesen werden muss — davon bin ich nicht überzeugt.

Wenn ein PM sich ein persönliches Werkzeug baut, zum Wegwerfen, mit geringem Risiko: Muss man dafür wirklich einen Entwickler abstellen? Vielleicht nicht. Sonst stellt man genau die Abhängigkeit wieder her, die man abbauen wollte.

Am Anfang kann das Review dagegen sehr wohl eine Rolle spielen, um den PM gute Praktiken beizubringen. Und je nach Tragweite kann es auch nötig sein. Noch einmal: Es ist kein Ja oder Nein. Es ist eine Frage des Risikos.

Irgendwann muss man auch die Verantwortung annehmen. Wenn ich beschließe, mir ein Werkzeug zu bauen, muss ich bereit sein, es auch selbst im Alltag einzusetzen. Wenn es Bugs gibt, ist es auch an mir, damit klarzukommen. Und genau da kann es wehtun, denn viele PM wissen nicht unbedingt, wie man die Bugs behebt, die sie gerade mit der KI erzeugt haben.

Tests als Hebel der Kontrolle

In diesem Experiment sind die Tests zentral geworden.

Nicht einfach, weil „Tests gut sind“. Sondern weil sie eines der wenigen Mittel sind, die Kontrolle über Code zu behalten, den man nicht vollständig selbst geschrieben hat.

Claude schreibt nicht von allein die richtigen Tests, wenn man ihn nicht darum bittet. Er kann sie vergessen. Er kann sie nachträglich schreiben. Er kann Tests schreiben, die seine Implementierung bestätigen statt der fachlichen Absicht. Er kann den Eindruck erzeugen, das Produkt sei abgesichert, weil es Tests gibt — obwohl eine echte Teststrategie fehlt.

Ein PM kennt TDD nicht unbedingt. Er kennt nicht unbedingt den Unterschied zwischen Unit-Test, Integrationstest und End-to-End-Test. Er kennt nicht unbedingt die Testpyramide. Er weiß nicht immer, wann man ein Verhalten testen sollte, bevor man es codet, und wie man eine Fachregel als Test ausdrückt.

Und dabei ist das in einem vibe-coding-Projekt vielleicht einer der wichtigsten Punkte.

In meinem Projekt gibt es über 500 Tests. Für ein Projekt dieser Größe ist das viel. Meistens geht nichts kaputt, und zwar gerade deshalb, weil Claude die Tests sehr häufig laufen lässt. Wenn doch etwas bricht, geben die Tests Halt. Sie zeigen, wo das erwartete Verhalten nicht mehr eingehalten wird.

Ich sage nicht, dass alles mit demselben Anspruch getestet werden muss. Ein sehr einfaches kleines internes Werkzeug mit geringem Risiko braucht nicht zwingend eine vollständige Teststrategie. Auch hier: eine Frage der Tragweite.

Aber sobald das Produkt ernster wird, sind Tests kein Bonus mehr. Sie werden Teil des Lenkrads.

Leitplanken bremsen nicht nur, sie beschleunigen

Wenn ich von Leitplanken spreche, meine ich nicht nur Schutzgitter, die PM vom Unfug abhalten.

Leitplanken dienen auch dem Tempo.

Lässt man einen PM und Claude Code allein vor dem Quellcode sitzen, greift die KI womöglich nicht zu den richtigen internen APIs. Sie nimmt den falschen Einstiegspunkt. Sie baut etwas nach, das es längst gibt. Sie liefert ein Werkzeug, das schlecht läuft, oder gar nicht, oder sie verliert Unmengen Zeit damit, die vorhandene Architektur zu umgehen.

Stellen die Entwickler dagegen Leitplanken bereit, wissen der PM und die KI, wohin sie gehen sollen.

Diese Leitplanken können vieles sein: ein Katalog der nutzbaren internen APIs, eine aus dem Code erzeugte fachliche Dokumentation, eine Zuordnung zwischen Fachbegriffen und technischen Einstiegspunkten, Beispielabfragen, wiederverwendbare Oberflächenkomponenten, Konventionen, geregelte Zugriffe, eine CI für Sicherheit, Claude-Dateien, Prompts, Skills.

Man kann sich zum Beispiel eine Umgebung vorstellen, in der ein PM interne Oberflächen, Abfragewerkzeuge, Listen, Diagramme oder fachliche Szenarien baut — gestützt auf dokumentierte und abgenommene APIs. Die gesamte technische Infrastruktur bauen die Entwickler. Der PM startet nicht vor einem leeren Blatt. Er setzt innerhalb eines Rahmens zusammen.

Genau das machen manche Werkzeuge seit Langem mit Abfragesprachen, Dashboards oder internen Plattformen. Die KI macht diese Logik nur mächtiger.

Und darauf kommt es an: Leitplanken bremsen nicht nur. Sie beschleunigen, weil sie die KI davor bewahren, den falschen Weg zu nehmen.

Vom kleinen internen Werkzeug zum Product Builder

Es gibt vielleicht noch eine Stufe darüber.

Bis hierhin könnte man meinen, ich rede nur von kleinen internen Werkzeugen: eine Ansicht, ein Export, ein Dashboard, ein Abfragewerkzeug, eine vorübergehende Oberfläche als Hilfe fürs Produktteam. Diesen Fall gibt es, und er ist schon interessant genug. Er kann Entwickler entlasten, den Alltag beschleunigen, einem Produktteam erlauben, bestimmte Bedürfnisse selbst zu bedienen.

Aber das ist nicht zwingend der einzige Horizont.

Wenn die Codebase des Unternehmens gut gefasst ist, wenn die internen APIs dokumentiert sind, wenn die Fachbegriffe lesbar sind, wenn Komponenten und Konventionen stabil sind, dann kann der PM vielleicht über das bloße interne Werkzeug hinausgehen. Er kann so etwas wie ein Product Builder werden.

Kein eigenständiger Entwickler für beliebige Themen. Niemand, dem man ohne Grenzen die kritischen Zonen des Produkts anvertraut. Aber jemand, der ein Modul, eine Oberfläche, einen Ablauf oder eine fachliche Variante bauen kann, gestützt auf die vorhandene Codebase.

Der Unterschied ist wichtig.

Beim kleinen internen Werkzeug baut der PM meist neben dem Produkt. Er konsumiert APIs, führt Informationen zusammen, produziert eine Oberfläche, die ihm oder seinem Team nützt.

Als Product Builder baut er eher in der Verlängerung des Produkts. Er nutzt die vorhandenen Bausteine, die Fachsprache des Codes, die Komponenten des Unternehmens, die Leitplanken der Entwickler. Er startet nicht vor einem leeren Blatt. Er arbeitet mit einem bereits strukturierten Material.

Und genau hier wird die Qualität der Codebase entscheidend. Eine schlecht gefasste Codebase sperrt PM und KI in die Bastelei ein. Eine lesbare, dokumentierte, fachlich orientierte und gut ausgestattete Codebase kann dagegen einen viel größeren Beitragsraum öffnen.

Vibe coding macht aus einem PM also nicht automatisch einen Product Builder. Es reicht nicht, ihm Claude Code und ein Git-Repository zu geben. Es braucht begehbares Gelände.

Wenn dieses Gelände existiert, wird die Sache sehr viel interessanter als die Frage „Können PM sich ihre kleinen Werkzeuge bauen?“. Die eigentliche Frage lautet dann: Wie weit kann eine Organisation Produktleuten erlauben, bestimmte Teile des Produkts direkt zu bauen, ohne die technische Kontrolle, die Kohärenz und die Sicherheit zu verlieren?

Und was ist mit den Spezifikationen?

Dieses Experiment hat mir auch eine fast provokante Frage zurückgebracht: Muss man überhaupt noch Spezifikationen schreiben?

Ich sage nicht, dass Spezifikationen überall verschwinden. Für viele Produkte, viele Zusammenhänge, regulatorische Themen und strukturierende Entscheidungen wird man weiterhin schreiben, festlegen, diskutieren und das Warum dokumentieren müssen.

Aber bei manchen internen Werkzeugen frage ich mich, ob die Spezifikation nicht gerade ihren Status ändert.

Ich habe in meinem Fall keine Spezifikation geschrieben. Ich habe angefangen. Ich habe gebaut. Ich habe es gezeigt. Man hat mir gesagt: Das fehlt, das bräuchte es, und zwar aus diesem und jenem Grund. Ich habe ergänzt. Ich habe iteriert.

Warum ein Mockup bauen, wenn ich direkt eine erste benutzbare Version bauen kann? Warum eine beschreibende Spezifikation schreiben, wenn ich das Verhalten im Produkt entstehen lassen und danach die fachliche Dokumentation aus dem Code erzeugen kann?

Ich hatte kürzlich geschrieben, dass die Produktfrage vom Quellcode ausgehen muss. Dieses Experiment weist in dieselbe Richtung, nur von der anderen Seite. Wenn der Code zur Wahrheit über das Verhalten wird, kann ein Teil der Dokumentation aus ihm neu erzeugt werden. Die Spezifikation verschwindet nicht zwangsläufig, aber sie kann nicht länger beanspruchen, dauerhaft die Wahrheit über das Produkt zu sein.

Für manche Bereiche könnte man fast sagen: Wir schreiben die Spezifikation nicht mehr vorher. Wir bauen, wir validieren, und dann erzeugen wir die Fachbeschreibung aus dem, was läuft.

Ich übertreibe natürlich ein wenig. Aber nicht so sehr.

Das organisatorische Risiko

Es gibt noch ein Risiko, weniger technisch, eher organisatorisch.

Wenn jeder anfängt, sich in seiner Ecke kleine Werkzeuge zu bauen, kann das schnell auseinanderlaufen. Nicht gewartete interne Werkzeuge können wichtig werden. Wegwerfskripte können am Ende jede Woche benutzt werden. Eine für ein Team zusammengebastelte Oberfläche kann zur Pflichtstation werden. Ein Werkzeug ohne Governance kann kritisch werden, ohne dass es je jemand so entschieden hätte.

Aber dieses Risiko gehört nicht zum vibe coding allein. Unternehmen kennen das längst von Excel-Dateien, Makros, Skripten, No-Code-Werkzeugen, Dashboards, die irgendwo im Stillen entstanden sind. Vibe coding schafft das Problem nicht. Es beschleunigt es, weil es das Bauen von Werkzeugen leichter macht.

Auch hier ist die Antwort kein Verbot. Die Antwort heißt: Zonen, Rechte, Verantwortlichkeiten, Grenzen und Leitplanken festlegen.

Was sich für die Entwickler ändert

Ich glaube nicht, dass PM die Entwickler ersetzen werden.

Ich glaube aber, dass manche kleinen internen Werkzeuge, die man bisher bei den Entwicklern bestellt hat, künftig direkt von Produkt-, Support-, Ops- oder Fachteams gebaut werden können — vorausgesetzt, der Rahmen stimmt. Und das kann die Entwickler entlasten.

Wie oft bittet man ein Entwicklerteam, den Produktkern zu verlassen, um ein kleines internes Werkzeug, einen Export, eine Ansicht, ein Dashboard oder eine vorübergehende Oberfläche zu bauen? Wenn ein Teil dieser Anfragen woanders aufgefangen werden kann, ist das nicht unbedingt eine schlechte Nachricht.

Aber die Rolle der Entwickler verschwindet dadurch nicht. Im Gegenteil, sie kann sich verschieben. Sie werden auch zu denen, die die Leitplanken bauen, die Plattformen, die sauberen APIs, die Konventionen, die sicheren Umgebungen, in denen andere etwas produzieren können, ohne alles kaputt zu machen.

Das ist nicht weniger technisch. Vielleicht ist es sogar architektonischer.

Die Erschöpfung

Ich will dieses Experiment nicht als reinen Rausch verkaufen.

Es ist anstrengend.

Über 180 Commits in vier Tagen sind auch mit einer KI nicht nebenbei zu haben. Man tippt nicht den ganzen Code, aber man steuert, liest gegen, testet, korrigiert, entscheidet, setzt neu an, beobachtet, erklärt noch einmal. Man kommt sehr schnell voran, aber man muss dem Tempo folgen.

Vibe coding gibt ein Gefühl von Macht, aber diese Macht ist nicht umsonst. Der PM wird zu einer Art Steuermann, Architekt auf kurze Distanz, Tester, Reviewer, Absichtsgeber, Leitplanke. Und wenn ihm die technische Kultur fehlt, steuert er am Ende etwas, das er nicht wirklich versteht.

Genau da wird das Gefühl von Kompetenz gefährlich.

Das kennen wir schon vom No-Code. Manche dachten, sie bräuchten keine Entwickler mehr, und entdeckten drei Tage später, dass eine Website ohne Sicherheit, ohne Schutz gegen Brute-Force-Angriffe, ohne Circuit Breaker sehr schnell zum Problem werden kann. Nicht, weil das Werkzeug schlecht gewesen wäre. Sondern weil es enorme Möglichkeiten zugänglich machte, ohne die Sicherheits- und Architekturkultur mitzuliefern, die dazugehört.

Vibe coding wirft dieselbe Art von Frage auf.

Ich dokumentiere eine Überfahrt

Ich habe keine abschließende Antwort.

Und das ist nach vier Tagen vielleicht die einzige ernsthafte Antwort, die es geben kann.

Ich bin noch mitten im vibe coding. Ich lerne weiter. Ich sehe weiter, was funktioniert, was bricht, was mir entgeht, was die Tests auffangen, was die Leitplanken beschleunigen, was mein alter technischer Hintergrund mich noch immer spüren lässt.

Ich will mir keine Meinung von der Tribüne aus zurechtlegen. Ich will sie mir in der Praxis erarbeiten.

Was ich im Moment sehe, ist eine neue, sehr mächtige Fähigkeit — eine, die die alten Fragen der Softwareentwicklung aber nicht abschafft. Manchmal macht sie sie sichtbarer. Sie beschleunigt sie. Sie verschiebt sie.

Mit vibe coding kommt man sehr schnell voran. Aber schnell voranzukommen ist nicht dasselbe, wie zu wissen, wohin man fährt — und was man dabei kaputtmachen könnte.

Also mache ich weiter.

Ich dokumentiere eine Überfahrt.