Vivid: "Sobald man Leuten ein Budget gibt, geben sie es aus."

. Traditionelle Banken testen gerade Copilot oder verzweifeln bei dem Aufbau eigener Modelle. Die Berliner Neobank ist im siebten Jahr, und Ka I ist dort kein Pilotprojekt mehr, sondern Alltagswerkzeug für Entwickler, Finance, Compliance und Kundenservice. Wir wollten wissen: Woran misst man Erfolg mit KI? Was baut man selbst, was kauft man? Und würde man den Stack heute noch einmal so bauen? Ein Gespräch mit Vivid Mitgründer Alexander Emeshev über KPIs für Ka I Agenten, Tool Zoos und die Frage, warum man mit dem teuersten Modell anfängt und mit dem billigsten aufhört. von Dirk Emminger.. Alexander, bevor wir über Ka I reden: Wie landet man dabei, Technologie für eine regulierte Bank zu bauen?. Mein ganzes Berufsleben war ich im Finance Umfeld. Mein Master war in Tech, ich habe in der Ai Tieh einer Bank angefangen. Das war damals der normale Karriere Weg.Seit gut 20 Jahren arbeite ich in Banken, und ich hatte immer das Glück, in Häusern zu sein, die extrem schnell gewachsen sind. Das prägt, wie man Prozesse baut und wie man sich selbst entwickelt.“Ich bin von Tech ins Projektmanagement gewechselt, dann ins Bisnäss Development. Heute würde ich mich nicht mehr als guten Entwickler bezeichnen. Mit Claude Code und Cursor bekommt man trotzdem einiges hin. Aber mein Wissen über klassische Ai Tieh ist deutlich niedriger als vor 20 Jahren. Welche Häuser waren das?. Angefangen habe ich bei Russian Standard Bank. Den Wodka kennt jeder aus der Bar, die Bank kaum jemand. Damals war das der Pionier für Consumer Finance in Russland. Dann Kaspi in Kasachstan, heute börsennotiert. Wir haben eine kleine Bank, die ein Private Equity Investor gekauft hatte, komplett neu aufgebaut. Zuerst zur führenden Konsumentenbank, dann das ganze E Commerce- und Payment Ökosystem drumherum.Heute ist Kaspi das größte Unternehmen des Landes, nicht nur die größte Bank. Rund 16 Millionen monatlich aktive Kunden. Seit knapp sieben Jahren bin ich in Deutschland.“Alle reden davon, dass Ka I Entwickler produktiver macht. Gibt es bei Vivid KPIs, an denen ihr das festmacht?. Viele, und sie unterscheiden sich je nach Team. Nehmen wir die operativen Bereiche: Operations, Compliance Operations, Customer Care. Dort ist die Frage: Wie gut ist der Agent, der Kundenanfragen beantwortet oder Compliance Alerts bearbeitet? Man schaut auf drei Dinge. Erstens die Deflection Rate, also wie viele Fälle der Agent überhaupt übernimmt.Zweitens: Wie viele davon erledigt er, ohne an einen Menschen zu übergeben?Drittens die Qualität. Da prüfen Menschen Stichproben und sagen ob das gut oder schlecht war. Daraus ergeben sich Quoten, die man direkt mit Menschen vergleichen kann.Wenn die menschliche Qualitätssicherung in einem Prozess bei über 90 Prozent liegt, sage ich: Der Agent darf automatisieren, wenn er über 90 Prozent kommt.In der Kundenbetreuung ist es dasselbe Prinzip, nur mit Sternen. Nach dem Kontakt fragen wir, ob der Kunde zufrieden war. Ist der Score besser als beim Menschen oder nicht?. Und für Entwicklung und Produkt?Früher haben wir die Ka I Adoptionsrate gemessen: Wer nutzt die Tools überhaupt? Das ist heute sinnlos, weil alle sie nutzen.“Wir schauen jetzt auf den Anteil der Merge Requests (Anm. d. Red.: Ein Merge Request ist die Einheit, die am Ende in Produktion geht), die von Nicht Technikern kommen. Ich zähle mich selbst dazu. Die Frage ist, ob sich der Anteil in die richtige Richtung bewegt, ob also immer mehr Leute ihre Features und Tools selbst bauen, ohne einen Entwickler zu brauchen. Jeder Merge Request wird reviewt, zu hundert Prozent von Menschen. Aber ob man nur reviewt oder den ganzen Code selbst schreibt, ist ein Unterschied. Das führt direkt zum Vivid Ai Tieh Stack. Was besitzt ihr wirklich, was kommt von Standardanbieter? . Ich würde trennen: auf der einen Seite die generischen LLMs und die Werkzeuge darum herum, auf der anderen Spezialtools für bestimmte Zwecke. Bei den generischen probieren wir alles aus. Was funktioniert, ist das Beste. Für Entwickler und Leute wie mich sind das Claude Code beziehungsweise Cowork, Cursor und OpenAI ChatGPT mit Codex. Zwischen den dreien bewegen sich die Mitarbeiter ständig.Als wir uns im Februar oder März in Frankfurt getroffen haben, war die Mehrheit auf Cursor. Danach haben wir alle auf Claude umgestellt. Jetzt schiebe ich die Leute wieder zurück zu Cursor. Das pendelt.“Und das sind nicht nur Produktentwickler. Compliance, Finance, buchstäblich jeder arbeitet hier täglich mit wechselnden Tools. Und die Modelle dahinter?. . Über API nutzen wir alle. OpenAI, Anthropic, dazu testen wir intern Open Source Modelle in unserer eigenen Umgebung. Wir wechseln zwischen ihnen. Warum alle? Weil die Entwicklung so schnell ist. Sobald ein neues Modell da ist, springen wir drauf und testen es: für Architekturdesign, für Analytics, für Produktentwicklung. Was funktioniert, setzen wir ein. Operative Agenten laufen bei uns auf OpenCode, auch dort mit den Modellen der großen Anbieter. Irgendwelche Spezialtools?. Da haben wir aufgehört zu kontrollieren. Wenn du im Customer Care arbeitest, kaufst du die Tools, die du brauchst. Der Kollege, der SEO und GEO verantwortet, hat mir gestern erzählt, was er gebaut hat und welche Tools er dafür abonniert hat. Ich kenne die Hälfte nicht. Irgendwas für Bildgenerierung, irgendwelche Checks. Das ist sein Job. Ich habe aufgehört, darauf zu achten, als mir klar wurde, dass sich die Qualität dieser Tools ständig ändert. Genau wie bei den Modellen. Ich habe ein Tool getestet, für uns hat es nicht gepasst, die Empfehlungen waren daneben. Wir haben zwei andere probiert. Einen Monat später war das erste plötzlich gut. So läuft das andauernd. Deshalb legen wir das in die Hände der Experten im jeweiligen Bereich. Sie testen, und was für sie funktioniert, nutzen sie. In den meisten Banken darf die Marketingabteilung kein Bildmodell kaufen, ohne dass es durch die Ai Tieh geht. Wie ist das bei euch geregelt? Bekommen die Leute ein Budget?. Nein. Ich gebe Leuten grundsätzlich kein Budget, auch nicht im Marketing, unserem größten Kostenblock. Sobald man Leuten ein Budget gibt, geben sie es aus. Das ist ein großer Fehler. Wenn jemand Budget sagt, sage ich: Nein, das ist Spend. Wir arbeiten mit einem Zero Budget Konzept. Das heißt: Ja, so viel erwarten wir auszugeben. Wenn du weniger brauchst, gut. Wenn du mehr brauchst, auch gut. Aber du bist verantwortlich und musst erklären können, warum du diese Person eingestellt oder dieses Tool genommen hast. Bei größeren Summen gibt es Kontrollen im Finance Team, die fragen: Seid ihr sicher? Aber bei 100 oder 200 Euro im Monat kostet der Antrag mehr als kaufen, testen und entscheiden, ob man es behält. Also gar keine Prüfung?Doch, aber nicht wegen der Summe, sondern wegen der Regulierung.“Für generisches Tooling wie Cursor gehen wir den ganzen Zyklus: Rechenzentren in Europa, Zero Data Rie Tenn-Schn, also verarbeiten, aber nicht speichern, alles, was Gesetz und Aufsicht verlangen. Bei einem Marketingtool, das Keywords anschaut? Wozu. Zurück zur Ausgangsfrage: Baut ihr einen eigenen Ka I Stack?. Kommt drauf an, was man darunter versteht. Im Sinne von eigenen Modellen.. Nein, das Rad erfinden wir nicht neu, da stecken wir ein LLM rein. Das heisst ihr baut den Harness? [die Umgebung um das Modell herum; Anm. d. Red.]. Den ja, und der ist das eigentlich Entscheidende. Ein Beispiel: Wir brauchen einen Agenten für Enhanced Diu Dilligence, also die vertiefte Prüfung bei einem Kunden mit erhöhtem Risiko. Dafür bauen wir einen Harness, also alles um das Modell herum, vom Datenzugriff bis zur Testschleife. Der erlaubt uns einen schnellen Zyklus: Instruktionen an den Agenten geben, laufen lassen, backtesten, auswerten, mit Menschen im Loop, Instruktionen anpassen, wieder hochladen, von vorn. Wie läuft das konkret?. Man startet mit dem teuren Modell. Heute Opus 5, davor 4.8, davor 4.7. Erste Ergebnisse sind meist so lala. Man schaut in die Testergebnisse, schärft die Instruktionen, lässt es wieder laufen, bis man sagt: Das gefällt uns. Und je schneller man dahin kommt, desto günstiger. Denn bis dahin zahlt man doppelt: die Gehälter der Leute, die den Prozess noch manuell machen, und die der Tech- und Produktleute, die den Agenten bauen. Wenn es drei Monate dauert, dauert es drei Monate. Dann geht der Agent in Produktion, wenn nötig nach internen Freigaben. Und dann drückt man die Kosten. Es läuft mit Opus 5, aber geht es auch mit Sonnet? Vielleicht ohne Reasoning?. Und Fable, das aktuelle Spitzenmodell?. Können wir nicht nehmen. Es hat europäische Rechenzentren, aber keine Zero Data Rie Tenn-Schn. Gut für Entwicklung, nicht für Kundendaten. Für Kundendaten reicht Opus 5 vollkommen. Manche dieser Prozesse liegen in Bereichen, in denen die Aufsicht genau hinschaut. Wie geht ihr damit um?Entscheidend ist Governance. Man muss zeigen können, dass die Verfahren nachhaltig und wiederholbar sind, dass man sie erneut durchlaufen kann und dieselben Metriken bekommt.“Noch besser ist ein externer Prüfer, der die Ergebnisse unabhängig verifiziert und bestätigt. Das braucht man in Bereichen, in denen der Regulator sensibel ist. In vielen anderen sagt er: Das ist eure Sache. Vivid ist im siebten Jahr. Wenn du den Stack heute, mit dem Stand von 2026, noch einmal bauen müsstest: von vorn?Gute Frage. Wer morgen anfängt, muss Ka I first entwickeln, das ist der Default. Selbst die Senior Entwickler coden nicht mehr allein.“Sie zerlegen die Aufgabe, entwerfen die Architektur zusammen mit dem Modell und entscheiden: Das mache ich selbst, das lasse ich generieren. Und sie haben mehrere Agenten parallel laufen, eine kleine Armee. Wer das nicht macht, ist zehn- oder hundertmal langsamer als alle anderen. So würden wir es machen, wenn wir morgen anfingen. Aber?. Aber ich sehe keinen Wert darin, bei null zu starten. Gestern saß ich mit Entwicklern im Raum nebenan, Thema: Wir haben zu viel Spaghetti gebaut, technische Schulden, das muss aufgeräumt werden. Einige unserer Leute sind schon dran.Meine Erwartung ist, dass wir bald wissen, wie man Refactoring weitgehend automatisiert.“Die Idee: Man hat eine gute Wissensbasis aller Anforderungen, die man für dieses System je gebaut hat. Anforderungen sind heute sauber dokumentiert, weil Claude sie schreibt. Man hat den ganzen Code in GitHub oder GitLab.Dann lässt man einen Agenten laufen und sagt: Räum auf. Das will ich erreichen, das sind die Anforderungen, das Legacy kannst du löschen.“Wie weit seid ihr?. Mittendrin. Ich wäre nicht überrascht, wenn wir in Teilen unserer Systeme bald genauso vorgehen. Aber man muss das sehr vorsichtig angehen. Und nein, vollautomatisch läuft das nicht. Es braucht immer den Menschen, der draufschaut, der entscheidet, was bleibt und was weg kann. Was sich geändert hat, ist der Aufwand. Refactoring war früher das, wovor sich jeder gedrückt hat. Heute ist es deutlich weniger schmerzhaft und deutlich schneller. Das ist der Punkt, an dem wir stehen. Alexander, danke für das Gespräch.Sie hörten einen Beitrag von „Dirk Emminger“

Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/249405

Vivid-Mitgründer Alexander Emeshev steht lächelnd vor einem beleuchteten Vivid-Schild. Die Umgebung ist modern gestaltet, was die Innovationskraft der Berliner Neobank unterstreicht. KI wird hier als integraler Bestandteil des Arbeitsalltags betrachtet. — Vivid-Mitgründer Alexander EmeshevVivid

Traditionelle Banken testen gerade Copilot oder verzweifeln bei dem Aufbau eigener Modelle. Die Berliner Neobank ist im siebten Jahr, und KI ist dort kein Pilotprojekt mehr, sondern Alltagswerkzeug für Entwickler, Finance, Compliance und Kundenservice. Wir wollten wissen: Woran misst man Erfolg mit KI? Was baut man selbst, was kauft man? Und würde man den Stack heute noch einmal so bauen? Ein Gespräch mit Vivid-Mitgründer Alexander Emeshev über KPIs für KI-Agenten, Tool Zoos und die Frage, warum man mit dem teuersten Modell anfängt und mit dem billigsten aufhört.

von Dirk Emminger

Alexander, bevor wir über KI reden: Wie landet man dabei, Technologie für eine regulierte Bank zu bauen?

Mein ganzes Berufsleben war ich im Finance Umfeld. Mein Master war in Tech, ich habe in der IT einer Bank angefangen. Das war damals der normale Karriere-Weg.

Seit gut 20 Jahren arbeite ich in Banken, und ich hatte immer das Glück, in Häusern zu sein, die extrem schnell gewachsen sind. Das prägt, wie man Prozesse baut und wie man sich selbst entwickelt.“

Ich bin von Tech ins Projektmanagement gewechselt, dann ins Business Development. Heute würde ich mich nicht mehr als guten Entwickler bezeichnen. Mit Claude Code und Cursor bekommt man trotzdem einiges hin. Aber mein Wissen über klassische IT ist deutlich niedriger als vor 20 Jahren.

Welche Häuser waren das?

Angefangen habe ich bei Russian Standard Bank. Den Wodka kennt jeder aus der Bar, die Bank kaum jemand. Damals war das der Pionier für Consumer Finance in Russland. Dann Kaspi in Kasachstan, heute börsennotiert. Wir haben eine kleine Bank, die ein Private-Equity-Investor gekauft hatte, komplett neu aufgebaut. Zuerst zur führenden Konsumentenbank, dann das ganze E-Commerce- und Payment-Ökosystem drumherum.

Heute ist Kaspi das größte Unternehmen des Landes, nicht nur die größte Bank. Rund 16 Millionen monatlich aktive Kunden. Seit knapp sieben Jahren bin ich in Deutschland.“

Alle reden davon, dass KI Entwickler produktiver macht. Gibt es bei Vivid KPIs, an denen ihr das festmacht?

Viele, und sie unterscheiden sich je nach Team. Nehmen wir die operativen Bereiche: Operations, Compliance Operations, Customer Care. Dort ist die Frage: Wie gut ist der Agent, der Kundenanfragen beantwortet oder Compliance-Alerts bearbeitet? Man schaut auf drei Dinge.

Erstens die Deflection Rate, also wie viele Fälle der Agent überhaupt übernimmt.
Zweitens: Wie viele davon erledigt er, ohne an einen Menschen zu übergeben?
Drittens die Qualität. Da prüfen Menschen Stichproben und sagen ob das gut oder schlecht war.

Daraus ergeben sich Quoten, die man direkt mit Menschen vergleichen kann.

Wenn die menschliche Qualitätssicherung in einem Prozess bei über 90 Prozent liegt, sage ich: Der Agent darf automatisieren, wenn er über 90 Prozent kommt.

In der Kundenbetreuung ist es dasselbe Prinzip, nur mit Sternen. Nach dem Kontakt fragen wir, ob der Kunde zufrieden war. Ist der Score besser als beim Menschen oder nicht?

Und für Entwicklung und Produkt?

Früher haben wir die KI-Adoptionsrate gemessen: Wer nutzt die Tools überhaupt? Das ist heute sinnlos, weil alle sie nutzen.“

Wir schauen jetzt auf den Anteil der Merge Requests (Anm. d. Red.: Ein Merge Request ist die Einheit, die am Ende in Produktion geht), die von Nicht-Technikern kommen. Ich zähle mich selbst dazu. Die Frage ist, ob sich der Anteil in die richtige Richtung bewegt, ob also immer mehr Leute ihre Features und Tools selbst bauen, ohne einen Entwickler zu brauchen. Jeder Merge Request wird reviewt, zu hundert Prozent von Menschen. Aber ob man nur reviewt oder den ganzen Code selbst schreibt, ist ein Unterschied.

Das führt direkt zum Vivid IT Stack. Was besitzt ihr wirklich, was kommt von Standardanbieter?

Ich würde trennen: auf der einen Seite die generischen LLMs und die Werkzeuge darum herum, auf der anderen Spezialtools für bestimmte Zwecke. Bei den generischen probieren wir alles aus. Was funktioniert, ist das Beste. Für Entwickler und Leute wie mich sind das Claude Code beziehungsweise Cowork, Cursor und OpenAI ChatGPT mit Codex. Zwischen den dreien bewegen sich die Mitarbeiter ständig.

Als wir uns im Februar oder März in Frankfurt getroffen haben, war die Mehrheit auf Cursor. Danach haben wir alle auf Claude umgestellt. Jetzt schiebe ich die Leute wieder zurück zu Cursor. Das pendelt.“

Und das sind nicht nur Produktentwickler. Compliance, Finance, buchstäblich jeder arbeitet hier täglich mit wechselnden Tools.

Und die Modelle dahinter?

Vivid-Mitgründer Alexander Emeshev sitzt entspannt auf einem Sofa. Er trägt ein T-Shirt mit Zebramuster. Im Hintergrund sind große Fenster und eine Pflanze in einem Topf sichtbar. Die Umgebung wirkt modern und hell. — Vivid

Über API nutzen wir alle. OpenAI, Anthropic, dazu testen wir intern Open-Source-Modelle in unserer eigenen Umgebung. Wir wechseln zwischen ihnen. Warum alle? Weil die Entwicklung so schnell ist. Sobald ein neues Modell da ist, springen wir drauf und testen es: für Architekturdesign, für Analytics, für Produktentwicklung. Was funktioniert, setzen wir ein. Operative Agenten laufen bei uns auf OpenCode, auch dort mit den Modellen der großen Anbieter.

Irgendwelche Spezialtools?

Da haben wir aufgehört zu kontrollieren. Wenn du im Customer Care arbeitest, kaufst du die Tools, die du brauchst.

Der Kollege, der SEO und GEO verantwortet, hat mir gestern erzählt, was er gebaut hat und welche Tools er dafür abonniert hat. Ich kenne die Hälfte nicht. Irgendwas für Bildgenerierung, irgendwelche Checks. Das ist sein Job. Ich habe aufgehört, darauf zu achten, als mir klar wurde, dass sich die Qualität dieser Tools ständig ändert.

Genau wie bei den Modellen. Ich habe ein Tool getestet, für uns hat es nicht gepasst, die Empfehlungen waren daneben. Wir haben zwei andere probiert. Einen Monat später war das erste plötzlich gut. So läuft das andauernd. Deshalb legen wir das in die Hände der Experten im jeweiligen Bereich. Sie testen, und was für sie funktioniert, nutzen sie.

In den meisten Banken darf die Marketingabteilung kein Bildmodell kaufen, ohne dass es durch die IT geht. Wie ist das bei euch geregelt? Bekommen die Leute ein Budget?

Nein. Ich gebe Leuten grundsätzlich kein Budget, auch nicht im Marketing, unserem größten Kostenblock. Sobald man Leuten ein Budget gibt, geben sie es aus. Das ist ein großer Fehler. Wenn jemand Budget sagt, sage ich: Nein, das ist Spend.

Wir arbeiten mit einem Zero-Budget-Konzept. Das heißt: Ja, so viel erwarten wir auszugeben. Wenn du weniger brauchst, gut. Wenn du mehr brauchst, auch gut. Aber du bist verantwortlich und musst erklären können, warum du diese Person eingestellt oder dieses Tool genommen hast. Bei größeren Summen gibt es Kontrollen im Finance-Team, die fragen: Seid ihr sicher? Aber bei 100 oder 200 Euro im Monat kostet der Antrag mehr als kaufen, testen und entscheiden, ob man es behält.

Also gar keine Prüfung?

Doch, aber nicht wegen der Summe, sondern wegen der Regulierung.“

Für generisches Tooling wie Cursor gehen wir den ganzen Zyklus: Rechenzentren in Europa, Zero Data Retention, also verarbeiten, aber nicht speichern, alles, was Gesetz und Aufsicht verlangen. Bei einem Marketingtool, das Keywords anschaut? Wozu.

Zurück zur Ausgangsfrage: Baut ihr einen eigenen KI-Stack?

Kommt drauf an, was man darunter versteht.

Im Sinne von eigenen Modellen.

Nein, das Rad erfinden wir nicht neu, da stecken wir ein LLM rein.

Das heisst ihr baut den Harness? [die Umgebung um das Modell herum; Anm. d. Red.]

Den ja, und der ist das eigentlich Entscheidende. Ein Beispiel: Wir brauchen einen Agenten für Enhanced Due Diligence, also die vertiefte Prüfung bei einem Kunden mit erhöhtem Risiko. Dafür bauen wir einen Harness, also alles um das Modell herum, vom Datenzugriff bis zur Testschleife. Der erlaubt uns einen schnellen Zyklus: Instruktionen an den Agenten geben, laufen lassen, backtesten, auswerten, mit Menschen im Loop, Instruktionen anpassen, wieder hochladen, von vorn.

Wie läuft das konkret?

Man startet mit dem teuren Modell. Heute Opus 5, davor 4.8, davor 4.7. Erste Ergebnisse sind meist so lala. Man schaut in die Testergebnisse, schärft die Instruktionen, lässt es wieder laufen, bis man sagt: Das gefällt uns. Und je schneller man dahin kommt, desto günstiger. Denn bis dahin zahlt man doppelt: die Gehälter der Leute, die den Prozess noch manuell machen, und die der Tech- und Produktleute, die den Agenten bauen.

Wenn es drei Monate dauert, dauert es drei Monate. Dann geht der Agent in Produktion, wenn nötig nach internen Freigaben. Und dann drückt man die Kosten. Es läuft mit Opus 5, aber geht es auch mit Sonnet? Vielleicht ohne Reasoning?

Und Fable, das aktuelle Spitzenmodell?

Können wir nicht nehmen. Es hat europäische Rechenzentren, aber keine Zero Data Retention. Gut für Entwicklung, nicht für Kundendaten. Für Kundendaten reicht Opus 5 vollkommen.

Manche dieser Prozesse liegen in Bereichen, in denen die Aufsicht genau hinschaut. Wie geht ihr damit um?

Entscheidend ist Governance. Man muss zeigen können, dass die Verfahren nachhaltig und wiederholbar sind, dass man sie erneut durchlaufen kann und dieselben Metriken bekommt.“

Noch besser ist ein externer Prüfer, der die Ergebnisse unabhängig verifiziert und bestätigt. Das braucht man in Bereichen, in denen der Regulator sensibel ist. In vielen anderen sagt er: Das ist eure Sache.

Vivid ist im siebten Jahr (Website). Wenn du den Stack heute, mit dem Stand von 2026, noch einmal bauen müsstest: von vorn?

Gute Frage. Wer morgen anfängt, muss KI-first entwickeln, das ist der Default. Selbst die Senior Entwickler coden nicht mehr allein.“

Sie zerlegen die Aufgabe, entwerfen die Architektur zusammen mit dem Modell und entscheiden: Das mache ich selbst, das lasse ich generieren. Und sie haben mehrere Agenten parallel laufen, eine kleine Armee. Wer das nicht macht, ist zehn- oder hundertmal langsamer als alle anderen. So würden wir es machen, wenn wir morgen anfingen.

Aber?

Aber ich sehe keinen Wert darin, bei null zu starten. Gestern saß ich mit Entwicklern im Raum nebenan, Thema: Wir haben zu viel Spaghetti gebaut, technische Schulden, das muss aufgeräumt werden. Einige unserer Leute sind schon dran.

Meine Erwartung ist, dass wir bald wissen, wie man Refactoring weitgehend automatisiert.“

Die Idee: Man hat eine gute Wissensbasis aller Anforderungen, die man für dieses System je gebaut hat. Anforderungen sind heute sauber dokumentiert, weil Claude sie schreibt. Man hat den ganzen Code in GitHub oder GitLab.

Dann lässt man einen Agenten laufen und sagt: Räum auf. Das will ich erreichen, das sind die Anforderungen, das Legacy kannst du löschen.“

Wie weit seid ihr?

Mittendrin. Ich wäre nicht überrascht, wenn wir in Teilen unserer Systeme bald genauso vorgehen. Aber man muss das sehr vorsichtig angehen. Und nein, vollautomatisch läuft das nicht. Es braucht immer den Menschen, der draufschaut, der entscheidet, was bleibt und was weg kann. Was sich geändert hat, ist der Aufwand. Refactoring war früher das, wovor sich jeder gedrückt hat. Heute ist es deutlich weniger schmerzhaft und deutlich schneller. Das ist der Punkt, an dem wir stehen.

Alexander, danke für das Gespräch.Dirk Emminger