[0:00]Wer KI Agenten einfach blind machen lässt, fährt früher oder später voll gegen die Wand. Was da extrem hilft, ist ein sauberer Workflow. Und genau damit haben meine Frau und ich über 5000 € beim Open AI Hackathon gewonnen. Wenn du schon mit KI Agenten gearbeitet hast, kennst du das sicher. Du startest motiviert, der Agent arbeitet los, nach zwei Stunden schaust du auf dein Produkt und merkst, der hat Sachen umgebaut, die schon funktioniert haben, dreht sich jetzt im Kreis bei einem Bug. Und am Ende sitzt du da und fragst dich, sollte mir die KI nicht eigentlich Arbeit abnehmen, statt mir ständig neue zu machen? Genau das passiert, wenn du ohne Workflow arbeitest. In diesem Video zeige ich dir eine Lösung dafür. Erstens gibt es den kompletten Workflow Schritt für Schritt. Ich zeige dir, was die Dumb Zone ist und warum 80 % deiner Bugs genau dort entstehen. Drittens, wie du jeden Bug fixen kannst, egal wie hart er ist. Dieser Trick allein hat mir schon Stundenlange Debugging Sessions gespart. Und am Ende gibt es noch die Auflösung, welchen Platz wir beim Hackathon bekommen haben, was wir eigentlich gebaut haben. Spoiler, es hat mit KI Agenten zu tun. Also schauen wir mal rein. Wir starten direkt mit dem Brainstorm Skill, das ist einer meiner Favorites. Den findet ihr in meinem GitHub Repository Link in der Description. Auf jeden Fall könnt ihr den ausführen, wenn ihr Schrägstrich Brainstorm eingebt oder den KI Agenten einfach fragt, hey, lass uns mal kurz über ein Thema sprechen. Grundsätzlich hilft euch dieser Skill dabei, wenn ihr zu viele Ideen habt, Entscheidungen treffen wollt, ein Sparring Partner braucht oder vor einem Problem steht. Also konkret schaut das dann so aus, wir starten Codex und in jedem Programm ist es ein bisschen anders, aber in Codex ist es Dollarzeichen und dann Brainstorm. Und ich kann euch wirklich raten, den mal auszuprobieren, weil das Coole ist, dass der richtig viele Brainstorming Methoden hat. Also, wenn wir ihn hier mal kurz fragen, dann listet er gleich richtig viele von seinen Methoden auf. Und je nachdem mit welchem Topic du kommst, schlägt er auch eine bestimmte Methodik vor. Und am Ende wird er euch sagen, hey, wir speichern das als Markdown File ab. Der Grund dafür ist, ihr wollt seinen Weg haben, wie ihr diese ganzen Informationen, über die ihr gesprochen habt, abspeichert. Damit ihr in der nächsten Phase und das ist die Align Phase, eine Referenz habt, worüber ihr hier gesprochen habt. Weil wir hier schon sehen könnt, wir haben eine Context Reset. Also wir starten die Konversation von neu. Wieso wir das immer machen, möchte ich euch jetzt zeigen. Es gibt nämlich die sogenannte Dumb Zone. Ganz einfach heruntergebrochen, heißt das, ein KI Modell hat eine Zone, wo sie besonders smart ist und eine noch viel größere Zone, wo sie sehr dumm ist. Aber schauen wir uns das jetzt genauer an, wie ihr das herausfinden könnt. Im Codex könnt ihr z.B. Status eingeben. Und dann seht ihr hier das Kontextfenster und die Zahl, die besonders wichtig für euch ist, wie viel habt ihr verbraucht? In diesem Fall haben wir jetzt 17.000 verbraucht und die Smart Zone ist von 0 bis ungefähr 100.000 Tokens. Das heißt, wir haben hier noch einiges übrig. In Claude Code könnt ihr das übrigens über den Kontext Befehl nachfragen. Da sehen wir dann hier 20.000 Tokens. Also wir merken uns, es ist wichtig, dass wir uns Erkenntnisse von einer Phase in einem Markdown File abspeichern. Damit wir zwischen den Phasen einen Context Reset haben können, aber nicht ganz von neu starten, sondern die Erkenntnisse aus der letzten Phase referenzieren können. Der wichtigste Schritt von der Alleinphase ist jetzt aber was ganz anderes. Es geht darum, dass wir ein gemeinsames Verständnis von dem bekommen, was wir eigentlich umsetzen wollen. Also wir wollen nicht in die Situation gelangen, wo sich hier zwei überlegen, ja, das ist eine sechs und er denkt sich, das ist ganz klar eine neun. Und dieses Problem ist nichts Neues. Wir haben das schon ewig in der Software Entwicklung, dass ein gemeinsames Verständnis bekommen, einer der wichtigsten Schritte. Denn alles, was nicht angesprochen wird, also, was du nicht sagst, hey, ich hätte das gern so, überlegt sich die KI etwas selber. Und wenn du in einem Team arbeitest, ist es besonders wichtig, dass du diesen Schritt gemeinsam machst. Sondern ich möchte jetzt zwei Wege zeigen, wie du das machen kannst. Der erste ist der Grill Me Skill von Matt Pocock. Den könnt ihr wieder finden unter Skills, Grill Me. Und der sagt eigentlich nichts anderes, als dass die KI mich intensiv interviewen soll über dieses Thema. Denn das Letzte, was ihr wollt, ist, dass die KI euch ein, zwei Fragen stellt, glaubt euch verstanden zu haben und dann direkt mit der Implementierung beginnt. Also in der Alleinphase geht es wirklich darum, dass du, die KI und deine möglichen Teammitglieder ein gemeinsames Verständnis bekommen. Und hier ist auch wieder am Ende dieser Phase speichern wir das Ganze wieder in ein Markdown File ab. Also wir hatten jetzt zwei Phasen. Zuerst die Brainstorm Phase, dann sind wir zur zweiten Phase zur Alleinphase übergegangen und jetzt kommen wir zur Planphase. Und in der Planphase geht es darum, dass wir das große Dokument, was wir hier erstellt haben, in kleine Tasks herunterbrechen. Hier kann aber einiges schiefgehen und da möchte ich euch kurz eine Methodik zeigen, nach der ich schon sehr lange Software entwickel und die bei KI Agenten auch unglaublich gut funktioniert. Und dafür möchte ich euch ein Konzept vorstellen und zwar ist das Horizontal vs Vertical Slicing. Schauen wir uns mal kurz an, was Horizontal Slicing ist. Bei Horizontal Slicing sagt man, zuerst baue ich das Frontend, dann baue ich die Logik, dann baue ich das Datenkonstrukt. Also jedes von denen ist eine Phase, die nacheinander ausgeführt wird. Das heißt, das braucht aber auch sehr lange, bis man das erste Mal etwas testen kann. Natürlich kann man mal sagen, ich baue nur den ersten Slice, also nur das User Interface und den Rest später. Das Problem dabei ist, hier kann man noch nicht wirklich etwas testen. Es ist keine Funktionalität dahinter. Grundsätzlich haben wir auch sehr lange versucht, so Software zu entwickeln und das hat eigentlich nie richtig gut geklappt. Und irgendwann hat er mal wer gesagt, hey, lass uns stattdessen Vertical Slicing machen. Das heißt, wir schneiden eigentlich vertikal durch, wie bei einem Kuchen. Also Slice 1 implementiert dann alles, das User Interface, die Logik und die Datenlogik. Also wir bauen jetzt z.B. nur den Reservieren Button bei einer Hotelbuchungslogik. Der zweite Slice wäre dann sowas wie Cancellen und der dritte Slice wäre dann vielleicht noch die E-Mail Bestätigung samt Newsletter oder sowas. Der Vorteil beim Vertical Slicing ist, ihr könnt sehr schnell etwas testen. Und dadurch bekommt nicht nur ihr Feedback, sondern auch der KI Agent. Und wenn man den KI Agenten jetzt nicht ein bisschen trimmt, hin zum Vertical Slicing, geht er leider sehr oft auf dieses Horizontal Slicing. Das heißt, der versucht zuerst das User Interface zu bauen und schaut sich dann die anderen Layer an. Wie ich das mache, zeige ich euch jetzt gleich. Also ich starte meine Prompt oft so, schau dir mal die Markdown Dokumente an, die wir kürzlich erstellt haben und lass uns darüber sprechen, welchen Vertical Slice sollen wir uns als nächstes vornehmen? Stell mir Fragen, bis wir ein gemeinsames Verständnis haben. Und genau so haben wir das im Hackerton auch gemacht. Und was noch ungemein dabei hilft, ist, dass man sich überlegt, wie könnte das User Interface grob ausschauen? Am besten du zeichnest das auf und gibst das dem KI Agenten. Das ist wieder so eine Übung, die uns extrem geholfen hat zu verstehen, was wollen wir bauen und hat es einfach gemacht, dem KI Agenten zu erklären, was wir haben wollen. Ein weiterer wichtiger Aspekt in der Planungsphase ist sich eine Testing Strategie zu überlegen. Und wenn ich meine, man überlegt sich das, dann sagt man genauso wieder in der Prompt, hey, lass uns gemeinsam überlegen, wie wir diesen Vertical Slice testen können. Denn damit der KI Agent ordentlich arbeiten kann, muss er auch wissen, wann eine Aufgabe fertig ist. Und wenn du schon bemerkst, hey, da kommen eigentlich nur noch mehr kosmetische Fragen, wie welche Farbe soll dieser Button haben, dann sagst du ihm einfach, erstell mir einen Plan. Die meisten KI Agenten haben ja ein Planning Tool, dass man ausführen kann. Ich bin aber nicht wirklich ein Fan davon. Es reicht eigentlich zu sagen, lass uns mal darüber sprechen und dann beginnt er eh nicht zu programmieren. Auf jeden Fall am Ende dieser Planungsphase kommt wieder ein Dokument heraus, dass wir als Markdown abspeichern. Diesen Plan, den wir da bekommen, über den schauen wir jetzt nur drüber, also wir lesen den jetzt nicht komplett und versuchen den Wort für Wort zu analysieren. Also wir schauen maximal drüber. Also wir haben uns jetzt auf ein Feature geeinigt, dass wir implementieren und gehen jetzt in die nächste Phase, nämlich die Implement Phase. Und hier wieder ganz wichtig, einen Context Reset machen. Also einmal Schrägstrich New oder Clear ausfüllen, um den Kontext zu resetten. Hier geht's eigentlich nur darum, dem KI Agenten zu sagen, dass er den Plan implementieren soll. Und worauf du natürlich wieder achten musst, ist der Kontext, dass der nicht über 100.000 kommt. Die Compaction, also, dass der KI Agent seinen eigenen Kontext immer wieder verkleinert, funktioniert schon ganz gut. Ich verwende das immer öfter, also, dass ich gar nicht mehr auf den Kontext schau, aber es kommt hier immer auf den KI Agenten an, den man verwendet. Ich finde z.B. das Codex von Open AI das richtig gut macht. Claude Code hingegen von Entropics ist richtig schlechtdrin. Besonders die Modelle mit 1 Million Kontext, da kommt's mir so vor, als wären die ersten 100.000 extrem gut, den nächsten 800.000 sind richtig dumm und dann hat man die letzten 100.000, die wieder richtig gescheit werden. Also wir passen auf den Kontext auf in der Implement Phase und dann beginnt schon die nächste Phase, nämlich die Testing Phase. Hier geht es darum, dass wir den KI Agenten natürlich Feedback geben zu Funktionalität und von dem was er gebaut hat. Also wir haben sehr kurze Iterationen, wo wir der KI Feedback geben zu dem, was sie eigentlich gar nicht kann, nämlich ein Gefühl zu bekommen, wie lässt sich die Software bedienen? Also, wenn sich der Workflow, den der KI Agent gebaut hat, ein bisschen awkward anfühlt, also z.B. viel zu viele Buttons, unendlich viele Input Felder, es steht viel zu viel Text. Also die Funktionalität aus der Implement Phase ist hier meistens eh schon erreicht, weil wir dem KI Agenten ja davor gesagt hat, wie er selber überprüfen kann, ob er sein Ziel erreicht hat. Und nach den Feedback Schleifen kommen wir in die Recap Phase und die finde ich ist besonders wichtig. Man lässt sich nämlich sehr oft dazu verleiten, einfach der KI zu sagen, bau noch ein Feature, bau noch ein Feature, bau dies, bau das und am Ende verliert man eigentlich den Überblick, was das ganze Tool eigentlich kann und vor allem, wie es funktioniert. Und genau das machen wir in der Recap Phase. Wir fragen den KI Agenten wirklich, wie funktioniert das, was wir gerade gebaut haben? Kannst du mir den Ablauf mal erklären, wie das Ganze funktioniert? Und am besten zeichne mir das Ganze noch in einem Diagramm auf, damit ich das visuell verstehe. Es ist extrem wichtig, dass du das Produkt verstehst und auch den Überblick behältst. Denn wenn du das nicht machst, bist du spätestens nach der fünften oder sechsten Iteration von diesem Zyklus nicht mehr die Person, die Entscheidungen treffen wird. Und wenn du das Denken an die KI abgibst, wird sich das Produkt einfach in die falsche Richtung entwickeln. Also überspringen diese Phase bitte nicht. Als nächstes kommen wir in die Refactor Phase. KI Agenten lieben es komplizierten Code hinzuzufügen. Das heißt, wir müssen die KI aktiv forcieren, entweder Code zu entfernen oder zu vereinfachen. Und das ist auch wieder etwas, mit dem ihr wirklich nicht warten könnt. Denn wenn ihr sagt, hey, darum kümmere ich mich eigentlich später, dann baut die KI auf einem richtig schlechten Fundament auf. Also ihr kennt es vielleicht dieses Bild, wo man sich zu Beginn noch ein bisschen Mühe gegeben hat, dann hat schon hier begonnen ein bisschen historisch zu wachsen und oben ist eigentlich nur noch mehr Chaos. Und wenn die KI Chaos sieht, schaut sie sich diesen Blödsinn einfach ab. Also schauen wir kurz, wie du das verhindern kannst. Dabei gibt es einige Fragen, die du die KI stellen kannst. Ich frage dann z.B., was wäre der kleinste sichere Schritt, der diese Code Basis besser machen kann? Kann ein neuer Entwickler den Ablauf ohne mentale Sprünge verstehen? Welche Refactoring Schritte würden das Verhalten erhalten, aber die Struktur verbessern? Falls ihr schon mal in der Software Entwicklung gearbeitet habt, werden euch diese Fragen sehr bekannt vorkommen oder habt sie in anderer Art und Weise schon mal irgendwo gehört. So und dann kommen wir auch schon in die letzte Phase, nämlich die Commit oder Pull Request Phase. Die ist eigentlich recht kurz, da sage ich dem KI Agenten eigentlich nur Commit Code Atomically. Also er soll möglichst kleine Git Commits machen. Danach sage ich ihm noch, er soll die Markdown Files, die wir erstellt haben, aufräumen, also eigentlich entfernen. Denn jetzt, wo wir das Ganze ausprogrammiert haben, steckt die Wahrheit eigentlich im Code. Und wir wollen nicht unsere Codebasis voll mit Markdown Files haben, die ziemlich sicher veraltet werden. Wenn ihr diese Dateien nicht löscht, wird sich der KI Agent in folgenden Iterationen all diese Dateien anschauen und würde sich von denen verwirren lassen. Also mein Tipp, unbedingt diese Dateien löschen. Wenn ihr den noch mal sehen wollt, sind sie eh gespeichert im vorherigen Commit. Das heißt, wir löschen sie und committen dann noch einmal. Und dann machen wir einfach ein Pull Request oder pushen direkt auf dem Master Branch, je nachdem, ob ihr alleine oder in einem Team arbeitet. Also wir haben uns jetzt alle acht Phasen angeschaut. Es startet mit der Brainstorm Phase, wo wir uns im Klaren werden, was wir eigentlich bauen wollen. Die Align Phase, wo wir genau ins Detail gehen, um zu verstehen, wie das Ganze funktionieren soll. Die Planungsphase, wo wir uns ein kleines Stück, ein Vertical Slice nehmen von dem ganzen Produkt, dass wir dann in der Implementierungsphase implementieren. In der Testing Phase machen wir noch mal kurze Feedback Schleifen, wo wir das Ganze ein bisschen vereinfachen, unnötige Buttons entfernen und vielleicht ein bisschen am Design iterieren. In der Recap Phase geht es darum, dass ihr versteht, was hat der KI Agent alles gemacht, denn ihr müsst eigentlich den Überblick behalten über das ganze Produkt. In der Refactor Phase geht es darum, dass wir den Code ein bisschen aufräumen und nachhaltiger bauen. In der Commit Phase stellen wir sicher, dass das alles noch abgespeichert ist und räumen noch mal die ganzen Markdown Files aus den vorherigen Phasen auf. Und dann geht's eigentlich wieder zurück in die Planungsphase, wo wir uns wieder einen Vertical Slice nehmen aus dem Align Dokument und iterieren wieder drüber. Es gibt jetzt Frameworks wie den Ralph Loop oder Get Shit Done Loop, der das Ganze hier automatisiert. Ich bin ehrlich gesagt kein Fan davon, denn die KI hat noch nicht dieses Produktgefühl. Es kommt dann am Ende zwar irgendwas sinnvolles raus, aber bei mir ist es eigentlich so, dass in diesen Iterationen wird es erst klar, was das Produkt alles können muss, wie es sich anfühlen soll. Und das ist nichts, was man zu Beginn ausdefinieren kann. Und das alles ist jetzt nichts Neues. Wir haben lange versucht in der Software Entwicklung mit dem Wasserfall Framework im Vorhinein genau zu definieren in Lastenheften oder sonstigen, was die Software alles können soll und am Ende ist dann irgendein Blödsinn rausgekommen. Der iterative Zyklus mit den kurzen Feedback Schleifen passt viel besser in das Agentische Programmieren. Code wird extrem schnell produziert, wir können sehr schnell Feedback geben und sagen, das geht in die richtige Richtung, das geht in die falsche Richtung. Deshalb meine Empfehlung, verwendet dieses Framework, wenn ihr nicht hundertprozentig sicher seid, wie das Produkt am Ende ausschauen soll. Aber es gibt hier auch eine Challenge. Sagen wir mal, ihr habt jetzt schon zehn Iterationen hinter euch. Also ihr habt zehn Mal diesen Flow hier durchgearbeitet, dann trefft ihr ziemlich sicher in diesen Iterationen auf Bugs, die sich richtig schwierig lösen lassen. Und ich zeige euch jetzt, wie ich bisher immer geschafft habe, da rauszukommen. Also das Wichtigste ist, dass die KI eine Methode hat für Selbstverifizierung. Das heißt, sie ist nicht angewiesen darauf, dass ihr überprüft, ob der Bugfix jetzt funktioniert hat. Und das erarbeitet sie gemeinsam mit der KI. Das schaut dann bei mir z.B. so aus. Ich stoße immer wieder auf diesen Bug. Da beschreibt sie in kurz. In den letzten Iterationen haben wir keinen Fix dafür gefunden. Lass uns gemeinsam herausfinden, wie du verifizieren kannst, dass der Bug auch gefixt wurde. Und dann seid ihr nicht mehr die Person, die das testen muss. Das heißt, der KI Agent kann jetzt hier was ausprobieren und kann hier dann sehen, ob es wirklich geklappt hat und möglicherweise dann noch einen weiteren Anlauf starten. Testet dann wieder, hat wieder nicht funktioniert, biegt dann vielleicht noch mal anders ab und kommt dann endlich aufs Rätsel Lösung und gibt euch dann nur noch mehr Bescheid, hey, ich habe es gefunden, hier ist die Lösung. Wenn nicht so schwierigen Problemen reicht es aber oft einfach zu sagen, beschreibe das Problem für den nächsten Agenten und was du schon versucht hast, um es zu fixen. Die Antwort kopierst du dir dann, startest einen neuen Chat und gibst diese Anweisungen dann dem KI Agenten. Das reicht dann meistens schon, um wirklich das Problem zu lösen. Aber der Weg hier oben führt eigentlich fast immer zum Ziel. Das ist jetzt grob mein Workflow, wie ich mit KI Agenten arbeite, also bei Projekten, wo ich mich jetzt explizit dafür entscheide, nicht den Code zu lesen. Was zu dem Workflow jetzt auch wichtig ist, vieles habe ich mir von anderen abgeschaut, kombiniert, selber neu ausprobiert und genau das würde ich auch dir raten. Es gibt nicht den Workflow, sondern es macht Spaß, einfach seinen eigenen zu verfeinern. Übrigens, was wir gebaut haben, heißt Honest Product Tester. Die Idee, du kannst mit diesem Tool deine Website testen lassen. Also sechs verschiedene KI Agenten gehen auf deine Website, jeder eine eigene Persona. Der eine ist der gestresste Manager, der andere die skeptische Studentin, der dritte der Techner, der alles brechen will. Jeder kriegt seinen eigenen Browser und schaut sich deine Website an. Gebaut haben wir das mit dem Pi Agent von Mario Zechner. Dazu habe ich übrigens ein eigenes Video gemacht. Am Ende bekommen sie von allen sechs KI Agenten ein Review und Feedback zu eurem Tool, was ihr gebaut habt. Bei dem Hackathon wurden wir durchgepowert von der Firma Sentry, Frühstück, Pizza, Leberkäse. Für die Nicht-Österreicher unter euch, es schmeckt besser, als es klingt und ist bei jedem Wiener Hackathon Pflicht. Alex, unser Moderator von dem Tag war übrigens auch eine echte Legende. Und am Ende wurden die Top 5 von, ich glaube, 45 Teams ausgerufen. Honest Product Tester.
[16:15]Wir haben den Platz 5 belegt. Zwei Chat GPT Pro Abos für Waner und mich, zusammen im Wert von über 5000 €. Eine Sache, die mir noch wichtig wäre. Wenn dich solche Workflows und Analysen auch aus Projektmanagement Sicht interessieren, meine Frau Wana hat jetzt selber einen YouTube Channel und würde sich extrem freuen über ein Abo. Also schaut mal bitte vorbei. Link dazu ist unten. Also wir sehen uns beim nächsten Mal. Servus!
