:quality(78))
Bei einer neu geschriebenen Warenwirtschaft würde ich zuerst die Bestände vergleichen. Liefert die KI-Version bei denselben Vorgängen andere Zahlen, braucht das Team eine Erklärung. OpenAI hat am 19. Oktober neue Tests zu Programmiersprachen wie COBOL und Visual Basic vorgestellt. Die gemeldeten Fortschritte machen einen näheren Blick lohnend: Wie weit hilft KI inzwischen dabei, ältere Unternehmenssoftware weiterzuentwickeln?
Zwei Tests, zwei unterschiedliche Aussagen
OpenAI beschreibt zwei Verfahren: MultiLangBench lässt Modelle einen SQLite-kompatiblen Datenbankkern in 20 Sprachen bauen. Ein zweiter Test prüft die Übersetzung vorhandener COBOL-Programme. Dabei müssen beobachtbare Ausgaben mit dem Original übereinstimmen; eine Aufgabe zählt erst als gelöst, wenn alle Tests bestehen.
Für den COBOL-Test nennt OpenAI bei niedriger Denktiefe 86,6 Prozent erfolgreiche Aufgaben mit GPT-6.1 Sol gegenüber 5,4 Prozent mit GPT-5.6 Sol. Das sind Herstellerangaben aus dieser Untersuchung. Die Zahl beschreibt keine Erfolgsquote für die Migration beliebiger Unternehmenssoftware. OpenAI-Veröffentlichung vom 19. Oktober.
Ein Modell kann in einer abgegrenzten Aufgabe überzeugen und im eigenen Projekt an einer undokumentierten Schnittstelle scheitern. Ich lese die Ergebnisse deshalb als Anlass für einen gezielten Versuch. Ein kompletter Systemwechsel braucht Belege aus der eigenen Anwendung.
Der veröffentlichte Test lässt sich genauer ansehen
MultiLangBench liegt als öffentliches Repository vor. Laut README beruhen die Prüfungen auf SQLite 3.40.1. Ein Test legt eine Ausgangsdatenbank an, führt eine Abfrage mit der erzeugten Implementierung aus und kontrolliert das Ergebnis mit dem echten SQLite. Das Verfahren setzt damit eine überprüfbare Referenz voraus.
Die Dokumentation nennt rund 24.000 übertragene Tests und empfiehlt für reguläre Durchläufe eine Auswahl von 272. Bei einem Ergebnisvergleich gehört deshalb auch der verwendete Testumfang dazu. Das Repository veröffentlicht den SQLite-Test; es ist kein öffentlicher Nachweis des separaten COBOL-Migrationswerts. MultiLangBench: README und Prüfverfahren.
Unternehmen können damit nachsehen, was geprüft wurde. Für ihre eigene Anwendung müssen sie passende Vergleichsfälle ergänzen. Eine Warenwirtschaft hat andere Datenflüsse als ein Datenbankkern. Beim Übertragen des Verfahrens sollte das Team festhalten, welche davon sein Test tatsächlich abdeckt und welche noch fehlen.
Eine kleine Änderung braucht klare Vergleichsfälle
Nehmen wir ein fiktives Beispiel: Ein Großhändler will die Reservierungslogik seiner alten Warenwirtschaft erneuern. Ein Auftrag reserviert Artikel, eine Änderung gibt einen Teil davon wieder frei. Bei einer Stornierung muss der verfügbare Bestand anschließend stimmen. Als Vorbereitung dokumentiert das Team einige typische Vorgänge im Altsystem und sichert deren Ergebnisse.
Die KI bekäme einen begrenzten Auftrag, etwa die Erklärung einer einzelnen Funktion oder einen Änderungsvorschlag in einer Arbeitskopie. Danach spielt das Team dieselben Vorgänge erneut durch. Dazu gehören im Beispiel auch eine leere Position, eine doppelt eingegangene Nachricht und ein abgebrochener Import. Für jeden Fall muss vor dem Versuch feststehen, welches Ergebnis erwartet wird.
Zu jedem Unterschied gehört eine Entscheidung. Hat die KI eine Regel übersehen? Enthält das Altsystem einen Fehler, den man bewusst beseitigen möchte? Oder wurde der Vergleich falsch aufgebaut? Die zuständige Fachperson muss das beantworten können. Das neue Programm soll schließlich den gewünschten Geschäftsablauf abbilden.
Alte Regeln müssen sichtbar werden
Vor einer Modernisierung muss jemand festhalten, welches Verhalten erhalten bleiben soll. Dafür würde ich Zeit einplanen. Eine historische Sonderregel kann fachlich gewollt sein. Ohne eine dokumentierte Entscheidung fehlt dem Entwickler ebenso wie dem Coding-Agenten eine Grundlage, um sie zu erhalten oder zu ändern.
Im Beispiel des Großhändlers müsste die Fachabteilung erklären, ob eine Reservierung nach einem Abbruch bestehen bleiben darf und wer sie aufheben kann. Ein Entwickler müsste den technischen Ablauf dazu prüfen. Für die KI wäre das ein konkreter Arbeitsauftrag mit bekannten Grenzen. Ohne diese Klärung würde jede Abweichung zur Diskussion über Anforderungen, die vorher niemand aufgeschrieben hat.
Auch die Testumgebung gehört zu dieser Entscheidung. Für einen ersten Versuch würde ich eine isolierte Kopie mit passenden Testdaten verwenden. Zugang zum laufenden Betrieb und echte Kundeninformationen braucht ein solcher Versuch zunächst nicht. Änderungen und Prüfergebnisse sollten nachvollziehbar bleiben, damit das Team sie unabhängig vom Agenten beurteilen kann.
Ein Versuch muss sich rechnen lassen
Bei der Bewertung eines solchen Versuchs gehört der gesamte Aufwand auf den Tisch: Vorbereitung, Arbeit mit dem Agenten, Fehlersuche und fachliche Abnahme. Gesparte Schreibzeit allein wäre mir als Maßstab zu wenig. Interessant ist, ob das Team am Ende eine geprüfte Änderung hat, deren Verhalten es versteht und deren Wartung es übernehmen kann.
Vor dem Start würde ich festlegen, wann Schluss ist. Beispielsweise dann, wenn die Ausgaben trotz mehrerer Korrekturen abweichen oder der zuständige Entwickler die vorgeschlagene Lösung nicht sinnvoll warten kann. Ein überschaubarer Versuch darf auch mit dem Ergebnis enden, dass eine andere Aufgabe besser geeignet ist.
In unserer KI-Beratung lässt sich eine solche Aufgabe eingrenzen. Für die Umsetzung sind die Schnittstellen und Tests Teil der individuellen KI-Softwareentwicklung. Wer zunächst den Umgang mit Agenten kennenlernen möchte, findet bei unseren KI-Workshops einen Einstieg.
Für einen Betrieb mit älterer Software wäre mein nächster Schritt ein abgegrenztes Modul mit bekannten Vergleichsfällen. Dann lässt sich prüfen, ob die gemeldeten Fortschritte auch bei der eigenen Arbeit helfen.
:quality(78))
:quality(78))
:quality(78))
