KI schreibt den Code. Wer ist dafür verantwortlich? Warum ein erfahrener Entwickler 2026 mehr wert ist, nicht weniger

Die Frage, die jeder Kunde stellen darf

Irgendwann im ersten Gespräch kommt sie, höflich oder weniger höflich: "Können wir das nicht einfach mit KI machen?" Die Frage ist berechtigt. 2026 kann ein Gründer einem Tool eine Web App beschreiben, ihr an einem Nachmittag beim Entstehen zusehen und sie vor dem Abendessen deployen. Einfache Websites, Dashboards, interne Tools, sogar ein Shop mit Checkout: all das lässt sich ohne einen Entwickler im Raum herstellen. Warum also einen erfahrenen bezahlen, und warum die Sätze, die Erfahrung kostet?

Dieser Artikel ist meine ehrliche Antwort. Er ist kein Argument gegen KI. Ich nutze KI jeden Arbeitstag und zeige dir genau wo, denn das ist ein Teil davon, warum meine Pakete kosten, was sie kosten, und nicht mehr. Er ist ein Argument über Verantwortung: KI hat verändert, wer den Code schreibt. Sie hat nicht verändert, wer dafür geradesteht, wenn er falsch ist. Die Unternehmen, die diesen Unterschied verstehen, haben in zwei Jahren noch ein funktionierendes Produkt, einen sauberen Prüfpfad und eine gültige Versicherung. Die anderen tauchen bereits in den Vorfallsberichten auf, und ich zitiere diese Berichte, statt dich zu bitten, mir zu glauben.

Was "Vibe Coding" ist, und warum die Demo nicht das Produkt ist

Der Begriff entstand Anfang 2025 für eine Art, Software zu bauen, bei der du in Alltagssprache beschreibst, was du willst, akzeptierst, was das Modell produziert, es laufen lässt, das Nächste beschreibst und den Code nie wirklich liest. Für Prototypen ist das enorm produktiv. Das Problem: Ein Prototyp und ein Produkt sehen auf dem Bildschirm identisch aus.

Eine funktionierende Demo beweist, dass der Happy Path einmal funktioniert, auf dem Rechner des Autors, mit den Daten des Autors, mit dem Autor als eingeloggtem Administrator. Ein Produkt muss für den tausendsten Nutzer funktionieren, auf einem langsamen Handy, mit einer halb abgebrochenen Session, unter dem Retry eines Zahlungsanbieters, nach einem Dependency Update, mit einem feindseligen Besucher, der jeden Parameter abtastet, an dem Tag, an dem die eine Person, die das System verstanden hat, im Urlaub ist. Die Lücke zwischen diesen beiden Zuständen ist die gesamte Disziplin des Software Engineering, und genau der Teil, den KI, sich selbst überlassen, nicht erledigt, weil niemand danach gefragt hat und die Demo schon fertig aussah.

Ich nenne das die Neunzig Prozent Falle. KI bringt dich an einem Tag auf neunzig Prozent. Die restlichen zehn Prozent, Integrationen mit echten Zahlungsanbietern und Steuerregeln, Altdaten, Randfälle, Performance unter Last, Sicherheit, Compliance Nachweise, dauern so lange wie die ersten neunzig, als noch Menschen alles geschrieben haben, und dort sterben die meisten KI gebauten Projekte leise. Zurück bleibt ein Gründer mit etwas, das fast funktioniert, niemandem, der es fertigstellen kann, und einer Rechnung für den Neustart.

Was die Forschung tatsächlich sagt

Nichts davon ist nur meine Meinung. In den letzten achtzehn Monaten hat die Sicherheitsbranche KI generierten Code im großen Maßstab vermessen, und die Ergebnisse sind konsistent.

Veracodes Studie 2025 zu generiertem Code fand, dass rund 45 Prozent der Proben mindestens eine Schwachstelle aus den OWASP Top 10 enthielten, der Standardliste der häufigsten Fehler in Webanwendungen. Die Cloud Security Alliance meldete Mängel in 62 Prozent der untersuchten Lösungen. Eine Sicherheitsfirma scannte mehr als 1.400 vibe gecodete Anwendungen, die produktiv liefen, und fand bei 58 Prozent mindestens eine kritische Schwachstelle; zusammen legten sie über 400 Geheimnisse offen: API Keys, Datenbankzugänge und Zahlungstoken, die im clientseitigen Code oder in öffentlichen Repositories lagen.

Etwa jede fünfte generierte Codeprobe importiert ein Softwarepaket, das es nicht gibt. Das Modell erfindet einen plausiblen Namen. Angreifer haben das bemerkt, diese Namen in den öffentlichen Paketregistern registriert und mit Schadsoftware gefüllt, eine Technik, die inzwischen Slopsquatting heißt. Ein Entwickler, der die Abhängigkeitsliste liest, ist die einzige Verteidigung. Ein Tool, das akzeptiert, was sich installieren lässt, ist keine.

Im März 2026 warnte das britische National Cyber Security Centre Unternehmen ausdrücklich, dass Vibe Coding ein erhebliches Risiko darstellt, und der Incident Monitor der OECD erfasste die Warnung als systemische Gefahr. Gartner prognostiziert gleichzeitig, dass bis 2028 rund 40 Prozent neuer Unternehmenssoftware mit diesen Werkzeugen entstehen wird. Beides stimmt zugleich: Die Methode bleibt, und sie ist ohne Aufsicht gefährlich.

Die Quellen stehen am Ende des Artikels. Einige stammen von Anbietern mit Interesse am Thema, deshalb empfehle ich, das Originalmaterial von Veracode und NCSC zu lesen statt der Zusammenfassungen. Die Richtung jeder Zahl ist dieselbe.

Die Gefahren, in der Reihenfolge, in der sie teuer werden

Kunden nennen mir ihre Sorgen ungefähr in der Reihenfolge unten. Die ersten sind laut und werden überall diskutiert. Die späteren sind leiser und kosten mehr.

Eins: Sicherheit, die du nicht siehst

Die klassischen Fehler sind mit voller Wucht zurück, weil die Modelle aus einem Jahrzehnt Code gelernt haben, der sie hatte: SQL per Stringverkettung, Nutzereingaben ohne Escaping gerendert, Berechtigungsprüfungen, die am Button existieren, aber nicht am Endpunkt, Datei Uploads, die alles annehmen, Session Tokens, die nie ablaufen, Adminrouten, die nur durch Unauffälligkeit geschützt sind. Jeder dieser Fehler ist in der Demo unsichtbar und in Produktion katastrophal.

Dann die Geheimnisse. Generierter Code legt den API Key gern dorthin, wo es bequem ist, und bequem ist meist der Browser. Die 400 offengelegten Zugangsdaten in jenem Produktionsscan waren keine exotischen Ausfälle; sie waren das Standardverhalten von Werkzeugen, die auf "es funktioniert" optimieren statt auf "es ist sicher".

Ein erfahrener Entwickler schreibt sicheren Code nicht, weil er klug ist. Er schreibt ihn aus Gewohnheit und nach Checkliste: parametrisierte Abfragen, Ausgabekodierung, Berechtigung bei jeder Anfrage auf dem Server, Geheimnisse im Tresor, überall minimale Rechte, Abhängigkeiten fixiert und geprüft, und ein Bedrohungsmodell, das aufgeschrieben wird, bevor das Feature gebaut wird. Beim letzten Punkt ist KI übrigens hervorragend, wenn jemand fragt.

Zwei: der Agent mit den Schlüsseln

2025 ging ein Vorfall durch die Presse, bei dem ein KI Coding Agent während eines Code Freeze die Produktionsdatenbank eines Unternehmens löschte und anschließend irreführende Angaben darüber machte, was er getan hatte. Die Details sind plattformspezifisch; die Lehre ist allgemein. Ein Agent mit Schreibzugriff auf Produktion ist ein neuer Mitarbeiter mit Root Rechten und ohne Angst. Kein vernünftiger Mensch gibt einem Neuzugang in der ersten Woche die Produktionszugänge, und doch ist genau das die Standardkonfiguration vieler Vibe Coding Setups.

Erfahrenes Engineering trennt Umgebungen, gibt jedem Akteur die minimal nötigen Rechte, stellt Produktionsänderungen hinter einen Release Prozess und hält Backups vor, die getestet sind, indem man sie tatsächlich wiederherstellt. Nichts davon ist glamourös. Alles davon ist der Unterschied zwischen einem Vorfall und einem Aussterbeereignis.

Drei: der kritische Pfad, der sich aus Versehen ändert

Das ist die Gefahr, die ich für die wichtigste halte, und die Unternehmen selten benennen, bevor sie ihnen passiert ist. Jedes Geschäft läuft über eine Handvoll Pfade, die funktionieren müssen: der Checkout, der Login, das Angebot, die Rechnung, das Onboarding Formular, der Datenexport, den die Buchhaltung braucht. Alles andere ist Dekoration.

Software ändert sich ständig. Jedes Feature, jedes Dependency Update, jeder "kleine Fix" berührt Code, von dem anderer Code abhängt. Ohne eine Testsuite, die festhält, wie sich die kritischen Pfade verhalten sollen, gibt es keine Möglichkeit zu wissen, ob die heutige Änderung das gestrige Versprechen gebrochen hat. Vibe gecodete Systeme haben diese Suite fast nie, denn Tests sind das Erste, was ein Tool weglässt, wenn niemand danach fragt, und die Zuversicht des Tools ist kein Beweis.

Hier verdienen testgetriebene und verhaltensgetriebene Entwicklung ihr Geld, und deshalb stelle ich sie ins Zentrum meiner Arbeit, statt sie als Overhead zu behandeln. In der verhaltensgetriebenen Entwicklung werden die kritischen Pfade zuerst aufgeschrieben, in Alltagssprache, die ein Kunde lesen kann: "Angenommen, ein Kunde hat Artikel im Warenkorb, wenn er mit einer gültigen Karte zahlt, dann wird die Bestellung bestätigt und der Bestand reduziert." Diese Sätze werden zu automatisierten Tests. Die Tests laufen bei jeder Änderung. Ein Release, das ein Versprechen bricht, geht nicht raus. Die Überraschung wird an meinem Schreibtisch abgefangen, nicht beim Kunden deines Kunden.

Im Kundenhub gehe ich einen Schritt weiter: Die kritischen Pfade werden verifiziert und hinter einer Freigabe eingefroren. Eines dieser Verhalten zu ändern ist eine bewusste, protokollierte Entscheidung, nie ein Nebeneffekt von etwas anderem. Für einen regulierten Kunden, oder einfach für einen, der gern ruhig schläft, ist dieses Protokoll mehr wert als die Featureliste.

Vier: Architektur und Datenmodell

Eine unbequeme Wahrheit über Software: Die Entscheidungen, die am wenigsten kosten, wenn man sie trifft, kosten am meisten, wenn man sie ändert. Wie die Daten strukturiert sind, wie Geld dargestellt wird, wie Zustände durch das System wandern, wie die Teile miteinander sprechen, wie ein zweiter Mandant oder ein zweites Land behandelt wird. All das ist am ersten Tag gratis. Jedes davon ist im zwölften Monat ein Neubau.

KI optimiert auf den Prompt vor ihr. Bitte sie um einen Shop, und sie liefert einen Shop für eine Währung, eine Steuerregel, ein Lager, mit Preisen als Gleitkommazahlen, die eines Tages mit der Buchhaltung um einen Cent uneins sind. Bitte sie um eine SaaS, und sie liefert eine Einzelmandanten Anwendung mit nachträglich angeschraubter Kundenkennung, der teuerste Fehler, den es in dieser Softwarekategorie gibt.

Ein erfahrener Entwickler hat diese Fehler bereits gemacht, auf dem Projekt von jemand anderem, und trägt die Narben. Er fragt nach dem zweiten Land, bevor er die erste Zeile schreibt. Diese Frage ist ein großer Teil dessen, wofür der Stundensatz steht, und das bestangelegte Geld im Budget.

Fünf: niemand versteht das System

Code, den niemand im Team erklären kann, lässt sich nicht sicher ändern, nicht prüfen, nicht übergeben und nicht mit ernstem Gesicht versichern. Vibe gecodete Systeme erzeugen genau das: Tausende Zeilen, die an einem Nachmittag entstanden sind, strukturiert, wie es dem Modell an diesem Tag gefiel, ohne Erzählung des Warum.

Die Branche hat einen Namen für das Ergebnis: Wartbarkeitsschulden. Sie sind in der Demo unsichtbar und erscheinen auf keiner Rechnung, aber jede künftige Änderung kostet mehr, jeder neue Entwickler braucht länger, bis er nützlich ist, und irgendwann ist die rationale Entscheidung, alles wegzuwerfen. Unternehmen stellen fest, dass der kostenlose Nachmittag die teuerste Stunde war, die sie je gekauft haben.

Was Erfahrung hinzufügt, sind Struktur und Geschichte: Konventionen, die ein künftiger Entwickler wiedererkennt, Dokumentation, die Entscheidungen erklärt, statt den Code nachzuerzählen, Tests, die zugleich Spezifikation sind, und eine Übergabe, die davon ausgeht, dass ich nicht ewig da sein werde. "Dokumentiert, getestet, deins" ist für mich kein Slogan; es ist eine vertragliche Zusage und eine Designvorgabe.

Sechs: Compliance kommt laufend dazu

Regulierung interessiert sich nicht dafür, wer den Code geschrieben hat. Die Datenschutzregime in Großbritannien und der EU verlangen, dass du weißt, welche personenbezogenen Daten du hältst, warum, wie lange, und dass du es nachweisen kannst. Die Regeln für elektronisches Marketing entscheiden, ob du diese E-Mail überhaupt senden darfst. Der European Accessibility Act gilt seit Juni 2025 für die meisten digitalen Dienste, mit nationaler Durchsetzung dahinter. Der EU Cyber Resilience Act wird ab 2027 Sicherheitspflichten für Produkte mit digitalen Elementen auferlegen, inklusive Dokumentation und Umgang mit Schwachstellen. Für viele Unternehmen kommen NIS2 oder Branchenregeln hinzu.

Jedes dieser Regelwerke stellt dieselben drei Fragen: Was hast du gebaut, woher weißt du, dass es sicher ist, und wer ist verantwortlich. Ein vibe gecodetes System beantwortet keine davon. Ein erfahrener Entwickler baut die Nachweise als Teil der Arbeit: eine Datenlandkarte, Einwilligung, die im Code durchgesetzt wird und nicht nur im Banner, Barrierefreiheit, die in die Komponenten eingebaut ist statt per Plugin angeschraubt, ein Release Register, ein Audit Log. Wenn die Aufsicht oder der Anwalt des Kunden fragt, ist die Antwort ein Link, kein Hektikanfall.

Sieben: Versicherung und Haftung

Dieser Punkt ist neu und entwickelt sich schnell. Seit dem 1. Januar 2026 stehen der Versicherungsbranche Standardformulierungen zur Verfügung, die Schäden im Zusammenhang mit generativer KI ausschließen, und mehrere Versicherer haben begonnen, KI bezogene Ansprüche ganz aus der Berufshaftpflicht auszunehmen oder den Begriff "professionelle Leistung" so zu verengen, dass Arbeit, die eine Maschine ohne menschliche Aufsicht erzeugt hat, herausfällt. Cyberpolicen knüpfen den Schutz zunehmend an dokumentierte Sicherheitskontrollen. Juristische Kommentare warnen inzwischen, dass ein Versicherer auch ohne ausdrücklichen Ausschluss im Schadenfall argumentieren wird, ein Dienstleister, der ungeprüfte KI Ausgabe ausgeliefert hat, habe gar keine professionelle Leistung erbracht.

Denk darüber nach, was das für ein Unternehmen bedeutet, dessen Produkt vibe gecodet wurde. Nach einem Vorfall sind die Fragen des Versicherers vorhersehbar: Wer hat dieses Release freigegeben, wo sind die Tests, was hat sich wann geändert, wer hatte Zugang zur Produktion, wo ist die Sicherheitsprüfung, wo ist die Dokumentation. Lautet jede Antwort "das hat die KI gemacht", reagiert die Police womöglich nicht, und die Geschäftsführer sind persönlich exponiert, wie sie es nie waren, solange ein benannter Ingenieur hinter der Arbeit stand.

Ich bin eine benannte Person mit beruflichem Ruf, einem Vertrag, einem dokumentierten Prozess und einem Prüfpfad. Das ist keine Prahlerei; es ist das, was die Arbeit versicherbar macht, für dich und für mich. Im Zeitalter der KI ist "wer ist verantwortlich" eine Bilanzfrage geworden.

Acht: Eigentum, Lizenzen und Lock-in

Viele Vibe Coding Plattformen hosten die Anwendung selbst, speichern die Daten in ihren Systemen und rechnen nach Nutzung ab. Der Code ist in der Theorie exportierbar und in der Praxis nirgendwo sonst lauffähig. Tokenkosten, die in der Demo trivial wirkten, skalieren mit jedem Nutzer. Ändert die Plattform ihre Preise, ihre Bedingungen oder ihre Meinung, geht das Geschäft mit.

Dazu kommt die Herkunft. Modelle, die auf öffentlichem Code trainiert wurden, können Fragmente unter Lizenzen reproduzieren, die dich verpflichten, dein eigenes Produkt offenzulegen, oder die schlicht jemand anderem gehören. Für ein Unternehmen, das eines Tages verkaufen, Kapital aufnehmen oder geprüft werden könnte, ist unklares Eigentum am Kernvermögen ein Due Diligence Problem mit Ansage.

Alles, was ich baue, läuft auf standardisierter, offener Technologie, in Infrastruktur, die du kontrollierst, mit dem Code in deinem Repository und deinem Namen darauf. Abhängigkeiten sind geprüft und ihre Lizenzen bekannt. Du kannst jederzeit mit allem gehen, und das ist die einzige ehrliche Grundlage für eine lange Zusammenarbeit.

Neun: Messung, die lügt, und das Falsche bauen

Zwei leisere Gefahren. Erstens gehören Analytics und Tracking zu den Dingen, die man am leichtesten mit voller Überzeugung falsch macht. Events, die doppelt feuern, Conversions, die Testbestellungen zählen, Einwilligung, die eine serverseitige Pipeline ignoriert, Attribution, die den falschen Kanal belohnt. Ein Unternehmen trifft dann Entscheidungen auf Zahlen, die präzise und falsch sind. Messung richtig hinzubekommen ist langsame, sorgfältige Arbeit, die jemanden braucht, der das Recht und die Leitungen versteht.

Zweitens baut KI alles, auch das Falsche, mit gleicher Begeisterung. Die knappste Fähigkeit in der Software ist heute nicht, Code zu schreiben; sie ist zu entscheiden, was man nicht schreibt. Ein erfahrener Entwickler, der ungenutzte Features, überbaute Produkte und auf der falschen Priorität verbrannte Budgets gesehen hat, widerspricht, fragt, was das Geschäft eigentlich verändern will, und spart oft mehr Geld mit einem Nein als mit einem Ja. Dieses Gespräch ist der Grund, warum ich jede Zusammenarbeit mit einem Workshop beginne und nicht mit einem Angebot.

Was "erfahren" 2026 tatsächlich bedeutet

Das Wort hat sich verändert. Vor zehn Jahren war ein erfahrener Entwickler jemand, der schnell viel korrekten Code schreiben konnte. Heute schreibt das Modell den Code schnell, und Erfahrung zeigt sich woanders:

Urteilsvermögen beim Risiko. Zu wissen, welcher Teil eines Systems generiert und überflogen werden kann und welcher entworfen, Zeile für Zeile gelesen und getestet werden muss, bevor man ihm traut. Die beiden auseinanderzuhalten ist die Fähigkeit.
Code kritisch lesen. Das Modell liefert plausiblen Code. Nur ein Leser mit Narben bemerkt die fehlende Berechtigungsprüfung, die Race Condition, den Index, der nicht da ist, die Dezimalzahl, die kein Float sein dürfte.
Bedrohungsmodellierung. Zu fragen, bevor das Feature existiert, wie ein feindseliger Nutzer, ein unachtsamer Nutzer und eine kaputte Abhängigkeit es jeweils missbrauchen werden.
Datenkorrektheit. Geld, Zeitzonen, Steuern, Bestand und Identität gut genug zu verstehen, um zu erkennen, wann die sauber aussehende Antwort falsch ist.
Umfang und Reihenfolge. Zu wissen, was zuerst gebaut wird, was aus dem MVP herausbleibt und was wartet, bis die Daten es rechtfertigen.
Integration mit der Realität. Zahlungsanbieter, Buchhaltungssysteme, Altdatenbanken, Versanddienstleister, Marktplätze. Die echte Welt hat keinen Prompt.
Aufschreiben. Tests als Spezifikation, Entscheidungen als Protokoll, Übergabe als Lieferergebnis.

Nichts davon erledigt das Modell allein. All das macht das Modell schneller, wenn ein Mensch, der es beherrscht, die Führung hat.

Wie ich KI nutze, und warum das deinen Preis senkt

Ich wäre ein Heuchler, würde ich vor KI warnen und dann so tun, als schriebe ich jede Zeile von Hand. Tue ich nicht. Ich nutze sie ständig, nach einer Regel: Je kleiner der Schaden eines Fehlers, desto mehr baut die KI allein; je größer er ist, desto mehr berät die KI, während ich entscheide. In der Praxis sind das drei Stufen.

Geringes Risiko: KI baut, ich werfe einen Blick darauf. Die visuelle Ebene, HTML und Styling, responsive Layouts, Dark Mode, E-Mail Vorlagen, PDF Layouts. Ein falsches Ergebnis ist sofort sichtbar und schadet nichts. Formulargerüste, clientseitige Validierung, Fehlerzustände, Länder- und Telefonwidgets, Texte in der zweiten Sprache. Standardmodelle, Controller und Views abseits des kritischen Pfads. Seed- und Testdaten, realistische Demoinhalte, anonymisierte Testdatensätze. Einmalskripte, Import- und Exportjobs, API Clients für Drittanbieter, Deployment Rezepte. Dokumentationsentwürfe, Kommentare im Code, Onboarding Anleitungen, das Runbook, das sonst nie geschrieben wird. Diese Stufe hat früher einen großen Teil der Stunden jedes Projekts verschlungen. Heute ist es ein Bruchteil, und diese Ersparnis steckt in meinen Paketpreisen, nicht in meiner Marge.

Mittleres Risiko: KI entwirft, ich redigiere. Tests schreiben: Ich gebe dem Modell die Akzeptanzkriterien und frage nach den Randfällen, den Widersprüchen, den Anforderungen, die niemand erwähnt hat, und dem, was ein feindseliger Nutzer versuchen würde. Darin ist es bemerkenswert gut, und es ist der wertvollste Einsatz, den ich gefunden habe, weil er die Testsuite breiter macht als die Vorstellungskraft eines einzelnen Menschen. Code Review als zweiter Leser: Bevor ich eine Änderung prüfe, liest das Modell den Diff und markiert das ungeprüfte Nil, die N+1 Abfrage, den fehlenden Index, die vergessene Berechtigungsprüfung. Refactoring unter grüner Testsuite. Release Notes aus den hinzugekommenen Tests, was sie konstruktionsbedingt ehrlich macht, denn ein Verhalten, das nicht getestet wurde, taucht in den Notes nicht auf. Triage von Logs und Stacktraces. Performanceanalyse, Abfragepläne, Caching Strategien, alles an echten Daten verifiziert. Scans von Abhängigkeiten und Geheimnissen.

Hohes Risiko: Ich entscheide, KI berät. Architektur, Datenmodell, Geld- und Steuerlogik, Zustandsautomaten, Authentifizierung und Berechtigung, Zahlungen, alles auf dem verifizierten kritischen Pfad. Hier ist das Modell Sparringspartner: Was bricht, wenn; was habe ich vergessen; wie würdest du das angreifen. Es committet nie allein, und seine Vorschläge durchlaufen dieselben Tests und dasselbe Review wie meine.

Für einen Kunden bedeutet das Konkretes. Die unkritischen achtzig Prozent eines MVP sind in Tagen statt Wochen fertig. Die Testabdeckung steigt, statt zu sinken, weil Tests zu schreiben jetzt einen Bruchteil der Zeit kostet. Dokumentation existiert, weil sie zu erstellen keine lästige Pflicht mehr ist. Eine verantwortliche Person mit diesen Werkzeugen leistet, was früher ein kleines Team brauchte, und du zahlst nie für den Koordinationsaufwand, die Übergaben oder die Juniorebene. Der Stundensatz ist der eines erfahrenen Ingenieurs. Die Stundenzahl ist die eines Teams mit KI. Die Summe liegt unter beiden Alternativen, und das Ergebnis ist etwas, das ein Versicherer, ein Prüfer und dein nächster Entwickler lesen können.

Was du schriftlich bekommst

Versprechen kosten nichts, deshalb hier, was als Nachweis existiert und nicht als Werbetext:

Tests, die du sehen kannst. Der Kundenhub zeigt die automatisierten Testläufe deines Projekts, die Verhaltensspezifikationen in Alltagssprache und welche kritischen Pfade verifiziert und hinter Freigabe eingefroren sind.
Ein Release Register. Was ausgeliefert wurde, wann, was sich geändert hat, welche Tests es abdecken, wer freigegeben hat. Das Dokument, nach dem ein Versicherer oder Prüfer zuerst fragt.
Ein Audit Log und ein Entscheidungsprotokoll. Jede wesentliche Aktion und jede wesentliche Entscheidung, mit Begründung, zum Zeitpunkt festgehalten.
Dokumente und Verträge an einem Ort, inklusive der Eigentumsklausel, die sagt, dass Code, Daten und Infrastruktur dir gehören.
Eine benannte Person im Vertrag, mit einem Prozess hinter dem Namen, was die Zusammenarbeit überhaupt erst versicherbar macht.
Der Workshop vor dem Vertrag, in dem wir entscheiden, was überhaupt gebaut werden soll.

Fragen an jeden, der deine Software bauen will

Ob du mit mir sprichst, mit einer Agentur oder mit einem Tool: Diese Fragen trennen ein Produkt von einer Demo. Jeder ehrliche Profi begrüßt sie.

Welche Teile dieses Systems werden generiert, welche von einem Menschen entworfen, und wie entscheidest du das?
Wo sind die automatisierten Tests, und kann ich die für meine kritischen Pfade in Alltagssprache lesen?
Was passiert, wenn eine Änderung einen kritischen Pfad bricht? Zeig mir den Prozess, nicht die Absicht.
Wer hat Zugang zur Produktion, und wie werden Geheimnisse gespeichert?
Wie werden Abhängigkeiten ausgewählt und geprüft, und wer kontrolliert, dass jedes Paket existiert und ist, was es behauptet?
Wo liegen meine Daten, wem gehört der Code, und kann ich alles mitnehmen und gehen?
Wie geht das System mit einer zweiten Währung, einem zweiten Land, einem zweiten Mandanten um? Lautet die Antwort "später", frag, was später kostet.
Was sind deine Nachweise für Compliance: Datenlandkarte, durchgesetzte Einwilligung, Barrierefreiheit, Release Protokolle?
Wer gibt ein Release frei, und was würde dein Versicherer sehen, wenn er fragt?
Was kostet der Betrieb beim Zehnfachen der heutigen Nutzung?
Was wirst du nicht bauen, und warum?
Wenn du morgen verschwindest, wie lange braucht ein anderer Entwickler, um in dieser Codebasis produktiv zu sein?

Sind die Antworten vage, ist das Risiko nicht theoretisch. Sind die Antworten Links zu echten Artefakten, sprichst du wahrscheinlich mit der richtigen Person.

Das ehrliche Fazit

KI hat Software im Überfluss verfügbar gemacht. Verantwortung hat sie nicht im Überfluss verfügbar gemacht. Der Code ist jetzt der einfache Teil; das Urteil darüber, was gebaut wird, die Disziplin zu beweisen, dass es funktioniert, die Architektur, die Wachstum übersteht, der Nachweis, der Aufsicht und Versicherer zufriedenstellt, und eine benannte Person, die für all das geradesteht, sind knapper denn je, gerade weil die Werkzeuge es so verlockend machen, sie wegzulassen.

Dafür zahlst du, wenn du mit einem erfahrenen Entwickler arbeitest, der KI richtig einsetzt: nicht für das Tippen, das heute wenig kostet, sondern für die Verantwortung, die das nie getan hat. Und weil das Tippen heute wenig kostet, zahlst du für das Ganze weniger als vor drei Jahren. Diese Kombination, niedrigere Kosten und höhere Sicherheit, ist das eigentliche Angebot, und der Grund, warum die Frage "können wir das nicht einfach mit KI machen" eine bessere Antwort hat als Ja oder Nein: Ja, mit jemandem, dessen Name darauf steht.

Quellen

Veracode, GenAI Code Security Report 2025 (45 Prozent der generierten Proben mit einer OWASP Top 10 Schwachstelle).
Cloud Security Alliance, Studie 2025 zu KI generierten Lösungen (62 Prozent mit Sicherheitsmängeln).
Escape, Scan vibe gecodeter Produktionsanwendungen (58 Prozent mit kritischer Schwachstelle, über 400 offengelegte Geheimnisse).
Warnung des britischen National Cyber Security Centre zu Vibe Coding, März 2026, erfasst im OECD AI Incidents Monitor.
Gartner Prognose zu Vibe Coding in Unternehmenssoftware bis 2028.
Insurance Business, Fenwick und Haynes Boone zu den KI Ausschlüssen seit Januar 2026 und zum Argument der "professionellen Leistung".
European Accessibility Act (gilt seit Juni 2025), EU Cyber Resilience Act (Pflichten ab 2027), UK GDPR, DSGVO und PECR.