Die Frage kommt inzwischen in fast jedem Erstgespräch: Schreibt die KI unsere Software bald selbst?
Ein klares Ja oder Nein wäre bequem, trifft es aber nicht. Ein Teil dessen, was vor zwei Jahren noch nach Prospekt klang, läuft heute im Alltag. Ein anderer Teil läuft weiterhin nicht. Und ein dritter war nie ein KI-Problem, sondern eines von Daten und Schnittstellen.
Was sich tatsächlich geändert hat, wohin die Arbeit dadurch gewandert ist und welche Posten in Projekten regelmäßig durchrutschen: darum geht es hier.
Drei Stufen, und nur eine davon ist neu
Wer über KI in der Entwicklung spricht, meint oft sehr verschiedene Dinge. Es lohnt sich, drei Stufen zu trennen. Sie unterscheiden sich nicht im Werkzeug, sondern darin, wie viel Zusammenhang die KI selbst erfassen muss.
Auf der ersten Stufe schlägt sie im Editor vor: vervollständigt Funktionen, schreibt Testfälle zu vorhandenem Code, erklärt fremden Quelltext. GitHub Copilot kann das seit Jahren zuverlässig. Handwerkszeug, keine Neuigkeit.
Auf der zweiten Stufe arbeitet sie über mehrere Dateien. Ein Refactoring quer durchs Modul, eine neue Schnittstelle samt Tests, die Migration eines Frameworks. Werkzeuge wie Cursor oder Claude Code lesen dafür selbstständig im Projekt, ändern an mehreren Stellen und lassen die Tests laufen. Das trägt heute, unter einer Bedingung: Das Projekt braucht eine verständliche Struktur und Tests, an denen die KI ihre eigene Arbeit messen kann. Wo beides fehlt, produziert sie schnell viel Schaden.
Die dritte Stufe ist die, um die es eigentlich geht. Aus einer sauber formulierten Anforderung entsteht in Stunden etwas Klickbares: Datenmodell, Oberfläche, Grundfunktionen. Kein Wireframe, sondern etwas, das man bedienen kann.
Das verändert vor allem die frühe Projektphase. Wir bauen deshalb inzwischen schon im ersten Workshop gemeinsam mit unseren Kund:innen einen Prototypen, statt Wireframes zu zeichnen. Über eine Skizze lässt sich schlecht streiten, über etwas Bedienbares sehr gut, weil Missverständnisse sofort auf dem Tisch liegen. Wer einmal erlebt hat, wie ein freigegebenes Konzept nach dem ersten Klicktest auseinanderfällt, weiß, was dieser Unterschied wert ist.
Und trotzdem: Ein Prototyp ist kein Produkt. Zwischen “läuft im Termin” und “läuft im Betrieb, mit echten Daten und echter Haftung” liegt der größere Teil der Arbeit. Wer diesen Unterschied verwischt, verkauft eine Illusion.
Die Arbeit verschwindet nicht, sie zieht um
Dass KI Entwickler:innen produktiver macht, hört man oft. Das greift zu kurz. Genauer ist: Der Aufwand verlässt eine Tätigkeit und taucht in drei anderen wieder auf.
Er wandert vom Schreiben ins Beschreiben. Eine unklare Anforderung führt jetzt schneller als je zuvor zu einer plausibel aussehenden falschen Lösung. Der Engpass sitzt nicht mehr an der Tastatur, sondern in der Frage, was eigentlich gebaut werden soll. Diese Klarheit entsteht im Gespräch mit der Fachabteilung.
Er wandert vom Schreiben ins Prüfen. Generierter Code sieht gut aus. Er ist sauber formatiert, sinnvoll benannt, ordentlich kommentiert. Auch dann, wenn er einen Denkfehler enthält. Genau das macht ihn heikler als schlechten menschlichen Code, dem man den Fehler ansieht. Review-Zeit ist keine Sparposition mehr, sondern die eigentliche Leistung.
Und er wandert ins Betreiben. Wo dreimal so viel Code entsteht, entsteht dreimal so viel, das gewartet und irgendwann wieder verstanden werden muss. Ein Prototyp, den keiner mehr durchdringt, ist eine Hypothek. Unabhängig davon, wer ihn geschrieben hat.
Verantwortung verschwindet dabei nirgends. Sie sitzt nur an einer Stelle, an der man sie schlechter delegieren kann.
Der Abschalttest
Der häufigste Architekturfehler in KI-Projekten hat nichts mit Modellen zu tun. Er sieht so aus: Unternehmenswissen wandert nach und nach in das KI-Werkzeug hinein. Produktdetails im Chatverlauf. Prozessregeln im Systemprompt. Ein Assistent, den jemand aus dem Vertrieb selbst zusammengeklickt hat und der inzwischen Dinge weiß, die sonst niemand aufgeschrieben hat.
Dafür gibt es einen einfachen Test. Frag dich, was passiert, wenn ihr das Werkzeug morgen abschaltet oder wechselt. Wenn dabei Wissen verloren geht, liegt es an der falschen Stelle.
Führende Daten gehören in die führenden Systeme: ins CRM, ins ERP, je nach Haus auch ins CMS oder in die Dokumentenablage. Dort haben sie eine Historie, ein Rechtekonzept und jemanden, der zuständig ist. Die KI liest daraus und schreibt Ergebnisse zurück, aber sie ist nie der Ort, an dem etwas zuerst entsteht.
Technisch heißt dieses Muster RAG, Retrieval-Augmented Generation. Die Frage geht zuerst an den eigenen Datenbestand, und erst die gefundenen Belege gehen zusammen mit der Frage an das Sprachmodell. Der praktische Gewinn ist nicht nur, dass die Antwort aktuell ist. Sie lässt sich auf eine Quelle zurückführen. Bei einer Auskunft an Kunden entscheidet genau das über brauchbar oder unbrauchbar.
Ein Modell gleicht keine schlechten Daten aus
Es formuliert sie nur eleganter.
Wenn dieselbe Kundin in drei Systemen anders heißt, wenn Produktattribute halb gepflegt sind, wenn niemand sagen kann, welches System bei Widersprüchen recht behält, dann liefert auch das beste Modell falsche Auskünfte. In vollständigen Sätzen und mit überzeugendem Ton, was die Sache nicht besser macht.
Deshalb beginnt ein KI-Projekt in der Praxis fast nie mit einem Modell, sondern mit einer unspektakulären Inventur: Welches System ist für welche Information die Quelle? Wer diese Frage beantwortet hat, hat den größten Teil der Vorarbeit hinter sich. Und profitiert davon auch dann, wenn am Ende gar keine KI zum Einsatz kommt.
Was in Angeboten meistens fehlt
Kalkuliert werden die Entwicklungskosten. Drei Posten stehen selten daneben.
Erstens die laufenden Modellkosten. Anders als bei klassischer Software kostet jede Nutzung Geld, weil jede Anfrage abgerechnet wird. Bei einem internen Assistenten mit überschaubarem Betrieb fällt das kaum auf. Steckt die Funktion dagegen in jedem Seitenaufruf eines Shops, wächst der Posten mit dem Erfolg. Beherrschbar ist das durchaus, über Zwischenspeichern, kleinere Modelle für einfache Aufgaben, harte Obergrenzen. Nur muss man es vorher rechnen und nicht nach der ersten Abrechnung.
Zweitens der Prüfaufwand. Jede Ausgabe, die nach außen geht oder eine Entscheidung auslöst, braucht einen definierten Umgang mit Fehlern. Entweder schaut ein Mensch drauf, oder das System begrenzt den Schaden selbst, indem es bei Unsicherheit nichts behauptet, sondern weiterreicht. Ein Assistent ohne diesen Mechanismus ist kein Produkt. Er ist ein Risiko mit Benutzeroberfläche.
Drittens die Angriffsfläche, und die hat zwei Seiten. Was in ein fremdes Modell fließt, verlässt das Haus. Die Frage nach Verarbeitungsort und Auftragsverarbeitung gehört an den Anfang und nicht in die Abnahme. Und sobald ein Modell fremde Inhalte liest, also E-Mails, hochgeladene Dokumente, Webseiten, können darin Anweisungen stecken, die es befolgt. Prompt Injection nennt sich das. Es ist kein Laborproblem, sondern der Grund, warum ein Assistent mit Schreibrechten auf produktive Systeme sehr eng abgesteckt gehört.
Die Pflicht, die schon gilt
Ein Punkt, der in der Diskussion um Werkzeuge und Modelle regelmäßig untergeht: Seit Februar 2025 verlangt Artikel 4 der KI-Verordnung von Unternehmen, die KI-Systeme einsetzen, nachweisbare KI-Kompetenz ihrer Mitarbeitenden.
Das betrifft mehr Betriebe, als die meisten vermuten. Es reicht, dass Beschäftigte KI-Werkzeuge im Arbeitskontext nutzen, dann gilt das Unternehmen als Betreiber. Ein vorgeschriebenes Curriculum gibt es nicht. Verlangt wird ein Kenntnisstand, der zum Einsatz passt: Wie arbeitet das Werkzeug, wo sind seine Grenzen, welche Daten dürfen hinein, woran erkennt man eine falsche Ausgabe.
Praktisch heißt das vor allem, mitzuschreiben. Wer wurde wann worauf geschult. Nicht weil sofort ein Bußgeld droht, sondern weil fehlende Schulung im Schadensfall als Organisationsverschulden gewertet werden kann.
Vieles davon ist gar kein KI-Problem
Eine Beobachtung, die selten jemand ausspricht: Ein guter Teil dessen, was als KI-Projekt angefragt wird, ist in Wahrheit ein Schnittstellenproblem.
Wenn Daten regelmäßig zwischen zwei Systemen wandern, Formate umgewandelt oder Freigaben weitergereicht werden, braucht das kein Sprachmodell. Es braucht eine Schnittstelle oder eine regelbasierte Automatisierung. Die ist berechenbar, nachvollziehbar, günstig im Betrieb, und sie überrascht niemanden.
Die sinnvolle Arbeitsteilung: Regeln übernehmen das Eindeutige, KI das Uneindeutige. Im Kundenservice sieht das so aus, dass die Anfrage regelbasiert eingelesen und zugeordnet wird, weil das eindeutig ist. Sie zusammenzufassen und einen Antwortvorschlag zu formulieren, ist es nicht, dafür ist die KI da. Freigegeben wird von einer Person, dokumentiert wird zurück im CRM. Jeder Schritt macht das, was er am besten kann.
Womit anfangen
Die schlechteste Ausgangsfrage lautet: Wo können wir KI einsetzen? Sie führt zuverlässig zu Lösungen, die sich hinterher ein Problem suchen.
Nützlicher ist eine Frage, die sich im Haus leicht beantworten lässt: Was tippt bei uns jemand regelmäßig von einem Bildschirm auf den anderen? Solche Stellen sind der beste Startpunkt, weil dort Aufwand, Fehlerquelle und Zuständigkeit schon bekannt sind. Danach kommt die Einordnung: Ist das ein Datenproblem, ein Schnittstellenproblem oder wirklich eines für KI?
Ein tragfähiger erster Anwendungsfall wiederholt sich oft genug, dass Automatisierung sich rechnet. Die nötigen Daten liegen bereits in einem System. Ein Fehler ist ärgerlich, aber nicht gefährlich. Und es gibt jemanden im Haus, der beurteilen kann, ob das Ergebnis stimmt. Fehlt eines davon, wird es ein schwieriges Projekt.
Klein anfangen ist richtig, aber messbar anfangen ist wichtiger. Was nach acht Wochen keinen Unterschied macht, macht ihn auch nach acht Monaten nicht.
Fazit
KI schreibt heute deutlich mehr Software, als vor zwei Jahren viele erwartet hätten, und deutlich weniger, als die Werbung nahelegt.
Lauffähige Prototypen in Stunden sind real und verändern die frühe Projektphase. Der Weg von dort in den Betrieb ist dadurch nicht kürzer geworden, eher aufwendiger, weil Beschreiben, Prüfen und Betreiben mehr Gewicht bekommen haben. Über den Nutzen entscheidet am Ende die Architektur: Wissen gehört in die führenden Systeme, nicht in das Werkzeug. Und keine Prompt-Optimierung ersetzt gepflegte Daten.
Was in die Kalkulation gehört und meistens fehlt: Betriebskosten, Prüfaufwand, Sicherheit. Was schon gilt, egal wie klein das Vorhaben ist: die Kompetenzpflicht aus der KI-Verordnung.
Wer auf das autonome Entwicklungsteam wartet, wartet auf die falsche Sache und übersieht dabei, was heute längst geht.
