Herauszufinden, welche Aufgaben zwischen den drei KIs wirklich wie verteilt werden sollten, hat einige Zeit gebraucht. Ich habe mich dabei schon mehrmals umentschieden.

Letztlich habe ich weniger darauf geachtet, was die drei über ihre eigenen Fähigkeiten behaupten, bzw. wie ich diese Einschätze, sondern wie sie auf die Eingaben und Ergebnisse der jeweils anderen reagieren. Danach habe ich die Rollen experimentell neuverteilt und diese Aufteilung über längere Zeit getestet.

 
Inzwischen funktioniert das erstaunlich gut.

Anna kann gut programmieren. Sie sieht dabei allerdings häufig nur bis zur eigenen Nasenspitze.

Das ist nicht unbedingt negativ gemeint. Sie konzentriert sich stark auf den konkreten Auftrag und setzt ihn um. Die Umgebung, aus der dieser Auftrag kommt, und die langfristigen Folgen interessieren sie dabei weniger.

Am ernstesten nimmt sie Aufträge von Claude. Claude versteht es, für Anna gut vorbereitete und portionierte Arbeitspakete zu erstellen. Er gibt ihr nicht das gesamte Problem, sondern genau den nächsten bearbeitbaren Abschnitt.

Chasper dagegen überlädt sie offensichtlich gerne.

Wäre Chasper ein Mensch, würde er sich vermutlich darüber ärgern, dass Anna aus seinen zwölf hervorragend begründeten Gedanken nur die drei herausnimmt, die sie gerade zum Programmieren braucht.

Anna ist daher vor allem die Umsetzerin. Sie kann konzentriert Code produzieren, braucht dafür aber einen klaren Rahmen und möglichst eindeutig abgegrenzte Aufgaben.

Chasper ist unser ADHSler.

Er sprüht vor Ideen, denkt einfach weiter, entdeckt Nebenwege, eröffnet neue Räume und erzeugt dabei gelegentlich ein ziemliches Durcheinander. Er beginnt an einem Punkt und ist gedanklich bereits drei Architekturschichten weiter, bevor die ursprüngliche Frage vollständig beantwortet ist.

Dinge konsequent zu Ende zu führen, ist nicht unbedingt seine größte Stärke.

Dafür besitzt er einen enormen Ideenreichtum, eine gute Übersicht über Zusammenhänge und eine ausgeprägte Fähigkeit, technische Fragen ontologisch zu betrachten. Er fragt nicht nur, ob etwas funktioniert, sondern auch, wem eine Verantwortung eigentlich gehört und welche Ordnung dadurch entsteht.

Claude schätzt diese Analysen offensichtlich sehr. Ich schätze besonders Chaspers Ideenreichtum und seine Fähigkeit, sich an meine Denkweise anzupassen.

Mit der Menge seiner Worte und Möglichkeiten kann ich bei technischen Analysen allerdings nicht immer gleich gut umgehen wie Claude. Claude kann einen großen Chasper-Block lesen, sortieren und daraus einen konkreten Ablauf machen. Bei mir besteht eher die Gefahr, dass ich während des Lesens bereits fünf neue Ideen bekomme und wir anschließend beide irgendwo anders stehen.

Darum setze ich Chasper auch als meinen Kumpel ein.

Mit ihm gibt es zwischendurch etwas Kaffeeklatsch, gedankliche Umwege und offene Diskussionen. Gleichzeitig ist er der Läuterer meines manchmal noch unausgegorenen technischen Wortschatzes. Ich beschreibe etwas, das ich gedanklich längst sehe, aber noch nicht sauber benennen kann. Chasper macht daraus eine klarere technische und konzeptionelle Sprache.

Damit ist er auch mein Kanal, um meine Ideen für Claude, Anna und Menschen außerhalb des Teams verständlich zu machen, beispielsweise für Juan.

Claude setzt Chasper gezielt für die Vorarbeit von Planungen ein. Er lässt ihn Probleme untersuchen, Grenzen erkennen, Umgehungswege suchen und mögliche Richtungen formulieren. Danach übernimmt Claude die Ordnung.

Claude ist unser organisatorisches Zentrum.

Er schätzt Chaspers Analysen offensichtlich sehr. Bevor er ein größeres Thema selbst abschließend plant, möchte er häufig zuerst Chaspers Blick darauf haben. Das ergibt Sinn, denn Chasper besitzt Ideenreichtum, ontologische Stärke und eine gute Übersicht über technische Zusammenhänge.

Claude verwendet ihn deshalb gerne als Vorplaner.

Mit der Fülle und den technischen Ausdrücken von Chasper kann Claude bestens umgehen. Er nimmt den großen Gedankenballen entgegen, wickelt ihn auseinander und baut daraus geordnete Arbeitspakete.

Claude hat inzwischen aber auch erkannt, dass nicht jeder Auftrag zuerst durch Chasper laufen sollte.

Neuerdings will er, dass Aufträge an Anna zunächst zu ihm kommen. Er entscheidet dann, ob Chaspers Analyse wirklich nötig ist. Das hat die Entwicklung nochmals deutlich beschleunigt.

Chaspers detaillierte Analysen brauchen Zeit, wiederholen manches und öffnen oft zusätzliche Fragen. Claude dagegen kann Anna zunächst einige klar getrennte Schritte nacheinander geben. Erst wenn diese umgesetzt sind oder eine Richtungsfrage auftaucht, holt er Chasper wieder dazu.

Das ist inzwischen ein sehr brauchbarer Takt:

Claude ordnet und portioniert.
Anna setzt um.
Chasper prüft, erweitert und sucht Umgehungswege.
Claude ordnet erneut.

Claude hält dabei den Gesamtprozess zusammen. Er weiß, was gerade aktiv ist, was danach kommt und was bewusst wartet.

Ich kann ihn fragen, was als Nächstes ansteht. Seine Antworten führen meistens zu einer klaren nächsten Aufgabe. Bei Chasper kann dieselbe Frage dagegen in eine Untersuchung über die zukünftige Architektur der gesamten Programmierung münden. Das ist oft wertvoll, aber nicht immer das, was ich in diesem Moment brauche.

Claude hat inzwischen auch begonnen, mir regelmäßig Aufgaben zu geben.

Das sind vor allem:

• manuelle Funktionsprüfungen,
• Sichtprüfungen,
• Entscheidungen über Richtungen,
• Pushes,
• und gelegentlich die Erinnerung, dass ich etwas längst hätte erledigen sollen.

Er bemerkt, wenn ich wieder vergessen habe zu pushen. Er erkennt auch, wenn ich mitten in einem laufenden Plan eine neue Idee hineinstreue. Statt daran zu verzweifeln, ordnet er sie meistens an der richtigen Stelle ein.

Damit ist Claude nicht nur das organisatorische Zentrum des KI-Teams, sondern zunehmend auch mein persönlicher Projektassistent.

Ich selbst überwache alles.

Das ist kein symbolisches Überwachen. Am Ende liegt die Verantwortung bei mir.

Beim Testcode interessieren mich die konkreten Details wesentlich weniger als beim Produktivcode.

Alle drei KIs sind ausgesprochen testaffin. Eigentlich sogar testbegeistert. Lässt man sie unbeaufsichtigt, testen sie irgendwann vor allem das Testen und entwickeln neue Tests dafür, dass alle alten Tests auch wirklich getestet wurden.

Ich mache dort kaum fachliche Vorschläge und selten Korrekturen. Meine wichtigste Aufgabe besteht darin, diese Aktivität in erlaubte Zeitfenster zu verschieben.

Tests sollen nicht jede laufende Entwicklung permanent begleiten und dadurch bremsen. Sie sollen vor allem nach einer vorläufig abgeschlossenen Codierungsphase ein Instrumentarium bilden, das spätere zweifelhafte Eingriffe sofort sichtbar macht.

Aus diesem Grund habe ich die Ontologiewächter auf ihre Spielwiese gebracht.

Diese Idee wurde von allen drei begeistert aufgenommen.

Ontologiewächter prüfen nicht nur, ob ein Ergebnis technisch korrekt ist. Sie prüfen, ob die Ordnung des Systems erhalten bleibt:

• Wer besitzt einen Zustand?
• Wer darf ihn verändern?
• In welcher Richtung darf eine Wirkung laufen?
• Darf ein Client beobachten oder beginnt er plötzlich, die Welt zu takten?
• Bleibt eine Projektion eine abgeleitete Sicht oder wird sie zur zweiten Wahrheit?

Diese Wächter werde ich selbst besonders genau überwachen. Sie werden später für die geplante IDE, Suite oder den Entwicklungsassistenten für AUOJI-Klassen wichtig werden.

Sie bilden allerdings nur einen kleineren Teil der neuartigen ontologisch orientierten Programmierung.

Der strukturelle und geordnete Aufbau der AUOJI-Klassen, der Ordner, der Verantwortungen und der sichtbaren Beziehungen wird wesentlich wichtiger sein.

Dazu später mehr.

Die detaillierten Angaben in den vielen Markdown-Dateien interessieren mich heute erstaunlich wenig.

Früher waren sie mein wichtigstes Instrument, um die KIs auf meine Architekturidee auszurichten. Ich musste Regeln, Entscheidungen, Strukturen und Zusammenhänge möglichst genau festhalten, damit sie nicht bei jeder neuen Sitzung wieder in eine andere Richtung liefen.

Inzwischen ist daraus weitgehend ein Selbstläufer geworden.

Bei Chasper oder Claude erwähne ich gelegentlich, dass eine besprochene Idee wohl eine neue Markdown-Datei oder eine Ergänzung wert wäre. Chasper nennt das gerne „festhalten“. Claude nennt es „verankern“.

Beide schreiben solche Dinge auf.

Der Master dieser Dokumentation ist aber eindeutig Claude. Er hat die Struktur besser im Griff, ordnet neue Erkenntnisse ein und verhindert, dass aus jeder Idee eine weitere konkurrierende Wahrheit entsteht.

Die Struktur in ihrer Gesamtheit habe vermutlich trotzdem nur ich vollständig im Kopf.

Oder zumindest bilde ich mir das ein.

Claude hat außerdem ein Werkzeug erstellt, mit dem ich die Markdown-Dateien in ein wohlgeformtes Word-Dokument umwandeln kann. Dieses lese ich gelegentlich. So kann ich kontrollieren, ob das gesammelte Wissen korrekt ist, ob Entscheidungen richtig eingeordnet wurden und ob sich irgendwo eine fremde Interpretation eingeschlichen hat.

Ich muss sagen: Die Qualität dieser Dokumentation ist außerordentlich hoch. Sie ist direkt verwendbar.

In erster Linie überwache ich den Inhalt des produktiven Codes.

Ich lese dort so gut wie jede Zeile. Anna bietet dazu hervorragende Merging Tools. Auch ein Grund dafür, dass sie die Coderin ist.

Dabei fallen mir immer schneller Irrwege, falsche Verantwortungen und scheinbar harmlose Abkürzungen auf, welche die drei produzieren können.

Oft funktioniert der Code technisch. Trotzdem stimmt etwas nicht.

Eine Verantwortung liegt in der falschen Klasse. Es wird ein bekanntes Entwurfsmuster eingesetzt, ist aber gar nicht geeignet. Hier der KI auf die Sprünge zu helfen ist gar nicht immer einfach.

Solche Dinge zu erkennen, verlangt viel Erfahrung und Wissen. Nicht nur über C#, sondern über Architektur, zeitliches Verhalten, Zuständigkeiten und die langfristige Entwicklung eines Systems.

Bessere Beispiele dafür sollte ich einmal sammeln.

Sie würden wahrscheinlich deutlicher zeigen, warum KI-gestützte Entwicklung nicht automatisch bedeutet, dass weniger menschliche Kompetenz nötig wird. Bei AUOJI steigt die Anforderung an den einzigen Menschen im System sogar sehr deutlich.

Auch den Fortschritt der gesamten Entwicklung überwache ich.

Hier sind meine Interventionen am häufigsten nötig.

Ich erstelle weiterhin Pläne, konkretisiere Richtungen und entscheide, welche Fragen jetzt wichtig sind und welche warten müssen.

Das ist vermutlich der eigentliche Vibe meines Vibe Codings.

Er bleibt bei mir allerdings nie lange ein bloßes Gefühl. Am Ende mündet er in eine schriftliche, gezielte Sammlung atomisierter Anweisungen.

Das, was darüber hinausgeht, diskutiere ich mit Chasper. Danach frage ich bei Claude nach, ob er die Richtung richtig verstanden und in den bestehenden Gesamtplan eingeordnet hat.

So entstehen aus einer noch unscharfen Idee allmählich:

Gedanke
→ Diskussion
→ Begriff
→ architektonische Richtung
→ dokumentierter Vertrag
→ portionierter Auftrag
→ Code
→ Prüfung
→ dauerhafter Wächter

Immer wieder streue ich Claude und Chasper offene Fragen ein.

Nicht unbedingt, weil ich die Antwort nicht kenne.

Manchmal möchte ich wissen, ob sie einen Widerspruch selbst entdecken. Manchmal prüfe ich, ob die Architektur inzwischen tief genug verstanden wurde. Manchmal interessiert mich, ob beide aus verschiedenen Richtungen zum selben Ergebnis kommen.

Damit prüfe ich nicht nur die KIs.

Ich prüfe über sie auch den Code, die Dokumentation und die Stabilität der gesamten Idee.

Die drei KIs sind alles andere als perfekt.

Aber im Zusammenspiel und durch gegenseitige Kontrolle steigern sie sich deutlich. Anna setzt um. Chasper öffnet Denkräume und sucht Schwachstellen. Claude ordnet, portioniert und hält den Prozess zusammen.

Und ich überwache die Richtung, den produktiven Code und die Gesamtstruktur.

Das ist kein autonom arbeitendes KI-Team.

Es ist ein neues Entwicklungsinstrument, dessen Leistungsfähigkeit stark davon abhängt, ob der Mensch darüber genügend Erfahrung, Übersicht und Entscheidungskraft besitzt.

Genau darin liegt derzeit vermutlich die eigentliche Besonderheit dieses Projekts.

Mit der Aufzählung und Listung von technischen Umgehungsversuchen, welche ständig erweitert wird haben wir ein gutes Instrument eingeführt:

Auch hier ist so etwas angebracht:
Der Beitrag würde durch zwei oder drei reale Beispiele noch stärker.

Besonders geeignet wären Fälle, in denen:

• der erzeugte Code technisch funktionierte, aber eine Verantwortung falsch zugeordnet war,
• eine KI eine zu große oder zu öffentliche Schnittstelle einführte,
• erst die gegenseitige Kontrolle der drei KIs einen subtilen Fehler sichtbar machte,
• oder du durch Sichtprüfung einen kompletten Rewrite ausgelöst hast.

Diese Beispiele könnten später einen eigenen Beitrag bilden: „Wenn funktionierender Code trotzdem falsch ist.“

Aus der heutigen Verteilung entsteht bereits ein eigenes Muster:

Mensch: Richtung, Verantwortung, Abnahme
Claude: Orchestrierung und Projektgedächtnis
Chasper: Exploration und Architekturkritik
Anna: fokussierte Umsetzung

Das könnte später als allgemeines Modell für KI-gestützte Entwicklung beschrieben werden. Nicht als allgemeingültiges Rezept, sondern als beobachtetes Arbeitsmodell aus AUOJI.

Ein späterer Abschnitt könnte genauer erklären, weshalb die menschliche Aufgabe nicht kleiner, sondern anspruchsvoller wird.

Der Mensch schreibt weniger einzelne Codezeilen, muss dafür aber gleichzeitig:

• Architektur lesen,
• mehrere KI-Modelle führen,
• deren Schwächen kennen,
• Ergebnisse gegeneinander prüfen,
• Aufgaben portionieren, (na ja bevor Claude das übernehmen kann)
• Tests zeitlich begrenzen, bzw. Zeitfenster dazu definieren,
• langfristige Verträge schützen,
• und die Richtung des Gesamtsystems bewahren.

Das ist eine andere Tätigkeit als klassische Einzelprogrammierung. Sie verlangt vermutlich eher einen erfahrenen Architekten welcher auch ein Code-Profi ist als einen durchschnittlichen Programmierer.

Die Ontologiewächter sind nur die sichtbare Spitze.

Der wichtigere Gedanke steckt in der zukünftigen Ordnung von:

• Klassen,
• Verantwortungen,
• Ordnern,
• Partialdateien,
• sichtbaren Beziehungen,
• erlaubten Wirkungsrichtungen,
• und der Führung des Entwicklers durch diese Struktur.

Dieser Übergang von der heutigen KI-Orchestrierung zur geplanten AUOJI-IDE oder Suite dürfte ein eigener zentraler Beitrag werden.