Beim Vibe Coding delegieren Entwickler die technische Umsetzung – Syntax, Boilerplate, Logikstrukturen – fast vollständig an ein Large Language Model. Menschen agieren nicht mehr als Autoren einzelner Codezeilen, sondern geben nur noch das gewünschte Verhalten und die Architektur der Anwendung vor. Doch wie sieht es in der Praxis mit den Kosten für ein solches Projekt aus? Stefan Müller, Titelautor der neuen iX 6/2026, erklärt, worauf man achten muss.

Wie kann man grob gesagt Tokenbudget und Kosten für ein Projekt mit Vibe Coding überschlagen?

Ein Token-Budget-Modell, kurz TBM, stützt sich auf viele verschiedene Faktoren. Daher ist ein pauschaler Überschlag naturgemäß etwas schwierig, zumal Softwareprojekte sehr unterschiedlich ausfallen können. Mit einem Topmodell wie Opus 4.6 oder 4.7 liegen wir bei professionellen Projekten eigentlich immer in einem Größenrahmen von 3.000 bis 15.000 Euro – oft auch deutlich darunter, je ausgebuffter die Softwareentwickler sind, die das Modell mit konkreten Vorgaben steuern. Ein Projekt, das über diese Schwelle hinausgegangen wäre, habe ich bisher nicht erlebt. Das TBM habe ich auch als Internetrechner veröffentlicht.

Was sind die größten Kostentreiber beim Vibe Coding?

Das ist einerseits die menschliche Vorarbeit bei der Spezifikation des Projektes. Je durchdachter ein Pflichtenheft ist, desto besser können sich KI-Agenten daran entlanghangeln. Wenn Anforderungen und ihre Umsetzung vage bleiben, kann es schnell teuer werden.

Andererseits entscheidet die Modellqualität: Wenn wir auf den Open-Source-Bereich festgelegt sind, explodieren die Token-Budgets schnell. Das hat nicht zwangsläufig hohe Kosten zur Folge, weil der Tokenpreis pro Million mit der geringeren Modellqualität ja ebenfalls sinkt (wobei Modelle wie DeepSeek V4 selbst diese Logik gerade durchbrechen). Dafür gehen die Personalkosten hoch – wegen des permanenten Nachbesserns und „Reparierens“ des entstandenen Codes. Das ist auch ein versteckter Kostentreiber: Wenn die Softwareentwickler dabei frustriert werden, finden weitere Einsätze dieses Ansatzes zukünftig weniger Akzeptanz.

Im Fall von Open-Source-Modellen würde ich den KI-Einsatz stark limitieren und nur punktuell im Entwicklungsprozess unterstützen lassen – zum Beispiel für einfache Tests oder das Schreiben von Boilerplate anhand konkreter Beispiele und Referenzen.

Wann ist der maschinell generierte Code wirtschaftlich besonders sinnvoll?

Ich finde maschinell generierten Code besonders sinnvoll, wenn schnell Ergebnisse benötigt werden – wenn die Frage nach dem „Wie“ gar nicht so relevant ist, sondern das Resultat im Vordergrund steht. Vibe Coding wird Unternehmen darüber hinaus auch in Zukunft in die Lage versetzen, eigene Softwarekomponenten zu erstellen, ohne auf große Lösungen mit unzähligen Funktionen zurückgreifen zu müssen. Der Vendor-Lock-in bricht langsam, aber sicher auf. Parallel dazu können Software-Manufakturen mit Vibe Coding Kundenbedürfnisse abseits ihres Tagesgeschäfts erfüllen und so neue Zielgruppen erschließen.

Stefan, vielen Dank für die Antworten! Einen Überblick, wie man Tokenbudget und Kosten für Vibe Coding schätzt, gibt es in der neuen iX. Außerdem zeigen wir, was die KI-gestützte Entwicklung in IT-Beratungen und Softwarehäusern kostet – und befassen uns damit, was KI-Gateways als Tools für Kostenkontrolle leisten können. All das und viele weitere Themen finden Leser im Juni-Heft, das ab sofort im heise Shop oder am Kiosk erhältlich ist.

In der Serie „Drei Fragen und Antworten“ will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.

(axk)