Im vergangenen Monat haben wir drei Experimente in der Zeit umgesetzt, die wir früher für eines gebraucht haben. Wir haben weder länger gearbeitet noch mehr Leute eingestellt. Wir haben nur geändert, wie wir neue Projekte beginnen.
Der Ansatz heißt VibeCoding und ist zu einem festen Teil unserer Arbeit bei ABXK.AI geworden. Das ist kein KI-Hype. VibeCoding bedeutet nicht, dass eine KI den Code schreibt, während man sich zurücklehnt. Es geht darum, KI-Werkzeuge klug einzusetzen, um die Zeit zwischen Idee und Ergebnis zu verkürzen.
VibeCoding im Vergleich zur klassischen Entwicklung: schnellere Prototypen mit KI-Unterstützung.
Was VibeCoding wirklich bedeutet
Der Begriff „VibeCoding“ fällt oft, und häufig so, dass erfahrene Entwickler skeptisch werden. Deshalb hier, was er für uns bedeutet.
VibeCoding ist KI-gestützte Entwicklung: Sie beschreiben, was entstehen soll, und die KI hilft bei der ersten Version. Danach prüfen, verbessern und wiederholen Sie, bis der Code funktioniert. Der „Vibe“ steckt im Gesprächscharakter — Sie arbeiten mit einem KI-Assistenten, statt jede Zeile selbst zu schreiben.
Bei ABXK.AI nutzen wir VibeCoding für:
- Schnelle Prototypen — rasch eine lauffähige Version, um die Kernidee zu testen
- Grundgerüst-Code — wiederkehrenden Code überspringen, der kein kreatives Denken braucht
- Unbekannte APIs erkunden — neue Bibliotheken schneller verstehen, weil man funktionierende Beispiele sieht
- Skripte zur Datenumwandlung — einmalige Skripte für Aufgaben in der Datenverarbeitung
Wofür wir es nicht nutzen:
- Produktivsysteme, die hohe Zuverlässigkeit brauchen
- Sicherheitskritische Code-Pfade
- Komplexe Logik, bei der es auf Präzision ankommt
- Code, der lange ohne größere Überarbeitung gepflegt werden soll
Dieser Unterschied ist wichtig. VibeCoding ist ein Werkzeug für bestimmte Situationen, kein Ersatz für Engineering-Können. Systeme, Algorithmen und Architektur zu verstehen, bleibt wichtig — VibeCoding verschiebt nur, wofür Sie Ihre Zeit einsetzen.
Warum das beim Experimentieren zählt
Ein Großteil unserer Arbeit bei ABXK.AI besteht darin, Ideen zu testen. Hilft dieses Handelssignal, Kurse vorherzusagen? Lässt sich die Modellleistung mit anderen Merkmalen verbessern? Verkraftet diese Datenpipeline größere Datenmengen?
Der klassische Weg sieht so aus:
- Tagelang eine saubere Umsetzung bauen
- Das Experiment durchführen
- Feststellen, dass die Hypothese falsch war
- Von vorn
Das Problem ist nicht die Qualität des Engineerings, sondern die Rückkopplungsschleife. Wer eine Woche baut und dann erfährt, dass es nicht funktioniert, hat eine Woche verloren. Über Dutzende Experimente summiert sich das zu Monaten.
VibeCoding verkürzt den ersten Schritt. Statt Tagen sind es Stunden. Der Code ist vielleicht nicht produktionsreif, reicht aber, um die Hypothese zu prüfen. Ist das Experiment vielversprechend, investieren Sie in eine saubere Umsetzung. Wenn nicht, machen Sie ohne großen Zeitverlust weiter.
Ein echtes Beispiel: eine neue Feature-Pipeline testen
Vergangene Woche wollten wir prüfen, ob Stimmungsdaten aus Finanznachrichten die Vorhersagen unseres Handelsmodells verbessern.
Geschätzter Aufwand klassisch: 3 bis 4 Tage, um eine saubere Pipeline zu bauen, sie an das bestehende System anzubinden, Tests zu schreiben und das Experiment durchzuführen.
Was wir tatsächlich gemacht haben: Mit VibeCoding in etwa zwei Stunden eine grobe Pipeline erstellt. Der Code war nicht elegant — feste Pfade, kaum Fehlerbehandlung, keine Tests —, aber er funktionierte gut genug, um Stimmungsmerkmale ins Modell zu speisen und zu prüfen, ob das Signal etwas taugt.
Ergebnis: Die Stimmungsdaten brachten in unserem Fall keine messbare Verbesserung. Gesparte Zeit: etwa zweieinhalb Tage.
Hätte das Experiment gute Ergebnisse gezeigt, hätten wir Zeit in eine saubere Version gesteckt. Hat es aber nicht, also ging es mit der nächsten Idee weiter.
Beide Ansätze im Vergleich
Ehrlich betrachtet ist keiner der beiden Ansätze immer besser — es kommt auf die Situation an.
Klassische Entwicklung
Stärken:
- Liefert gut wartbaren und gut getesteten Code
- Besser für komplexe Systeme mit vielen Teilen
- Leichtere Fehlersuche, wenn etwas schiefgeht
- Das Wissen steckt im eigenen Kopf, nicht in KI-Prompts
- Funktioniert gut bei Problemen, die man genau versteht
Schwächen:
- Langsamere Rückkopplung
- Höherer Zeitaufwand zu Beginn
- Verleitet dazu, zu viel zu bauen, wenn der Bedarf unklar ist
- Teurer Weg, um herauszufinden, dass eine Idee nicht trägt
VibeCoding
Stärken:
- Schneller Fortschritt bei frühen Ideen
- Geringere Kosten für Experimente, die scheitern könnten
- Hilfreich beim Erlernen neuer Werkzeuge oder APIs
- Gut für Wegwerf-Code und Prototypen
- Weniger Kontextwechsel beim Erkunden
Schwächen:
- Generierter Code muss oft stark aufgeräumt werden
- Ohne sorgfältige Prüfung schleichen sich kleine Fehler ein
- Kein tiefes Verständnis des Codes
- Ungeeignet für sicherheitskritische oder produktive Systeme
- Es braucht Selbstdisziplin, um keinen chaotischen Code anzuhäufen
Die wichtigste Erkenntnis: Beide Ansätze haben ihren Platz. Wir nutzen VibeCoding zum Erkunden und Testen und wechseln zur klassischen Entwicklung, sobald wir für die Produktion bauen.
Wann welcher Ansatz passt
Diese einfache Faustregel nutzen wir:
VibeCoding, wenn:
- Sie eine Idee testen, die sich als falsch herausstellen kann
- der Code vorübergehend oder experimentell ist
- Geschwindigkeit wichtiger ist als langfristige Qualität
- Sie ein unbekanntes Gebiet erkunden
- das Risiko eines Fehlschlags gering ist
Klassische Entwicklung, wenn:
- Sie Produktivsysteme bauen
- der Code über Monate oder Jahre gepflegt wird
- Sicherheit, Zuverlässigkeit oder Leistung entscheidend sind
- Sie genau verstehen müssen, wie etwas funktioniert
- andere sich auf Ihren Code verlassen
Eine Mischung aus beidem, wenn:
- Sie mit VibeCoding die Idee testen
- und danach sauber neu schreiben, sobald klar ist, dass sie funktioniert
- Das ist bei Forschungsprojekten oft unser Standard
Grenzen und verantwortungsvoller Einsatz
VibeCoding hat echte Grenzen, die man kennen sollte.
Qualitätsgrenze: KI-generierter Code folgt meist gängigen Mustern. Für neue Probleme oder schnellere Lösungen müssen Sie den Code oft selbst schreiben.
Prüfaufwand: Sie müssen jede Zeile lesen und verstehen. Sonst holen Sie sich unbekanntes Verhalten ins System. Das kostet Zeit und Aufmerksamkeit.
Weniger Lerneffekt: Schreibt die KI den Code, lernen Sie weniger über das Problem. Bei einmaligen Experimenten ist das in Ordnung, bei Fähigkeiten, die Sie aufbauen wollen, ein echter Preis.
Schwierigere Fehlersuche: Scheitert KI-generierter Code, ist die Fehlersuche schwerer, weil Sie ihn nicht selbst geschrieben haben. Sie müssen erst verstehen, was der Code überhaupt tun soll.
Gefahr der Selbstüberschätzung: Funktionierender Code ist nicht dasselbe wie korrekter Code. Ohne gutes Testen erzeugt VibeCoding ein Gefühl von Fortschritt, das nicht echt ist.
Wir betrachten das als bekannte Grenzen, nicht als Grund, auf den Ansatz zu verzichten. Jedes Werkzeug hat Grenzen. Entscheidend ist, es richtig einzusetzen. Nach mehreren Monaten mit VibeCoding helfen uns dabei vier Gewohnheiten:
Prüfzeit einplanen. Wir setzen Experimente tatsächlich schneller um. Wir verbringen aber auch mehr Zeit mit der Prüfung von generiertem Code als erwartet. Unterm Strich lohnt es sich, Magie ist es nicht.
Wissen, wann Schluss ist. Wer beim fünften Prompt-Versuch ist, damit die KI etwas Komplexes hinbekommt, hat vermutlich den Punkt überschritten, an dem selbst schreiben schneller gewesen wäre.
Erst testen, dann vertrauen. Weil Sie den Code nicht selbst geschrieben haben, sind Tests Ihr Sicherheitsnetz. Wir führen Experimente mehrfach durch und prüfen die Ergebnisse, bevor wir ihnen trauen.
Prototypen bleiben Prototypen. Es ist verlockend, per VibeCoding entstandene Prototypen direkt in Produktion zu bringen. Tun Sie es nicht. Die Probleme mit unordentlichem Code wachsen schnell.
Sie möchten wissen, wie wir diese Ideen anwenden? Lesen Sie, wie wir KI-Entwicklungskosten senken — projektübergreifend.