„Programmieren lernen lohnt sich nicht mehr.“ Den Satz höre ich gerade in jedem zweiten Gespräch. Er ist die bequemste Fehleinschätzung dieses Jahrzehnts.
Die Begründung klingt erst mal plausibel. Ein Modell mit Werkzeugzugriff liest heute das Dateisystem, fragt die Datenbank ab, korreliert Logs, fasst Tickets zusammen und schreibt den Patch gleich mit. Das stimmt alles, und es ist ein enormer Hebel. Die Schlussfolgerung daraus ist trotzdem falsch. Wer Systeme baut, die Geld bewegen, Zugang gewähren oder Daten aufbewahren, braucht heute mehr feste Wege als je zuvor. Gerade weil das Modell alles lesen kann.
Der Engpass war nie das Tippen
Billiger geworden ist der erste Entwurf. Nicht billiger geworden sind Betrieb, Zusicherung und Nachweis.
Der Engpass in der Softwareentwicklung war noch nie die Geschwindigkeit, mit der jemand Zeichen in eine Datei bringt. Er war die Frage, welchem Vorgang man vertraut, und wer geradesteht, wenn er schiefgeht. Diese Frage hat sich durch KI nicht erledigt. Sie ist dringender geworden, weil jetzt sehr viel mehr Code sehr viel schneller entsteht.
Ein Modell ist eine Verteilung, kein Vertrag
Ein Programm ist ein Versprechen: gleiche Eingabe, gleiche Ausgabe, jedes Mal. Darauf ruht alles, was wirklich zählt. Lohnabrechnung, Zinsberechnung, Zutrittskontrolle, Dosisrechner, Steuerlogik, Mandantentrennung.
Ein Sprachmodell gibt dieses Versprechen nicht. Auch bei temperature: 0 ist Reproduzierbarkeit eine Eigenschaft der Infrastruktur und nicht der Semantik: anderes Batching, andere Hardware, ein neuer Modell-Snapshot, und die Ausgabe verschiebt sich. Das ist kein Defekt, das ist die Bauart.
| Feste Funktion | Modellaufruf |
|---|---|
| Gleiche Eingabe, gleiche Ausgabe | Die Ausgabe ist eine Stichprobe |
| Fehler sind reproduzierbar | Fehler sind selten und unregelmäßig |
| Eine Änderung ist ein Diff | Eine Änderung ist ein neuer Snapshot |
| Verhalten ist vollständig testbar | Verhalten ist nur stichprobenhaft messbar |
| Rollback dauert Sekunden | „Rollback“ heißt: altes Modell hoffentlich noch verfügbar |
Beide Spalten sind nützlich. Nur nicht an derselben Stelle. Der Fehler liegt nicht darin, das Modell zu benutzen. Der Fehler liegt darin, es dort zu benutzen, wo ein Vertrag gebraucht wird.
Was feste Wege liefern, was Sprache nicht liefern kann
Determinismus
Die Buchung ergibt zweimal denselben Betrag. Ohne diese Eigenschaft ist keine Abstimmung, kein Abschluss und keine Fehlersuche möglich.
Autorisierung
Rechte gehören vor das Modell, nicht in den Prompt. „Du darfst keine Datensätze anderer Mandanten anzeigen“ ist keine Zugriffskontrolle, das ist eine Bitte. Zugriffskontrolle ist ein WHERE mandant_id = ?, das der Aufrufer nicht überschreiben kann.
Nachweis
Ein Commit, ein Migrationsskript, eine Zeile im Audit-Log beantworten die Frage „warum ist das passiert?“. „Das Modell hat so entschieden“ beantwortet sie nicht und ist gegenüber Prüfern, Kunden und Gerichten wertlos.
Umkehrbarkeit
Deploy zurückrollen, Migration rückwärts fahren, Transaktion abbrechen. Ein Vorgang, den man nicht zurücknehmen kann, darf nicht probabilistisch ausgelöst werden.
Prompt Injection ist kein Bug, sondern die Bauform
Sobald ein Modell fremden Text liest, eine Mail, eine Webseite, ein PDF, das Ticket eines Kunden, verschwimmt die Grenze zwischen Daten und Anweisung. Das ist kein Implementierungsfehler, den jemand irgendwann wegpatcht. Es folgt daraus, dass beides derselbe Token-Strom ist.
Das Muster dahinter ist alt und heißt confused deputy: Der Angreifer hat selbst keine Rechte, aber er kann jemanden bitten, der welche hat. Die Antwort darauf ist architektonisch, nicht sprachlich. Das Modell bekommt kein Datenbankpasswort. Es bekommt eine Funktion.
// nicht: freier Schreibzugriff für das Modell
// sondern: eine Funktion, die nein sagen kann
export async function erstatteBetrag(auftragId: string, cent: number) {
if (cent <= 0 || cent > 20_000) throw new Error("Betrag außerhalb Limit");
const auftrag = await db.auftrag.find(auftragId, { mandant: session.mandantId });
if (!auftrag || auftrag.status !== "bezahlt") throw new Error("nicht erstattungsfähig");
return db.tx(async (t) => {
await t.erstattung.create({ auftragId, cent, ausgeloestVon: session.userId });
await t.audit.log("erstattung", { auftragId, cent, quelle: "assistent" });
});
}Das Modell darf diese Funktion aufrufen. Es kann das Limit nicht anheben, den Mandanten nicht wechseln, den Status nicht umgehen und den Audit-Eintrag nicht unterdrücken, weil diese Regeln außerhalb seines Einflussbereichs liegen. Genau das ist gemeint, wenn von Leitplanken die Rede ist. Kein freundlicher Ton im Systemprompt, sondern Code, der nein sagt.
Was die KI sehen darf, und was nicht
„Die KI kann auf alle Daten zugreifen“ ist technisch richtig und betrieblich der Anfang des Problems. Zugriff ist keine Ja-Nein-Frage, sondern eine Matrix aus Datenklasse, Weg und Begründung.
| Datenklasse | Weg | Begründung |
|---|---|---|
| Quellcode, eigene Repos | direkt | Kein Personenbezug, jede Änderung ist ein prüfbarer Diff |
| Produktionslogs | maskiert | Logs enthalten Tokens, Mailadressen, IPs und Session-IDs, oft unbemerkt |
| Kundendatensätze | über Funktion | Zweckbindung und Mandantentrennung müssen im Code erzwungen sein, nicht im Prompt. Art. 32 DSGVO verlangt technische Maßnahmen |
| Beschäftigtendaten | mitbestimmt | Sobald Leistung oder Verhalten auswertbar wird, greift § 87 Abs. 1 Nr. 6 BetrVG |
| Schlüssel, Tokens, Zertifikate | nie | Was einmal im Kontext war, steht im Log, im Cache und im Transkript |
| Schreibzugriff auf Produktion | nie direkt | Nur über geprüfte Funktionen mit Limit, Transaktion und Audit-Eintrag |
| Entscheidung über Menschen | nicht allein | Art. 22 DSGVO schützt vor rein automatisierten Einzelfallentscheidungen. Der EU AI Act stuft Teile davon als Hochrisiko ein, die Pflichten greifen gestaffelt ab 2026 |
Diese Zeilen sind keine Bürokratie, die man wegoptimiert. Sie sind der Grund, warum es überhaupt eine Anwendung gibt und nicht nur ein Chatfenster.
SaaS ist nicht tot, es verliert nur seine Verkleidung
Die Behauptung „KI ersetzt SaaS“ setzt Software mit ihrer Oberfläche gleich. Die Oberfläche ist das Billigste an einem Produkt. Teuer und schwer ist der Rest: Zustand über Jahre, Migrationen ohne Datenverlust, Rollen- und Rechtemodell, Mandantentrennung, Aufbewahrungsfristen von acht Jahren und mehr, Verfügbarkeitszusagen, Auftragsverarbeitungsverträge, Backups, die man tatsächlich zurückspielen kann.
Ein Chat kann eine Rechnung erzeugen. Er kann sie nicht revisionssicher aufbewahren, nicht garantieren, dass die Summe aller Buchungen stimmt, und nicht haften.
Was sich wirklich ändert: die Oberfläche wird dünner. Aus dem Formular mit vierzig Feldern wird ein Satz. Die Kernlogik dahinter wird dadurch nicht unwichtiger, sondern exponierter. Sie ist jetzt die einzige Stelle im System, an der noch Struktur sitzt. Unter Druck steht das Preismodell pro Sitzplatz, nicht das Produkt.
Die Kosten des Ausprobierens sind gefallen. Der Wert des Beurteilens ist gestiegen.
Warum sich Coden jetzt mehr lohnt, nicht weniger
- →Der Prototyp kostet fast nichts mehr. Eine Idee vom Freitagabend läuft am Sonntag. Wer die Sprache nicht spricht, kann die Idee nicht formulieren und die Antwort des Modells nicht prüfen.
- →Lesen ist wichtiger geworden als Tippen. Code, den du nicht beurteilen kannst, ist Code, den du nicht verantworten kannst. Und irgendwer verantwortet ihn immer.
- →Schnittstellen entwerfen ist die eigentliche Arbeit. Welche Funktionen es gibt, was sie zusichern, wo die Grenze verläuft. Genau daran hängt, ob das Modell nützlich oder gefährlich ist.
- →Typen, Tests und Verträge sind das, was generiertem Code überhaupt Vertrauen gibt. Je mehr Code aus einem Modell kommt, desto mehr Wert hat alles, was ihn automatisch widerlegen kann.
Fazit
Das Modell ist ein außergewöhnliches Werkzeug. Es liest alles, es entwirft schnell, es trägt dich über jede Anfangshürde. Aber es ist ein Werkzeug für den Entwurf und für die Ränder, nicht für den Kern. Der Kern bleibt, was er war: feste Wege, klare Funktionen, prüfbare Grenzen.
Wer das bauen kann, wird nicht überflüssig. Er wird die Person, die entscheidet, wie weit die KI gehen darf.
Die rechtlichen Hinweise in diesem Text sind Orientierung, keine Rechtsberatung. Aufbewahrungsfristen unterscheiden sich je nach Belegart und Rechtsraum.