Vorinstallierte Anwendungen moderner Betriebssysteme gelten vielen Nutzerinnen und Nutzern als überladen. Ein aktuell diskutierter Fall macht das greifbar: Ein Entwickler war mit dem Ressourcenverbrauch der Wetter-App unter Windows 11 unzufrieden und hat sich kurzerhand eine eigene Variante gebaut — mit Unterstützung des KI-Assistenten Claude. Statt rund 700 Megabyte belegt seine Lösung nach eigenen Angaben etwa 70 Megabyte.

Der Fall ist klein, die dahinterliegende Frage nicht. Wenn ein einzelner Entwickler an einem Abend eine schlanke, exakt passende Anwendung erzeugt, verschiebt sich die betriebswirtschaftliche Rechnung zwischen Kaufen und Selberbauen.

Was mit Vibe Coding gemeint ist

Der Begriff Vibe Coding beschreibt eine Arbeitsweise, bei der Software überwiegend im Dialog mit einem Sprachmodell entsteht: Man beschreibt in natürlicher Sprache, was die Anwendung tun soll, lässt Code generieren, testet, beschreibt die Abweichung und iteriert. Die Entwicklerin oder der Entwickler steuert also stärker über Absicht und Prüfung als über jede einzelne Zeile.

Das senkt die Einstiegshürde für kleine Werkzeuge erheblich. Anwendungen, deren Eigenentwicklung sich früher nie gerechnet hätte — ein Statusfenster, ein Importskript, ein interner Konverter —, liegen plötzlich im Bereich weniger Stunden.

Warum Standardsoftware oft schwer ist

Große, universell einsetzbare Anwendungen tragen Funktionen mit, die ein einzelner Betrieb nie benötigt: Mehrsprachigkeit, Telemetrie, Werbeflächen, Synchronisationsdienste, Konfigurationsoberflächen für Dutzende Sonderfälle. Jede dieser Funktionen kostet Speicher, Startzeit und Angriffsfläche.

Eine Eigenlösung, die genau eine Aufgabe erfüllt, kann deutlich kleiner ausfallen — nicht weil sie besser programmiert wäre, sondern weil sie weniger kann. Genau darin liegt ihr Vorteil und zugleich ihr Risiko.

Die Rechnung geht nicht immer auf

Der Bau ist heute der günstigste Teil eines Softwarelebenszyklus. Teuer bleibt alles danach:

  • Wartung: Betriebssystem-Updates, geänderte Schnittstellen und ausgelaufene Bibliotheken treffen auch kleine Werkzeuge.
  • Sicherheit: Wer selbst baut, verantwortet selbst, dass Abhängigkeiten aktuell und Eingaben geprüft sind.
  • Personenabhängigkeit: Ein Tool, das nur eine Person versteht, wird beim nächsten Rollenwechsel zum Problem.
  • Dokumentation: Ohne nachvollziehbare Entscheidungen ist auch generierter Code nach sechs Monaten fremder Code.

Der Versuch, ein CRM- oder ERP-System auf diesem Weg zu ersetzen, ist entsprechend keine sinnvolle Schlussfolgerung aus einem Wetterfenster. Je stärker ein System regulatorische Anforderungen, viele Nutzerrollen oder langlebige Daten trägt, desto eher spricht die Bilanz weiter für erprobte Standardsoftware.

Wo Eigenbau realistisch lohnt

Sinnvoll wird der KI-gestützte Eigenbau typischerweise dort, wo eine Aufgabe klar umrissen ist und kein Markt dafür existiert, der den Aufwand trägt:

  • interne Hilfswerkzeuge, die Daten zwischen zwei Systemen umformen
  • Auswertungen, die heute mühsam per Hand in Tabellen entstehen
  • kleine Oberflächen für Fachabteilungen, die eine bestehende Schnittstelle bedienbar machen
  • Prototypen, die eine Anforderung sichtbar machen, bevor ein größeres Projekt beauftragt wird

Gerade der letzte Punkt wird unterschätzt. Ein lauffähiger Prototyp klärt Anforderungen schneller als drei Abstimmungsrunden über ein Konzeptdokument — und kann anschließend bewusst weggeworfen werden.

Leitplanken für den Betrieb

Damit aus produktiven Einzelinitiativen keine unkontrollierte Werkzeuglandschaft entsteht, hilft ein einfacher Rahmen. Drei Fragen genügen als Einstieg:

  1. Datenklasse: Verarbeitet das Werkzeug personenbezogene oder geschäftskritische Daten? Dann gelten dieselben Regeln wie für gekaufte Software.
  2. Nutzerkreis: Bleibt es beim Einzelarbeitsplatz oder wird es zum Teil eines Prozesses, auf den sich andere verlassen?
  3. Ausstiegspfad: Was passiert, wenn die Person, die es gebaut hat, nicht mehr verfügbar ist?

Wer diese Fragen dokumentiert beantwortet, kann kleine Lösungen bewusst leichtgewichtig halten — und erkennt früh, wann ein Werkzeug den Sprung in die reguläre Entwicklung mit Versionsverwaltung, Code-Review und Deployment-Prozess machen muss.

Qualität bleibt eine menschliche Aufgabe

Generierter Code ist nicht automatisch schlechter Code, aber er ist ungeprüfter Code. Die Verantwortung für Architektur, Sicherheit und Lesbarkeit verschiebt sich vom Schreiben zum Bewerten. Das erfordert weiterhin Fachwissen — nur an anderer Stelle im Prozess.

Der beschriebene Fall taugt deshalb weniger als Beweis dafür, dass Standardsoftware überflüssig wird, sondern als Hinweis darauf, dass die Schwelle für passgenaue Eigenlösungen deutlich gesunken ist.

Einordnung für Web- und Softwareprojekte

Für Projekte bedeutet das vor allem eine ehrlichere Make-or-Buy-Entscheidung: Nicht mehr der Entwicklungsaufwand ist das entscheidende Argument, sondern die Frage, wer das Ergebnis über Jahre pflegt. Kleine, klar abgegrenzte Werkzeuge lassen sich heute wirtschaftlich selbst bauen und sollten bewusst als solche behandelt werden — mit definiertem Zweck, dokumentierten Abhängigkeiten und einem geplanten Ende. Für tragende Systeme bleibt dagegen der etablierte Weg richtig, wobei KI-Unterstützung dort vor allem bei Prototypen, Migrationsskripten und Routineaufgaben Zeit freispielt.

Quellen