GenAI jenseits von Anwendungscode – maßgeschneidertes Tooling und Analysen

Wenn von GenAI in der Softwareentwicklung die Rede ist, denken viele zuerst an die Erzeugung von Anwendungscode – und damit an Entwickler:innen als primäre Zielgruppe. Dabei liegt ein großer Mehrwert gerade dort, wo Fachseite und Technik aufeinandertreffen: bei der Beantwortung von Fragen, die fachliches Systemwissen voraussetzen, aber technische Mittel erfordern.

Als begleitendes Beispiel dient die Arbeit an einer Unternehmenswebseite. Eine Webseite ist nie fertig – neue Anforderungen kommen hinzu, Inhalte und Bausteine werden ausprobiert, aber selten aufgeräumt, und auch vermeintlich kleine Änderungen wie die Anpassung der Linkstruktur können im Content Management System (CMS) große Aufwände mit sich bringen. Die Fragen, die sich daraus ergeben, sind vielfältig:

• Wie bereitet man Inhalte auf neue Anforderungen vor – etwa die Optimierung für KI-gestützte Suchmaschinen (Generative Engine Optimization, kurz GEO), wenn sich das Feld gerade erst formiert?
• Wie verschafft man sich einen Überblick, welche der dutzenden CMS-Bausteine tatsächlich noch genutzt werden – und was aufgeräumt werden kann?
• Wie lassen sich hunderte oder tausende Inhalte systematisch anpassen, wenn sich die Struktur der Webseite ändert?

Was diese Fragen verbindet: Sie setzen fachliches Systemwissen voraus, erfordern aber technische Mittel für die Beantwortung – etwa Abfragen an die Programmierschnittstelle des CMS oder Skripte, die Inhalte systematisch auswerten. Eine Marketingabteilung, die die Inhalte verantwortet, hat dieses Wissen über das System und seine Inhalte – aber in der Regel keine Entwickler:innen im Team. Welche CMS-Bausteine werden auf welchen Seiten eingesetzt? Wie viele der konfigurierten Formulare sind tatsächlich in Verwendung? Solche Analysen, die für fundierte Entscheidungen nötig wären, bleiben daher oft liegen.

GenAI kann diesen Graben mit zweckgebundenem Tooling überbrücken: Fachabteilungen können sich maßgeschneiderte Skripte und Analysen für konkrete Herausforderungen erzeugen lassen – Werkzeuge, die nach erfülltem Zweck nicht weiter gepflegt werden müssen. Mein Kollege Goetz Markgraf hat kürzlich ein Fünf-Level-Modell der KI-gestützten Softwareentwicklung vorgestellt. Das Modell beschreibt Autonomiestufen, die sich über die Softwareentwicklung hinaus anwenden lassen – überall dort, wo GenAI schrittweise mehr Eigenständigkeit übernimmt. Im Folgenden zeigen wir anhand unserer Praxis, wie sich vier dieser Level konkret anfühlen – von der reinen Recherche bis zum agentengesteuerten Massenupdate von CMS-Inhalten.

Spoiler: GenAI liefert nicht nur Code, sondern Antworten – als Recherche-Assistent, als Analyse-Werkzeug und als Ausführungspartner für datengestützte Entscheidungen. Dieser Artikel durchläuft vier Autonomiestufen und zeigt, wie der Einsatz mit jeder Stufe an Tiefe gewinnt.

Vier Stufen – und was es dafür braucht

Das Fünf-Level-Modell meines Kollegen beschreibt eine Progression von reiner Wissensarbeit (Level 1) über gezielte Code-Optimierung (Level 2) und agentengestützte Analyse (Level 3) bis hin zur spezifikationsgetriebenen Massenbearbeitung (Level 4). Level 5 – vollautonome Systeme – ist noch weitgehend hypothetisch und wird hier bewusst ausgelassen. Es geht dabei nicht um Anwendungsentwicklung, sondern um Problemlösung. Das Ziel unseres Projekts ist, konkrete Herausforderungen rund um die eigenen Arbeitsfelder zu adressieren – von der Recherche über die Analyse und Quantifizierung bis zum maßgeschneiderten, zweckgebundenen Tooling. Der Einsatz von GenAI lässt sich in verschiedene Phasen unterteilen:

• Level 1 steht für sich – reines Verstehen eines neuen Themenfelds.
• Level 2 und 3 bewegen sich in der Analysephase – Quantifizieren, Überwachen, datengestützt entscheiden.
• Level 4 markiert den Übergang in die Umsetzungsphase – mit schreibendem Zugriff und produktiven Änderungen.

Die Analyse-Level (2 und 3) setzen dabei Fitness Functions um: automatisierte, datengestützte Auswertungen, die eine Quantifizierung des Systems erlauben. Damit lassen sich KPIs überwachen – besonders wertvoll, wenn sich das System weiterentwickelt oder grundlegend verändert.

Der Mensch bleibt über alle Level hinweg in der Rolle des/der Entscheider:in: Was soll recherchiert, analysiert oder verändert werden? Wie sind die Ergebnisse zu interpretieren? Welche Schlüsse lassen sich daraus ziehen? Ab Level 2 kommen technische Voraussetzungen hinzu, die bei der reinen Recherche (Level 1) noch keine Rolle spielen:

• Das Werkzeug: Damit GenAI nicht nur Code vorschlägt, sondern ihn auch direkt ausführen kann, wird ein Client mit sogenanntem Tool-Calling benötigt – etwa Claude Code, Opencode oder Gemini CLI. Neben den Terminal-basierten Clients kommen auch immer mehr Desktop-Apps wie bspw. Antigravity und Codex auf. Diese Clients können vom Modell generierte Befehle (z. B. Python-Skripte) eigenständig ausführen und die Ergebnisse zurückmelden. So entsteht ein iterativer Arbeitsfluss: generieren, ausführen, prüfen, anpassen.
• Die Arbeitsumgebung: Die Ausführung findet im Terminal statt. Der Agent nutzt Shell-Befehle wie curl, cat oder echo, um Dateien zu lesen, APIs abzufragen und Ergebnisse zu verarbeiten. Wer mit diesen Befehlen nicht vertraut ist, kann sich von GenAI erklären lassen, was ein Befehl tut – Level 1 hilft also auch beim Verständnis der höheren Level.
• Guter Kontext: Wichtig ist, der GenAI abhängig von der konkreten Aufgabe den Kontext zu liefern: eine präzise Problembeschreibung, die API-Dokumentation (bspw. das GraphQL-Schema) und idealerweise einen bestehenden Query als Ausgangspunkt.
• API-Zugriff per Token: Das CMS stellt Zugriffsschlüssel (sogenannte Access-Tokens mit spezifischen Berechtigungen) bereit, mit denen Anfragen Zugriff auf die Inhalte gewährt werden – lesend (Read-Token) oder auch schreibend (Write-Token). Bei den Analyse-Leveln reicht ein Read-Token; schreibender Zugriff kommt erst bei Level 4 ins Spiel und erfordert entsprechend eine höhere Absicherung und Kontrolle dessen, was die KI macht.

Die Beispiele stammen aus der Arbeit an der eigenen Unternehmenswebseite codecentric.de. Sie umfasst ca. 500 Inhaltsseiten in zwei Sprachen und Blogposts im vierstelligen Bereich. Die Seiten setzen sich aus über 50 Komponenten (auch Bausteine genannt) zusammen – wiederverwendbare Elemente wie Hero-Banner, Kontaktformulare oder Text-Bild-Abschnitte. Hinzu kommen dutzende Formulare mit komplexen Abhängigkeiten und ein Verlinkungsschema mit dynamischen Links, aber auch tausenden internen Links im Fließtext. Bei diesem Umfang lässt sich ohne systematische Analyse kaum beurteilen, was davon aktiv in Verwendung ist und für Optimierungen berücksichtigt werden sollte.

Level 1: Orientierung schaffen – Recherche zu einem neuen Thema

Vor der technischen Umsetzung steht das Verstehen. Mit dem Übergang zum KI-Zeitalter wird auch eine Webseite mit neuen Anforderungen konfrontiert und es stellt sich z. B. die Frage, wie Inhalte für KI-gestützte Suchmaschinen optimiert werden können – ein Feld, das sich unter dem Begriff Generative Engine Optimization (GEO) gerade erst formiert. Die konkreten Fragestellungen sind vielfältig: Wie unterscheidet sich GEO von klassischem SEO? Welche Maßnahmen sind für eine Unternehmenswebseite sinnvoll? Was ist llms.txt? Was sind Grounding Pages?

In Level 1 wird GenAI (ChatGPT, Claude, Gemini) als Recherche-Assistent genutzt – man stellt Fragen, lässt sich Konzepte erklären, vergleicht Ansätze. Der gesamte Kontext wird manuell per Copy-Paste oder Dokumenten-Upload bereitgestellt. Zusätzlich zum Prompt lässt sich bei den meisten GenAI-Anbietern die Deep Research Funktion aktivieren. Damit wird ein autonomer Prozess gestartet, der in einem iterativen Vorgehen Quellen sucht, liest, bewertet und erneut sucht. Am Ende wird ein umfassender Bericht zum Thema erstellt, zu dem sich weitere Fragestellungen innerhalb der Konversation stellen lassen.

Eine typische Anfrage sieht dabei so aus:

Ich administriere unsere Unternehmenswebseite https://codecentric.de – wir sind ein mittelständisches IT-Dienstleistungsunternehmen aus Deutschland.

Wir möchten evaluieren, welche Maßnahmen im Bereich Generative Engine Optimization (GEO) für unsere Webseite sinnvoll sind – also wie wir unsere Inhalte so aufbereiten, dass sie von KI-gestützten Suchmaschinen besser erfasst und referenziert werden.

Zwei konkrete Ansätze, die wir prüfen wollen:

• llms.txt (llmstxt.org) – ein Standard, um Webseiten maschinenlesbar zusammenzufassen
• Grounding Pages (groundingpage.com) – dedizierte Seiten, die als Referenzquelle für KI-Modelle dienen

Bewerte beide Ansätze für unseren Fall und zeige mir konkrete Inhalte für unsere Unternehmenswebseite.

Anschließend lassen sich gezielt weitere Fragen zu den Recherche-Ergebnissen stellen und die Inhalte über die verlinkten Quellen verifizieren.

Das Ergebnis ist ein detaillierter Bericht über ein Themenfeld mit Quellenangaben, der in Minuten statt in Tagen vorliegt. Auf diese Weise lässt sich schnell Wissen aneignen und Rückfragen zum eigenen Anwendungsfall diskutieren. Eine Überprüfung der wichtigsten Quellen gehört zur Pflicht im verantwortungsvollen Umgang mit KI-generierten Inhalten. Der Bericht kann als Grundlage für strategische Entscheidungen dienen, welche GEO-Maßnahmen umgesetzt werden sollen.

Level 2: Gezielt abfragen – Bestehende Queries optimieren lassen

Bei Level 2 geht es darum, gezielte Abfragen an das CMS zu senden, um die Nutzung von bestimmten Komponenten zu ermitteln. Optimalerweise hat man bereits einen funktionierenden GraphQL-Query für das CMS – im Beispiel wird ein Query genutzt, der die verwendeten Formulare findet, aber der Query wurde lange Zeit nicht verwendet. In der Zwischenzeit hat das cloudbasierte Headless-CMS einige Updates mitgemacht. Außerdem wurden neue Komponenten hinzugefügt, in denen das Formular enthalten sein kann. Statt den Query manuell zu überarbeiten, wird er der GenAI zusammen mit der API-Dokumentation übergeben, und diese optimiert ihn. Den optimierten Query vergleicht man zunächst mit dem ursprünglichen Query, um die Änderungen zu verstehen und zu bewerten. Anschließend kann der Query selbst und manuell ausgeführt werden. Programmierkenntnisse sind dafür nicht nötig – CMS-Kenntnis und ein vorhandener eigener Query reichen aus. Wer das System kennt und weiß, welche Frage beantwortet werden soll, kann GenAI für seine Aufgaben nutzen.

Die Anfrage an GenAI

Die folgende Anfrage illustriert, wie wenig Aufwand nötig ist, um einen verbesserten Query zu erhalten. GenAI erhält eine Problembeschreibung, einen Verweis auf die API-Dokumentation und einen Query als Ausgangspunkt:

Ich muss herausfinden, wo in unserem CMS Content vom Typ "Form" verwendet wird. Im Backend sehe ich 62 Elemente. Vermutlich sind sie überwiegend in Buttons konfiguriert.

Die Dokumentation der API findet sich hier: [Link zur API-Dokumentation]

Hier ist ein Query, den wir zuvor verwendet haben, um genutzte Formulare zu finden – er ist möglicherweise nicht aktuell und prüft nicht alle Stellen:

1{
2  pages(first: 1000, stage: PUBLISHED) {
3    title
4    sections {
5      ... on ContentInSection {
6        button {
7          form {
8            title
9          }
10          url
11        }
12      }
13    }
14  }
15}

Aus dieser Anfrage generiert GenAI einen optimierten GraphQL-Query, der alle relevanten Sektionstypen berücksichtigt und die Formular-Nutzung vollständig abbildet. Was manuell Stunden an Query-Bastelei und Ausprobieren im API-Explorer erfordert hätte, ist so in wenigen Minuten einsatzbereit. Der Query kann anschließend selbst ausgeführt werden.

Das Ergebnis ist eine wiederholbare, datengestützte Auswertung – eine Fitness Function, die misst, wie viele der definierten Formulare tatsächlich genutzt werden. Dieser KPI hilft, ungenutzte Inhalte zu identifizieren und gezielt zu reduzieren. Es kann sein, dass der erzeugte Query nicht auf Anhieb funktioniert. Doch dann hilft der iterative Einsatz von GenAI, um den Query erneut anzupassen, indem eine Fehlermeldung oder Änderungswünsche als neuer Input zum bestehenden Prompt eingebracht wird.

Level 3: Eigenständig analysieren – Der Agent erkundet das CMS

Im vorherigen Beispiel wird ein konkreter Query als Ausgangspunkt verwendet. Bei Level 3 wird nur noch das Informationsbedürfnis beschrieben – den Rest erledigt der Agent. Die Eingabe erfolgt in natürlicher Sprache, z. B.: "Ich möchte wissen, welche Komponenten auf welchen Seiten genutzt werden", und der Agent arbeitet die nötigen Schritte selbständig ab. Programmierkenntnisse sind nicht zwingend nötig, aber wer dieses Level nutzt, sollte mit dem System vertraut sein und nachvollziehen können, was der Agent ausführt – welche Queries er stellt, ob die Ergebnisse plausibel sind. Wer das CMS kennt und die Ein- und Ausgaben einordnen kann, kann dieses Level eigenständig nutzen.

Die Verwendung einer Skriptsprache wie Python ist nicht zwingend erforderlich, erleichtert aber gerade im Zusammenspiel mit GraphQL die Arbeit. Alternativ kann mit vorinstallierten Programmen des Betriebssystems wie curl gearbeitet werden, falls keine Skriptsprache wie Python installiert ist. Die Agenten kennen die Systemprogramme und wissen, wie diese zu verwenden sind.

Die Anfrage an GenAI

Der Unterschied zu Level 2 zeigt sich bereits in der Anfrage: Das Ziel wird vorgegeben und auf die Introspection als Einstiegspunkt verwiesen – den Weg dorthin erarbeitet der Agent eigenständig:

Ich möchte wissen, welche der CMS-Komponenten auf welchen Seiten tatsächlich genutzt werden – als Grundlage für die Entscheidung, welche Komponenten weiterhin gepflegt werden müssen.

Ermittle zunächst über die GraphQL-Introspection [Link zur Introspection-Dokumentation] alle verfügbaren Sektionstypen im Schema. Frage anschließend für jeden Typ ab, auf welchen Seiten er eingesetzt wird – in beiden Sprachversionen und unter Berücksichtigung der Paginierung.

Das Read-Token für die API liegt in der Datei .env im aktuellen Verzeichnis. Im Repository findest du außerdem bestehenden Python-Code, der zeigt, wie die API angesprochen wird.

Exportiere das Ergebnis als CSV mit den Spalten: component_type, page_slug, language, usage_count. Komponenten ohne Nutzung sollen mit usage_count = 0 und leerem page_slug aufgeführt werden.

GraphQL-APIs bieten eine eingebaute Selbstauskunft – die sogenannte Schema-Introspection: Die API kann nach ihrem eigenen Schema gefragt werden, also welche Datentypen, Felder und Beziehungen sie kennt. Das ist der entscheidende Unterschied zum vorherigen Beispiel: Die Struktur muss nicht vorab bekannt sein, der Agent übernimmt die Erkundung.

Als Ergebnis liefert der Agent nicht nur die Rohdaten, sondern bereitet sie auch auf – etwa als Übersicht, wie viele Komponenten insgesamt definiert sind, wie viele davon tatsächlich auf Seiten eingebunden sind und welche ungenutzt bleiben. Sofort ist erkennbar, wo Handlungsbedarf besteht. Der gleiche Ansatz lässt sich auf Formulare übertragen: Von den definierten Formularen wird nur rund zwei Drittel tatsächlich genutzt. Ohne Analyse würde der ungenutzte Rest weiter mitgepflegt. Auch hier entstehen Fitness Functions – aber mit höherem Automatisierungsgrad. Der Agent kann eigenständig neue Auswertungen erstellen, wenn sich die Fragestellung ändert oder die Anwender:innen am System gearbeitet haben. Das Informationsbedürfnis wird beschrieben, der Agent liefert die Kennzahl. So lassen sich KPIs laufend überwachen. Die Auswirkung: Der Aufwand wird datengetrieben eingegrenzt, anstatt auf Vermutungen zu basieren.

Level 4: Kontrolliert verändern – Tausende Inhalte systematisch anpassen

Kommen wir nun zu einem komplexeren Beispiel: Zur SEO-Optimierung sollen die Blogposts von der bisherigen Subdomain mit dem Pfadschema /jahr/monat/slug auf die Hauptdomain unter /blog/slug umziehen. Im Fließtext der Blogposts sind jedoch harte Links zu weiteren Blogposts enthalten, sei es als Referenz oder nächster Teil einer Serie. Diese müssen im Fließtext systematisch aktualisiert werden, damit durch die Umstellung keine kaputten Links entstehen.

Ein modernes CMS kennt die Relationen zwischen Inhalten: Referenziert ein Button eine andere Seite, bleibt der Link auch beim Verschieben des Ziels intakt. Die Blogpost-Inhalte in unserem Beispiel sind jedoch als Markdown bzw. Rich Text gespeichert – das gibt Autor:innen mehr Freiheiten und erfordert keine CMS-spezifischen Kenntnisse, bedeutet aber auch: Links im Fließtext sind für das CMS bloßer Text, keine verwalteten Referenzen. Der gesamte Inhalt eines Blogposts ist für das CMS nur ein Datenfeld mit längerem Inhalt. Die Aktualisierung muss deshalb manuell innerhalb dieses Inhalts erfolgen.

Regular Expressions (textbasierte Suchmuster, vergleichbar mit einer erweiterten Suchen-und-Ersetzen-Funktion) scheinen die naheliegende Lösung – doch die Vielfalt der Link-Varianten macht eine naive Umsetzung fehleranfällig:

• Links existieren als http und https, mit und ohne Sprachpräfix (/en/), mit und ohne Trailing Slash (/slug/).
• Suchlinks verwenden abweichende Parameter (?s= statt ?q=).
• Manche URLs enthalten Tracking-Parameter, die entfernt werden müssen.
• Gleichzeitig dürfen bestimmte URLs nicht umgeschrieben werden: Links zu Content-Seiten oder Autorenprofilen.
• Der Content ist Markdown mit eingebettetem HTML – Code-Blöcke und externe Links dürfen nicht verändert werden.
• UTF-8 und Umlaute in Slug-Pfaden sorgen für zusätzliche Edge Cases.

Die Anfrage an GenAI

Anders als bei den vorherigen Beispielen ist dieser Prompt nur der Beginn einer längeren Konversation. Im Verlauf werden die Transformationsregeln weiter spezifiziert – etwa welche URL-Varianten erkannt werden müssen, welche Ausnahmen gelten und wie Edge Cases behandelt werden. Jede Antwort der GenAI liefert neuen Code oder Tests, die geprüft, korrigiert und erweitert werden. So entsteht die Spezifikation nicht vorab auf dem Papier, sondern im Dialog mit der KI auf Basis des jeweils generierten Codes:

Zur SEO-Optimierung ziehen unsere Blogposts von https://blog.beispiel-unternehmen.de/2024/05/mein-slug auf https://www.beispiel-unternehmen.de/blog/mein-slug um. Interne Verlinkungen in den Blogpost-Inhalten auf andere Blogposts verweisen noch auf das alte Schema und müssen aktualisiert werden.

Schreibe ein Python-Skript, das den Content aller Blogposts über die GraphQL-API abruft, interne Links im Markdown-Fließtext erkennt und auf das neue Schema transformiert. Im Repository findest du bestehenden Python-Code für die API-Anbindung und die .env mit dem Read-Token.

Beginne mit einem ersten Entwurf der Transformationsregeln und einer Testdatei mit Beispiel-URLs. Wir werden die Spezifikation anschließend gemeinsam iterativ erweitern.

GenAI generiert auf dieser Grundlage ein Regex-basiertes Python-Skript, das die verschiedenen URL-Muster erkennt und korrekt transformiert. Entscheidend ist dabei der spezifikationsgetriebene Ansatz: Extensive Spezifikationen definieren die Transformationsregeln, Edge Cases werden als Test-Spezifikation erfasst, Tests laufen gegen die echte API (Read-Token zum Testen, Write-Token für Produktion) und der generierte Code durchläuft ein Review vor dem schreibenden Zugriff. Gerade bei Massenoperationen auf produktivem Content sind die Ausnahmefälle entscheidend. Ein eigens erstellter Test-Blogpost bündelt alle bekannten Edge Cases und kann wiederholt vom Skript verarbeitet werden, um Korrektheit sicherzustellen. Parametrisierte Tests prüfen systematisch jede URL-Variante: Was soll transformiert werden, was muss unverändert bleiben.

Schreibender Zugriff auf produktiven Content erfordert die Begleitung durch Software-Entwickler:innen – sowohl um den generierten Code zu verstehen als auch um die richtige Vorgehensweise sicherzustellen: Testabdeckung, Code-Review, kontrollierte Ausführung, um nur ein paar Kriterien zu nennen. Die Auswirkungen, falls die automatisierten Änderungen nicht dem gewünschten Ergebnis entsprechen, können fatal sein. Von hunderten von kaputten Links über unvollständige Linktexte und "�"-Sonderzeichen statt Umlauten bis hin zu abgeschnittenen Inhalten ist vieles möglich. Der interne wie externe Reputationsverlust ist gewiss, während das Einspielen des Backups aus dem letzten Monat auch die Arbeit und Änderungen von den Teamkolleg:innen zurücksetzt. Erfahrene Entwickler:innen wissen, dass die automatisierte Bearbeitung von mehreren Tausend Blogposts für zusätzliche Serverlast sorgt, und erweitern das Skript um eine Batch-Funktion. Damit können zuerst kleine Mengen verprobt werden, die händisch geprüft werden, bevor größere Batches abgearbeitet werden.

Das Ergebnis ist ein Skript, das zuverlässig mehrere tausend Blogposts korrigieren kann – automatisiert, reproduzierbar, testbar. Habe ich vor der ersten produktiven Ausführung trotzdem Bedenken, dass etwas schiefläuft? Ja – und als Mensch gehe ich meine Checkliste im Kopf noch einmal durch und fange mit kleinen Batches an, während der stets positiv gestimmte AI Agent nach jeder Iteration behauptet, dass das Skript nun fertig sei und sofort für alle Blogposts ausführen möchte.

Erfolgsfaktoren – Was wir gelernt haben

Guter Kontext ist entscheidend. Je besser die bereitgestellte API-Dokumentation und die Beispiele, desto brauchbarer das Ergebnis. Ein funktionierender Query als Ausgangspunkt macht einen Unterschied.

Iteratives Vorgehen zahlt sich aus. Der erste Wurf der GenAI ist selten perfekt – aber Korrekturen und Erweiterungen gehen schnell, da auf dem bereits Generierten aufgebaut wird. Mit jedem Prompt wird die Analyse schrittweise verfeinert. Zu beachten ist aber auch, dass die Ergebnisse je nach GenAI-Modell und Version unterschiedlich ausfallen können. Nachsteuern innerhalb der Konversation ist daher i. d. R. nötig und Teil des normalen Arbeitsablaufs.

Testen ist unverzichtbar. Gerade bei Massenoperationen auf produktivem Content sollten Edge Cases systematisch gesammelt und als Testdaten gepflegt werden. Ein dedizierter Test-Datensatz mit bekannten Sonderfällen spart auf Dauer erheblich Zeit.

Zweckgebundenes Tooling ist völlig in Ordnung. Die Skripte müssen nicht produktionsreif sein. Sie dienen einem konkreten, zeitlich begrenzten Zweck – und genau dafür ist GenAI als Beschleuniger ideal.

Der Mensch steuert, die KI beschleunigt. Domänenwissen über das System, seine Geschichte und seine Eigenheiten bleibt beim Menschen. GenAI liefert die Umsetzungsgeschwindigkeit, nicht die inhaltliche Strategie. Die Intensität der menschlichen Steuerung ändert sich dabei über die Level: Bei Level 1 wird jeder Schritt gelenkt, bei Level 4 wird das Ziel vorgegeben und geprüft, was der Agent daraus macht – doch die Entscheidungshoheit bleibt. Damit einher geht: Je mehr Eigenständigkeit GenAI eingeräumt wird, desto wichtiger werden Absicherung und Prüfung. Bei einem rein lesenden Zugriff ist das Risiko geringer. Bei schreibendem Zugriff auf produktiven Content sind umfangreiche Tests, Code-Review und kontrollierte Ausführung unverzichtbar – ein Leitgedanke, den auch der eingangs erwähnte Kollege in seinem Blogpost betont.

Die Stufen bauen aufeinander auf. Niemand startet ohne Vorkenntnisse direkt auf Level 3. Die Level bilden eine Lernkurve: Wer auf Level 2 oder 3 an Verständnisgrenzen stößt – etwa bei einem Shell-Befehl oder einer API-Antwort –, kann jederzeit auf Level 1 zurückgreifen und sich von GenAI erklären lassen, was gerade passiert. So wächst das eigene Verständnis mit jeder Stufe. Gleichzeitig gilt: Nicht jedes Problem erfordert das höchste Level. Wer nur eine Frage klären will, braucht keinen Agenten – eine gezielte Recherche auf Level 1 reicht. Die richtige Stufe ergibt sich aus dem konkreten Bedürfnis, nicht aus den technischen Möglichkeiten.

Das Knowledge Gap schließen. Wer das System kennt, kann mit GenAI für die Analyse eigenständig Antworten einholen – ohne auf Engineering-Kapazität warten zu müssen. Wer Agenten selbsttätig agieren lässt, sollte aber immer verstehen, was diese ausführen; ab einem gewissen Punkt ist die Begleitung durch Entwickler:innen essenziell. Aber auch dann verändert sich die Zusammenarbeit: Die Fachseite muss ihr Anliegen nicht mehr in technische Anforderungen übersetzen, sondern kann es in der eigenen Sprache formulieren – GenAI übernimmt die Übersetzung ins Technische.

Analysephase vor Umsetzungsphase. Fitness Functions liefern die Datengrundlage für fundierte Entscheidungen. Erst wenn die Analyse steht – wenn klar ist, welche Komponenten genutzt werden, welche Formulare verwaist sind, welche Abhängigkeiten bestehen – folgt die Umsetzung.

Fazit – GenAI als Brücke zwischen Fachseite und Technik

Die vier Beispiele zeigen: GenAI entfaltet seinen Mehrwert nicht erst beim Schreiben von Anwendungscode. Schon bei der Recherche, der Analyse und der datengestützten Entscheidungsfindung schafft es greifbaren Nutzen. Das verändert die Zusammenarbeit zwischen Fachseite und Engineering. Mit abgestufter Eigenständigkeit je nach Level können Fachexpert:innen zunehmend eigene Antworten einholen – und auch dort, wo die Begleitung durch Entwickler:innen nötig bleibt, verändert sich das Gespräch: weg von technischen Detailfragen, hin zur fachlichen Zielbeschreibung.

Für die Fachseite bedeutet das konkret: Statt auf Engineering-Kapazität zu warten – die in vielen Fachabteilungen schlicht nicht vorhanden ist –, lässt sich ein Großteil der Analyse eigenständig durchführen. Der Engpass verschiebt sich von der technischen Umsetzung zur Befähigung im Umgang mit GenAI. Und diese Befähigung ist deutlich leichter zu beschaffen als dedizierte Engineering-Ressourcen.

Wer tiefer einsteigen möchte: In unserem Webinar zu KI-gestützter Software-Modernisierung zeigen wir anhand eines weiteren Praxisbeispiels, wie GenAI bei der Modernisierung unterstützt. Wer herausfinden möchte, wie sich der eigene Fachbereich mit GenAI befähigen lässt, findet in unserem Workshop zu Generative-KI-Use-Cases einen strukturierten Einstieg.

Für welche Herausforderungen habt ihr euch schon mal ein Tool generieren lassen? Teilt eure Erfahrungen – wir sind gespannt.