Seit dem Wochenende steht auf Github eine neue Version des Anti-DoS-Valves zur Verfügung. Nach der Veröffentlichung vor nun schon mehr als 9 Jahren hatte ich immer mal wieder kleinere Erweiterungen gemacht, aber diese Version habe ich erstmals in Antigravity und damit massiv KI-unterstützt entwickelt. Ich kann daher nun nicht mehr sagen, dass ich diese Software (komplett) selbst entwickelt habe. Treffender ist nun die Beschreibung, dass ich die Entwicklung dirigiert habe. Dazu schreibe ich im zweiten Abschnitt dieses Posts mehr. Zuerst zu den Veränderungen, die in aller Ausführlichkeit in den Releasenotes beschrieben sind:
Aus neuen Erfahrungen gelernt
Das Valve wird auch heute noch in nur leicht abgewandelter Form in den Servern genutzt, die die BIS Anwendungen tragen. Hier hat es uns über viele Jahre recht zuverlässig gegen zu aggressive Zugriffe geschützt, die aus sehr unterschiedlichen Quellen kamen: Mal von einzelnen Personen aus dem Uni Umfeld, die nicht böswillig waren, aber sich keine großen Gedanken darüber gemacht haben ob es OK ist im Millisekundentakt Abfragen zu starten. Manchmal auch beauftragte Dienstleister, die legitime Nutzer*innen unserer Daten sind, aber teilweise ebenfalls ohne diesen Schutz zu hohe Lasten verursacht hätten. Und natürlich der eine oder andere anonyme Crawler aus dem Netz, der plötzlich auftaucht und wieder verschwindet.
Zwei Entwicklung haben das Valve in der bisherigen Form aber an seine Grenzen und auch drüber hinaus gebracht:
- Das Auftreten von extrem rücksichtlosen Akteuren im Netz, denen es offenbar nur darum geht so viel Content wie möglich in so kurzer Zeit wie möglich abzugreifen, ohne dabei Rücksicht auf die Leistungsfähigkeit der abgefragten Systeme zu nehmen. Es liegt hier nahe die Entwickler*innen von KI-Systemen als Verantwortliche zu vermuten, und deren unstillbaren Hunger nach Trainingsdaten. Solche Zugriffe sind teilweise kaum noch von gezielten DDoS Angriffen zu unterscheiden, stammen aber teilweise aus großen Cloudinfrastukturen und scheinen dort als legitime Kunden zu gelten.
- Neue Formen der Verschleierung von Zugriffen für Webscraping und Angriffe, insbesondere Residential Proxies. Hier sind Dienstleister entstanden, die Endgeräte wie Smart-TVs oder auch Smartphones verwenden, um darüber Zugriffe zu routen. Hier hat man es dann mit großen Zahlen von IP-Adressen und im Gegensatz zu Zugriffen aus Cloudinfrastrukturen auch mit vielen Subnetzen zu tun.
Die Abwehr bzw. Begrenzung dieser Angriffe war dann doch wieder mit viel Handarbeit und Nachsteuern verbunden, die Automatismen des Valves haben hier nicht ausgereicht.
Die neue Version desValves bietet daher nun zwei Optionen, die gegen solche Angriffe mehr Möglichkeiten bieten:
- ipv4SubnetMask und ipv6SubnetMask: Ermöglichen es Zugriffe nicht mehr auf IP-Adressebene zu zählen, sondern auf einer einstellbaren Subnetzebene. Das kann gegen Angreifer helfen, die ihre Zugriffe durch Cloudinfrastrukturen und die darin verfügbaren, zahlreichen IP-Adressen verschleiern.
- serverWideBlocking: Diese Option erlaubt erstmals eine Trennung von Angriffdetektion und Angriffsreaktion. Während die detektierenden Adressen weiterhin über relevantPaths detailscharf definiert werden, kann nun die Reaktion in einer kompletten Blockade im ganzen Server bestehen. Das kann für Honeypot Adressen genutzt werden: Ein Link, der nur irgendwo versteckt genannt wird, aber von bösartigen Crawlern gefunden werden kann, ist der Auslöser und wird in relevantPaths konfiguriert. Wird die Adresse angefasst erfolgt dann eine komplette Sperrung.
Trotzdem sind auch diese neuen Mittel vermutlich noch nicht ausreichend, um sich zuverlässig gegen Residential Proxies abzusichern. Schon allein deshalb, weil sich solche Proxies in den Subnetzen befinden können, aus denen auch unsere normalen Nutzer*innen kommen. Hier kann eine sehr scharfe Einstellung zu Kollateralschäden führen, die man nicht in Kauf nehmen kann. Es gibt noch ein paar Ideen, wie man hier weiter machen könnte, aber vielleicht läuft das auf ein neues, das Valve ergänzendes Produkt hinaus.
Umgang mit viel größeren Adressmengen
Wesentliche Änderungen in der Architektur des Monitors betrafen den hochperformanten und speichereffizienten Umgang mit großen Mengen von registrierten IP-Adressen. Ich war beim erste Design der Funktion eher von einigen hundert IP-Adressen ausgegangen, die mal sich pro Slot merken möchte.
Die Erfahrungen mit Überflutungen durch riesige Mengen von IP-Adressen waren auch hier ein Treiber darüber nachzudenken, wie weit man eigentlich mit der bisherigen Architektur gehen kann: Was passiert, wenn pro Sekunde Zugriffe von 10.000 unterschiedlichen IP-Adressen eintreffen? Zugegebenermaßen wäre wohl die Antwort, dass bei solchen Lasten schon andere Bestandteile der Systemarchitektur zusammenbrechen würden.
Trotzdem sind hier im Dialog mit der KI Verbesserungen entstanden, die es dem Monitor erlauben sollen auch mit mehr als 100.000 pro Slot gespeicherten IP-Adressen umzugehen, ohne den Speicher oder die Threadpools des Tomcat Servers zu überlasten. Der Test steht hier noch aus, aber mir erscheint die neue Architektur sehr plausibel und belastbar.
Die Einführung eines separaten Caches für bereits geblockte IP-Adressen oder Subnets, dessen Größe über die neue Option maxBlockedIPCacheSize eingestellt werden kann, verhindert in solchen Hochlastsituation auch ein Verdrängen bereits gesperrter Adressen aus dem Cache. Die aber einer Cachegröße von 500 auf ein nebenläufiges Verfahren umgestellte Cachebereinigung entlastet der Server, ebenso wie das in Extremsituationen reduzierte Logging.
Meine eindeutige Empfehlung an Betreiber*innen von Tomcat Servern: Dreht die Anzahl der IP-Adressen drastisch hoch, es kostet (fast) nichts und kann noch ein Element sein, welches in kritischen Situationen hilft. Wie viele Ressourcen es euch kostet ist nun leicht abzuschätzen:
Ein neues Tool für Erstellung und Simultation von Konfigurationen
Es gibt im Repo nun eine HTML Single Page App, die es leicht macht sich eine Konfiguration zusammenzustellen: Es werden alle verfügbaren Optionen mit einer kurzen Erläuterung gezeigt und aus den Einstellungen wird live ein XML-Schnipsel generiert, der sich direkt in die Serverkonfiguration übernehmen lässt. Hier wird auch der ungefähre Speicherbedarf gezeigt, den diese Konfiguration im Maximalfall verursachen kann.
Aber das Tool kann noch mehr: Es übernimmt die Simulationsfunktion, die ich bisher in einem Google Drive Sheet angeboten habe, und die das Verhalten des Monitors bei Zugriffen einer einzelne IP-Adresse im Zusammenspiel mit der gerade eingestellten Konfigurationsparametern berechnet.
Hinzugekommen ist hier noch ein zweiter Simulationsmodus, der eine Abschätzung des Verhaltens bei sehr großen Mengen von Zugriffen ermöglicht. Hier steht Fragen wie die im Vordergrund, ab welcher Menge von unterschiedlichen IP-Adressen die Caches volllaufen. Ich bin selbst noch nicht sicher, wie hilfreich das in Zukunft sein wird, aber die KI hat meine Idee schnell umgesetzt und noch eigene Ideen beigesteuert. Und es sieht cool aus.
Ein neues Valve mit der bewährten Grundarchitektur
So viel zur neuen Version des Valves und den Erweiterungen. Insgesamt hat sich die Codebasis sehr deutlich vergrößert – allein die Zahl der Unittests hat sich ca. verdreifacht – und die schon vorhandenen Teile haben teilweise deutliche Überarbeitungen erhalten.
Trotzdem ist die grundsätzliche Architektur gleich geblieben und damit auch das Funktionsprinzip der Zähler, die auf IP-Adressen bzw. davon abgeleiteten Subnetzen arbeiten. Das macht das Verständnis einfacher, hat aber auch die oben schon beschriebenen Grenzen bei Residential Proxies.
Erfahrungen mit der KI-unterstützten Entwicklung
Eigentlich hatte ich nur vor ein paar kleine Punkte anzugehen, die z. B. die automatischen Prüfungen durch GitHub bemängelt haben. Aber dann sind in 3 Tagen mehr als 30 Commits entstanden, denn irgendwie bin ich hier in ein Vibe Coding Rabbit Hole gefallen.
Ich habe Antigravity heute einmal gefragt, wie viel wir (ein merkwürdiger Begriff, wenn es um die Zusammenarbeit mit einer KI geht, aber mir fällt kein angemessenerer ein) in den 3 Tagen gemacht haben, und das ist die Zusammenfassung:
Quantitative Kennzahlen des Sprints
| Dimension | Gesamter Sprint (18.–20.09. bis v1.5.0) |
|---|---|
| Git Commits | 29 Commits |
| Geänderte Codezeilen | +5.815 / -544 (18 Dateien) |
| Konversationen / Sessions | 8 getrennte Sessions |
| Dialogumfang (Prompts / Steps) | weit über 120–150 Interaktionsschritte |
| Neuerstellte Tools/Artefakte | Concurrency-Tests, Testsuite, Simulator (~1.800 Zeilen HTML/JS), Dockerfile-Updates |
Fazit / Einordnung
Vom Umfang und der inhaltlichen Dichte her entsprach der Dialog am Freitag (und dessen Vollendung am Wochenende) typischerweise dem Arbeits- und Diskussionsaufwand eines mehrwöchigen Entwicklungs-Sprints eines erfahrenen Senior-Entwicklerteams.
Ob man die Einschätzung teilen sollte, dass dies einem mehrwöchtigen Entwicklungs-Sprint eines ganzen Teams entspricht möchte einmal dahingestellt lassen. Aber es war eine sehr intensive Phase und das, was in dieser Zeit umgesetzt wurde, hätte mich auf jeden Fall Wochen ohne KI-Unterstützung gekostet. Wobei ich eine Entwicklung in diesem Umfang wohl nie angegangen wäre. Das sind meine Erfahrungen mit dieser Zeit, die sich nach echter, durchaus anstrengender Programmierarbeit angefühlt hat, obwohl ich kaum noch in klassischem Sinne programmiert habe:
Tooling
- Ich habe Antigravity in der Version verwendet, die Google heute die IDE Version nennt
- Hier sieht man die volle VS Code Oberfläche mit allen Funktionen wie Erweiterungen, Code Editoren, Versionskontrolle, automatischen Codeverbesserungsvorschlägen etc.
- Der KI Teil hat sich hier in linken Chatleiste abgespielt:
- Auch hier kann man mehrere Chats / Agenten parallel nutzen, aber man hat auch immer den vollen Code im Überblick. Das war hier hier sehr wichtig um bei diesem kritischen Produkt den Überblick zu behalten
- Ich habe mehr als 90% der Arbeiten mit Gemini 3.8 Flash medium gemacht. Für mich hat gut funktioniert und mein Google AI Pro Abo hat mich hier weit getragen. Erst gegen Ende bin ich auf die Claude Modelle gewechselt
Renovierung eines kleines Java Projekts: Problemlos
- Die ersten Schritte bestanden darin die in Teilen schon sichtbar gealterte Anwendung auf einen modernen Stand zu bringen. Die Frage an Antigravity war hier also, welches Punkte man hier angehen könnte
- Hier kam als größter Punkt JUnit. Bisher in Version 4 verwendet, aber wie die KI richtigerweise anmerke, noch mit Spuren der Vorgehensweisen aus JUnit 3. Die Umstellung der Tests ging reibungslos und hat den Code schlanker und moderner gemacht
- Auch ein kleiner Programmierungsfehler wurde gefunden (vertauschte Variablen), der im realen Betrieb bisher nicht aufgefallen war, sowie fehlende volatile Deklarationen, die vielleicht dafür gesorgt haben, dass in Hochlastphasen bereits gesperrte Adressen länger Zugreifen konnten als eigentlich gewünscht
Renovierung und Aktualisierung der README
- Einer der für mich großen Vorteiler der KI-unterstützen Entwicklung ist weiterhin, dass man nicht nur die Programmierung delegieren kann, sondern auch gleich weite Teile der Dokumentation
- Die umfangreiche README Datei hatte ich in 2019 in einem Urlaub unter umfangreicher Hilfe des Google Übersetzers geschrieben. Trotzdem hat sich der Text an vielen Stellen nicht so richtig rund angefühlt bzw. nicht so, wie ein Muttersprachler es geschrieben hätte. Diesen Text noch einmal anzupassen habe ich mir nie die Zeit genommen
- Aber nun war es ein Prompt in der Art, dass der Text einmal auf Rechtschreibfehler geprüft werden solle verbunden mit dem Hinweis, dass ich nicht so richtig gut englisch schreiben konnte. Die KI fand denn auch verschiedene Germanismen, was hier 1-zu-1 aus dem Deutschen übersetzte Formulierungen meint, die im Englischen so nicht findet. Das Ergebnis dieser Überarbeitung war nahezu perfekt und der Text, der wie ich finde seinen sprachlichen Charakter behalten hat, fühlt sich für mich nun deutlich besser an
- Die Pflege der README im Zuge der Weiterentwicklungen habe ich ebenfalls der KI übertragen, die sich hier meist sehr gut geschlagen hat. Manchmal kam nur ein etwas zu überschwenglicher KI-Stil durch, den ich dann bereinigt habe. Das gute daran: Man hat das Thema aus dem Kopf, wenn das neue Feature fertig ist, und schleppt es nicht unter ‚muss ich später mal machen‘ als kognitive Last mit sich herum
- Auch habe ich die KI Ablaufbeschreibungen ergänzen lassen, die sie im Zuge von Konzeptionen schon ohne entsprechenden Auftrag erzeugt hat. Hier hat die Arbeit mit KI glaube ich ein deutlich besseres Ergebnis erzeugt, als ich es zuerst selbst erstellt habe
Lesen, sehr viel lesen. Und schreiben
Ich habe in dieser Zeit nur sehr wenig Java Code direkt bearbeitet. Und im Konfighelper, der HTML Single Page App, überhaupt nicht. Dafür habe ich sehr, sehr viel gelesen, gelernt und entschieden. Und vorher natürlich beschrieben, was ich haben möchte. Hier ein Beispiel, welches die Einführung der Option serverWideBlocking gestartet hat:
Ich denke über eine weitere Option nach bei dem Valve die im Zusammenhang mit der heutigen Wirkung von ‚relevantPaths‘ steht:
Bisher hat die Einstellung der relevanten Pfade eine doppelte Bedeutung: Sie definiert zum einen die Pfade, die quasi als Detektoren für Angriffe dienen. Aber zugleich sind dies auch die einzigen Pfade, die das Valve dann zu schützen vermag.
Ich hätte mir in bestimmten Szenarien gewünscht, dass ich diese beiden Funktionen trennen kann. Also im Extremfall z. B. in der Lage bin den IP-Adresszählung auf einer oder zwei URLs zu machen, aber wenn daraus eine Sperrung entsteht, die auf den kompletten Server wirken zu lassen.
Ich dachte hier zuerst an einen Schalter, der das Verhalten so umstellt, dass – wenn der Schalter gesetzt ist, eine Sperrung auf den ganzen Webserver gilt. Aber vielleicht wäre es flexibler statt dessen eine Option pathsForBlocking einzuführen, die definiert, auf welchen Adressen ein existierender Block aktiv wird.
Allerdings wirft das wieder Fragen auf wie die, ob die Pfade in pathsForBlocking zusätzlich zu den Pfaden in ‚relevantPaths‘ wirken, oder ausschließlich. Beide hätte Vor- und Nachteile.
Gib mir doch einmal Deine Bewertung zu meiner grundsätzlichen Idee und die zu den Implementierungsansätzen. Betrachte dabei die Komplexität in der Implementierung wie auch in der Verständlichkeit für meine Nutzer
Das war die Antwort:
Deine grundsätzliche Idee berührt ein klassisches Architektur- und Schutzmuster moderner Web Application Firewalls (WAFs): die saubere Trennung von Detection Scope (Erkennung) und Enforcement Scope (Sanktionierung).
1. Bewertung der grundsätzlichen Idee
Urteil: Fachlich exzellent und absolut praxisnah.
Bisher zwingt
relevantPathsden Administrator zu einem Dilemma:
- Entweder man schützt nur die teuren/kritischen Endpunkte (z. B.
/login,/api/checkout,/search): Dann zählt man zwar präzise Angriffe und vermeidet False Positives bei normalen Besuchern – aber der Angreifer kann nach der Erkennung weiterhin den gesamten restlichen Server belasten oder ungestört andere Pfade abtasten.- Oder man schützt den ganzen Server: Dann zählen auch unkritische Klicks (Bilder, Browsen) in das gleiche Limit, was die Schwellwert-Kalibrierung extrem erschwert und legitime Power-User gefährdet.
Die Trennung ist daher ein logischer und sehr wertvoller Evolutionsschritt für das Valve.
2. Eine wichtige technische Konsequenz unter der Haube
Bevor man die Konfigurationsoptionen betrachtet, gibt es im Code eine zentrale Voraussetzung:
- Bislang ruft
isRequestAllowed()für URLs inrelevantPathsdie MethodeisIPAddressBlocked(ip)auf, welche wiederummonitor.registerAndCheckRequest()aufruft. Prüfen und Hochzählen sind aktuell eine einzige Operation.- Wenn eine Sperre nun auch für Pfade gelten soll, die nicht in
relevantPathsliegen, darf ein Aufruf dort den Zähler nicht inkrementieren (und keinen neuen Counter anlegen), sondern darf nur nachsehen, ob die IP bereits inblockedCounters(oder einem gesperrten Slot) vorhanden ist.Implementierungsaufwand intern:
Du bräuchtest imAntiDoSMonitor/AntiDoSSloteine leichtgewichtige Methode wieisCurrentlyBlocked(counterName)bzw.isLocked(counterName), die nur lesend O(1) inblockedCountersnachschlägt. Das ist performant und sauber umzusetzen.
3. Gegenüberstellung der Implementierungsansätze
Ansatz A: Der boolesche Schalter (z. B.
serverWideBlocking="true|false"oderblockAllPaths="true|false")
- Wie es funktioniert:
relevantPathssteuert weiterhin, wo gezählt wird.- Wenn
serverWideBlocking="true"aktiv ist und eine IP gesperrt ist, greift der Block auf allen Pfaden.- Ausnahme:
alwaysAllowedIPsund ggf.nonRelevantPaths(z. B. für statische Fehlerseiten, Health-Checks/health).- Vorteile:
- Maximale Verständlichkeit: Ein Schalter, keine regex-Verwirrung. Jeder versteht sofort: „Zähle auf relevantPaths, aber sperre bei Alarm den ganzen Server.“
- Geringe Implementierungskomplexität: Nur ein Boolean-Flag im Valve.
- 95 % aller Use Cases abgedeckt: Wer Login/API schützt, will in der Praxis fast immer den kompletten Client aussperren, nicht nur eine Teilmenge anderer URLs.
- Perfekt für den Config-Helper: Ein einfacher Schalter („Serverweite Sperre bei Limitüberschreitung“).
- Nachteile:
- Keine feingranulare Auswahl (nur „alles oder nur relevantPaths“).
Ansatz B: Ein zweites Muster
pathsForBlocking(oderenforcementPaths)
- Wie es funktioniert:
Ein zusätzlicher regulärer Ausdruck, der definiert, für welche Pfade ein bestehender Block greift.- Zu deiner Frage: Zusätzlich oder Ausschließlich?
- Ausschließlich: Wäre fatal und fehleranfällig! Wenn jemand
relevantPaths="^/login"konfiguriert undpathsForBlocking="^/api/.*", dann wäre der Angreifer für/api/gesperrt, könnte aber/loginfröhlich weiter attackieren (weil/loginnicht inpathsForBlockingsteht). Der Nutzer müsstepathsForBlockingimmer als Superset vonrelevantPathspflegen.- Zusätzlich (Union): Wenn überhaupt dieser Ansatz, dann zwingend zusätzlich (effektiver Blockbereich =
relevantPaths$\cup$pathsForBlocking).- Vorteile:
- Maximale theoretische Flexibilität (z. B. Zählen auf
/login, Sperren auf/loginund allen/api/*, aber öffentlicher Blog/blog/*bleibt erreichbar).- Nachteile:
- Hohe kognitive Last für den Nutzer: Nutzer müssen dann das Zusammenspiel von bis zu 3 Regex-Filtern verstehen:
relevantPaths(Zählung + Default-Block)pathsForBlocking(Zusatz-Block)nonRelevantPaths(Ausnahmen)- Schwere Fehleranalyse: Wenn ein Request geblockt oder nicht geblockt wird, muss der Admin 3 Regex gegeneinander abgleichen.
- Komplexität in Doku & Konfigurator: Deutlich höherer Erklärungsbedarf.
4. Empfehlung und elegantes Lösungsdesign
Wenn man das Verhältnis aus Nutzen, Implementierungsaufwand und Nutzerverständlichkeit abwägt, empfehle ich folgendes Vorgehen:
Empfehlung: Ein Schalter mit klarem Namen, z. B.
serverWideBlocking(Default:false)
- Semantik:
relevantPaths: Definiert weiterhin die Inspektions-Pfade (wo Angriffe gemessen werden).serverWideBlocking="false"(Default, 100 % abwärtskompatibel): Sperrung greift nur aufrelevantPaths.serverWideBlocking="true": Sobald eine IP das Limit überschreitet, wird sie für jede Anfrage an den Server abgewiesen.- Rolle von
nonRelevantPaths:
- Bleibt die übergeordnete Ausnahme / Whitelist für Pfade.
- Wenn
serverWideBlocking="true"aktiv ist, kann der Admin übernonRelevantPathsweiterhin z. B./health,/erroroderrobots.txtexplizit freihalten, selbst wenn ein Client geblockt ist.- Ablauf in
isRequestAllowed(ip, requestURI):1. Ist IP in alwaysForbidden? -> Block 2. Ist IP in alwaysAllowed? -> Allow 3. Ist URI in nonRelevantPaths? -> Allow 4. Wenn serverWideBlocking == true: Ist IP aktuell gesperrt? (isIPAddressCurrentlyBlocked, NUR lesend!) -> Block 5. Ist URI NICHT in relevantPaths? -> Allow (weder Zählung noch Block) 6. Zählen & Prüfen (isIPAddressBlocked): Wenn Schwellwert überschritten -> Block Sonst -> AllowFazit
- Die Idee ist hervorragend und schließt eine echte funktionale Lücke.
- Der Schalter-Ansatz (
serverWideBlocking) schlägt denpathsForBlocking-Ansatz in punkto Verständlichkeit, Fehlertoleranz und Wartbarkeit um Längen, während er nahezu alle praktischen Anwendungsfälle abdeckt.
Das sind fast 800 Worte in 100 Zeilen Markdown mit zahlreichen Formatierungen.
Für mich hat sich der Stil eine Aufgabe bzw. ein Ziel erst einmal mehr oder weniger offen zu beschreiben und dann die KI um eine Einschätzung zu bitten wieder sehr bewährt. Aber er hat den Preis, dass man dann auch meist sehr viel Einschätzung bekommt und die verarbeiten muss. Ich habe in der Entwicklungszeit nie mehr als 2 parallele Konversationsstränge geführt, da ich einfach mehr Zeit mit dem Lesen und Bewertungen der Antworten und Vorschläge brauchte, als die Agenten dann mit der Umsetzung.
Aber ich habe hier auch wahnsinnig viel gelernt! Gerade die Aspekte der threadsicheren, aber möglichst lockfreien Programmierung sind mir aus meiner früheren Arbeit nicht so geläufig und Dinge wie AtomicBoolean, VarHandle, LongAdder oder ReentrantLock waren mir vorher kaum geläufig oder sogar komplett unbekannt.
In gewisser Weise haben sich die langen Auseinandersetzungen mit den Vorschlägen der KI, immer mit der Möglichkeit sich zu unbekannten Konzepten einmal einen Mockup des damit möglichen Codes generieren zu lassen, für mich als eine Art Crashkurs in diesen Konzepten erwiesen.
Es ist schwer abzuschätzen, wie viel Text ich in dieser Zeit gelesen und geschrieben habe, aber in der Statistik oben ist von über 100 Interationen die Rede und auch wenn nicht alle so umfangreich waren, wie die hier gezeigte, so waren auch noch umfangreichere dabei.
Die neue Aufgabe in der Softwareentwicklung
Für mich hat sich der Fokus der Softwareentwicklung hier ganz stark verschoben: Weg von der meist undokumentierten und nur im Kopf stattfindenden Überlegung und Konzeption gefolgt von der schrittweisen, vielleicht explorativen Abbildung in selbst geschriebenen Code.
Hin zu einer schrittweisen, schriftlichen Konzeption, die man zusammen mit der KI weiterentwickelt und diskutiert, bis sich ein reifer Implementierungsplan entwickelt, der dann von der KI umgesetzt und dokumentiert werden kann. Und dessen Ergebnisse man einem Review unterzieht und ggf. noch einmal korrigieren lässt.
Der Umgang mit dem Code fokussiert sich hier auf die Kontrolle und das übergreifende Verständnis, und geht weg vom selbst eintippen.
Kleine, überschaubare Schritte sind wichtig
- Ich habe bei den Umbauten am Java Code weiter das Prinzip verfolgt Änderungen schrittweise zu machen und nach jedem Schritt den Code zu reviewen und mir dadurch auch wieder anzueignen, da so mein Verständnis erhalten geblieben ist. Ich wäre auch nach diesen zahlreichen Änderungen in der Lage den Java Code direkt weiterzuentwickeln
- Für jeden absolvierten Schritt wurde entsprechend auch ein Commit gemacht, damit sich die darauf aufbauenden Schritte sauber trennen und ggf. wieder zurückrollen lassen. Hier gab es auch tatsächlich einen Punkt, an dem ich kurz darüber nachdachte alles wieder wegzuwerfen, bevor es sich dann doch hat retten lassen
- Warum spreche ich hier immer vom Java Code? Weil es mit dem Konfigurationshelfer nun auch einen umfangreichen HTML Code gibt, in den ich überhaupt keinen Blick geworfen habe. Hier habe ich getestet und Fehler durch die KI beheben lassen, aber mir nicht den Aufwand gemacht im Detail zu verstehen, wie es programmiert wurde. Ich kann das für mich so rechtfertigen, dass diese Code nicht in den Servern zum Einsatz kommt und eventuelle Fehler hier nicht kritisch sind
KI erzeugt guten, aber nicht perfekten Code
- Das zuvor beschriebene, schrittweise Vorgehen hat es mir ermöglicht Probleme in dem generierten Code zu finden. Damit meine ich weniger echte Fehler in der Programmierung, durch die Unittests hat die KI meist schon selbst bemerkt, wenn etwas nicht mehr funktioniert
- Es ging eher darum Unsauberkeiten zu erkennen, z. B. wenn durch Refactorings nicht mehr wirklich benötigte Teile entfernt werden können um den Code übersichtlicher zu halten
- Es hat glaube ich auch geholfen die KI bei Weiterentwicklungen immer nach der Komplexität des notwendigen Codes zu fragen, wenn verschiedene Optionen diskutiert wurden. Nach meinem Eindruck ist dies dann von der KI mehr oder weniger von selbst als Ziel beibehalten worden
- In den späteren Schritten hat die KI auch damit begonnen Kommentierungen im Code zu machen, die ich wirklich hilfreich fand. Hier finden sich zum Beispiel konzeptionelle Hinweise (Reduktion des Speicherbedarfs, etc.), die sonst nicht im Projekt abgebildet wird
- Trotzdem ist es nicht so, dass die KI sofort zu den Lösungen kommt, bei denen man ganz am Ende landet. Ein Beispiel ist diese Entwicklung:
- In einer Klasse AntiDosCounter war der Status locked ein noch nicht volatile, was die KI richtigerweise als Fehler anmerkte
- In folgenden Schritten wurde ein AtomicInteger ergänzt, welches einen Zähler für die Bereinigung mitbrachte. Dies sollte den Umgang mit der Bereinigung von vollen AntiDoSSlot-Objekten verbessern
- Im nächsten Schritt, in dem ich mit der KI den Speicherverbrauch optimieren wollte, wurde dann u. a. dieses Objekt kritisiert und nun zusammen mit anderen durch VarHandle ersetzt
- Dieses Beispiel zeigt denke ich, dass es im Dialog mit der KI um iterative Verbesserungen geht, ähnlich wie man es auch selbst macht, wenn man sich nach und nach an ein Ziel heranarbeitet, ohne gleich alles von rechts auf links ziehen zu wollen
Unittests, immer wieder Unittests
- Ich habe das Valve mit dem expliziten Ziel entwickelt ein möglichst vollständig Abbeckung mit Unittests zu erreichen. Nur so kann in einer Komponente, die auf der einen Seite betriebskritisch ist, sich aber auf der anderen Seite manuell kaum sinnvoll testen lässt, eine hohe Zuverlässigkeit erreichen
- Die KI hat diese Unittests konsequent genutzt und auch weiterentwickelt, wenn Verhältensänderungen und neue Funktionen hinzukamen, so dass die Anzahl der Testcases nun 60 übersteigt. Beim Start der Arbeiten waren es erst ca. 20
- Warum sich die KI direkt auf die Unittests konzentriert hat ist mir nicht klar. Ob es einfach daran lag, dass es dieses Tests schon gab, oder das die README davon spricht, dass eine hohe Testabdeckung das Ziel ist?
- Jedenfalls musste ich die KI nicht auffordern Testcases zu entwickeln und sie hat dann auch für komplexe Szenarien, in denen Zugriffe durch mehrere Threads benötigt werden um eine Anpassung zu testen, entsprechenden Code erzeugt
- Auch hier gab es aber mindestens einen Fall, in dem ein fehlerhafter Test angelegt wurde. Das hat die KI erst bemerkt beim Abbarbeiten der Codehinweise, die VS Code gab. Der Aufruf des Befehls @current_problems, durch den die dazu aufgefordert wird alle diese Hinweise zu bearbeiten, brachte die KI dazu nochmal nachzudenken und den Fehler zu bemerken
- Vom Risiko, dass KI unvollständige Unittests erzeugt, liest man auch an anderer Stelle. Allerdings ist mein Eindruck aus den gemachten Reviews, dass die Qualität normalerweise gut ist
- KI löst auch ein Problem, welches einen früher vielleicht gebremst hat bei der Anlage von Unittests bzw. bei Refactorings von Methoden, die in zahlreichen Unittests verwendet werden: Selbst Umbauten, die die Art des Aufrufs grundlegend verändern und die sich nicht mit klassischen Mitteln des Refactorings gut lösen lassen erledigt die KI ohne Probleme
- Ich habe mir daher vorgenommen für meine nächsten Projekte noch stärker auf Unittests zu setzen, da sie sich nun noch leichter als bisher entwickeln und pflegen lassen
Fragen lohnt sich
- Es lohnt sich immer mal wieder die KI zu fragen, ob sie in Hinblick auf Querschnittsaspekte wie Sicherheit oder Performance im Code Verbesserungspotentiale sieht
- Nach meiner Erfahrung muss man hier nicht zwischen Sprachmodellen wechseln oder die Antigravity Konversation wechseln oder gar ein komplett anderes Tool nehmen
- Für mich hat es sich eher bewährt, dass noch der Kontext vorhanden war, warum eine bestimmte Änderung mal gemacht wurde und welche Trade-offs damit verbunden ware. Gerade bei Optimierungsfragen gibt es oft nicht die eine Lösung, die konkurrierende Aspekte wie geringen Verbrauch aller denkbaren Ressourcen, Sicherheit und überschaubare Code Komplexität optimal erfüllen.
- Hier ist es gut, wenn die KI nicht einfach gedächtnislos auf das aktuelle Ziel losstürzt, sondern noch weis, warum der Code so ist, wie er heute ist
Schmeichelei
- Sie bleibt ein Problem bei den heutige KI-Lösungen, wie man am Beispiel im vorherigen Abschnitt sehen kann: Jeder Vorschlag und jede Idee ist ganz hervorragend und wird gelobt, selbst wenn sie in den Details der langen Antworten danach vielleicht zerpflückt wird. Und es ist ja nicht so, dass die KI nicht meinungsstark wäre und Kritik üben kann
- Ich bin selbst unsicher, in wie weit mich das bei der Arbeit in Antigravity beeinflusst: Gibt es mir unterschwellig ein gutes Gefühl und Selbstbewusstsein? Oder stimmt mein bewusstes Gefühl davon eher etwas genervt zu sein?
- Es ist hier glaube ich wichtig sich selbst zu beobachten und ob dieser Umgang etwas mit einem macht, sowohl in Hinblick auf die Selbsteinschätzung wie auch auf das Vertrauen in die Kompetenz der KI: Kann es geschehen, dass einem die KI so sympathisch wirb, dass man ihr keine Fehler mehr zutraut oder Hemmungen entwickelt ihre Ergebnisse zu kritisieren, wie es einem bei einem Menschen vielleicht passieren würde, den man mag?
Fazit: Alles ist sehr schnell und fast alles ist sehr anders
Ich bin ganz glücklich mit dem Stand, den das Valve nun erreicht hat, und glaube es gibt einem beim Schutz der eigenen Tomcat Server gegen die neuen Bedrohungen Möglichkeiten an die Hand, die bisher gefehlt haben. Und man muss ehrlich sagen, dass ich ohne KI-Unterstützung nicht so weit gekommen wäre und vermutlich Dinge wie den Konfigurationshelper gar nicht erst angegangen wäre.
Diese 3 Tage Entwicklung haben sich dabei – auch wenn ich fast keinen Code angefasst habe – nach anstrengender und anspruchsvoller Arbeit angefühlt: Ich habe viel konzipiert, sehr viel gelesen und verarbeitet, einiges gelernt und die Richtung vorgegeben, in die sich das Produkt entwickelt.
Ich sehe es daher nicht so, dass die KI mit als erfahrenen Softwareentwickler überflüssig macht. Sie verlagert aber sehr stark welche Kompetenzen ich genutzt habe in dieser Zeit. Die Frage, die ich heute noch nicht beantworten kann ist dabei die, ob ich meine Fähigkeit den von der KI generierten Java Code tief zu verstehen und zu reviewen in dieser neuen Vorgehensweise behalten werde, oder ob es dafür notwendig wäre doch hin und wieder selbst Code zu schreiben. Oder muss ich Zukunft nur noch um so genauer beschreiben, was der Code tun soll und wie er über Tests abzusichern ist?
Das ist ein offener Punkt und er betrifft denke ich auch sehr die Frage, wie noch in Studium und Ausbildung befindliche Informatiker*innen den Einstieg in eine Berufswelt schaffen können, die sich radikal verändert.