Kitze: Warum 'Vibe Engineering' funktioniert und 'Vibe Coding' nicht

Warum Kitze Vibe Engineering von Vibe Coding unterscheidet

Kitze ist der Schöpfer von Sizzy (einem Browser für Entwickler), Zero to Ship und mehreren anderen Tools. Dieser Konferenzvortrag unterscheidet “Vibe Coding” (akzeptieren, was immer KI ausgibt) von “Vibe Engineering” (Agenten mit technischem Wissen steuern). Seine These: Die Skeptiker in der Mitte der Fähigkeitsverteilung liegen falsch, während Juniors, die es lieben, und Seniors, die es meistern, beide richtig liegen - aus unterschiedlichen Gründen.

Über das Spektrum der Adoption: “On one hand you have juniors who are like ‘hell yeah, give me the thing, I love doing my own SaaS.’ Then you have super senior people doing libraries and frameworks. And then you have the majority in the middle like ‘this will never be good enough, my code is perfect.’ It’s hilarious, but it’s a pattern.” (Auf der einen Seite hast du Juniors, die so sind wie ‘ja Mann, gib mir das Ding, ich liebe es, mein eigenes SaaS zu machen.’ Dann hast du super erfahrene Leute, die Bibliotheken und Frameworks machen. Und dann hast du die Mehrheit in der Mitte wie ‘das wird nie gut genug sein, mein Code ist perfekt.’ Es ist urkomisch, aber es ist ein Muster.) Die Verteilung ist bimodal: begeisterte Anfänger und erfahrene Praktiker, mit skeptischen Mid-Levels dazwischen.

Darüber, was Vibe Engineering tatsächlich ist: “I’m not vibe coding. I love this term someone coined—vibe engineering. When you’re actually using agents to code all the time but you just look at your screen like ‘I’m going to catch you.’ You’re suspicious of the code because it’s based on our knowledge.” (Ich mache kein Vibe Coding. Ich liebe diesen Begriff, den jemand geprägt hat - Vibe Engineering. Wenn du tatsächlich die ganze Zeit Agenten zum Coden verwendest, aber einfach auf deinen Bildschirm schaust wie ‘Ich werde dich erwischen.’ Du bist misstrauisch gegenüber dem Code, weil er auf unserem Wissen basiert.) Die Unterscheidung: Vibe Coder akzeptieren blind, Vibe Engineers überwachen aktiv.

Darüber, dass Composer One alles verändert hat: “Composer One made me realize I missed coding. What I would do is let a model run like GPT-5 Codex and it would take 37 years. Now I’m back in the driver’s seat. I can be like ‘Stop. No no no. We do the other thing.’ It feels like coding.” (Composer One hat mir klar gemacht, dass ich das Coden vermisst habe. Was ich getan hätte, wäre ein Modell wie GPT-5 Codex laufen zu lassen und es würde 37 Jahre dauern. Jetzt bin ich wieder am Steuer. Ich kann sagen ‘Stopp. Nein nein nein. Wir machen das andere.’ Es fühlt sich an wie Coden.) Die Geschwindigkeit der Feedback-Loops zählt mehr als die Modellkapazität.

Über PA-Devs (pain-in-the-ass-Entwickler): “You leave a nitpick comment on a two-line PR. You spend more than 2 minutes on a PR review. The thought of agreeing with a colleague causes stomach pain. You say ‘well actually’ in code comments.” (Du hinterlässt einen Kleinigkeits-Kommentar auf einem Zwei-Zeilen-PR. Du verbringst mehr als 2 Minuten mit einem PR-Review. Der Gedanke, einem Kollegen zuzustimmen, verursacht Magenschmerzen. Du sagst ‘eigentlich’ in Code-Kommentaren.) Die größte Barriere für KI-Adoption ist nicht Kapazität - es ist Perfektionismus, der ohnehin schon kontraproduktiv war.

Über echte Produktivitätsgewinne: “I achieved in two weeks more than I achieved in last year. This was solely due to Composer One. I was about to abandon projects… I moved Benji to Next 16 with App Router, TRPC, Monorepo, Turbo Repo, React Native app, and put in 90% of the features—in less than a week.” (Ich habe in zwei Wochen mehr erreicht als im letzten Jahr. Das war ausschließlich wegen Composer One. Ich war kurz davor, Projekte aufzugeben… Ich habe Benji auf Next 16 mit App Router, TRPC, Monorepo, Turbo Repo, React Native App migriert und 90% der Features eingebaut - in weniger als einer Woche.) Die Geschwindigkeit ermöglicht Projekte, die sonst nicht existieren würden.

6 Erkenntnisse von Kitze zu KI-unterstützter Entwicklung

• Vibe Engineering ≠ Vibe Coding - Vibe Coding ist blindes Akzeptieren von Output; Vibe Engineering ist das Überwachen von Agenten mit technischem Wissen und das Erkennen von Fehlern in Echtzeit
• Gib KI an Seniors, nicht an Juniors - “Gib KI-Tools nicht deinen Praktikanten und Juniors. Wenn du deinen skeptischen Senior überzeugst, Vibe Engineering zu machen, bekommst du 10x-Ergebnisse”
• Composer One ist ein Paradigmenwechsel - Schnelle Feedback-Loops lassen dich am Steuer bleiben; langsame Modelle haben Leute zu YouTube Shorts getrieben, während sie gewartet haben
• PA-Devs sind der echte Blocker - Perfektionismus, der optimale Abstraktionen verlangt und Zwei-Zeilen-PRs kritisiert, ist mit oder ohne KI kontraproduktiv
• LLMs kümmert repetitiver Code nicht - Das ist ein Feature: Menschen abstrahieren zu früh, LLMs duplizieren gerne, wenn es angemessen ist
• Fähigkeitsanforderungen haben sich geändert, nicht verschwunden - Modellgrenzen kennen, Kontextmanagement, Prompt Engineering und beurteilen, wann Code “gut genug” ist, sind neue erforderliche Fähigkeiten

Was das für Entwicklerproduktivität bedeutet

Kitzes Vortrag reframt die KI-Coding-Debatte: Das Problem ist nicht KI-Kapazität, es ist menschlicher Perfektionismus. “Vibe Coding” scheitert, weil es unüberwachtes Glücksspiel ist. “Vibe Engineering” funktioniert, weil es KI-Geschwindigkeit mit menschlichem Urteil kombiniert, was gut genug ist. Die Ironie: Entwickler, die ohnehin schon pragmatisch bezüglich Code-Qualität waren (vs. über-abstrahierende Perfektionisten), sind diejenigen, die gedeihen. Die Fähigkeit ist nicht Englisch schreiben - es ist wissen, wann Code gut genug ist, was schon immer der schwierigste Teil des Engineerings war.