![]() |
|
Aki's Vibes - Druckversion +- GridTalk.de (https://www.gridtalk.de) +-- Forum: Projekt Foren (https://www.gridtalk.de/forumdisplay.php?fid=48) +--- Forum: Sonstiges (https://www.gridtalk.de/forumdisplay.php?fid=64) +--- Thema: Aki's Vibes (/showthread.php?tid=5342) |
RE: Aki's Vibes - Akira - 14.09.2026 Acht Irrtümer, die nicht wiederkommen dürfen ![]() Oder: wie ich gemerkt habe, dass mein Projekt zwar ein Gedächtnis für Entscheidungen hatte, aber keines für Irrtümer. Vor ein paar Wochen habe ich hier vom Ringbuch der Architektin erzählt. Kurzfassung: Für jede Architektur-Entscheidung gibt es bei mir eine datierte, unterschriebene Seite. Was nicht mehr gilt, wird nicht gelöscht, sondern durchgestrichen und ersetzt. Die KI, mit der ich arbeite, muss das Ringbuch lesen, bevor sie eine Wand anfasst. Das funktioniert. Aber es beantwortet nur eine einzige Frage: Was gilt? Es beantwortet nicht: Was habe ich schon versucht? Was ist dabei schiefgegangen? Und welchen Weg habe ich bewusst nicht genommen? Ich dachte lange, das stünde ja alles im Tagebuch. Die Werkstatt stellt keine Entscheidungen her, sondern Irrtümer Neben dem Hotel habe ich eine zweite Baustelle: die Brillenwerkstatt. Das ist AkiGlass, mein eigener Viewer — die Software, durch die man in die Welt hineinschaut. Ich habe hier schon erzählt, warum ich mir die Brille selber schleife. Die Arbeit dort ist eine völlig andere als im Hotel. Im Hotel entscheide ich. Soll die Rezeption diesen Anruf führen oder die Zentrale? Das ist eine Frage, auf die man eine Antwort geben und sie unterschreiben kann. In der Werkstatt entscheide ich fast nie. Ich messe. Der Himmel ist an einer Stelle zu hell. Warum? Ich habe eine Vermutung. Ich baue einen Messaufbau, führe ihn aus, und die Vermutung fällt. Ich habe die nächste. Die fällt auch. Stand heute liegen in der Werkstatt achtzehn geltende Entscheidungen — und zehn Versuche. Die Entscheidungen waren schnell hingeschrieben. Die Versuche sind die eigentliche Arbeit. Das Ringbuch kann Irrtümer nicht aufnehmen Der Reflex wäre: schreib die Vermutung doch auch ins Ringbuch. Geht nicht. Eine Ringbuch-Seite ist eine Zusage. Sie sagt: so wird gebaut. Eine widerlegte Vermutung ist keine Zusage, sie ist ein Zwischenstand. Wenn ich beides in dasselbe Buch schreibe, weiss in vier Wochen niemand mehr — ich am allerwenigsten —, welche Seite eine Verpflichtung war und welche nur laut gedacht. Und der Schaden geht in beide Richtungen. Was ich nicht eintrage, ist eben auch nicht da. Die Erkenntnis „das ist es nicht" ist genauso teuer erkauft wie die Erkenntnis „so machen wir es". Sie hat nur keinen Platz gehabt. Das Tagebuch auch nicht Blieb das Projekt-Tagebuch. Ich führe eines, seit April, und ich führe es gern. Als ich im September zum ersten Mal ernsthaft hineingeschaut habe, stand da:
Und dann habe ich nachgezählt, wie oft in diesen 386 Einträgen ein Ergebnis steht. Nicht als Prosa, sondern als etwas, das man finden kann. Null Mal. Kein „Ergebnis", kein „Status", kein „Fazit", kein abgehaktes Kästchen. Von 386 Einträgen verweisen 41 auf eine Aufgabennummer. Der Rest hängt in der Luft. In fast der Hälfte aller Einträge steht irgendwo „offen" oder „unklar", in knapp einem Drittel „versucht" oder „probiert", in einem Zwanzigstel „verworfen". Das Kernproblem ist aber nicht die Wortwahl. Es ist folgendes: Ein Eintrag vom 3. Mai sagt „wir versuchen X". Ein Eintrag vom 12. Juni sagt „X war eine Sackgasse". Diese beiden Einträge sind durch nichts miteinander verbunden. Keine Nummer, kein Rückverweis, kein Zustand. Die Verbindung existiert nur in meinem Kopf. Und mein Kopf ist, das habe ich inzwischen mehrfach belegt, der unzuverlässigste Datenspeicher im ganzen Projekt. Ein Tagebuch ist ein Erzählstrom. Ein Erzählstrom hat keinen Zustand. Er hat nur ein Ende. Also ein drittes Buch Ich führe jetzt drei Bücher statt zwei.
Ein Werkstattbuch-Eintrag ist keins von beiden anderen. Er hat, was eine Ringbuch-Seite hat: eine Nummer und einen Zustand. Und er hat, was ein Tagebuch-Eintrag hat: ein Datum und eine Geschichte. Aber er hat etwas Eigenes, das die beiden anderen nicht können — er hat einen Ausgang. Oben auf jedem Blatt steht die Vermutung. Ganz wörtlich, in dem Wortlaut, in dem ich sie hatte, bevor ich es besser wusste. Und dahinter steht, was daraus geworden ist: bestätigt, widerlegt, verworfen, blockiert, läuft noch. Das Entscheidende ist: die Vermutung bleibt stehen, auch wenn sie falsch war. Sie wird nicht korrigiert. Sie wird beschriftet. Und dann gibt es auf jedem Blatt ein Regal mit einer Überschrift, auf die ich ein bisschen stolz bin: Widerlegt, soll nicht wiederkommen. Acht Stück allein für einen hellen Streifen Wie voll so ein Regal wird, zeigt der Versuch, der mich Mitte September zwei Tage gekostet hat. Unter dem Horizont stand ein weisser Streifen. Flach, hell, an einer scharfen Kante endend. Cool VL — der Viewer, an dem ich mich messe — zeigt ihn nicht. Hier ist, was am Ende im Regal lag:
Acht Vermutungen. Acht Widerlegungen. Die tatsächliche Ursache war eine ganz andere: vier Werte, die die Himmelsrechnung braucht, kommen als glatte Null an, wo eigentlich 1605 stehen müsste. Jede einzelne dieser acht Zeilen ist bezahlte Arbeit. Und jede einzelne wäre in einem Tagebuch nach drei Wochen unauffindbar gewesen. Im Regal steht sie mit einem Satz, warum sie es nicht ist. Wenn der Streifen in einem halben Jahr wiederkommt, fange ich bei Nummer neun an. Die Tür, die aufgeht, während man misst Der schönste Eintrag im Werkstattbuch hat aber gar nichts mit dem Himmel zu tun. Ich hatte eine Messreihe zur Zeichengeschwindigkeit. Ein paar Läufe brachen mitten drin ein, von fast hundert Bildern pro Sekunde auf achtzehn, und blieben dort. Meine Vermutung: der Viewer hört irgendwann auf, verdeckte Dinge wegzulassen, und zeichnet stur alles. Klang gut. War falsch. Der Viewer hat eine eingebaute Höflichkeit: sobald sein Fenster nicht mehr im Vordergrund ist, legt er sich nach jedem Bild vierzig Millisekunden schlafen. Er soll ja nicht den ganzen Rechner blockieren, während man was anderes macht. Das ist kein Fehler, das ist Absicht, und es steht sogar kommentiert im Quelltext. Nur: Ich habe die Bildschirmfotos für die Messung mit einem Werkzeug gemacht, das immer das aktive Fenster aufnimmt. Und in einem Lauf steht im Protokoll um 19:01:55 ein Bildschirmfoto — von meinem Browser. Sechs Sekunden später bricht die Messkurve ein. Ich habe meine eigene Messung kaputtgemacht, indem ich zugesehen habe. Das Bittere daran ist nicht der verlorene Nachmittag. Es ist, dass so ein Lauf plausibel aussieht. Keine Fehlermeldung, keine Warnung, einfach eine ordentliche Tabelle mit ordentlichen Zahlen, die nichts über die Wirklichkeit aussagen. Seitdem steht in meinem Messprotokoll ein fünfter Pflichteintrag neben Ort, Position, Blickrichtung und Uhrzeit: war das Fenster vorne? Und eine Messung, die gegen dieselbe Vermutung lief, musste ich im selben Zug zurückziehen. Auch das steht im Werkstattbuch. Ich finde, das gehört dazu. Das Fach für Wege, die keiner gegangen ist Es gibt noch einen Abschnitt auf jedem Blatt, und der ist Pflicht. Er heisst Alternativen, die offen bleiben. Da hinein kommt, was ich hätte tun können und nicht getan habe — mit dem Grund dahinter. Nicht „verworfen", sondern warum. Ein Beispiel aus dem Streifen-Versuch: Ich hätte die Sichtweite hochdrehen können, dann hätte das Wasser bis zum Horizont gereicht und den Streifen verdeckt. Hätte funktioniert. Steht trotzdem unter „nicht gegangen", mit einem Satz: deckt das Band zu, statt es zu behandeln. Ein anderes: die Wasser-Zeichenvorschriften einfach komplett von Cool VL übernehmen. Naheliegend, geht schnell. Auch nicht gegangen, weil Cool VL die Hälfte seiner Korrekturen gar nicht dort macht — man bekäme eine halbe Rechnung und wüsste es nicht. Dieses Fach ist der einzige Ort im ganzen System, an dem ein nicht gegangener Weg überlebt. Das Ringbuch kennt ihn nicht, es kennt nur den gegangenen. Das Tagebuch hat ihn vielleicht erwähnt, aber unauffindbar. Ohne dieses Fach ist die Frage „haben wir das mal geprüft?" in sechs Monaten nicht beantwortbar — und wird dann halt nochmal geprüft. Drei Sachen, die ich daraus gelernt habe
Und ja — das hier ist ein Beitrag darüber, dass ich Buch über meine Fehler führe. Ich sehe die Ironie. Die steht jetzt auch in einem Buch. RE: Aki's Vibes - Pius Noel - 15.09.2026 Dieser Thread gehört zu dem Besten, was ich jemals zum Thema VIbe Coding gelesen habe. RE: Aki's Vibes - Akira - 15.09.2026 (15.09.2026, 11:12)Pius Noel schrieb: Dieser Thread gehört zu dem Besten, was ich jemals zum Thema VIbe Coding gelesen habe. Vielen Dank! Es macht auch riesig Spass !!! Ich lerne jeden Tag was Neues. Vibe Coding ist das schon lange nicht mehr, war es auch nie. Ausschlaggebend für diese Projekte waren Matt Pocock und seine Skills. Als ich im April seine Youtube Videos gesehen habe, wusste ich, das könnte funktionieren. Inzwischen hat das Vorgehen auch schon einen Namen "Spec Driven Developement" oder SDD. Neben Matt’s Vorgehen gibt es noch eine Reihe anderer Vorgehensweisen, aber sein Skill "grill-me" hat Furore gemacht. Das Vorgehen ist recht einfach.
Am Anfang war das noch ganz einfach. Im Kontextfenster, welches das LLM zur Verfügung stellt, konnte ich eigentlich alles, das Issue und das Drumherum, verpacken. Inzwischen sind die Probleme aber komplexer geworden und ich merkte schnell dass der Agent plötzlich zu loopen begann. Das heisst er schlug was vor, was wir vor Tagen schon durchprobiert hatten. Deshalb benötigte ich die nächste Stufe, das Projektgedächtnis, welches ich inzwischen recht weit implementiert habe und am Feintunen bin. Die Reise bleibt spannend! und die Vibes sind immer noch gut! |