Direkt zum Hauptbereich

Erfahrung mit Vibe-Coding - und warum das keine Teamprobleme löst

Die KI-Werkzeuge zum Erstellen von Werkzeugen für die tägliche Arbeit werden immer besser. Die selbstgestrickten Tools erleichtern die eigene Arbeit. Aber für den Einsatz im Team fehlt noch etwas.

Jetzt wird es einfacher, Tools für die eigene Arbeit zu erstellen

Es gibt einige KI-Tools, mit denen man sehr gut eigene Werkzeuge für die tägliche Arbeit erstellen kann. Während ich diesen Artikel schreibe, ist Claude von Anthropic meine KI der Wahl. Chat-GPT schneidet da auch gut ab. Mit anderen KIs (Perplexity, Mistral, Gemini) habe ich nicht so gute Erfahrungen gemacht. Sie waren nicht schlecht, aber Claude war einfach besser.

Foto von fran innocenti auf Unsplash

Es gibt einen lokalen Claude-Client, mit dem man Code auf der Konsole erstellen kann (Claude Code). Man kann Claude oder die Modelle von anderen KIs in Cursor oder PearAi (beide kostenpflichtig) nutzen, um Code zu erstellen. Mir reicht der Zugang per Weboberfläche auf Claude.

Mit V0 von Vercel und Lovable habe ich zwei Dienste gefunden, die mir Vorschläge für Programmoberflächen machen, wenn ich noch keine rechte Vorstellung von der Software habe. Meist brauche ich die aber nicht.

Ich habe mir eine Reihe von einfachen Werkzeugen mit KI erstellt. Dazu gehören folgende Tools:

  • Eine komplette Vorgangsverwaltung mit Datenbank.
  • Eine Aufgabenmanager-GUI für todo.txt
  • Eine Störungserfassung
  • Eine Zeiterfassung
  • Ein Skript, das mir einen Stapel Fotos nach Datum und Ort sortiert.
  • Ein Tool, das mir meine E-Mails nach Kunden sortiert und in Unterordner schiebt.

Die Arbeit mit der KI zum Erstellen solcher Programme nennt man übrigens Vibe Coding. Mir gefällt Vibe Coding sehr. Jetzt kann ich mir die Tools erstellen, die ich mir die letzten 20 Jahre gewünscht habe und für die ich zu faul war, sie selbst zu erstellen. Bevor ich Empfehlungen zum Umgang abgebe, möchte ich betonen, dass dies Werkzeuge für die persönliche, aber nicht für die Teamproduktivität sind.

Teams brauchen mehr als neue Werkzeuge

Wenn es um die persönliche Produktivität geht, tickt jeder anders. Die einen lieben Excel, die anderen hassen es. Eine Person mag lieber Zettel, eine andere liebt ihr elektronisches Board.

Das ändert sich nicht, wenn wir mit KI neue Werkzeuge erstellen. Der eine möchte sein Excel schneller mit einem von KI erstellten Programm befüllen lassen. Ein anderer schreibt mit einem neuen Programm neue Karten für sein Kanban-Board.

Neue Tools und Möglichkeiten sind spannend. Aber Teams müssen sich abstimmen und gemeinsam passende Regeln finden. Solange das nicht passiert, wird KI den Arbeitsalltag nicht verändern. Wie kann man das machen?

Ausgangspunkt sind für mich immer die Lieferprozesse des Teams: Was müssen wir eigentlich liefern? Wofür werden wir bezahlt? Was erwarten unsere internen und externen Kunden? Welche Mengen, welche Qualität müssen wir liefern? An welche Zeiten wollen wir uns halten?

Danach schließt sich eine Diskussion an, was die Nervpunkte sind. Wenn eine Maschine bestimmte Informationen schon hat oder geduldiger ist oder ein besseres Gedächtnis als ein Mensch hat, kann man über Automatisierung und KI nachdenken. Aber das muss im Team besprochen werden. Das Verfahren unterscheidet sich nicht von den schon bekannten Verfahren zur Verbesserung der Prozesse (z. B. TWI Job Methods, Toyota Improvement Kata, A3-Berichte).

(Das sind übrigens Situationen, in denen die Beraterinnen und Berater vom Common Sense Team oder von Reflect den Teams helfen.)

Worauf achte ich beim Vibe-Coding? 

Paul Leonardi und Tsedal Neeley haben ein wichtiges Buch über Digitalisierung geschrieben, The Digital Mindset. Schon in Kapitel 1 geht es um die Kommunikation mit KI. Ich habe mir daraus zwei Dinge gemerkt: 1. Wir brauchen ein rudimentäres Verständnis über die Funktionsweise der KI, mit der wir interagieren. 2. Wir müssen uns selbst klar sein, was wir wollen. Wer nicht weiß, was er will und keine Ahnung hat, was die KI liefert, wird keine guten Ergebnisse bekommen.

Hier ist mein Vorgehen für Programme mit grafischen Oberflächen:

  • Technologie-Stack festlegen 
  • Datenspeicherung festlegen
  • GUI in einer einfachen Version erstellen und dann erweitern.
  • PRD und Dokumentation erstellen.

Schauen wir uns diese Punkte genauer an. 

Technologie-Stack festlegen

Die KIs können Code für unterschiedliche Programmiersprachen erstellen. Ich habe verschiedene Techniken ausprobiert: Python, Web (React/Angular), C++, Groovy, Node.js/Electron.

Die besten Ergebnisse auf meinem Windows-Rechner hatte ich mit Python. Für die persönliche Arbeit brauche ich oft keine Weboberfläche. Python kann Oberflächen mit Qt bauen. Diese sehen gut aus und funktionieren sehr gut. Bei den anderen Werkzeugen bin ich immer wieder auf Probleme gestoßen. Jetzt bleibe ich erst einmal bei Python.

Fange mit dem Datenmodell oder der Datenspeicherung an

Im ersten Schritt beschreibe ich der KI mein Problem und bitte um einen Vorschlag, wie man die Daten speichern könne. Ich nutze drei Möglichkeiten:

  • Für einfache Listen soll das Programm einfach Excel-Dateien lesen und schreiben. CSV-Dateien wären noch einfacher. Aber es gibt immer wieder Schwierigkeiten mit dem Spaltentrenner (Komma oder Semikolon?). LibreOffice kann das gut unterscheiden, aber MS Excel nicht. Also bleibe ich bei Excel. Zudem kann ich die Listen dann mit Excel selbst bearbeiten und ändern.
  • Für Einstellungen nutze ich JSON. Das ist ein maschinenlesbares Format, damit sich ein Programm Einstellungen merkt, z. B. die zuletzt verwendete Datei oder Dropdown-Listen.
  • Für aufwändigere Daten nutze ich eine SQLite-Datenbank. Das ist ein einfaches Datenbankformat, für das ich keine aufwändige Datenbank-Engine lokal installieren muss. Zudem kann ich mit dem DB Browser für SQLite trotzdem per SQL die Daten auswerten oder ändern. Claude erstellt ER-Diagramme als Textdatei, die ich mir dann bei Mermaid.live ansehen kann. 

Ich schaue mir den Vorschlag an und lasse mir Musterdaten erzeugen. Wenn ich damit einverstanden bin, gehe ich zum nächsten Schritt.

GUI erstellen und verfeinern

Die KI kann einfache Python-Skripte erstellen, um Dinge zu tun. Ich habe mir z. B. ein Skript geschrieben, das einfach alle E-Mails in einem Verzeichnis nach einem bestimmten Schema benennt und das Dateidatum auf das Absendedatum setzt. Dafür brauche ich keine Oberfläche.

Programme mit grafischen Benutzeroberflächen sind hilfreich, wenn ich Daten eingeben will oder nach Informationen suche. Ich habe z. B. eine Datenbank mit meinen Vorgängen. In meinem Vorgangsbrowser kann ich nach Vorgängen suchen und per Doppelklick den Pfad im Explorer öffnen, an dem die Dokumente dazu liegen.

Aus dem letzten Schritt habe ich einen Vorschlag für die Datenspeicherung bekommen. Damit gehe ich in einen neuen Chat. Ich beschreibe kurz mein Problem. Ich lade eine Musterdatei oder die Beschreibung des Datenformats hoch und bitte die KI, mir eine GUI dazu zu erstellen. Ich erkläre, was mir wichtig ist.

Python kennt unterschiedliche Widget-Sets, um Oberflächen zu erzeugen: Tcl/Tk (tkinter) und Qt (PySide6). Das muss man dazu sagen.

Der erste Wurf der KI ist oft schon sehr gut und ohne Fehler. Wenn ich die erste Version sehe, fallen mir ein paar Dinge ein, um die Bedienung zu erleichtern:

  • Live-Filter, um die Infos in Listen einzugrenzen
  • Veränderbare Spaltenbreiten
  • Sortieren, wenn man auf die Spaltenüberschriften klickt.
  • Autocompletion bei Suchfeldern, wenn die Listen dahinter zu lang sind.
  • Wechseln der Datenbank oder der Datei, in der die Daten gespeichert sind.
  • Verweis auf andere Skripte
  • Integration der Benutzerhilfe
  • Erstellen von Progamm-Icons 

Ich gehe in kleinen Schritten vor. Zu viele Änderungswünsche gleichzeitig verwirren die KI und führen oft zu Fehlern. Eine typische Vibe-Coding-Session dauert bei mir ungefähr eine Stunde.

Einfache Fehler korrigiert die KI. Dagegen ist Debuggen ein Problem. Eine KI versteht ja das Programm, das sie baut, überhaupt nicht.

Wenn ich den Eindruck habe, das Skript sei zu lang geworden, bitte ich die KI um Vorschläge zum Vereinfachen.

Ich nutze nur Skripte, die aus einer Datei bestehen. Das begrenzt den Funktionsumfang. Aber es vereinfacht die Wartung und Fehlersuche. 

Dokumentation und PRD erstellen

Wenn ich mit dem Ergebnis zufrieden bin, lasse ich mir zwei Dokumente erstellen. Das erste dokumentiert das Programm, die Hilfe sozusagen. Wenn ich das Tool nicht so häufig benutze, vergesse ich vielleicht, was ich mir gedacht habe und wie es verwende.

Das zweite Dokument fasst die Anforderungen an das Programm zusammen, das Product Requirements Document (Produktanforderungsdokument). Es beschreibt, was das Programm eigentlich machen soll. Warum brauche ich das? 

Mit diesem Dokument kann ich in einem neuen Chat das Programm neu erzeugen. Wenn die Chats zu lang werden oder wenn die KI einen Fehler einfach nicht fixen kann, hilft ein frischer Anfang in einem neuen Chat. Eine KI nutzt ein sog. Kontextfenster, z. B. die letzten fünf Anfragen in einem Chat (genauer genommen ist es eher eine bestimmte Anzahl von Zeichen). Sie erinnert sich deshalb nicht, welche Anforderungen ich am Anfang eines langen Chats gestellt habe.

Realistische Erwartungen, bitte

Tools, die auf diese Weise mit KI erstellt werden, sind so gut wie die eigenen Excel-Dateien. Sie sind nicht massentauglich. Der Ersteller weiß, was man damit machen kann und wo die Grenzen liegen. Es werden nicht alle Anwendungs- und Testfälle berücksichtigt. Diese Tools sind nicht für das Ausrollen im ganzen Unternehmen gedacht. Es hat schon seinen Sinn, dass man bestimmte Softwareprodukte in die Hände von professionellen Entwickler:innen, Designer:innen und Tester:innen gibt. Wenn man Software an einen größeren Anwenderkreis gibt, muss man einiges mehr tun, als nur die Funktionalität sicher zu stellen.

Wenn man Tools erstellt, muss man kein guter Programmierer sein. Aber man braucht ein Grundverständnis davon, was ein Programm ist und es welchen Bestandteilen es besteht. Wenn man unsicher ist, ist es hilfreich, auf vergleichbare Funktionen in anderen Programmen zu verweisen oder Screenshots anzuhängen. Das liefert gute Ergebnisse. 

Auf diese Weise gelingt es mir, in einer Stunde praktische Tools zu erstellen, die mir dann jeweils mehrere Stunden Arbeit abnehmen.

 

Kommentare

Beliebte Posts aus diesem Blog

Wie lassen sich Ergebnisse definieren? - Drei Beispiele (WBS, CBP und BDN)

Ich habe schon darüber geschrieben, warum das Definieren von Ergebnissen so wichtig ist. Es lenkt die Aufmerksamkeit des Projektteams auf die eigentlichen Ziele. Aber was sind eigentlich Projektergebnisse? In diesem Beitrag stelle ich drei Methoden vor, um leichter an Ergebnisse zu kommen.

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Microsoft Copilot - Notebook, Pages, Agents und mehr

Es tut sich sehr viel an der Copilot Front. Gefühlt entwickelt Microsoft mit aller Kraft die KI-Anwendung weiter. Mit dem letzten Update hat sich die Microsoft-Startseite stark verändert. Hier zeige ich, was sich hinter all den Begrifflichkeiten verbirgt und was davon alltagstauglich ist.

Schätzungen sind schätzungsweise überschätzte Schätze

"Wer viel misst, misst viel Mist." Zumindest ist diese Gefahr gegeben. Entweder misst man z. B. Mist, weil man zu früh zu KPIs zur Messung von Ergebnissen greift, oder aber man greift zu den falschen KPIs, die gar nicht das messen, was man wissen möchte. Einst war agiles Arbeiten der alternative Ansatz, aber inzwischen gibt es auch für einige Details dessen, was in Konzernen als "agil" praktiziert wird, einleuchtende alternative Ideen, die bis heute noch nicht so richtig auf die große Bühne vorgedrungen zu sein scheinen. 

Wenn es mal gerade etwas schwierig bei Kund:innen wird… Zwei Fragen, die uns helfen, unsere Strategie mit unseren Kund:innen abzusprechen.

Seit 2024 organisieren Bob Galen und ich eine Masterclass für agile Coaches. Wir möchten die Ausbildung von agilen Coaches verbessern und ihnen Techniken mitgeben, mit denen sie bei ihren Kund:innen etwas einfacher haben. Bisher haben wir in vier Durchgängen mit jeweils 14 Modulen ungefähr 70 Extraordinarily Badass Agile Coaches ausgebildet (/1/). In diesem Blogpost möchte ich ein paar Erfahrungen und simple Techniken aus der Masterclass teilen, wie wir unsere Strategie besser abstimmen können. Sie beschränken sich nicht auf agiles Coaching – das ist nur das Setting.

A shared file storage is not a library

In over 90% of cases where we advise organizations on filing systems, we find that they are organized by topic. This system quickly leads to chaos because outdated documents are not disposed of quickly enough. So why does everyone think to structure their filing system by topic? I believe we have the wrong idea.

Teamleitungen gesucht

Was macht Teams erfolgreich? Kann man das lernen? Ab Herbst starten unsere Kurse für aktuelle und künftige Teamleitungen. Jetzt gibt es die Gelegenheit, den Kurs zu testen.

Wie läuft ein Projekt zum Entwickeln von Szenarien ab?

Seit 2016 beschäftigen Edgar und ich uns intensiv mit der Szenariotechnik. Szenarien sind ein wirkungsvolles Werkzeug, um Projekte oder ganze Geschäftsmodelle auf ihre Zukunftstauglichkeit zu testen.

Wie überprüft man den aktuellen Stand einer neuen gemeinsamen Ablage?

Ihr habt in eurem Team die individuellen, unordentlichen Ablagen auf eine gemeinsame Ablage, die nach Vorgängen und Prozessen geordnet ist, umgestellt. Woher wisst ihr, ob das wirklich funktioniert? In diesem Beitrag gibt es 10 Auditfragen.