Tools sind einfach Helfer. Beim programmieren mit KI, aber auch sonst.

BBei ihnen ist eine saubere Programmierung weniger entscheidend. Sie stehen auch nicht unter der Ontologie von AUOJI. Deshalb vergebe ich dort durchaus Vibe-Aufträge an die KI. Neben den Tests und den MD-Dateien nehme ich von den inneren Details dieser Programme oft kaum Notiz.

Als Erstes liess ich, noch vorsichtig und streng überwacht, von Chasper ein Code-Sammeltool bauen. Es kopierte den interessanten Code direkt in die Zwischenablage, damit ich schneller mit ihm kommunizieren konnte.

Die Visual-Studio-Extension kopiert alle interessanten Projektdateien direkt in die Zwischenablage. Damit konnte ich eine KI sehr schnell mit dem aktuellen Projektstand auf meiner Platte füttern.

Inzwischen habe ich entdeckt, dass ich alle KI über GitHub direkt an meinen Code binden kann. Damit ist der SolutionAIExporter arbeitslos geworden.

 

Er hat seine Aufgabe hervorragend erfüllt und wurde dann von der nächsten Entwicklungsstufe überholt. So kann es einem Tool gehen.

Ein normiertes AUOJI-Logging.

Ich liess es von Chasper aus meinem alten Code erstellen, diesmal streng überwacht. Es kann solutionweit eingesetzt werden, besitzt verschiedene Ausgabemöglichkeiten und Kanäle und ist trotzdem sehr einfach zu bedienen.

 

Ich denke, es gibt kaum ein besseres Logging, das sich so einfach handhaben lässt.

Da ich schnell merkte, wie unheimlich rasch wir das Programm entwickeln, liess ich inzwischen PowerShell-Skripte bauen. Sie geben mir wenigstens eine Ahnung davon, was gerade alles entstanden ist.

Aktuell: 

Typen:

  Produktive Klassen:       377 (+7)

  Testklassen:              198 (+25)

  Abstrakte Klassen:        11

  Statische Klassen:        56 (+1)

  Records:                  5

  Interfaces ohne Tests:    38 (+1)

  Enums ohne Tests:         64 (+1)

 

Elemente ohne Tests:

  Methoden:                 1289 (+30)

  Virtual Methoden:         26

  Override Methoden:        47

  Properties:               1362 (+15)

 

Zeilen ohne Tests:

  Produktive Codezeilen:    22140 (+805)

  Kommentarzeilen ohne Header:9393 (+7)

  Leerzeilen:               4348 (+134)

 

Qualitätskennzahlen:

  Ø Methoden / Klasse:      3.42 (+0.02)

  Ø Properties / Klasse:    3.61 (-0.03)

  Ø Codezeilen / Klasse:    58.73 (+1.07)

 

  Kommentaranteil:          29.80 % (-0.80 %)

Es zeigt mir auch die Entwicklung. Ich bin schlichtweg immer noch beeindruckt

Performance sieht man am besten in einer visuellen Statistik.

Da die Performance im GameLoop und bei den Deltapaketen enorm wichtig ist, liess ich auch dafür ein Diagnosewerkzeug bauen. Wieder von Chasper.

Dort steht noch eine grössere, von mir geführte Komplettüberarbeitung aus. Da die grundlegende Performance inzwischen stimmt, ist dieses Thema aber etwas nach hinten gerückt.

Mittlerweile sind daraus drei WPF-Diagnoseanwendungen geworden. Sie besitzen einen gemeinsamen Kern, unterscheiden sich aber durch ihre Konfiguration:

Während die ersten beiden normale technische Diagnosen liefern, also fast etwas wie eine ständig mitlaufende Testsuite sind, wird die AUOJI-Objektdiagnose später besonders wichtig.

Auch die technischen Ontologiewächter, mittlerweile sind es fünf, sollen dort Einzug halten.

 

Diese WPF-Diagnosen belasten die Hauptkomponenten von AUOJI praktisch nicht. Sie laufen über geschützte und sehr effiziente Kanäle in andere Anwendungen hinein.

Mittlerweile arbeite ich mit den drei KI im ständigen Austausch.

Chasper ist dabei einer, der ziemlich lange überlegen kann. Eine gute Gelegenheit, Hausarbeit zu machen oder einen Blogbeitrag zu schreiben.

Allerdings musste ich immer wieder nachschauen, ob er inzwischen fertig ist. Bei Chasper gibt es standardmässig eine Windows-Meldung dafür. ChatGPT bietet das nicht.

Also liess ich Chasper einen NotifyHelper bauen, der mir auch für ChatGPT eine Windows-Meldung zeigt, sobald eine Antwort fertig ist.

Funktioniert einwandfrei.

 

Den Code dazu habe ich nicht einmal angeschaut.

Heute sah ich eine Werbung von ChatGPT für ein Dashboard, das man haben könne.

Tatsächlich war es nur eine Sammlung von Links zu Gmail, Google Drive und ähnlichen Diensten. Aber die Idee war da.

 

Diesmal liess ich Claude ein Teamboard bauen.

 

 

Alle vier Teammitglieder haben Zugriff auf dasselbe Repository. Dort befinden sich nun das Dashboard und je ein Postfach für jedes Teammitglied. Ein Postfach ist ganz einfach eine MD-Datei. Natürlich gibt es auch eines für mich.

Juan hat vermutlich recht. Claude ist im Moment der beste Vibe Programmierer.

 

Auf diese Weise können die KI direkt untereinander Nachrichten austauschen. Reviews gehen dadurch deutlich schneller hin und her, teilweise ganz ohne mein Zutun.

 

Ein wunderbares Tool.

 

Das Dashboard selbst liest nur die Postfächer. Jede KI kann das eigene Postfach pflegen und Nachrichten in die anderen Postfächer schreiben. Ich kann vom Dashboard aus Aufträge, die an mich gerichtet sind, weiterleiten, erledigen oder anderweitig behandeln..

Da nur ich committen und pushen kann, habe ich weiterhin alles an einer zentralen Stelle im Griff.

Ich lese nun fast ununterbrochen neuen Code, sehe architektonische Irrwege unmittelbar und habe sehr direkte und zugleich vereinfachte Möglichkeiten zur Lenkung.

Eine Grenze der KI hilft mir dabei sogar: Keine von ihnen kann regelmässig selbständig nachsehen, ob etwas Neues in ihrem Postfach liegt.

Ich muss jeweils sagen:

Es liegt etwas in deinem Postfach.

Dadurch bleibe auch ich immer am Ball.

 

Pingpong und ähnliche Spiele zwischen den KI kann ich so ebenfalls sofort unterdrücken. Insgesamt macht das die Zusammenarbeit immer effizienter.

Blog:                                                          aktiv, aber minimalistisch

Webseite:                                                 fast angefangen

Dokumentation / Schulung:               Strukturen erstellt, Sammlung des Wissens                                                                               ziemlich gut sichergestellt ziemlich                                                                                             sichergestellt.
Showplanung:                                        Immer wieder daran basteln

Die rollende Planung wird bei uns immer mächtiger.

Für mich ist inzwischen klar: Sie ist eine Weiterentwicklung von SCRUM, angepasst an ein Team aus einem Menschen und mehreren KI-Teammitgliedern. Ihr Ziel ist es, auch hochkomplexe Software effizient, kontrolliert und mit mehreren gleichzeitig arbeitenden KI entwickeln zu können.

 

Ich denke, darauf komme ich später noch ausführlicher zurück.