- Hogarama
- KI
Systemanalyse mit KI: So viel hatten wir selbst nicht mehr im Blick
„KI-gestützte Systemanalyse – so haben wir Legacy-Code entzaubert“ – oder wie wir mit KI verlorenes Wissen wiederentdecken – ein Learning Friday Projekt, das echten Mehrwert für Software-Modernisierungsprojekte liefert.
Ausgangslage: Die Herausforderung der Software-Modernisierung
Bei der Software-Modernisierung stehen wir oft vor einer großen Herausforderung: Alte Legacy-Systeme mit Millionen Lines of Code, veraltete Technologien und fehlende Dokumentation. Die ursprünglichen Entwickler:innen sind nicht mehr verfügbar und das Wissen über Systemarchitektur und Zusammenhänge ist verloren gegangen.
Genau hier wollten wir mit unserem Learning Friday Projekt „AI-gestützte Systemanalyse“ ansetzen. Unser Ziel war: Herausfinden, ob und wie KI-Agenten uns dabei helfen können, verloren gegangenes Systemwissen wiederherzustellen und Modernisierungsprojekte effizienter zu gestalten.
Was wir uns erhofft haben
Jeder aus unserem Team hatte eine klare Erwartung:
-
Egor: „Ich will ein vollständiges Überblicksdokument mit Systemarchitektur, Komponenten und deren Zusammenhänge. Dazu detaillierte Beschreibungen der Maven-Module, Release-Zyklen und Deployment-Prozesse. Ich möchte wissen, wie ich die lokale Entwicklungsumgebung aufsetzen kann, welche Umsysteme ich anbinden muss und welche Testinstanzen es gibt.“
-
Christian: „Ich will automatisch generierte Diagramme, Erkennung von Architekturstilen und konsistente Dokumentation, die sich nur bei Code-Änderungen aktualisiert. Außerdem möchte ich einen Ansatz mit Target-Templates testen: ‚Hier ist eine Beispieldokumentation – erstelle etwas Ähnliches für unser System.‘ „
-
Mattias: „Ich will mit natürlicher Sprache Fragen ans System stellen, einen Conversational Agent, der Fragen zum System beantwortet und eine natürliche Sprachsuche ermöglicht – so wie: ‚Wo wird die Zahlungsvalidierung durchgeführt?‘ “
Der praktische Test mit Claude Code
Als Testobjekt wählten wir unser Open-Source-Projekt Hogarama – ein System zur automatischen Pflanzenbewässerung mit verteilter Architektur. Mit Claude Code (Agent von Anthropic) machten wir uns an die Arbeit.
Was gut funktionierte
// Dokumentation und Überblick erstellen
Nach dem Befehl „Lese Wiki-Seiten zum System und schreibe ein kurzes Dokument für neue Entwickler:innen“ analysierte der Agent 17 Wiki-Dateien und erstellte diese strukturierte Zusammenfassung:
# Hogarama - Einführungsdokument für neue Entwickler ## Überblick Hogarama ist ein Showcase-Projekt von Gepardec, das als Demonstrationsplattform für OpenShift und verschiedene Technologien dient. Das System ermöglicht die Überwachung und Steuerung von Pflanzen mittels Sensoren und Aktoren. ## Architektur Das System besteht aus drei Hauptkomponenten: - **Sensornetzwerk** (Raspberry Pi mit Sensors/Aktoren) - **Cloud-Kontrollserver** (OpenShift-basiert) - **Client-Anwendung** (Web/Mobile) ## Kernkomponenten - **AMQ/Kafka**: Messaging-Systeme für die Kommunikation - **MongoDB**: Speicherung der Sensordaten - **PostgreSQL**: Management-Daten und Konfiguration - **Hogajama**: Backend (Java EE) und Frontend (Angular/Ionic) - **Keycloak**: Single-Sign-On und Identity Management ## Erste Schritte 1. Repository klonen 2. Einrichtung der Entwicklungsumgebung wählen (Docker oder lokal) 3. Kompilieren mit entsprechenden Profilen: `mvn clean install -P security-dummy,messaging-rest` 4. Docker-Container starten: `cd Docker-Infrastructure && docker-compose up -d`
// Fehlerdiagnose und Troubleshooting
Bei konkreten Problemen lieferte der Agent detaillierte, praxisnahe Anleitungen. Auf die Frage „Bei uns funktioniert ein Feuchtigkeitssensor bei einer Pflanze nicht. Wo kann ich anfangen?“ kam diese strukturierte Antwort:
## Fehlersuche bei Feuchtigkeitssensoren ### Hardware-Komponenten - Sensor: YL-69 (Sonde) und YL-39 (Logikeinheit) oder SparkFun Bodenfeuchtesensor - Analog-Digital-Wandler: MCP3008 Chip (nötig, da Raspberry Pi keine analogen Eingänge hat) - Steuerungseinheit: Raspberry Pi 3 Model B+ ### Überprüfen der Verkabelung 1. Sensor-Verbindung prüfen: - VCC → 3.3V vom Raspberry Pi - GND → Raspberry Pi Ground - A0 → Kanal 0 am MCP3008 Chip 2. MCP3008 Verbindung prüfen: - VDD/VREF → 3.3V - AGND/DGND → Ground - CLK → Pin #23 (SCLK) - DOUT → Pin #21 (MISO) - DIN → Pin #19 (MOSI) - CS/SHDN → Pin #24 (CE0) ### Software-Diagnose 1. Log-Dateien prüfen: - SSH auf den Raspberry Pi - Logs anzeigen: sudo journalctl -u habarama -f - Suche nach Debug-Meldungen wie: "ADC Sensor: 'SensorName' Output: 523" ### Manuelle Sensorprüfung 1. Mit einem Multimeter den Widerstand des Sensors messen 2. Sensor in trockene und feuchte Erde stecken und Werte vergleichen 3. Überzeugen Sie sich, dass die Sensorsonde nicht korrodiert ist
// Lokale Entwicklungsumgebung aufsetzen
Beim Versuch, die lokale Entwicklungsumgebung einzurichten, war der Agent auch extrem hilfreich. Der Dialog verlief etwa so:
Entwickler: „Ich will jetzt lokal entwickeln. Ich brauche eine Umgebung, wo ich das Backend und Frontend starten kann.“
Agent: „Um lokal zu entwickeln, richte eine Umgebung mit JBoss und simulierten Sensoren wie folgt ein…“
Entwickler: „http://localhost:8080/hogajama ist 404, alle anderen auch“
Der Agent führte dann selbstständig verschiedene Diagnose-Befehle aus:
# Prüfe ob der Server läuft curl -I http://localhost:8080 # HTTP/1.1 200 OK - Server läuft! # Suche nach context-root Konfigurationen Search(pattern: "context-root", include: "*.xml") # Prüfe verschiedene Context-Pfade curl -I http://localhost:8080/hogajama-rs # HTTP/1.1 302 Found # Überprüfe Deployment-Verzeichnis ls -la ~/jboss-hogajama/standalone/deployments/ # Nur README.txt vorhanden - keine WAR-Dateien!
Und lieferte dann die konkrete Lösung:
Ich sehe, dass der JBoss-Server läuft, aber es scheinen keine Anwendungen deployt zu sein. Die WAR-Dateien sind erstellt worden, aber nicht im Deployment-Verzeichnis des JBoss. Hier sind die Schritte, um die Anwendung zu deployen: 1. Kopiere die kompilierten WAR-Dateien ins Deployment-Verzeichnis: cp Hogajama/hogajama-rs/target/hogajama-rs-0.0.1-SNAPSHOT.war ~/jboss-hogajama/standalone/deployments/ cp Hogajama/hogajama-frontend/target/hogajama-frontend-0.0.1-SNAPSHOT.war ~/jboss-hogajama/standalone/deployments/ cp Hogajama/hogajama-angular-frontend/target/hogajama-angular-frontend-0.0.1-SNAPSHOT.war ~/jboss-hogajama/standalone/deployments/ 2. Warte ein paar Augenblicke, bis die Anwendungen deployt sind. 3. Dann solltest du auf die Anwendungen zugreifen können unter: - http://localhost:8080/ (Frontend) - http://localhost:8080/hogajama-rs (REST-Services) - http://localhost:8080/unitmanagement (Angular-Frontend)
Obwohl der Schluss “Ich sehe, dass der JBoss-Server läuft, aber es scheinen keine Anwendungen deployt zu sein” falsch ist (wie oben zu sehen ist etwas deployed), waren die zwei letzten URLs tatsächlich korrekt.
// Verstehen komplexer Systemnamen
Der Agent half auch beim Verständnis der verwirrenden Namenskonventionen im Projekt.
Frage: „Ich sehe immer unterschiedliche Namen wie Hogarama, Habarama, Hogajama etc. Was ist das alles?„
Antwort des Agents:
## Erklärung der verschiedenen Namen im Projekt ### Hogarama - Bedeutung: Home and Garden Automation (Heim- und Gartenautomatisierung) - Rolle: Name des Gesamtprojekts/Systems - Zweck: Showcase-Projekt von Gepardec für OpenShift-Technologien ### Habarama - Rolle: Komponente für die Datensammlung und Gerätesteuerung - Technologie: Python-Code, der auf Raspberry Pis läuft - Verantwortlichkeit: - Sammelt Sensordaten (Feuchtigkeit, etc.) - Steuert Aktoren (Pumpen) - Sendet Daten via MQTT an das Backend - Verzeichnis: /Habarama im Repository ### Hogajama - Rolle: Backend- und Frontend-Komponente - Technologie: Java EE/Jakarta EE Backend + Angular/Ionic Frontend - Verantwortlichkeit: - Verarbeitet eingehende Sensordaten - Speichert Daten in MongoDB/PostgreSQL - Entscheidet über Bewässerungsaktionen - Bietet REST-APIs und Benutzeroberfläche - Verzeichnis: /Hogajama im Repository
// Sensor-Daten interpretieren
Besonders hilfreich war die Interpretation von Rohwerten. Auf die Frage „Da sehe ich die Zahlen wie 809, 811 etc. Was bedeuten sie?“ erklärte der Agent:
Die Zahlen (809, 811) sind Rohwerte der Feuchtigkeitssensoren vom ADC (Analog-Digital-Wandler). So interpretierst du sie: 1. Die Werte liegen im Bereich 0-1023 (10-Bit-Auflösung) 2. Bei den Feuchtigkeitssensoren gilt: - Höhere Werte (800-1023): trockener Boden - Niedrigere Werte (0-200): feuchter Boden 3. Umrechnung in Feuchtigkeit (prozentual): - Feuchtigkeit = 1 - (Rohwert/1024) - Bei 809 → Feuchtigkeit = 1 - (809/1024) ≈ 0,21 oder 21% - Bei 811 → Feuchtigkeit = 1 - (811/1024) ≈ 0,21 oder 21% Diese Werte sind also ein Hinweis auf recht trockenen Boden. Das System nutzt sie für Bewässerungsentscheidungen, typischerweise wenn der normalisierte Wert unter 0,2 (20%) fällt.
Das stimmt nicht zu 100%, da es am Sensor-Typ liegt, ob hohe Werte hohe Feuchtigkeit bedeuten oder umgekehrt. Das ist aber jedenfalls eine wertvolle Information für diejenigen, die noch wenig Know-How über das System haben.
// Ansible-Rolle im System verstehen
Der Agent konnte auch die Rolle von Tools im System erklären:
## Rolle von Ansible im Hogarama-System ### 1. Automatisierte Raspberry Pi-Konfiguration Ansible automatisiert die Einrichtung der Raspberry Pi-Geräte als Sensordaten-Sammler und Aktor-Steuereinheiten. ### 2. Hauptaufgaben der Ansible-Skripte - **Netzwerkkonfiguration**: WLAN-Verbindungen und statische IPs - **SSH-Einrichtung**: Installation von SSH-Schlüsseln - **Sensorclient-Installation**: - Aktiviert SPI-Hardware-Schnittstelle - Installiert Python-Abhängigkeiten (Adafruit_Python_GPIO, paho.mqtt.python) - Erstellt Konfigurationsdatei (habarama.json) - Richtet systemd-Dienst ein ### 3. Setup-Prozess für neue Geräte 1. Raspbian-Installation auf dem Raspberry Pi 2. SSH aktivieren 3. Ansible-Inventory-Datei anpassen 4. Playbook ausführen: ansible-playbook main.yml -i inventory.yml
// Sensor-Daten simulieren
Der Agent half auch bei der Konfiguration der Testumgebung:
Frage: „Wie simuliere ich die Sensordaten?“
Du kannst Sensordaten auf verschiedene Arten simulieren: 1. Raspberry-PI-Mocks CLI - dies ist der einfachste Weg: cd Hogajama/raspberry-pi-mocks/raspberry-pi-mocks-cli 2. Je nach Konfiguration deiner Umgebung: - Für REST: ./mock-cli-rest.sh - Für Kafka: ./mock-cli-kafka.sh - Für AMQ: ./mock-cli-amq.sh 3. Oder direkt mit Java: java -jar target/raspberry-pi-mocks-cli-0.0.1-SNAPSHOT-jar-with-dependencies.jar --config=examples/restTestConfig.prop
// Testen von Raspberry PI Komponenten in Hogarama
Die Herausforderung
Das Herzstück der Habarama-Komponente ist das plant.py Skript, welches:
- Feuchtigkeitssensoren über einen MCP3008 ADC ausliest
- Aktoren (Wasserpumpen) über GPIO-Pins steuert
- Sensordaten via MQTT an das Backend sendet
- Auf Steuerbefehle vom Backend reagiert
Die Herausforderung bestand darin, diese Hardware-nahen Funktionen ohne echte Raspberry Pi Hardware zu testen.
Die Agent Strategie aufbereitet als Dokumentation
Es wurde der Agent dazu verwendet, um zuerst alle Python-Dateien im Repository zu finden und zu identifizieren welche Python-Dateien relevant sind. Hierbei wurde die plant.py Datei identifiziert und der Agent wurde aufgefordert Unit-Tests zu schreiben und dies in einer Dokumentation zu gestalten:
Test Strategie Resultat
=== Unsere Teststrategie
Wir haben einen zweistufigen Ansatz entwickelt:
==== 1. Vollständige Unit-Tests (`test_plant.py`)
Diese umfassende Test-Suite deckt alle Komponenten ab:
[source,python]
----
class TestActor(unittest.TestCase):
"""Test suite for the Actor class."""
def test_do_water_success(self, mock_log, mock_sleep):
"""Test successful water activation."""
actor = plant.Actor(self.gpio_actor_config)
# Test watering for 3 seconds
actor.do_water(3)
# Verify GPIO operations and timing
mock_sleep.assert_called_once_with(3)
----
Die Tests nutzen Mocking für:
* `RPi.GPIO` - GPIO-Operationen
* `Adafruit_MCP3008` - Analog-Digital-Wandler
* `paho.mqtt.client` - MQTT-Kommunikation
==== 2. Standalone-Logiktests (`test_plant_standalone.py`)
Da das originale `plant.py` noch in Python 2 geschrieben ist, haben wir zusätzlich Standalone-Tests entwickelt:
[source,python]
----
def test_moisture_value_interpretation(self):
"""Test interpretation of moisture sensor values"""
# Trockener Boden
dry_value = 809
moisture_percent = 1 - (dry_value / 1024)
self.assertAlmostEqual(moisture_percent, 0.21, places=2)
# Feuchter Boden
wet_value = 100
moisture_percent = 1 - (wet_value / 1024)
self.assertAlmostEqual(moisture_percent, 0.90, places=2)
----
=== Testabdeckung
Unsere Tests decken folgende Bereiche ab:
.Testbereiche
[cols="1,3"]
|===
|Bereich |Details
|Kommandozeilen-Argumente
|Parsing von `-w` (Bewässerung) und `-d` (Dauer) Optionen
|Sensor-Datenformat
|JSON-Struktur und Wertebereich (0-1023)
|MQTT-Kommunikation
|Verbindungsaufbau, Reconnect-Logik, Topic-Subscription
|Actor-Steuerung
|GPIO-Pin Kontrolle, Thread-Sicherheit, Zeitsteuerung
|Konfiguration
|Laden und Validierung der `habarama.json`
|===
=== Ausführung der Tests
Die Tests können einfach ausgeführt werden:
[source,bash]
----
# Standalone-Tests (funktioniert mit Python 2 plant.py)
cd Habarama/ansible/files
python3 -m unittest test_plant_standalone.py -v
# Oder mit dem bereitgestellten Skript
./run_tests.sh
----
.Testergebnis
----
test_moisture_value_interpretation ... ok
test_sensor_data_json_format ... ok
test_mqtt_connection_parameters ... ok
...
----------------------------------------------------------------------
Ran 11 tests in 0.001s
OK
----
=== Erkenntnisse und Ausblick
Die Entwicklung der Tests hat mehrere wichtige Erkenntnisse gebracht:
. **Python-Version**: Das `plant.py` Skript sollte auf Python 3 migriert werden
. **Hardware-Abstraktion**: Durch Mocking können Hardware-Komponenten effektiv simuliert werden
. **Kontinuierliche Integration**: Die Tests ermöglichen CI/CD ohne physische Hardware
=== Fazit
Mit diesem Testansatz haben wir eine solide Grundlage für die Qualitätssicherung der Habarama-Komponente geschaffen. Entwickler können nun Änderungen am Code vornehmen und sofort verifizieren, dass die Kernfunktionalität weiterhin gewährleistet ist - ganz ohne Raspberry Pi auf dem Schreibtisch.
[TIP]
====
Die vollständige Test-Suite und Dokumentation finden Sie im Repository unter `/Habarama/ansible/files/`. Die README_TESTS.md enthält detaillierte Anleitungen zur Ausführung und Erweiterung der Tests.
====
Im Repository wurden diese Dateien erstellt:
- test_plant.py - Full test suite with 20+ test cases - test_plant_standalone.py - Python 2 compatible standalone tests - requirements-test.txt - Test dependencies - run_tests.sh - Test runner script - README_TESTS.md - Test documentation
Was weniger gut funktionierte
// Subtile Fehler finden
Wir bauten einen subtilen Fehler in ein Python-Script ein – beispielsweise eine fehlerhafte Bit-Shifting-Operation oder falsche ADC-Wert-Translation. Der Agent fand zwar offensichtliche Syntaxfehler, hatte aber Schwierigkeiten mit logischen Fehlern:
Agent (initial): „Der Fehler liegt in Zeile 42, die Bit-Operation ist falsch.“
Entwickler: „How do I make sure this is an issue?“
Agent (widersprüchlich): „Bei näherer Betrachtung ist es doch kein Fehler, sondern ein Fix.“
// Automatische Diagrammerstellung
Trotz der Fähigkeit, Markdown-Diagramme zu erstellen, waren diese oft zu simpel für die tatsächliche Systemkomplexität. Detaillierte Architekturdiagramme mit allen Komponenten und Datenflüssen müssten weiterhin manuell erstellt werden.
// Setup ohne vorhandene Dokumentation
Bei Aufgaben, für die keine Dokumentation existierte (wie das Aufsetzen einer komplett neuen Entwicklungsumgebung), konnte der Agent nur generische Vorschläge machen. Die spezifischen Konfigurationsdetails mussten durch Trial-and-Error gefunden werden.
Unsere wichtigsten Erkenntnisse
Erfüllte Erwartungen
- Systemüberblick und Dokumentation: Exzellente Zusammenfassung vorhandener Informationen
- Konkrete Hilfestellung: Praktische Anleitungen für Fehlersuche und Systemverständnis
- Debugging-Unterstützung: Systematische Fehleranalyse mit konkreten Lösungsvorschlägen
- Wissensextraktion: Effiziente Konsolidierung verteilter Dokumentation
- Kontextuelles Verständnis: Gute Erklärungen von Zusammenhängen und Konzepten
Nicht erfüllte Erwartungen
- Automatische Diagrammerstellung: Nur einfache ASCII-Diagramme möglich
- Tiefgehende Code-Analyse: Kontextlimit bei großen Codebasen
- Komplexe Logikfehler: Schwierigkeiten bei subtilen Programmierfehlern
Kosten und praktische Überlegungen
Die Nutzung war überraschend kostengünstig: etwa 5$ für 1,5 Stunden intensiver Arbeit (ohne viel Code-Generierung). Dies macht den Einsatz auch für kleinere Teams attraktiv. Beim typischen Stundensatz eines Entwicklers amortisiert sich der Einsatz bereits, wenn nur wenige Stunden Arbeitszeit eingespart werden.
Einschränkungen: dies gilt nur für bestimmte Arbeiten. Beispiele sind das schnelle Erlangen eines Überblicks über ein unbekanntes bzw. schlecht dokumentiertes System, sowie das Erstellen einfacher Codestücke, Konfigurationen, etc. Bei Aufgaben von etwas höherem Schwierigkeitsgrad, die nicht dem üblichen Standard entsprechen oder darüber hinausgehen, ist es sehr einfach, mehr Zeit zu verlieren als bei klassischen Vorgehensweisen (z.B. stackoverflow, google). Unsere subjektive Einschätzung ist, dass das verstärkt für erfahrene Entwickler gilt.
Kostenersparnis durch Wiederverwendbarkeit
Bei arbeits-/tokenbasierten Kosten ist Wiederverwendbarkeit ein wichtiges Thema: wenn eine Abfrage 5$ kostet, will man für dieselbe Abfrage auch nur ein Mal den vollen Preis bezahlen. Bei der Entwicklung stellen sich jedoch, gerade bei neuen Entwicklern oder Projekten, tendenziell häufig dieselben Fragen: “Wie implementiere ich ein Feature der Art X?”, “Wo finde ich ein Beispiel für … ?”, etc.
Als Lösungsansatz haben wir uns hier MCP angesehen: wir stellten eine Datenbank zur Verfügung, um gefundene richtige Antworten zu persistieren, versehen mit Keywords. Beispiel: “Store this answer as an FAQ in the mcp DB. Question: Where is the script reading the humidity sensor values? Tags: sensor, values, humidity”.
Das Setup einer read-write MCP-Datenquelle war sehr einfach und erforderte nur wenige Schritte. Verwendet wurde dafür der JDBC-MCP Server von Quarkus in Kombination mit JBang und einer PostgreSQL Datenbank. Die Anbindung des Claude Agent wird hier beschrieben.
Dieser Prozess funktionierte sehr gut und erscheint uns als gangbarer Weg, Kosten zu sparen. Zur sinnvollen Verwendung muss in der Folge ein Agent per Default angewiesen werden, vor aufwändigeren Arbeiten zuerst die Datenbank nach möglichen existierenden Antworten abzusuchen (out-of-scope für dieses Projekt).
Beispiele: Prompts & Kosten
| Prompt | Kosten | Bewertung |
|---|---|---|
| I recall from our earlier sessions that there is a python script reading the sensor values from the humidity sensor, but I dont remember where. the answer should be in one of the files starting with claude-session-log. find it | 0.11 USD | OK, allerdings nur nach Zusatz der Files, in denen zu suchen war |
| Store this answer as an FAQ in the mcp DB. Question: Where is the script reading the humidity sensor values? Tags: sensor, values, humidity" + additional prompt before insert: "replace the absolute path in the answer with a relative one from the project dir | 0.14 USD | OK, auf die Probleme von absoluten Pfaden musste jedoch hingewiesen werden (was für einen Menschen selbstverständlich wäre) |
| I need to find out where an error is happening with the values - could be anywhere, but lets make sure it's not in the script first. check it. | 0.15 USD | OK, mögliche Fehler wurden gelistet |
| Folgeprompt: How do I make sure issue 1 is really an issue? | 0.44 USD | Falsch: die (korrekte) Aussage von zuvor wurde revidiert (“the issue found probably is NOT an issue at all, but an intentional fix”) |
| store the whole current session in claude-session-log_1.MD | 0.27 USD | OK |
Beispiele: Prompts & Kosten, GitHub MCP
Auch die Anbindung des github-Repository mittels github-mcp-server war einfach. Hier ein paar Kostenbeispiele unter dessen Verwendung.
| Prompt | Kosten | Bewertung |
|---|---|---|
| I was assigned #347. Point out where to start and suggest a plan. You can use the github mcp server for info. | 0.64 USD | Teilweise OK: Ergebnis war ein Plan, der größtenteils stimmte und Anmerkungen aus dem Ticket berücksichtigte. Er enthielt auch unnötige Schritte, die den gängigen Antworten im Internet entsprachen, hier aber einfach nicht angebracht waren. |
| where are the sequence generators you're speaking of? | 0.15 USD | OK |
| I get incompatible types: inference variable K has incompatible bounds in file SensorTypeCache. Fix it | 0.37 USD | Unvollständig: nach den Changes musste noch einiges selbst erledigt werden - die IDE-Features waren hier der bessere Weg. Informationen im Ticket wurden hier nicht beachtet (hierzu hätte es wohl einer erneuten Aufforderung bedurft, obwohl es eingangs explizit genehmigt wurde). |
Fazit: KI als wertvoller Assistent, kein Wundermittel
KI-Agenten wie Claude Code können bei der Systemanalyse definitiv unterstützen, besonders wenn:
- Dokumentation vorhanden ist, die konsolidiert werden muss
- Konkrete Fragen zu bestehenden Systemen beantwortet werden sollen
- Debugging-Unterstützung bei Deployment-Problemen benötigt wird
- Standardaufgaben wie README-Erstellung oder Troubleshooting-Guides anstehen
- Systemzusammenhänge erklärt werden müssen
Sie ersetzen jedoch nicht:
- Tiefgehendes Systemverständnis und Architektur-Expertise
- Manuelle Analyse komplexer Legacy-Systeme
- Die Notwendigkeit guter Ausgangsdokumentation
- Kritisches Denken bei der Fehlersuche!!!
Für Modernisierungsprojekte empfehlen wir: KI-Agenten als Werkzeug zur Effizienzsteigerung einsetzen, aber realistische Erwartungen haben. Sie sind hervorragend darin, vorhandenes Wissen zu strukturieren und bei konkreten Problemen zu helfen – die eigentliche Architekturarbeit bleibt aber weiterhin Aufgabe des Menschen.
Unser Tipp: Startet mit kleinen, konkreten Aufgaben und baut schrittweise Vertrauen in die Fähigkeiten des Tools auf. Die Investition von ein paar Stunden Learning Friday kann sich schnell auszahlen!
Bereit, dein Legacy-System neu zu verstehen?
Nutze die Kraft von KI-Agenten, um Dokumentation zu rekonstruieren, Zusammenhänge sichtbar zu machen und dein Team schneller einsatzbereit zu machen.
Ob CI/CD auf OpenShift, JBoss Upgrade oder Secure Java Code Refactoring – wir zeigen dir, wie du verlorenes Wissen zurückholst.
