Mensch & KI

Viel Code. Wenig Fortschritt. Und eine ziemlich unbequeme Erkenntnis.

MENSCH & KI
FIELD NOTE 005

Warum es hier eine Weile ruhig war. Und was ich bei der Entwicklung mit KI über meine eigenen Grundsätze lernen musste.


Nach meiner letzten Feld Note war es hier ziemlich ruhig.

Fast zwei Monate keine neue Geschichte über die Zusammenarbeit zwischen Mensch und KI.

Nicht, weil nichts passiert wäre.

Ganz im Gegenteil.

Wir haben entwickelt, getestet, Fehler gesucht, Funktionen erweitert und versucht, unsere KI-Agenten immer selbstständiger arbeiten zu lassen.

Es wurde unglaublich viel gearbeitet, insbesondere im Bereich Human und KI.

Und irgendwann musste ich mir eine ziemlich unangenehme Frage stellen:

Was davon hat uns unserem eigentlichen Ziel eigentlich nähergebracht?

Denn ich wollte eigene Ideen in funktionierende Software verwandeln. Mit KI-Unterstützung. Möglichst unabhängig, wirtschaftlich und ohne ständig selbst vor dem Bildschirm sitzen zu müssen.

Stattdessen verbrachte ich immer mehr Zeit damit, die Zusammenarbeit meiner Agenten zu organisieren.

Irgendetwas lief da nicht ganz richtig.


Wenn die Organisation der Arbeit zur eigentlichen Arbeit wird

In Feld Note #003 hatte ich bereits beschrieben, wie aus einer einfachen Idee ein zunehmend komplexes Agenten-Board wurde.

Aufgaben sollten verschiedene Entwicklungsphasen durchlaufen. Agenten sollten implementieren, andere Agenten prüfen und ich wollte nur dort eingreifen, wo tatsächlich eine menschliche Entscheidung notwendig war.

Eigentlich vernünftig.

Nur blieb es nicht bei einem Board.

Wir brauchten Zustände, Übergänge, Berechtigungen, technische Nachweise und Prüfregeln.

Dann kamen Fehlerfälle dazu. Und Sonderfälle für die Fehlerfälle.

Irgendwann konnte eine gewöhnliche Statusänderung dafür sorgen, dass der gesamte Ablauf blockiert war.

Also wurde wieder analysiert, korrigiert und getestet.

Die Agenten produzierten fleißig Code. Und wir lösten durchaus echte technische Probleme.

Nur hatte ich zunehmend das Gefühl, dass wir vor allem damit beschäftigt waren, unseren eigenen Entwicklungsprozess am Leben zu halten.

Ich wollte Software entwickeln. Stattdessen entwickelte ich die Verwaltung meiner Softwareentwicklung.

Auch eine Beschäftigung. Nur nicht ganz die, die ich mir vorgestellt hatte.


Ausgerechnet ich hätte es besser wissen müssen

Das eigentlich Ärgerliche daran ist, dass ich viele Jahre lang ziemlich genau das Gegenteil vertreten habe.

In der Softwareentwicklung, im Projektmanagement und später auch in der Führung.

Keep it simple.

Keine goldenen Henkel an Funktionen bauen, die niemand braucht.

Vorhandene Lösungen nutzen, statt alles neu zu erfinden.

Und niemals vergessen, dass jede Entscheidung Zeit, Geld und Ressourcen kostet.

Ein technisch interessantes Feature ist noch lange kein wirtschaftlich sinnvolles Feature.

Das habe ich anderen oft genug erklärt.

Und ausgerechnet bei meinem eigenen Projekt musste ich feststellen, dass ich diese Grundsätze zeitweise selbst aus den Augen verloren hatte.

Vielleicht lag es daran, dass das Entwickeln wieder so viel Spaß machte.

Vielleicht auch daran, dass KI eine ziemlich gefährliche Illusion erzeugt:

Wenn die nächste Funktion nur einen Prompt entfernt ist, erscheint sie plötzlich fast kostenlos.

Ist sie aber nicht.

KI-generierter Code muss verstanden, getestet, integriert und gewartet werden. Jede zusätzliche Funktion bringt möglicherweise neue Abhängigkeiten und Fehlerquellen mit.

Und irgendwann ist das Projekt zwar technisch beeindruckend, aber niemand möchte mehr die nächste Änderung anfassen.

Ich kenne solche Projekte.

Ich wollte eigentlich keines davon selbst bauen.

Viel Coding ist noch kein Fortschritt

Das war wahrscheinlich meine wichtigste Erkenntnis dieser Wochen.

Wir hatten viel entwickelt. Manches davon war technisch anspruchsvoll und durchaus sinnvoll.

Aber wir hatten zu selten hinterfragt, ob der Aufwand noch im richtigen Verhältnis zum Nutzen stand.

Ein Team kann vollkommen ausgelastet sein, Aufgaben abschließen und hervorragende Statusberichte produzieren.

Und trotzdem an den entscheidenden Dingen vorbeiarbeiten.

Bei unseren KI-Agenten war es nicht anders.

Mehr Code bedeutete nicht automatisch mehr Nutzen.

Mehr Automatisierung bedeutete nicht automatisch weniger menschlichen Aufwand.

Und mehr Kontrolle machte unseren Entwicklungsprozess nicht automatisch besser.

Wir hatten begonnen, die Möglichkeiten der Technologie stärker zu verfolgen als den eigentlichen Zweck unserer Entwicklung.

Das musste sich ändern.


Also haben wir angehalten

Nicht die Entwicklung aufgegeben.

Sondern angefangen, wieder die Fragen zu stellen, die eigentlich vor jeder Implementierung stehen sollten.

Brauchen wir diese Funktion wirklich?

Gibt es bereits eine Lösung?

Was ist der einfachste sinnvolle Weg?

Und was kostet uns das Ganze an Zeit, Geld und späterer Wartung?

Denn auch meine eigene Zeit ist ein Budget. Selbst wenn ich abends mit Begeisterung vor dem Rechner sitze.

Wir haben begonnen, unsere Entwicklungsregeln wieder stärker auf Einfachheit, Wiederverwendung und klare Aufgabenbegrenzung auszurichten.

Vor allem aber wollten wir weg von der ständigen manuellen Koordination unserer Agenten.

Der angestrebte Ablauf ist überschaubar:

Eine klar definierte Aufgabe. Ein Agent implementiert. Automatisierte Tests prüfen das Ergebnis. Ein unabhängiger Agent übernimmt das Review. Notwendige Korrekturen gehen zurück an den Entwickleragenten.

Und erst danach entscheide ich über die Freigabe.

Unabhängige Reviews hatten wir zwar schon vorher. Aber wir wollen sie nun konsequent in einen schlanken, möglichst automatisierten Prozess integrieren.

Dass diese Prüfungen notwendig sind, zeigte uns das Local Agent Lab ziemlich eindrucksvoll.

Bei einer Entwicklungsaufgabe meldete ein Agent zunächst 80 erfolgreiche Tests.

Das unabhängige Review fand trotzdem mehrere ernsthafte Probleme.

Erst nach weiteren Korrekturen und insgesamt drei Review-Runden konnte die Implementierung freigegeben werden.

Ein Agent, der überzeugend behauptet, fertig zu sein, ist noch lange nicht fertig.

Das sollten nach Möglichkeit die technischen Nachweise bestätigen.

Und nicht ich nachts um halb zwölf mit drei offenen Terminals herausfinden müssen.



Haben wir das Problem damit gelöst?

Nein.

So einfach wäre es schön.

Wir haben unsere Arbeitsweise hinterfragt, Entscheidungen korrigiert und begonnen, Entwicklungsabläufe konsequenter zu vereinfachen.

Im Local Agent Lab gibt es bereits konkrete Erfahrungen mit unabhängigen Reviews. Die weitere Automatisierung ist noch in Arbeit.

Auch unser Board wird nicht über Nacht einfacher, nur weil wir beschlossen haben, weniger Komplexität zu wollen.

Und vermutlich werden wir noch weitere Fehler machen.

Entscheidend ist hoffentlich, dass wir sie früher erkennen.

Nicht erst, nachdem wir wochenlang eine Lösung für ein Problem entwickelt haben, das ohne unsere vorherige Lösung gar nicht existiert hätte.


Was davon hängen bleibt


Die vergangenen Wochen haben mich an etwas erinnert, das ich eigentlich längst wusste.

Gute Softwareentwicklung bedeutet nicht, möglichst viel zu bauen. Sondern das Richtige – mit vertretbarem Aufwand.

Das gilt mit KI genauso wie ohne.

Vielleicht sogar noch stärker.

Denn je schneller die Umsetzung wird, desto leichter überspringt man die Frage, ob etwas überhaupt umgesetzt werden sollte.

Genau dort bleibt der Mensch wichtig.

Nicht als Aufpasser für jeden einzelnen Arbeitsschritt.

Sondern als jemand, der auch einmal fragt, ob wir überhaupt in die richtige Richtung laufen.

Mein Entwicklerherz freut sich jedenfalls immer noch darüber, wieder Software entwickeln zu können.

Aber mein früheres Ich würde mir wahrscheinlich gelegentlich auf die Finger klopfen.

Zu Recht.

Und vielleicht erklärt das auch, warum es hier eine Weile so ruhig war.

Wir waren ziemlich beschäftigt.

Jetzt sollten wir wieder darauf achten, dass aus dieser Beschäftigung auch echter Fortschritt wird.

In der nächsten Feld Note geht es wieder stärker um die Technik. Denn parallel dazu habe ich versucht, mit lokalen KI-Modellen auf meinem Laptop ein eigenes Entwicklerteam aufzubauen.

Mit einigen Überraschungen, vielen Fehlversuchen und der Erkenntnis, dass kostenlos und unabhängig zwei ziemlich unterschiedliche Dinge sind.

Aber das ist eine andere Geschichte.