Ursprünglich auf Französisch verfasst. Von KI übersetzt — der Sinn wurde bewahrt, nicht der Stil.
Ich komme aus dem Code.
Ich war DevOps, auch wenn man das damals nicht unbedingt so nannte. Ich war Entwickler. Ich war Softwarearchitekt. Dann habe ich mich schrittweise von diesen Berufen entfernt und bin zur Führung von Entwicklerteams, zum Projektmanagement, zur Agilität, zum Product Management übergegangen.
Ich habe nicht von heute auf morgen vollständig aufgehört zu kodieren. Anfangs schrieb ich noch selbst ein paar Python-Skripte, um eine Aufgabe zu automatisieren, Dateien zu sortieren, ein Format zu transformieren, ein kleines Tool zu bauen. Dann habe ich begonnen, einen Teil dieser Entwicklung an ChatGPT zu delegieren, im Chat-Modus. Danach bin ich schrittweise zu Claude Code übergegangen. Aber in allen Fällen blieb es bei kleinen Code-Stücken für Tools, kein echtes Produktentwicklung im vollen Sinne.
Bisher war das sehr eingegrenzt. Ein Python-Skript, eine Funktion. Eine präzise Aufgabe. Eine saubere Delegation: Statt den LLM darum zu bitten, Dateien selbst in seinem Kontext zu sortieren, ließ man ihn ein Skript schreiben. Es führte eine Operation aus, man prüfte, man machte weiter.
Aber seit einigen Tagen ist das nicht mehr so.
Seit vier Tagen habe ich wieder mit der Entwicklung angefangen. Oder genauer gesagt: Ich lasse Claude Code entwickeln. Und diesmal rede ich nicht von einem Hilfsskript. Ich rede von einem echten Produkt, von null gestartet, mit Bildschirmen, internen APIs, fortgeschrittenen Verhaltensweisen, Datenänderungen, Architekturentscheidungen, Tests, vom Code generierter Dokumentation.
Dieser Text ist keine Schlussfolgerung über Vibe Coding. Dafür fehlt mir der Abstand. Vier Tage sind zu kurz, um eine Doktrin zu erschaffen. Das ist vielleicht sogar der wichtigste Punkt: Ich bin noch mittendrin. Ich dokumentiere eine Überquerung.
Die Honeymoon-Phase
Das Erste, das auffällt, ist die Geschwindigkeit.
In vier Tagen habe ich etwas produziert, das mich zu der Zeit, als ich selbst entwickelte, wahrscheinlich einen Monat gekostet hätte. Vielleicht zwei. Und das sage ich nicht, um es schöner klingen zu lassen. Ich bin von null gestartet. Ich habe mehr als 180 Commits gemacht. Ich habe gebaut, gebrochen, korrigiert, reorganisiert, getestet, Verhaltensweisen hinzugefügt, das Produkt präsentiert, Evolutionswünsche erhalten, weitergemacht.
Das ist berauschend.
Es gibt einen Moment, in dem man sich sagt: Das ist unglaublich. Ich kann eine Idee haben, sie formulieren, Claude bitten, sie zu implementieren, testen, anpassen, wiederholen. Ich schreibe keine Spec mehr, indem ich mir vorstelle, wie das Produkt später aussehen wird. Ich bin schon drin.
Und das verändert viel.
Mit einem Prototyp kann man schon iterieren. Man sieht einen Bildschirm, einen Parcours, eine Absicht. Man sagt sich: Der Knopf ist eigentlich nicht an der richtigen Stelle, dieser Anwendungsfall ist nicht klar, eine Information fehlt. Aber mit einem Produkt, das funktioniert — auch wenn es unvollkommen ist —, wird die Iteration noch direkter. Man nutzt wirklich. Man sieht wirklich. Man spürt die Reibungen.
In meinem Fall kam die Verschiebung recht natürlich. Am Anfang sah es aus wie ein Prototyp. Dann begann der Prototyp zu funktionieren. Dann habe ich ihn präsentiert. Dann wurden Evolutionen von mir verlangt. Dann wurde ich gefragt, wann man ihn benutzen kann.
Genau dort beginnt oft die Gefahr: wenn das Wegwerfbare nützlich wird.
Die kalte Dusche
Das Zweite, das auffällt, ist, dass Claude Code, wenn man ihn allein lässt, absolut alles machen kann.
Nicht alles im Sinne von, dass nichts funktioniert. Es ist fast das Gegenteil. Oft funktioniert es. Der Bildschirm wird angezeigt. Die Daten kommen hoch. Der Knopf tut etwas. Die Demo läuft. Und genau deshalb ist es gefährlich.
Claude hat eine natürliche Tendenz zu preschen. Er kodiert. Er fügt hinzu. Er wächst. Er beginnt mit einer vernünftigen Datei, dann schwillt diese Datei an, an, an, bis sie zu einem Block wird, der irgendwie alles macht. Wenn man sie ändern muss, verliert er Zeit. Wenn man die Absicht verstehen muss, wird es schwieriger. Wenn ein Bug auftaucht, weiß man nicht mehr genau, wo man schauen soll.
Ein erfahrener Entwickler denkt recht schnell an die Trennung der Verantwortlichkeiten. Er fragt sich, wo die Fachlogik zu platzieren ist, wo der Transport zu isolieren ist, wo das Rendering zu setzen ist, wie die Konzepte zu benennen sind, wie zu vermeiden ist, dass alles mit allem gekoppelt ist. Claude kann das, aber er tut es nicht spontan mit Konstanz. Man muss ihn führen.
Gleiches gilt für die Volumetrie.
In meinem Projekt können manche APIs einige Hundert Elemente zurückgeben. Andere können Zehntausende zurückgeben. Das ist nicht dieselbe Welt. 200 Elemente zu laden, um sie 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, kann Claude sehr wohl alles laden, alles an die Webseite übergeben, alles auf der Frontseite filtern und das Problem als gelöst betrachten. Im Test, mit wenig Daten, kann das den Anschein erwecken zu funktionieren. Im echten Einsatz explodiert es. Oder schlimmer: Es bricht nicht wirklich, es wird langsam, blockiert, unverständlich.
Ein Bug ist nicht immer ein roter Fehler in der Konsole. Manchmal ist es einfach ein Produkt, das nicht mehr reagiert, weil man 5.000 Elemente still geladen hat, ohne Log, ohne Paginierung, ohne klare Strategie. Und dort kann ein nicht-technischer PM nicht verstehen, was passiert.
Einen sehr schnellen Junior-Entwickler steuern
Die Beziehung mit Claude Code hat mich sehr an das Steuern eines extrem schnellen Junior-Entwicklers erinnert.
Er kann enorm viel produzieren. Er kann auch absurde Freiheiten nehmen. Man gibt ihm einen Screenshot einer Komponente, er tut nicht genau das, was verlangt wird. Er interpretiert. Er vereinfacht. Er geht in eine Richtung. Manchmal muss man ihm grundlegende Dinge erneut erklären: warum diese Datei nicht alles enthalten darf, warum diese Schicht diese andere Schicht nicht kennen darf, warum man nicht alle Daten lädt, warum man die Tests schreiben muss, warum man die Tests neu starten muss.
Und manchmal versteht er nicht sofort.
Das ist an sich nicht schlimm. Menschliche Entwickler machen auch Fehler. Dinge, die von Entwicklern entwickelt wurden, gehen manchmal in die Produktion und halten der Last nicht stand. Technische Schulden sind nicht mit PMs entstanden, die Vibe Coding machen.
Aber KI fügt eine Geschwindigkeit hinzu, die das Problem verändert. Sie erlaubt es, sehr schnell viel mittelmäßigen Code zu produzieren. Wenn der Rahmen nicht gut ist, kommt die Schuld schnell. Sehr schnell.
Von meiner Seite hilft mir meine technische Vergangenheit. Ich verstehe die großen Linien der Architektur. Ich sehe, wenn eine Datei anfängt zu groß zu werden. Ich sehe, wenn die Schichten sich vermischen. Ich spüre, wenn etwas ein Volumetrie- oder Wartbarkeitsproblem aufwerfen wird.
Aber ich beherrsche nicht alles. Es gibt Teile des Codes, die ich nicht sofort erklären könnte. Wenn ich mir die Zeit nehme, kann ich sie verstehen. Aber ich kann nicht behaupten, dieselbe Beherrschung zu haben wie wenn ich jede Zeile selbst geschrieben hätte.
Bei diesem Produkt akzeptiere ich das. Bei anderen Produkten würde ich das nicht akzeptieren.
Und diese Nuance ist wesentlich.
Das eigentliche Thema: Kompetenz multipliziert mit Risiko
Man könnte die Frage so stellen: Können alle PMs jetzt Software mit KI entwickeln?
Meine spontane Antwort wäre: Nein.
Oder genauer gesagt: Es kommt darauf an.
Aber das „Es kommt darauf an" ist kein Ausweichen. Es ist nicht nur eine Frage der individuellen Kompetenz. Es ist ein Verhältnis zwischen dem Kompetenzniveau und dem Risikoniveau des Produkts.
Das ist genau wie bei einem Junior-Entwickler. Öffnet man einem Junior sofort das komplexeste, kritischste, für das Geschäft einflussreichste Repository? Nicht unbedingt. Gibt man ihm Zugang zu allen Repos, allen Daten, allen Rechten? Auch nicht.
Für einen PM, der Vibe Coding macht, ist es dasselbe.
Es geht nicht darum zu sagen: PMs dürfen es oder dürfen es nicht. Es geht darum zu definieren, was sie tun können, in welchem Bereich, mit welchen Grenzen, gemäß ihrem Niveau und gemäß dem Risiko.
Ich mag die Analogie des Führerscheins. Man fährt kein beliebiges Fahrzeug ohne Führerschein, weil man gefährlich werden kann. Und selbst mit einem Führerschein fährt man nicht alles. Vielleicht kann ein eingerosteter PM ein 125-cm³-Motorrad fahren. Das bedeutet nicht, dass er auf ein großes Motorrad steigen und bei Regen auf der Autobahn fahren soll.
„PM-Code" ist in meinem Mund keine Beleidigung. Es bedeutet nicht, dass der Code eines PMs zwangsläufig schlecht ist. Es bedeutet, dass es Code ist, der von jemandem produziert wird, der den Code nicht sehr gut oder nicht mehr sehr gut beherrscht. Man muss also Einschränkungen akzeptieren. Und vor allem muss man akzeptieren, sie zu definieren.
Grün, Orange, Rot
Ich glaube nicht an ein universelles Raster.
Jedes Unternehmen muss seine Politik definieren. Aber das Prinzip scheint mir ziemlich klar: Je mehr das Produkt sensible Daten berührt, Schreibvorgänge, kritische Workflows, Sicherheit, Abrechnung, Rechte, desto höher müssen die Anforderungen steigen.
Ein kleines internes Tool, persönlich, mit kurzer Lebensdauer und begrenztem Einfluss, kann wahrscheinlich mit wenig Formalismus leben. Wenn es kaputt geht, ist es nicht schlimm. Man wirft es weg, korrigiert es, macht weiter.
Ein internes Tool, das geteilt wird, mit fortgeschrittenen Verhaltensweisen, begrenzten Schreibvorgängen und fachlichen Abhängigkeiten, wird schon zu etwas anderem. Dort muss man sich mehr Fragen stellen.
Und sobald man kritische Produktion berührt, sensible Kundendaten, Berechtigungen, irreversible Schreibvorgänge, Workflows mit starkem Kunden- oder Geschäftseinfluss, wechselt man nochmals die Kategorie.
Sicherheit zum Beispiel scheint mir nicht verhandelbar. Man kann über das erforderliche Testniveau für ein kleines wegwerfbares Tool diskutieren. Man kann über das Review diskutieren. Man kann über das Dokumentationsniveau diskutieren. Aber Sicherheit sollte nicht von der Stimmung des Moments abhängen.
Glücklicherweise haben Entwickler bereits viel Werkzeug dafür: Continuous Integration, Scanner, Regeln, Praktiken, Kompetenzen, manchmal sogar Prompts oder interne Skills. Das Thema ist also nicht, alles für PMs neu zu erfinden. Es ist, die augmentierten PMs an das bereits vorhandene Werkzeug anzuschließen.
Nein, ich glaube nicht an systematische Reviews
Man könnte antworten: Es reicht, dass alles von Entwicklern überprüft wird.
Ich bin bei dieser Antwort ziemlich skeptisch.
Systematische Reviews sind zu einem Reflex geworden, aber sie verdienen es, diskutiert zu werden. Sie kommen insbesondere aus der Open-Source-Welt, aus mehreren Gründen: Qualität, Sicherheit, Übertragung, Governance, Vertrauen zwischen Beitragenden. Aber in einem Unternehmen, für alle Arten von Code, in allen Kontexten, bin ich nicht überzeugt, dass alles systematisch überprüft werden muss.
Wenn sich ein PM ein persönliches, wegwerfbares Tool mit geringem Risiko baut, muss man wirklich einen Entwickler mobilisieren, um es zu überprüfen? Vielleicht nicht. Sonst schafft man genau die Abhängigkeit, die man zu reduzieren versuchte.
Andererseits kann das Review zu Beginn eine Rolle spielen, um PMs bei der Annahme guter Praktiken zu helfen. Es kann auch je nach Einsatz notwendig sein. Noch einmal, es ist kein Ja oder Nein. Es ist eine Frage des Risikos.
Irgendwann muss man auch die Verantwortung akzeptieren. Wenn ich mich entscheide, mir ein Tool zu bauen, muss ich akzeptieren, mein eigenes Essen zu essen. Wenn es buggt, liegt es auch an mir, mich selbst zu behelfen. Und das kann wehtun, weil viele PMs nicht unbedingt wissen, wie sie die Bugs lösen, die sie gerade mit der KI erstellt haben.
Tests als Kontrollhebel
In dieser Erfahrung sind Tests zentral geworden.
Nicht nur weil „Tests gut sind". Sondern weil sie eines der seltenen Mittel sind, die Kontrolle über Code zu behalten, den man nicht vollständig selbst geschrieben hat.
Claude schreibt nicht spontan die richtigen Tests, wenn man ihn nicht darum bittet. Er kann es vergessen. Er kann Tests nachträglich schreiben. Er kann Tests schreiben, die seine Implementierung validieren, statt die Fachintention. Er kann den Eindruck erwecken, das Produkt sei gesichert weil es Tests gibt, während eine echte Teststrategie fehlt.
Ein PM kennt nicht unbedingt TDD. Er kennt nicht unbedingt den Unterschied zwischen einem Unit-Test, einem Integrationstest, einem End-to-End-Test. Er kennt nicht unbedingt die Testpyramide. Er weiß nicht immer, wann ein Verhalten vor dem Kodieren getestet werden soll, noch wie man eine Fachregel als Test ausdrückt.
Und dennoch ist das in einem Vibe-Coding-Projekt vielleicht einer der wichtigsten Punkte.
In meinem Projekt gibt es mehr als 500 Tests. Das ist viel für ein Projekt dieser Größe. Meistens bricht nichts, genau weil Claude die Tests sehr oft neu startet. Wenn etwas bricht, geben die Tests einen Stützpunkt. Sie ermöglichen zu verstehen, wo das erwartete Verhalten nicht mehr respektiert wird.
Ich sage nicht, dass alles mit demselben Anspruchsniveau getestet werden muss. Ein kleines, sehr einfaches internes Tool mit geringem Risiko braucht nicht unbedingt eine vollständige Teststrategie. Auch hier ist es eine Frage des Ausmaßes.
Aber sobald das Produkt ernsthafter wird, sind Tests kein Bonus. Sie werden Teil des Lenkrads.
Leitplanken beschleunigen genauso wie sie schützen
Wenn ich von Leitplanken spreche, rede ich nicht nur von Schutzvorrichtungen, die PMs daran hindern, Fehler zu machen.
Leitplanken dienen auch dazu, schneller voranzukommen.
Wenn man einen PM und Claude Code allein vor dem Quellcode lässt, kann die KI sehr wohl nicht die richtigen internen APIs nehmen. Sie kann den falschen Einstiegspunkt verwenden. Sie kann etwas rekonstruieren, das bereits existiert. Sie kann ein Tool produzieren, das schlecht funktioniert, oder überhaupt nicht funktioniert, oder eine Menge Zeit damit vergeudet, die bestehende Architektur zu umgehen.
Wenn dagegen Entwickler Leitplanken liefern, wissen PM und KI, wohin sie gehen sollen.
Diese Leitplanken können mehrere Formen annehmen: ein Katalog der nutzbaren internen APIs, eine vom Code generierte funktionale Dokumentation, ein Mapping zwischen fachlichen Konzepten und technischen Einstiegspunkten, Beispielanfragen, wiederverwendbare Oberflächenkomponenten, Konventionen, gerahmte Zugänge, Sicherheits-CI, Claude-Dateien, Prompts, Skills.
Man kann sich zum Beispiel eine Umgebung vorstellen, in der ein PM interne Bildschirme, Abfragetools, Listen, Grafiken oder fachliche Szenarien erstellen kann, auf Basis dokumentierter und validierter APIs. Die gesamte Betriebsschicht ist von den Devs aufgebaut. Der PM startet nicht von einer weißen Seite. Er komponiert in einem Rahmen.
Das ist bereits das, was manche Tools seit langem mit Abfragesprachen, Dashboards oder internen Plattformen tun. KI macht diese Logik einfach mächtiger.
Der wichtige Punkt liegt hier: Leitplanken verlangsamen nicht nur. Sie beschleunigen, weil sie die KI daran hindern, den falschen Weg einzuschlagen.
Vom kleinen internen Tool zum Product Builder
Es gibt vielleicht eine weitere Stufe.
Bis jetzt könnte man glauben, ich spreche nur von kleinen internen Tools: ein Konsultationsbildschirm, ein Export, ein Dashboard, ein Abfragetool, eine temporäre Oberfläche, um dem Produkt zu helfen. Dieser Fall existiert, und er ist bereits interessant. Er kann Entwickler entlasten, den Alltag beschleunigen, einem Produktteam ermöglichen, selbst bestimmten Bedürfnissen zu begegnen.
Aber das ist nicht unbedingt der einzige Horizont.
Wenn die Codebasis des Unternehmens gut gerahmt ist, wenn die internen APIs dokumentiert sind, wenn die fachlichen Konzepte lesbar sind, wenn die Bausteine und Konventionen stabil sind, dann kann der PM vielleicht über das einfache interne Tool hinausgehen. Er kann zu einer Art Product Builder werden.
Nicht ein autonomer Entwickler für jedes Thema. Nicht jemand, dem man ohne Einschränkung die kritischen Zonen des Produkts anvertraut. Aber jemand, der in der Lage ist, ein Modul, einen Bildschirm, einen Parcours oder eine funktionale Variante zu erstellen, gestützt auf die bestehende Codebasis.
Der Unterschied ist wichtig.
Im Fall des kleinen internen Tools baut der PM oft neben dem Produkt. Er konsumiert APIs, aggregiert Informationen, produziert eine für ihn oder sein Team nützliche Oberfläche.
Im Fall des Product Builders baut er mehr in der Verlängerung des Produkts. Er nutzt die bestehenden Bausteine, die fachliche Sprache des Codes, die Komponenten des Unternehmens, die von Entwicklern gesetzten Leitplanken. Er startet nicht von einer weißen Seite. Er komponiert mit einem bereits strukturierten Material.
Und genau dort wird die Qualität der Codebasis entscheidend. Eine schlecht gerahmte Codebasis schließt den PM und die KI im Flickwerk ein. Eine lesbare, dokumentierte, fachlich orientierte und mit Werkzeug versehene Codebasis kann dagegen einen breiteren Beitragsraum öffnen.
Vibe Coding verwandelt also einen PM nicht automatisch in einen Product Builder. Es reicht nicht, ihm Claude Code und ein Git-Repository zu geben. Es braucht ein begehbares Terrain.
Wenn dieses Terrain existiert, wird das Thema viel interessanter als „Können PMs ihre kleinen Tools bauen?". Die echte Frage wird: Bis wohin kann eine Organisation Produktprofilen erlauben, bestimmte Teile des Produkts direkt zu bauen, ohne technische Beherrschung, Kohärenz und Sicherheit zu verlieren?
Und die Specs in all dem?
Diese Erfahrung hat mich auch dazu gebracht, eine fast provokative Frage neu zu stellen: Muss man noch Specs schreiben?
Ich sage nicht, dass Specs überall verschwinden werden. Für viele Produkte, Kontexte, Regulierungsthemen, strukturierende Entscheidungen wird man immer schreiben, rahmen, diskutieren und das Warum dokumentieren müssen.
Aber für bestimmte interne Tools frage ich mich, ob die Spec dabei ist, ihren Status zu verändern.
In meinem Fall habe ich keine Spec geschrieben. Ich bin eingetaucht. Ich habe gebaut. Ich habe gezeigt. Man sagte mir: Das fehlt, das wäre nötig, aus diesem und jenem Grund. Ich habe hinzugefügt. Ich habe iteriert.
Warum einen Prototyp machen, wenn ich direkt eine erste nutzbare Version bauen kann? Warum eine beschreibende Spec schreiben, wenn ich das Verhalten im Produkt entstehen lassen und dann die funktionale Dokumentation aus dem Code generieren kann?
Ich hatte kürzlich geschrieben, dass die Produktfrage vom Quellcode ausgehen müsse. Diese Erfahrung geht in dieselbe Richtung, aber von der anderen Seite. Wenn Code zur Wahrheit des Verhaltens wird, kann ein Teil der Dokumentation aus ihm heraus regeneriert werden. Die Spec verschwindet nicht unbedingt, aber sie kann nicht mehr beanspruchen, dauerhaft die Wahrheit des Produkts zu sein.
Für bestimmte Bereiche könnte man fast sagen: Man schreibt die Spec nicht mehr vorher. Man baut, validiert, dann generiert man das Fachliche aus dem, was läuft.
Ich übertreibe ein wenig den Zug, offensichtlich. Aber nicht so viel.
Das organisatorische Risiko
Es gibt auch ein weniger technisches, eher organisatorisches Risiko.
Wenn alle anfangen, ihre kleinen Tools in ihrem Winkel zu bauen, kann das schnell in alle Richtungen gehen. Nicht gewartete interne Tools können wichtig werden. Wegwerfbare Skripte können am Ende jede Woche benutzt werden. Ein für ein Team zusammengeflickter Bildschirm kann zu einem obligatorischen Durchgangspunkt werden. Ein Tool ohne Governance kann kritisch werden, ohne dass irgendjemand es entschieden hat.
Aber dieses Risiko ist nicht typisch für Vibe Coding. Unternehmen kennen das bereits mit Excel-Dateien, Makros, Skripten, No-Code-Tools, in einem Winkel gebauten Dashboards. Vibe Coding schafft das Problem nicht. Es beschleunigt es, weil es die Produktion von Tools leichter macht.
Auch hier ist die Antwort nicht, es zu verbieten. Es ist, die Zonen, die Rechte, die Verantwortlichkeiten, die Grenzen und die Leitplanken zu definieren.
Was das für Entwickler verändert
Ich glaube nicht, dass PMs Entwickler ersetzen werden.
Ich glaube jedoch, dass bestimmte kleine interne Tools, die man von Entwicklern verlangte, direkt von Produkt-, Support-, Ops- oder Fachteams produziert werden könnten, vorausgesetzt, sie sind gut gerahmt. Und das kann Entwickler entlasten.
Wie oft bittet man ein Entwicklerteam, den Kern des Produkts zu verlassen, um ein kleines internes Tool zu bauen, einen Export, einen Konsultationsbildschirm, ein Dashboard, eine temporäre Oberfläche? Wenn ein Teil dieser Anfragen anderswo aufgenommen werden kann, ist das nicht unbedingt eine schlechte Nachricht.
Aber das lässt die Rolle der Devs nicht verschwinden. Im Gegenteil, das kann sie verschieben. Sie werden auch zu denjenigen, die die Leitplanken, die Plattformen, die sauberen APIs, die Konventionen, die sicheren Umgebungen bauen, in denen andere produzieren können, ohne alles kaputt zu machen.
Das ist nicht weniger technisch. Es ist vielleicht sogar architektonischer.
Die Erschöpfung
Ich will diese Erfahrung nicht als ausschließlich euphorischen Moment verkaufen.
Es ist erschöpfend.
Mehr als 180 Commits in vier Tagen zu machen, auch mit einer KI, ist nicht neutral. Man tippt nicht den ganzen Code, aber man steuert, liest, testet, korrigiert, entscheidet, nimmt wieder auf, überwacht, erklärt neu. Man macht sehr schnell Fortschritte, aber man muss der Geschwindigkeit folgen.
Vibe Coding gibt ein Machtgefühl, aber es ist keine kostenlose Macht. Der PM wird zu einer Art Pilot, Proximitätsarchitekt, Tester, Reviewer, Absichtsgeber, Leitplanke. Und wenn er nicht genug technische Kultur hat, kann er sich dabei wiederfinden, etwas zu steuern, das er nicht wirklich versteht.
Dort ist die Kompetenzillusion gefährlich.
Das haben wir schon mit No-Code erlebt. Personen dachten, keine Entwickler mehr zu brauchen, 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 konnte. Es war nicht, dass das Tool schlecht war. Es gab Zugang zu einer Macht, ohne automatisch die damit verbundene Sicherheits- und Architekturkultur zu übertragen.
Vibe Coding stellt dieselbe Art von Frage.
Ich dokumentiere eine Überquerung
Ich habe keine endgültige Schlussfolgerung.
Und das ist vielleicht die einzige seriöse Schlussfolgerung, die nach vier Tagen möglich ist.
Ich bin noch beim Vibe Coding. Ich lerne weiter. Ich sehe weiter, was funktioniert, was kaputt geht, was mir entgeht, was Tests auffangen, was Leitplanken beschleunigen, was mein altes technisches Gepäck mir noch zu spüren ermöglicht.
Ich will mir keine Meinung von der Tribüne aus machen. Ich will sie durch die Praxis aufbauen.
Im Moment sehe ich eine neue, sehr mächtige Fähigkeit, die aber die alten Fragen der Software nicht beseitigt. Sie macht sie manchmal sichtbarer. Sie beschleunigt sie. Sie verschiebt sie.
Vibe Coding erlaubt es, sehr schnell voranzukommen. Aber schnell vorzugehen ist nicht dasselbe, wie zu wissen, wohin man geht, noch zu wissen, was man riskiert zu brechen.
Also mache ich weiter.
Ich dokumentiere eine Überquerung.
Weiterführendes
Die Produktfrage muss vom Quellcode ausgehen In 8 Tagen habe ich verstanden, dass sich der Beruf des Product Managers von Grund auf verändern wird KI sollte nicht nur dazu dienen, zehnmal mehr zu produzieren. Sie sollte uns auch zwingen, zehnmal besser zu verstehen, was wir produzieren. Code centric