Eine Antwort auf die Herausforderungen, die in diesem LinkedIn-Post über KI-Kodierassistenten und die Anhäufung technischer Schulden beschrieben werden
In einem kürzlich erschienenen LinkedIn-Beitrag erzählte ein Entwicklungsleiter eine ernüchternde Geschichte: Sein Team lieferte eine Funktion in drei Tagen mithilfe von KI-Codierassistenten aus – eine Aufgabe, die zuvor drei Wochen dauerte. Sechs Monate später konnten sie einen kritischen Fehler darin nicht beheben. Das Team hatte „technische Schulden in dreifacher Geschwindigkeit angehäuft“.
Der Beitrag beschreibt ein vertrautes Muster, das sich in der gesamten Branche abzeichnet: beeindruckende Geschwindigkeitsmetriken, gefolgt von Wartungsalbträumen. KI-generierter Code, der funktioniert, den aber niemand wirklich versteht. Funktionen, die Funktionen in Mustern aufrufen, die niemand kennt. Kommentare, die beschreiben , was der Code tut, aber nicht warum. Keine dokumentierten architektonischen Entscheidungen oder Entwurfsüberlegungen.
Die vorgeschlagene Lösung – die BMAD-Methode – umfasst spezialisierte KI-Agenten, strukturierte Dokumentation, Kontrollmanifeste, doppelte Prüfungen und fortlaufende Hauptbücher. Es ist ein durchdachter Ansatz, der „80 % der Geschwindigkeit beibehält“ und gleichzeitig „100 % der Rückverfolgbarkeit“ wiederherstellt.
Aber es gibt einen alternativen Ansatz, der diese Probleme von vornherein löst, anstatt sie zu verwalten.
Die Low-Code-Alternative
Low-Code-Entwicklungsplattformen umgehen die gesamte Kategorie der im ursprünglichen Beitrag beschriebenen Probleme. Hier ist der Grund dafür:
Visuelle Architektur als lebendige Dokumentation
Im Gegensatz zu KI-generiertem Code, bei dem „niemand den Code versteht“, bieten Low-Code-Plattformen visuelle Darstellungen Ihrer Anwendungsarchitektur. Das Schema, die Beziehungen und die Geschäftslogik werden grafisch modelliert, sodass die Systemstruktur für jeden im Team sofort verständlich ist. Es gibt keine undurchsichtigen Funktionsketten oder unerkennbare Muster mehr – die Architektur ist die Dokumentation.
Deklaratives Design über generierten Code
Mit Low-Code-Tools häufen Sie nicht Tausende von Zeilen KI-generierten Implementierungscodes an. Stattdessen definieren Sie Ihre Anwendung durch hochgradige Abstraktionen:
- Datenmodelle und ihre Beziehungen
- Geschäftslogik durch visuelle Workflows oder eingeschränkte Skriptumgebungen
- UI-Komponenten durch strukturierte Konfiguration
Wenn Sie sechs Monate später Funktionen ändern müssen, arbeiten Sie mit diesen High-Level-Abstraktionen und müssen nicht versuchen, Implementierungsdetails zu entschlüsseln, die niemand in Ihrem Team geschrieben hat oder vollständig versteht.
Inhärente Rückverfolgbarkeit ohne Overhead
Die BMAD-Methode versucht, die Rückverfolgbarkeit durch umfassende Dokumentation, Versionierung und Prozessdisziplin zu verbessern. Low-Code-Plattformen bieten dies standardmäßig. Schemaänderungen werden nachverfolgt und versioniert, Beziehungen zwischen Entitäten sind explizit, und Geschäftsregeln werden in strukturierten, überprüfbaren Formaten definiert.
Graph-basierter Low-Code: Es geht noch weiter
Jetzt wird es erst richtig interessant: nicht alle Low-Code-Plattformen sind gleich.
Herkömmliche Low-Code-Tools verwenden visuelle Darstellungen von High-Level-Abstraktionen, was bereits eine erhebliche Verbesserung gegenüber der Verwaltung von Rohcode darstellt. Aber Plattformen, die die Konfiguration von Low-Code-Laufzeitelementen als zusammenhängenden Graphen speichern – zum Beispiel in einer Graphdatenbank – gehen noch einen Schritt weiter.
Unmittelbar von abstrakten Definitionen ausgehen
In einer graphenbasierten Low-Code-Plattform verfügt Ihre Anwendung nicht nur über eine visuelle Darstellung, die in herkömmlichen Code kompiliert wird. Stattdessen läuft die Anwendung direkt auf der Grundlage der im Graphen gespeicherten abstrakten Definitionen:
- Die Schemadefinitionen
- Die Regeln der Geschäftslogik
- Die Frontend-Elemente
- Die Beziehungen zwischen all diesen Komponenten
Es gibt keine versteckte Implementierungsschicht. Was Sie modellieren, läuft auch. Die Lücke zwischen Entwurf und Laufzeit verschwindet vollständig.
Alles ist miteinander verbunden
In einem System, in dem alle Komponenten einer Anwendung als Knoten und Beziehungen in einem zusammenhängenden Graphen gespeichert sind, können Sie einfach die Beziehungen verfolgen, um zu verstehen, wie alles zusammenpasst:
- Sie möchten sehen, welche Geschäftslogik einen bestimmten Datentyp verwendet? Folgen Sie den Rändern.
- Sie möchten alle UI-Komponenten finden, die bestimmte Daten anzeigen? Verfolgen Sie die Verbindungen.
- Sie fragen sich, was passiert, wenn ein Benutzer eine Aktion auslöst? Gehen Sie den Graphen durch.
Dies ist keine Dokumentation, die nicht mit der Realität übereinstimmen könnte. Es handelt sich um die Realität Ihrer Anwendung, die jederzeit abgefragt und durchsucht werden kann.
KI-Agenten und graphengestützte Konfiguration
Hier ist die entscheidende Erkenntnis für Teams, die KI-Unterstützung nutzen: Für KI-Agenten ist es um Größenordnungen einfacher, mit einem Konfigurationsgraphen zu arbeiten, als eine Textcodebasis für ein Projekt derselben Komplexität zu erstellen und zu pflegen.
Überlegen Sie es sich:
- Strukturierte Daten vs. unstrukturierter Code: Eine Graphdatenbank speichert Ihre Anwendung als strukturierte, typisierte Daten mit eindeutigen Beziehungen. KI muss keine Syntax analysieren, keine Absicht ableiten und keine Architektur erraten – alles ist explizit.
- Atomare, überprüfbare Änderungen: Die Änderung eines Diagrammknotens oder einer Beziehung ist ein diskreter, überprüfbarer Vorgang. Vergleichen Sie dies mit der Änderung von KI-Code, bei der eine Änderung Auswirkungen haben kann, die schwer vorherzusagen oder zu überprüfen sind.
- Durchsetzung von Beschränkungen: Diagrammschemata erzwingen Datenintegrität. KI kann nicht versehentlich ungültige Konfigurationen erstellen oder Beziehungen unterbrechen – die Datenbank verhindert dies.
- Abfragbarer Kontext: KI kann den Graphen abfragen, um den vollständigen Kontext jeder Änderung zu verstehen. Die Frage „Zeigen Sie mir alle Geschäftslogik, die diesen Entitätstyp verwendet“ ist eine einfache Graphenabfrage und keine komplexe Code-Analyseaufgabe.
- Umkehrbare Operationen: Graphenbasierte Änderungen sind transaktional und können problemlos rückgängig gemacht werden, im Gegensatz zu Codeänderungen, die eine sorgfältige Zusammenführung und Konfliktlösung erfordern können.
Wenn es sich bei Ihrer Anwendung um einen Graphen handelt, wird KI zu einem Werkzeug für die strukturierte Datenmanipulation und nicht für die Codegenerierung. Dies ist ein grundlegend leichter lösbares Problem.
Der echte Vergleich
Vergleichen wir die beiden Ansätze sechs Monate nach der ersten Entwicklung:
Traditioneller KI-generierter Code (auch mit BMAD):
- Umfangreiche Dokumentation zu pflegen
- Codeprüfungen durch Menschen UND KI-Agenten
- Kontrollmanifeste zur Festlegung von Grenzen
- Kontinuierlich geführte Bücher zur Verfolgung von Änderungen
- Details der Implementierung müssen noch entschlüsselt werden
- 80% der Geschwindigkeit, erheblicher Prozess-Overhead
Graph-basierter Low-Code:
- Visuelles Schema bleibt sofort nachvollziehbar
- Beziehungen sind eindeutig und abfragbar
- Änderungen an hochrangigen Abstraktionen
- Neue Teammitglieder verstehen das System schnell
- KI-Assistenz arbeitet mit strukturierten Daten, nicht mit Codegenerierung
- Vergleichbare oder bessere Geschwindigkeit, minimaler Prozess-Overhead
Die grundsätzliche Frage
Im Originalbeitrag werden die Teams aufgefordert, eine umfassende Prozessdisziplin zur Verwaltung von KI-generiertem Code einzuführen. Aber vielleicht stellen wir ja die falsche Frage.
Statt „Wie können wir die KI-Code-Generierung disziplinieren?“ sollten wir uns vielleicht fragen: „Warum generieren wir überhaupt traditionellen Code, wenn Higher-Level-Ansätze diese Probleme von Haus aus lösen?“
Und es geht noch weiter: „Warum verwenden wir nicht graphbasierte Darstellungen, bei denen KI mit strukturierten Konfigurationsdaten arbeiten kann, anstatt komplexe Codebasen zu erstellen und zu pflegen?“
Der Weg nach vorn
Verstehen Sie mich nicht falsch – die BMAD-Methode steht für durchdachte technische Disziplin. Teams, die in der traditionellen Entwicklung mit KI-Assistenten feststecken, würden von ihr profitieren.
Aber es gibt einen besseren Weg: die Wahl von Entwicklungsplattformen, die:
- Arbeiten Sie auf der richtigen Abstraktionsebene
- Speichern der Anwendungsstruktur als zusammenhängende, abfragbare Daten
- Direkt von diesen abstrakten Definitionen ausgehen
- KI-Unterstützung als Werkzeug für die Datenmanipulation und nicht für die Codegenerierung
Hier geht es nicht darum, zwischen Geschwindigkeit und Wartbarkeit zu wählen. Es geht darum, einen Ansatz zu wählen, bei dem diese beiden Aspekte nicht von vornherein im Widerspruch zueinander stehen.
Kennen Sie den im Originalbeitrag beschriebenen Zyklus der technischen KI-Schulden? Haben Sie darüber nachgedacht, wie graphenbasierte Low-Code-Plattformen die Gleichung grundlegend verändern könnten?
Für Teams, die komplexe Anwendungen entwickeln und eine hohe Geschwindigkeit ohne technische Schulden anstreben, könnte die Erkundung graphbasierter Low-Code-Plattformen die strategischste Entscheidung des Jahres sein.
Dieser Beitrag wurde als Antwort auf Benny Cheungs hervorragende Analyse der Herausforderungen der KI-Programmierung geschrieben. Wenn Sie mit KI-generierten technischen Schulden zu tun haben, lohnt es sich, seine BMAD-Methode zu studieren – und zu überlegen, ob ein anderes Paradigma Ihnen nicht sogar besser helfen könnte.
