TrenchOps DE 🇩🇪🐎 
Ihre Vibe-Coder bauen keine Tools - Sie schreiben Mängelberichte gegen Ihr Unternehmen
Vor einiger Zeit traf ich mich mit einem alten Kollegen auf einen Drink. Wir machen das regelmäßig - zwei Leute, die schon genügend Serverräume und Lenkungsausschüsse von innen gesehen haben, um zu wissen, dass die besten Analysen nach einem Vorfall bei einem Negroni entstehen.
Er war bester Laune. Die Nutzung von "Vibe Coding" (die Art, Software schnell via AI, z.B. Claude zu programmieren, ohne den Code selbst zu schreiben (oder sogar zu verstehen)) in seinem Unternehmen war durch die Decke gegangen. Nicht nur bei den Software-Entwicklern, sondern auch bei Beratern, Architekten, und Technikern im Support - kurz: Jeder mit einem Puls und einer Claude-Lizenz baute plötzlich eigene Tools. Das Management feierte das. Man warf mit Zahlen wie mit Trophäen um sich: Ein Techniker verbrauchte Token im Wert von 100 Dollar pro Tag. Applaus. High-fives. Präsentationen.
Und mal ehrlich? Das ist auch in Ordnung. Wenn eine Token-Rechnung von 100 Dollar am Tag ein Tool hervorbringt, das zehn Stunden Entwicklungsarbeit pro Woche einspart, ist das der günstigste Mitarbeiter, den Sie je eingestellt haben. Ich bin nicht hier, um Token-Budgets schlechtzureden. Übrigens: "Vibe Coding" hat es innerhalb von etwa zwölf Monaten von einem beiläufigen Tweet von Andrej Karpathy bis zum Wort des Jahres im Collins Dictionary geschafft. Das ist eine schnellere Einführung, als die meisten Unternehmen für eine neue Spesen-Abrechnungssoftware benötigen.
Doch während mein Kollege feierte, tat ich das, was über 20 Jahre im Support einen gelehrt haben: Ich achtete auf den Alarmton, der unter dem Applaus zu hören war.
Denn niemand in dieser Feierrunde stellte die entscheidende Frage: "Warum müssen Ihre Techniker überhaupt eigene interne Tools bauen?"
Lassen Sie uns diesen Umstand im Detail betrachten. Er hat drei Ebenen, und jede ist problematischer als die vorherige.
Die erste Ebene ist das Offensichtliche, das jeder bereits kennt und höflich ignoriert: Sicherheit, Code-Qualität, fehlende Prüfungen, keine Tests. Mitarbeiter außerhalb der Entwicklung wissen oft nicht, was sie nicht wissen. Das ist ärgerlich, aber verkraftbar. Darum geht es mir heute nicht.
Die zweite Ebene ist die Schatten-IT im neuen Gewand. Jedes dieser per Vibe Coding erstellten Programme ist ein kleines, undokumentiertes und ungepflegtes System. Einige davon werden im Stillen tragende Lasten übernehmen. Sie laufen auf einer vergessenen virtuellen Maschine, greifen auf echte Daten zu und existieren noch lange, nachdem ihr Schöpfer das Unternehmen verlassen hat. Eines Tages geht das Tool kaputt, der Prozess dahinter bricht zusammen, und niemand weiß, dass dieses System jemals existierte, bis der Vorfall analysiert wird. Ich habe persönlich erlebt, wie ein "provisorisches" Skript drei Firmenumstrukturierungen und zwei Manager überlebt hat, die nie wussten, dass es überhaupt läuft. Schatten-IT kündigt sich nicht an. Sie sammelt sich an wie Plaque.
Aber die dritte Ebene ist es, die Führungskräfte um den Schlaf bringen sollte. Es ist der Punkt, den das Management meines Kollegen komplett verpasst hat, während der Champagner floss:
Jedes intern per Vibe Coding erstellte Tool ist ein nicht eingereichter Mängelbericht gegen Ihr Unternehmen.
Denken Sie kurz darüber nach, was wirklich geschehen ist. Ein Mitarbeiter benötigte ein Werkzeug, um seine Arbeit effizient zu erledigen. Ihr Unternehmen hat es ihm nicht zur Verfügung gestellt. Also hat er die Arbeit, für die Sie ihn bezahlen, unterbrochen, sich gerade genug Wissen angeeignet, um gefährlich zu sein, und es selbst gebaut. In einem Startup mit fünf Leuten ist das ein Dienstagnachmittag und es ist großartig. In einem Unternehmen, das Aktien an Anteilseigner verkauft und eine IT-Abteilung, ein Innovationsbudget sowie einen Roadmap-Plan hat, ist das ein Offenbarungseid. Es bedeutet, dass Ihre interne Tool-Entwicklung so leise versagt hat, dass niemand es eskalierte, aber laut genug, dass Ihre Leute das Heft selbst in die Hand nahmen.
Und hier kommt der Teil, der in Firmen meist gefiltert wird, bevor er die Geschäftsführung erreicht: Raten Sie mal, wer diese Behelfslösungen baut? Nicht Ihre Faultiere. Sondern Ihre Zugpferd-Mitarbeiter 🐎. Genau die Leute, denen es nicht egal ist, dass Arbeitsabläufe kaputt sind, verbrauchen ihre Energie damit, Ihre Lücken in der Werkzeuglandschaft zu flicken. Sie sind auch die Ersten, die demotiviert sind, wenn sie merken, dass sie das Schiff flicken, anstatt es zu segeln. Nichts brennt einen Leistungsträger schneller aus, als strukturell daran gehindert zu werden, über offizielle Kanäle gute Arbeit zu leisten.
Am Ende dieses Weges steht ohnehin eine Wand. Vibe-Coding reicht nur so weit, wie der Zugriff des jeweiligen Mitarbeiters es zulässt. Die wirklich teuren Ineffizienzen - das CRM, das drei Integrationen benötigt, die Bereitstellungs-Pipeline, die Systeme hinter komplexen Zugriffsrechten - lassen sich nicht vom Laptop eines Technikers aus zusammenflicken. Also optimieren Ihre motiviertesten Mitarbeiter alles, was in Reichweite liegt, stoßen an diese Wand und starren dann auf das eigentliche Problem, ohne es erreichen zu können. Das ist keine Erfolgsgeschichte über Produktivität. Das ist ein Kündigungsschreiben mit sechs Monaten Vorlauf.
Was sollten Sie also tun? Verbieten Sie Vibe Coding nicht - das wäre eine Bestrafung des Überbringers der Botschaft, und ehrlich gesagt ist diese Botschaft ein Geschenk. Tun Sie stattdessen Folgendes:
👉 Erfassen Sie den Bestand dessen, was Ihre Leute gebaut haben. Jedes interne Tool, das mit echten Daten oder Prozessen arbeitet. Ja, die Liste wird peinlich sein. Aber es ist besser, wenn Sie das finden als der Wirtschaftsprüfer oder, noch schlimmer, ein Systemausfall.
👉 Lesen Sie die Landkarte. Sortieren Sie die Tools in zwei Stapel. Stapel eins: Horizontale Bequemlichkeit - persönliche Skripte, kleine Helfer, Arbeitserleichterungen. Prima, fördern Sie das. Stapel zwei: Tools, die Lücken flicken, für die Ihre IT oder Ihr Innovationsteam verantwortlich sein sollte. Dieser Stapel ist keine bloße Werkzeugliste; es ist Ihre tatsächliche interne Roadmap, geschrieben von den Leuten, die den Schmerz täglich erleben, mit einer Präzision, die kein Anforderungs-Workshop je erreichen wird.
👉 Behandeln Sie Prototypen als Spezifikationen, nicht als Produktionssysteme. Ein per Vibe Coding erstelltes Tool beweist den Bedarf und zeigt den Arbeitsablauf. Die Entwicklung sollte es dann korrekt nachbauen, mit klarer Verantwortlichkeit, Überwachung und einem Wartungsplan. Der Unterschied zwischen "Beleg" und "Produktion" ist der Unterschied zwischen einem preiswerten Dashboard und einem sehr teuren Zwischenfall.
👉 Befördern Sie Ihre besten Vibe-Coder in das Tool-Team oder stellen Sie spezielle Entwickler für interne Werkzeuge ein. Jemand in Ihrer Organisation hat gerade Eigeninitiative, Fachwissen und einen konstruktiven Instinkt bewiesen - kostenlos, in der eigenen Zeit, gegen Ihre Prozesse. Diese Person signalisiert Ihnen, was sie karrieretechnisch erreichen möchte. Hören Sie zu, bevor es ein Wettbewerber tut.
👉 Finanzieren Sie interne Tools, als wären sie ein Produkt, denn das sind sie. Ihre Kunden sitzen zufällig in Ihrem Gebäude. Nichts summiert sich teurer als vernachlässigte interne Werkzeuge: Es verlangsamt alle, züchtet Schatten-IT und demotiviert genau die Leute, die Sie sich am wenigsten leisten können zu verlieren.
Das Management meines Kollegen feierte die Token-Rechnungen. Was sie hätten feiern sollen, ist die kostenlose, schonungslose Prüfung, die ihre Mitarbeiter ihnen gerade überreicht haben - und sie hätten darauf reagieren müssen.
Vibe Coding hat kein Problem in diesem Unternehmen geschaffen. Es hat eines offengelegt. Da liegt der feine Unterschied, und die Unternehmen, die das verstehen, werden jene fressen, die es nicht tun.
Haben Sie in Ihrer Organisation bereits die Wurzeln der Vibe-Coding-Schatten-IT entdeckt - oder befinden Sie sich noch in der Champagner-Phase? 👇
Dieser Artikel ist auch auf English verfügbar.
0 comment(s)
No comments yet. Be the first to comment.
Leave a comment