KI-Coding für alle? Was der Fall Goldman Sachs lehrt

In vielen Unternehmen kommt die Frage gerade auf den Tisch der Geschäftsleitung: Sollen nur die Entwickler mit Claude Code, Cursor oder Copilot arbeiten, oder auch Vertrieb, Controlling und Produktmanagement? Die Werkzeuge versprechen, dass jede gute Idee in Stunden zu einem lauffähigen Programm wird. Ein aktueller Fall aus dem Bankensektor zeigt, dass die Antwort weniger einfach ist, als sie klingt.

Der Fall: erst geöffnet, dann wieder eingeschränkt

Goldman Sachs hat den Großteil der Belegschaft wieder von fortgeschrittenen KI-Coding-Tools wie Claude Code und GitHub Copilot ausgeschlossen. Das berichtet The Decoder unter Berufung auf Bloomberg und interne Richtlinien vom Oktober. Nutzen dürfen die Werkzeuge nur noch Ingenieure.

Vorher hatten Trader und Banker die Tools über Monate selbst eingesetzt, etwa um Handelsströme zu überwachen oder Inhalte zu erstellen. Intern sorgt die Einschränkung laut Bericht für Unmut.

Bemerkenswert ist der Wechsel im Ton. Noch im Sommer hatte der CIO der Bank das Vibe Coding durch nicht-technische Mitarbeitende öffentlich gelobt. Sein Bild: Jemand aus dem Handel hat eine Idee, baut mit KI einen ersten Prototyp, und danach übernimmt ein Ingenieur den Ausbau für den Produktiveinsatz. Als Grund für den Rückzieher nennt der Bericht nur eine Überprüfung von „Produktivität und Risikomanagement“. Ein Sprecher erklärte, nach der Experimentierphase gingen die Tools nun an diejenigen, die sie langfristig am besten einsetzen könnten.

Was genau den Ausschlag gab, ist öffentlich nicht bekannt. Sie sollten daraus also keine voreiligen Schlüsse ziehen. Die Frage für Ihr Haus lautet trotzdem: Haben wir festgelegt, wer mit diesen Werkzeugen was bauen darf?

Wo die Lücke liegt: Prototyp ist nicht Produkt

Die Idee hinter dem ursprünglichen Modell ist schlüssig. Der Fachbereich kennt das Problem am besten und kann es mit KI schnell greifbar machen. Schwierig wird es an der Stelle, an der aus einem Prototyp ein Werkzeug wird, auf das sich andere verlassen.

In einer lebhaften Diskussion auf Reddit fragt ein Entwickler, warum so viele Vibe-Coder offenbar keine automatischen Prüfungen einrichten. Gemeint sind CI/CD, also Abläufe, die jede Änderung automatisch testen und ausliefern, und Linting, eine automatische Prüfung auf typische Fehler und Stilbrüche. Die Antworten sind aufschlussreich. Mehrere Teilnehmer stellen fest: Wer selbst kein Entwickler ist, kennt diese Praktiken meist gar nicht. Sie werden nur genutzt, wenn das KI-Werkzeug sie vorschlägt und der Nutzer zustimmt.

Für Sie als Leitung ist das der Kern. Das Risiko liegt weniger im Werkzeug als darin, dass ein Fachbereich nicht weiß, welche Absicherungen fehlen. Mehr zu den Haftungsfragen, die daraus entstehen können, finden Sie im Beitrag zu den Risiken von Vibe Coding für die Geschäftsleitung.

Auch mit Tests ist nicht alles abgesichert

Die Diskussion zeigt auch: Automatische Prüfungen sind notwendig, aber nicht ausreichend.

• Tests prüfen Funktion, nicht Qualität. Ein Teilnehmer weist darauf hin, dass ein KI-Modell nicht zwischen Fehlern und bewussten Designentscheidungen unterscheiden kann. Es baut auf dem auf, was es vorfindet. Die Prüfstrecke meldet, ob etwas läuft, aber nicht, ob sich schlechte Muster im Code ansammeln. Empfohlen wird, den Code regelmäßig zu prüfen, durch Menschen oder einen eigens beauftragten Agenten.
• Schleichende Mängel bleiben unbemerkt. Berichtet wird etwa von Werten, die die KI an vielen Stellen fest in den Code geschrieben hat, statt sie zentral zu pflegen. Das fällt erst auf, wenn sich etwas ändern soll.
• Ausprobieren gehört dazu. Erfahrene Nutzer raten, die Anwendung gezielt von Hand zu bedienen und zu versuchen, sie kaputtzumachen. Gefundene Fehler kommen dann als Test in die automatische Prüfung. Bei Anwendungen mit vielen Nutzerinteraktionen können Tests ohnehin nicht jeden Fall abdecken.
• „Funktioniert“ muss definiert sein. Ein Teilnehmer beobachtet, dass Probleme oft entstehen, weil vorab nicht beschrieben wurde, wie ein funktionierendes Ergebnis aussieht.

Ein Entwickler schildert zudem, dass sich mit Claude Code seine Arbeit verschoben hat: Das Schreiben geht schneller, dafür prüft er deutlich länger, weil er den erzeugten Code nicht durchschaut. Die Zeitersparnis ist also nicht automatisch Nettoersparnis. Wie Sie das sichtbar machen, beschreibt der Beitrag zu Kennzahlen für KI-Coding.

Was das für Ihre Entscheidung bedeutet

Pauschal sperren oder pauschal freigeben sind beide keine guten Antworten. Wie Sie Freigaben so gestalten, dass sie tatsächlich gelten, behandelt der Beitrag KI-Richtlinie durchsetzen. Für die Frage, wer bauen darf, hilft eine kompakte Abwägung:

• Chance: Fachbereiche machen Ideen schnell greifbar. Das spart Abstimmungsschleifen, bevor Entwicklungsbudget fließt.
• Risiko: Prototypen werden stillschweigend zu Produktivwerkzeugen, ohne Prüfroutinen, ohne Verantwortlichen und ohne Überblick über die Codequalität.
• Nächster Schritt: Legen Sie fest, wo der Prototyp endet und wer ihn übernimmt. Klären Sie, welche Prüfungen Pflicht sind, bevor etwas produktiv genutzt wird.

Die Fragen, die Sie Ihrer IT und Ihren Fachbereichen stellen sollten: Wer nutzt heute schon KI-Coding-Tools außerhalb der Entwicklung? Was davon läuft bereits im Tagesgeschäft? Und wer würde es bemerken, wenn eines dieser Programme falsche Ergebnisse liefert?

Fazit

Der Fall Goldman Sachs ist kein Beleg dafür, dass Vibe Coding für Fachbereiche scheitert. Er zeigt aber, dass eine offene Experimentierphase irgendwann Regeln braucht. Wer diese Regeln früh festlegt, muss sie später nicht unter Druck zurücknehmen.

Sie wollen mit Ihrem Führungsteam klären, wer bei Ihnen mit KI-Coding-Tools bauen darf und wo die Übergabe an die Entwicklung liegt? Fragen Sie ein Inhouse-Seminar an oder melden Sie unverbindlich Ihr Interesse am offenen Seminar an.