Diagramme sterben aus einem langweiligen Grund: Sie haben nur eine Form, und die ist für mindestens die Hälfte dessen, was du brauchst, die falsche. Eine Zeichnung ist großartig für Lesende und nutzlos in einem Pull Request. Ein Block Diagramm-Code lässt sich wunderbar reviewen und sagt einem Stakeholder gar nichts. Also entscheiden sich Teams für eins, und der andere Bedarf bleibt offen, bis das Diagramm hinterherhinkt und niemand ihm mehr traut.
Die Lösung ist, sich nicht zu entscheiden. Behalte beide Formen und wechsle frei zwischen ihnen. Code wird zum Diagramm, wenn du es sehen willst; ein Diagramm wird zu Code, wenn du es reviewen oder ablegen willst. KI glättet den Weg in beide Richtungen, und der Hin- und Rückweg macht das Diagramm langlebig.
Richtung eins: ein Diagramm aus Code generieren
Du hast bereits Text, der Struktur beschreibt, ob Mermaid, D2 oder ein Artefakt wie eine Compose-Datei oder ein SQL-Schema. Hol ihn herein, und er wird zu echten, editierbaren Formen, fertig angeordnet. Jetzt kannst du Dinge tun, die Text nicht kann: den riskanten Pfad hervorheben, einen Bounded Context gruppieren, eine Notiz dort ablegen, wo die knifflige Stelle sitzt.
graph LR
client --> api
api --> cache
api --> db
worker --> queue
Füge das ein, und du bekommst kein gerendertes Bild, sondern eine Menge Kästen und Pfeile, die du anfassen und verschieben kannst. Der Code hat dir die Struktur gratis geliefert. Deine Änderungen fügen die Bedeutung hinzu.
Richtung zwei: das Diagramm in Code umwandeln
Jetzt umgekehrt. Du hast auf der Leinwand ein Diagramm geformt und willst es im Repository haben, neben dem Code, den es beschreibt, wo es reviewt und versioniert werden kann. Exportiere es zurück nach Mermaid oder D2 und committe den Text. Wenn das nächste Mal jemand einen Pull Request öffnet, der das System ändert, ändert sich der Code des Diagramms im selben Review, unter denselben Augen.
Wo KI beim Hin- und Rückweg hilft
Beide Richtungen werden mit einem Modell im Kreislauf einfacher, aber nicht so, wie der Hype es nahelegt. KI ist nicht dazu da, den Code oder die Zeichnung zu ersetzen. Sie überbrückt die unordentlichen Lücken:
- Von loser Eingabe zu sauberem Code. Beschreib einen Ablauf in einem Satz und erhalte einen ersten Wurf Diagramm-Code, den du rendern und verfeinern kannst.
- Vom chaotischen Diagramm zu aufgeräumtem Code. Lass den exportierten Text vereinfachen oder neu beschriften, damit sich die committete Version gut liest.
- Von Abweichung zu frischem Entwurf. Wenn sich das System weiterentwickelt hat, generiere aus der aktuellen Quelle neu und gleiche ab, statt ein altes Bild von Hand zu flicken.
Zwei Formen einer Wahrheit. Der Code hält sie reviewbar; das Bild sorgt dafür, dass sie gelesen wird.
Warum das besser ist, als sich für eine Seite zu entscheiden
Das Diagramm mit nur einer Form erzwingt einen schlechten Kompromiss. Diagramme als Code allein geben dir Reviewbarkeit und ein Bild, das niemand gern liest. Eine Zeichnung allein gibt dir ein freundliches Bild, das sich still vom Code entfernt. Beide zu behalten, mit einem einfachen Hin- und Rückweg, gibt dir die Reviewbarkeit von Text und die Klarheit einer Darstellung aus derselben Quelle. Keine der beiden ist Bürger zweiter Klasse.
Die Gewohnheit, die sich lohnt
Behandle die beiden Formen als ein Artefakt mit zwei Ansichten. Entwirf in der, die gerade schneller ist, skizziere visuell oder tippe die Struktur, und hol dir dann per Hin- und Rückweg die andere Form gratis dazu. Mach das konsequent, und das ewige Problem des veralteten Diagramms verschwindet weitgehend, weil es immer einen billigen Weg zurück zum korrekten Stand gibt.
Füge etwas Diagramm-Code ein und forme ihn, oder zeichne etwas und exportiere den Code. Wenn du den Hin- und Rückweg einmal erlebt hast, ist es keine lästige Pflicht mehr, ein Diagramm aktuell zu halten, die du auslässt.