Wenn die KI immer schneller programmiert, wer kümmert sich dann um die Qualität? Dieser Artikel stellt drei autonome Rückkopplungs-Schleifen für Korrektheit, Performance und Architektur vor und zeigt, warum menschliche Steuerung trotzdem wichtig bleibt.
Geschwindigkeit allein macht Softwareentwicklung nicht nachhaltig#
Mit Agentic AI können wir Software inzwischen in einer Geschwindigkeit entwickeln, die vor wenigen Jahren kaum vorstellbar war. KI-Agenten implementieren Features, schreiben Tests, beheben Fehler und erstellen Pull Requests. Immer häufiger können sie diese Aufgaben weitgehend autonom erledigen.
Aber Geschwindigkeit allein macht Softwareentwicklung noch nicht nachhaltig.
Wenn wir immer mehr Code generieren, ohne seine langfristige Qualität im Blick zu behalten, entsteht ein Problem: Die Software funktioniert heute vielleicht hervorragend, wird aber mit jeder Änderung schwieriger zu verstehen, zu erweitern und zu warten.
Das Problem ist nicht grundsätzlich neu. Auch menschliche Entwickler können unter Zeitdruck technische Schulden anhäufen. Der Unterschied liegt in der Geschwindigkeit, mit der KI solche Probleme erzeugen kann.
Die spannende Frage lautet deshalb:
Können wir Agentic AI nicht nur zur Entwicklung neuer Features einsetzen, sondern auch zur kontinuierlichen Verbesserung der bestehenden Software?
Ein interessanter Ansatz dafür sind autonome Rückkopplungs-Schleifen (Feedback Loops).
Dabei beobachtet ein Agent bestimmte Qualitätseigenschaften, identifiziert Verbesserungsmöglichkeiten, verändert den Code und überprüft anschließend, ob seine Änderung tatsächlich eine Verbesserung gebracht hat.
Drei besonders interessante Beispiele sind:
- Korrektheit: Fehler systematisch finden und beheben.
- Performance: Die Laufzeiteigenschaften messbar verbessern.
- Architektur: Komplexität und Kopplung reduzieren, um zukünftige Änderungen zu erleichtern.
Korrektheit: Fehler finden, bevor sie beim Benutzer auftreten#
Die erste Rückkopplungs-Schleife versucht, die funktionale Korrektheit der Software kontinuierlich zu verbessern.
Dazu braucht ein Agent eine Möglichkeit, Fehler zuverlässig zu erkennen.
Ein besonders interessantes Verfahren ist Deterministic Simulation Testing (DST).
Deterministic Simulation Testing#
DST wird unter anderem bei FoundationDB und TigerBeetle eingesetzt. Auch außerhalb von Datenbanken wird das Verfahren genutzt: Dropbox testet so seine Sync-Engine, MongoDB und das Ethereum-Netzwerk nutzen dafür die Plattform Antithesis, die von den FoundationDB-Gründern stammt.
Die Idee besteht darin, den tatsächlichen Anwendungscode in einer kontrollierten Umgebung auszuführen, in der normalerweise unvorhersehbare Einflüsse simuliert werden.
Dazu gehören beispielsweise:
- Netzwerkunterbrechungen und verzögerte Nachrichten
- Abstürze einzelner Komponenten
- Unterschiedliche zeitliche Reihenfolgen konkurrierender Operationen
- Fehler beim Lesen und Schreiben von Daten
- Systemzeit und Zufallszahlen
Der entscheidende Vorteil: Die simulierten Abläufe sind reproduzierbar.
Wenn eine bestimmte Kombination von Ereignissen einen Fehler auslöst, lässt sich derselbe Ablauf erneut ausführen. Ein KI-Agent kann den Fehler analysieren, eine Korrektur implementieren und anschließend überprüfen, ob der Fehler tatsächlich verschwunden ist.
Dabei können sehr viele unterschiedliche Fehlerkonstellationen automatisch untersucht werden.
Braucht jede Software DST?#
Nein. Für eine gewöhnliche Geschäftsanwendung mit REST-API, Datenbank und einigen Hintergrundprozessen kann ein vollständiges DST-System einen unverhältnismäßig hohen Aufwand verursachen.
Die zugrunde liegende Idee ist aber übertragbar:
Je zuverlässiger wir Fehler automatisch erkennen und reproduzieren können, desto besser eignet sich unser Testsystem als Grundlage für autonome Verbesserungen.
Bei Geschäftsanwendungen kommen dafür unter anderem folgende Verfahren infrage:
- Ausführbare Spezifikationen, beispielsweise mit Gherkin-Szenarien
- Integrations- und Szenariotests
- Property-Based Testing
- Mutationstests zur Bewertung der Testwirksamkeit
- Statische Analyse und Compilerprüfungen
- Gezielte Simulation von Fehlerbedingungen
Besonders wichtig sind dabei ausführbare Spezifikationen.
Ein Agent muss schließlich nicht nur wissen, dass ein Test fehlschlägt. Er muss auch erkennen können, welches Verhalten tatsächlich erwartet wird.
Die Grenze: Tests kennen nicht automatisch die Anforderungen#
Selbst ein perfektes Testsystem garantiert keine fachlich korrekte Software.
Wenn eine Anforderung fehlt oder falsch spezifiziert wurde, kann der Agent sie nicht allein aus den Testergebnissen rekonstruieren.
Ein System kann sämtliche Tests bestehen und trotzdem genau das Falsche tun.
Das ist der Unterschied zwischen Verifikation und Validierung: Verifikation prüft, ob die Implementierung ihrer Spezifikation entspricht; Validierung prüft, ob das Ergebnis tatsächlich das Gewünschte erreicht (mehr dazu im Artikel Agentic AI ist wie eine Rakete).
Deshalb bleibt die Validierungsfrage, was die Software leisten soll, von der Verifikationsfrage getrennt, ob die Implementierung diese Anforderungen erfüllt.
Die erste Rückkopplungs-Schleife kann die Verifikation zunehmend autonom übernehmen. Die Validierung benötigt weiterhin fachliche Zielvorgaben und deren Überprüfung.
Performance: Messbare Optimierung statt Bauchgefühl#
Die zweite Rückkopplungs-Schleife beschäftigt sich mit der Geschwindigkeit und Effizienz der Software.
Hier bietet sich ein anderer Ansatz an: Statt nur Fehler zu erkennen, können wir kontinuierlich Leistungskennzahlen messen und versuchen, sie zu verbessern.
Eine technische Grundlage dafür liefert OpenTelemetry.
Was ist OpenTelemetry?#
OpenTelemetry, häufig als OTel abgekürzt, ist ein offenes Framework zur Erfassung und Weitergabe von Beobachtungsdaten aus Softwaresystemen.
Dazu gehören insbesondere:
- Metrics: Messwerte wie Antwortzeiten, Durchsatz, Speicherverbrauch und Fehlerraten
- Traces: Die Verarbeitung eines Requests über verschiedene Komponenten hinweg
- Logs: Protokollierte Ereignisse und Fehlermeldungen
OpenTelemetry liefert dabei die Instrumentierung und Übertragung der Daten, nicht automatisch die eigentliche Optimierung.
Ein KI-Agent kann diese Informationen jedoch analysieren, um Performance-Probleme zu erkennen und gezielt Verbesserungen vorzuschlagen.
Performance Hill Climbing#
Ein interessanter Ansatz ist das sogenannte Hill Climbing.
Dabei versucht ein Optimierungsalgorithmus, sich schrittweise einem besseren Ergebnis anzunähern.
Für einen KI-Agenten könnte das folgendermaßen aussehen:
- Aktuelle Performance messen.
- Einen möglichen Engpass identifizieren.
- Eine gezielte Codeänderung durchführen.
- Performance unter vergleichbaren Bedingungen erneut messen.
- Die Änderung übernehmen, wenn sie tatsächlich besser ist.
- Andernfalls die Änderung verwerfen und einen anderen Ansatz versuchen.
Das Ergebnis kann eine schrittweise Verbesserung sein.
Nicht jede Optimierung führt zu einer Verbesserung; eine Verschlechterung wird bei einer einfachen Hill-Climbing-Strategie verworfen.
Ein Beispiel aus einer typischen Geschäftsanwendung:
Ein REST-Endpunkt benötigt im 95. Perzentil 800 Millisekunden. OpenTelemetry-Traces zeigen, dass ein erheblicher Teil der Zeit durch wiederholte Datenbankabfragen entsteht.
Der Agent identifiziert ein N+1-Query-Problem, optimiert den Datenzugriff und führt anschließend die funktionalen Tests und Performance-Benchmarks erneut aus.
Wenn die Antwortzeit dadurch auf 250 Millisekunden sinkt, ohne andere Qualitätsziele zu verletzen, kann er die Änderung übernehmen.
Performance hat mehrere Dimensionen#
Eine Optimierung ist allerdings selten so einfach wie „schneller ist besser“.
Beispielsweise kann eine Cache-Schicht die Antwortzeit reduzieren, gleichzeitig aber den Speicherverbrauch erhöhen und neue Probleme bei der Datenkonsistenz erzeugen.
Deshalb braucht auch diese Rückkopplungs-Schleife klare Ziele und Grenzen.
Ein mögliches Ziel könnte sein:
Minimiere die P95-Antwortzeit, solange Speicherverbrauch, Fehlerrate und Datenkonsistenz innerhalb vorgegebener Grenzen bleiben.
Solche Ziele eignen sich grundsätzlich gut zur Automatisierung.
Eine Voraussetzung ist allerdings, dass die Messungen verlässlich und vergleichbar sind. Unterschiedliche Lastprofile oder schwankende Umgebungsbedingungen können sonst vermeintliche Verbesserungen vortäuschen.
Architektur: Kann KI ihren eigenen Code entschlacken?#
Die dritte Rückkopplungs-Schleife ist möglicherweise die interessanteste, und zugleich die schwierigste.
Sie beschäftigt sich nicht primär damit, ob Software funktioniert oder schnell genug ist, sondern damit, wie leicht sie sich zukünftig verändern lässt.
Hier taucht in der Diskussion um KI-generierten Code zunehmend der Begriff Deslop auf.
Was bedeutet Deslop?#
Slop ist eine abwertende Bezeichnung für minderwertige KI-generierte Inhalte, insbesondere auch für unnötig komplizierten, redundanten oder schlecht strukturierten Code.
Deslop bezeichnet entsprechend den Versuch, solche Qualitätsprobleme nachträglich zu beseitigen.
Ein KI-Agent könnte beispielsweise:
- Doppelte Implementierungen zusammenführen
- Unnötige Abstraktionen entfernen
- Überflüssige Fehlerbehandlung reduzieren
- Verantwortlichkeiten zwischen Komponenten klarer aufteilen
- Zyklische Abhängigkeiten auflösen
- Redundante Tests erkennen
- Schwer verständliche Kontrollflüsse vereinfachen
- Kopplung zwischen Modulen reduzieren
Das klingt zunächst nach gewöhnlichem Refactoring.
Der Unterschied liegt darin, dass solche Arbeiten nicht mehr ausschließlich als Nebenprodukt konkreter Featureentwicklungen stattfinden, sondern regelmäßig und gezielt als eigenständiger Verbesserungsprozess.
Das Problem: Was ist eine gute Architektur?#
Während sich Korrektheit und Performance zumindest teilweise objektiv messen lassen, ist die Bewertung einer Softwarearchitektur schwieriger.
Eine Architektur ist nicht allein deshalb gut, weil sie wenige Klassen besitzt oder besonders elegant aussieht.
Sie ist gut, wenn sie ihren Zweck erfüllt.
Ein entscheidender Zweck besteht darin, zukünftige Änderungen möglichst einfach, sicher und kostengünstig zu machen.
Genau hier entsteht eine interessante neue Messmöglichkeit.
Tokenverbrauch als Wartbarkeitsmetrik#
Wenn KI-Agenten einen großen Teil unserer Softwareentwicklung übernehmen, können wir ihren tatsächlichen Aufwand für Änderungen messen.
Beispielsweise:
| Metrik | Schwer wartbarer Code | Gut wartbarer Code |
|---|---|---|
| Gelesene Dateien | 45 | 8 |
| Geänderte Dateien | 17 | 3 |
| Benötigte Tokens | 180.000 | 35.000 |
| Agent-Iterationen | 12 | 3 |
Illustrative Zahlen für vergleichbare Änderungen, keine empirischen Ergebnisse.
Die Grundüberlegung ist überzeugend:
Wenn ein Agent für eine kleine fachliche Änderung 45 Dateien untersuchen und 17 Dateien verändern muss, spricht das möglicherweise für eine zu starke Kopplung oder unklare Verantwortlichkeiten.
Wenn dieselbe fachliche Änderung mit deutlich geringerem Aufwand umgesetzt werden kann, könnte das ein Hinweis auf eine bessere Architektur sein.
Der Tokenverbrauch wird damit zu einer potenziellen extern beobachtbaren Metrik für Wartbarkeit.
Hoher Tokenverbrauch ist dabei nicht nur ein Symptom, sondern selbst ein Problem. Je mehr Kontext ein Agent aufnehmen muss, desto eher gehen Details darin verloren; LLMs arbeiten in sehr großen Kontexten messbar unzuverlässiger. Mehr Tokens bedeuten deshalb:
- schlechtere Qualität der Ergebnisse, weil Details im Kontext untergehen
- höhere Kosten bei nutzungsabhängiger API-Abrechnung
- langsamere Verarbeitung und längere Rückkopplungszyklen
- mehr Kontextverdichtungen, bei denen frühere Erkenntnisse verloren gehen
- eine harte Grenze: Passt eine Änderung nicht mehr in das Kontextfenster, muss der Agent sie zerlegen oder scheitert
Schwer wartbarer Code verteuert und verschlechtert damit genau die Arbeit, die ihn verbessern soll.
Aber misst Tokenverbrauch wirklich Architekturqualität?#
Nicht unmittelbar.
Der Tokenverbrauch hängt auch von anderen Faktoren ab:
- Leistungsfähigkeit und Verhalten des verwendeten Modells
- Größe und Aufbereitung des bereitgestellten Kontexts
- Effizienz der verwendeten Entwicklungswerkzeuge
- Schwierigkeit der jeweiligen Aufgabe
- Qualität der Dokumentation
- Anzahl der notwendigen Korrekturversuche
Ein Agent, der weniger gründlich prüft, benötigt möglicherweise weniger Tokens und produziert trotzdem schlechteren Code.
Deshalb wäre der reine Tokenverbrauch als Optimierungsziel gefährlich.
Interessanter wäre der Aufwand pro erfolgreich und nachweislich korrekt umgesetzter Änderung, gemessen über eine ausreichend große Menge vergleichbarer Aufgaben.
Lokale Verbesserungen sind nicht automatisch globale Verbesserungen#
Ein weiterer schwieriger Punkt ist der Betrachtungszeitraum.
Das Entfernen einer Abstraktion kann die nächsten zehn Änderungen vereinfachen, aber die elfte erheblich erschweren.
Umgekehrt kann eine zusätzliche Abstraktion zunächst mehr Code verursachen, langfristig aber zahlreiche Änderungen vereinfachen.
Ein autonomer Deslop-Agent sieht häufig nur einen Ausschnitt der zukünftigen Anforderungen.
Deshalb können solche Agenten besonders gut lokale Verbesserungen vornehmen. Grundlegende Architekturentscheidungen benötigen dagegen eine breitere Betrachtung und gegebenenfalls menschliche Steuerung.
Drei Rückkopplungs-Schleifen, ein gemeinsames Ziel#
Die drei beschriebenen Verfahren setzen an unterschiedlichen Qualitätseigenschaften an.
Das Interessante daran ist nicht die Auswahl genau dieser drei Bereiche.
Entscheidend ist die Trennung zwischen Softwareentwicklung und kontinuierlicher, messbarer Qualitätsverbesserung.
Bei klassischer Softwareentwicklung entsteht Qualitätsverbesserung häufig nur dann, wenn jemand ein konkretes Problem erkennt und Zeit für dessen Behebung einplant.
Allerdings dürfen die verschiedenen Rückkopplungs-Schleifen nicht unabhängig voneinander beliebige Änderungen vornehmen.
Eine Performance-Optimierung darf die Korrektheit nicht verletzen. Ein Refactoring darf nicht unbemerkt die Performance verschlechtern. Und eine vermeintliche Architekturverbesserung darf keine wichtigen fachlichen Anforderungen beseitigen.
Die verschiedenen Qualitätsziele müssen deshalb gemeinsam betrachtet werden.
Welche Rückkopplungs-Schleifen braucht eine Anwendung?#
Die drei Beispiele sind keine vollständige Liste und schon gar kein verbindliches Modell für jede Software.
Welche Eigenschaften kontinuierlich optimiert werden sollten, hängt von den Anforderungen des jeweiligen Systems ab.
Bei einer verteilten Datenbank kann die Simulation von Netzwerkfehlern und konkurrierenden Operationen entscheidend sein.
Bei einer typischen Geschäftsanwendung sind möglicherweise fachliche Korrektheit, Datenintegrität und Wartbarkeit wichtiger als die letzten Millisekunden Antwortzeit.
Bei einem Echtzeitsystem stehen dagegen Latenzgrenzen und Vorhersagbarkeit im Vordergrund.
Auch weitere Rückkopplungs-Schleifen sind denkbar:
| Qualitätsbereich | Mögliche Messgröße | Mögliche Optimierung |
|---|---|---|
| Sicherheit | Bestätigte Schwachstellen, Regelverstöße | Schwachstellen beheben, Angriffsflächen reduzieren |
| Zuverlässigkeit | Fehlerraten, Ausfallzeiten | Fehlerbehandlung und Wiederanlauf verbessern |
| Ressourcenverbrauch | CPU-Zeit, Speicher, Energiebedarf | Ressourcen effizienter nutzen |
| Testbarkeit | Mutationsscore, Testaufwand | Tests wirksamer und einfacher machen |
| Wartbarkeit | Änderungsaufwand, Kopplung, Komplexität | Architektur und Code vereinfachen |
| Barrierefreiheit | Automatisierbare Accessibility-Prüfungen | Zugänglichkeit der Benutzeroberfläche verbessern |
Auch hierbei gilt: Nicht jede aufgeführte Eigenschaft lässt sich vollständig automatisch bewerten. Oft liefern Messwerte nur Indizien, die interpretiert werden müssen.
Es wäre sogar denkbar, die Auswahl und Gewichtung der Rückkopplungs-Schleifen im Laufe eines Projekts anzupassen.
Ein junges Produkt benötigt möglicherweise zunächst andere Optimierungsziele als ein seit zehn Jahren betriebenes System.
Können solche Rückkopplungs-Schleifen wirklich autonom arbeiten?#
Hier müssen wir zwischen zwei Dingen unterscheiden:
- Die Optimierung innerhalb vorgegebener Ziele
- Die Festlegung und Bewertung dieser Ziele
Die erste Aufgabe kann Agentic AI zunehmend autonom übernehmen.
Die zweite ist erheblich schwieriger.
Ein Agent kann eine Antwortzeit optimieren. Aber soll er dafür den Speicherverbrauch verdoppeln?
Er kann eine komplexe Architektur vereinfachen. Aber darf er dabei Erweiterungsmöglichkeiten entfernen, die erst im nächsten Jahr benötigt werden?
Er kann sämtliche Tests erfolgreich ausführen. Aber woher weiß er, dass die Tests sämtliche wichtigen Anforderungen abdecken?
Die Ziele, Grenzen und akzeptablen Risiken müssen deshalb explizit festgelegt werden.
Das bedeutet nicht, dass jede einzelne Änderung menschlich überprüft werden muss.
Vielmehr können wir auch die Freigabe von Optimierungen risikobasiert automatisieren.
Rückkopplungs-Schleifen und risikobasierte Freigabe#
In meinem bisherigen Ansatz zur risikobasierten KI-Softwareentwicklung, der Gray Software Factory, steht die Frage im Vordergrund, unter welchen Bedingungen ein Agent Änderungen eigenständig übernehmen darf.
Hier ergibt sich eine natürliche Ergänzung.
Die Rückkopplungs-Schleifen erzeugen Verbesserungen. Der risikobasierte Entwicklungsprozess entscheidet, welche dieser Änderungen automatisch akzeptiert werden können.
Ein kleines, gut durch Tests abgesichertes Refactoring könnte damit automatisch übernommen werden.
Eine grundlegende Änderung an der Modularchitektur könnte dagegen eine menschliche Entscheidung erfordern.
Das Ziel ist ausdrücklich nicht, möglichst viele menschliche Reviews durchzuführen. Es geht darum, menschliche Aufmerksamkeit dort einzusetzen, wo sie tatsächlich einen Mehrwert bietet.
Damit ergänzen sich zwei unterschiedliche Mechanismen:
Risikobasierte Qualitätskontrolle schützt vor Änderungen, deren Risiken nicht ausreichend beherrscht werden.
Kontinuierliche Qualitätsverbesserung versucht, die Codebasis über viele Änderungen hinweg systematisch zu verbessern.
Wie messen wir, ob die Software langfristig wirklich besser wird?#
Hier liegt möglicherweise die größte Herausforderung.
Bei einer einzelnen Änderung können wir recht einfach feststellen, ob Tests erfolgreich sind oder sich eine Benchmark-Messung verbessert hat.
Aber wie erkennen wir, ob die gesamte Codebasis nach einem Jahr autonomer Entwicklung tatsächlich besser geworden ist?
Klassische interne Metriken wie Komplexität, Kopplung, Codeabdeckung oder Mutationsscore können Hinweise liefern. Sie sind allerdings keine unmittelbaren Maße für den wirtschaftlichen oder praktischen Nutzen einer Architektur.
Interessanter wäre es, auch die von außen beobachtbaren Folgen zu messen:
- Wie häufig verursachen Änderungen neue Fehler?
- Wie lange dauert es, eine fachliche Änderung vollständig umzusetzen?
- Wie viele Korrekturversuche sind erforderlich?
- Wie hoch ist der Rechen- und Tokenaufwand pro erfolgreich abgeschlossener Änderung?
- Wie häufig müssen bereits abgeschlossene Änderungen später überarbeitet werden?
Besonders der Änderungsaufwand könnte durch Agentic AI erstmals relativ systematisch beobachtbar werden.
KI-Agenten hinterlassen umfangreiche maschinenlesbare Spuren ihres Arbeitsprozesses. Wir können erfassen, wie viele Dateien sie lesen, welche Werkzeuge sie aufrufen, wie viele Versuche sie benötigen und wie viel Zeit und Rechenleistung sie verbrauchen.
Damit entstehen neue Möglichkeiten, die langfristige Wartbarkeit von Software empirisch zu untersuchen. Architekturqualität würde nicht mehr ausschließlich anhand interner Codeeigenschaften beurteilt, sondern anhand ihrer tatsächlichen Auswirkungen auf zukünftige Entwicklungsarbeiten.
Allerdings müssen solche Messungen vergleichbar bleiben. Ein Projekt, das zunehmend anspruchsvollere Anforderungen umsetzt, benötigt möglicherweise mehr Aufwand, obwohl seine Architektur besser geworden ist.
Fazit: Nachhaltige KI-Softwareentwicklung braucht mehr als schnelle Codegenerierung#
Agentic AI verändert nicht nur die Geschwindigkeit der Softwareentwicklung, sondern eröffnet auch neue Möglichkeiten für die kontinuierliche Qualitätspflege.
Die drei Rückkopplungs-Schleifen sind Beispiele für ein allgemeineres Prinzip:
Softwarequalität sollte nicht nur bei der Abnahme einzelner Änderungen überprüft, sondern während des gesamten Lebenszyklus kontinuierlich verbessert werden.
Die KI kann viele Verbesserungsmöglichkeiten erkennen, untersuchen, implementieren und bewerten. Menschen müssen jedoch weiterhin dafür sorgen, dass die richtigen Ziele verfolgt und wesentliche Risiken angemessen berücksichtigt werden.
Die Verbindung aus autonomen Verbesserungsprozessen und risikobasierter Freigabe könnte damit zu einer wichtigen Grundlage nachhaltiger KI-Softwareentwicklung werden.
Vielleicht sollten wir den Erfolg von Agentic AI zukünftig weniger daran messen, wie viel Code sie heute erzeugt, und stärker daran, wie einfach, zuverlässig und effizient sich dieser Code morgen weiterentwickeln lässt.
Quellen und weiterführende Literatur#
- FoundationDB: Simulation and Testing – Deterministische Simulation und automatisierte Fehlerprüfung.
- TigerBeetle: Deterministic Simulation Testing – Reproduzierbare Simulationen verteilter Systeme.
- TigerBeetle: Protocol-Aware Deterministic Simulation Testing – Weiterentwicklung des DST-Ansatzes.
- OpenTelemetry: Documentation – Standardisierte Instrumentierung und Erfassung von Telemetriedaten.
- OpenTelemetry: Signals – Metrics, Traces und Logs.
- Phil Eaton: What’s the big deal about Deterministic Simulation Testing? – Einführung in DST und seine Einsatzgebiete.
- Dropbox: Testing sync at Dropbox – Deterministische, per Seed reproduzierbare Zufallstests der Sync-Engine Nucleus.
- Fortune: Antithesis, Jane Street, Ethereum and the FoundationDB legacy – MongoDB, Ethereum und Jane Street als Nutzer der DST-Plattform Antithesis.
- Nikita M. (@meln1k) auf X – Der Post, der DST, OTel-Metriken und Deslop-Skills als drei KI-Schleifen gegenüberstellt.
Anlass für diesen Artikel war ein X-Post von Nikita M. (@meln1k), der Deterministic Simulation Testing, OpenTelemetry-Metriken und sogenannte Deslop-Skills als drei Möglichkeiten kontinuierlicher KI-gestützter Codeverbesserung gegenüberstellt und den Tokenverbrauch im Tagesgeschäft als Maß für Architekturqualität vorschlägt. Die hier vorgestellte Einordnung und Erweiterung ist eine eigenständige Betrachtung dieser Idee.
Dieser Artikel ist mit Unterstützung von KI entstanden.