Post #4119790
2026-07-26 19:59 UTC
Replies (2)
-
@0815@social.tchncs.de 2026-07-26 20:51
@isotopp@infosec.exchange Was ist mit Halluzinationen? Die werden bei LLM wohl nicht verschwinden. Sollen die durch Qualitätskontrolle und gezielte Filter eingedämmt und entfernt werden? Dann spielt die Musik im Harness-Engineering. Modellauswahl irgendwann egal. Die wohlformulierten Leitplanken machen den Unterschied ob ich einen Gegenwert für die Token bekomme.
-
@isotopp@infosec.exchange 2026-07-27 06:59
"Halluzinationen" – also Abweichungen zwischen dem, was man erwartet und was das Modell produziert, oder "Wie stelle ich sicher, daß ich das kriege, was ich will". Eine große kritische Lücke ist zwischen dem, was ich so informal in den Prompt tippe und was dann in den User Stories landet. Das ist halt unter Umständen sehr viel hineininterpretiert, was ich geschrieben habe. Darum ist es sehr wichtig, gerade bei den User Stories eine Sektion "Offene Fragen" zu prompten und auch nach "Suggestions and Notes" oder gar "Suggestions and Risks" zu prompten. Das kann man alles als Rückkanal nutzen, mit dem das Modell einem aufzeigen kann, was es alles gesehen oder nicht gesehen hat und was es erst mal so hin entschieden hat und wo man reinfassen und klären muß. Generell ist es kritisch, die generierten User Stories genau zu lesen, hart zu editieren und in 2 oder 3 passes glatt zu ziehen. Das spart einem später viele Schmerzen. Daraus generieren wir die Tickets und wenn wir alles richtig gemacht haben, dann kann man die so durchlesen und abnicken. Unter Umständen schmeißt man da noch eine Zeile oder zwei hinsichtlich Bibliotheken ("httpx statt requests!") oder Implementierungspräferenzen rein, wo es absehbar notwendig sein wird. Danach läuft dann die Codegenerierung und die ist recht hart an die Tickets geknüpft: Die Tickets sind normal sehr kleinteilig, und weil wir eine TDD Skill verlangen, implentiert das Modell eventuell irgendwelchen Scheiß, korrigiert sich dann aber hart selbst, weil die Tests nicht passen. Das macht auch klar, wo die zweite Stelle ist, wo wir genau und in der Tiefe lesen müssen, um Qualität zu sichern – die Tests. Gute Kenntnisse des Testharness und das Lesen und Verstehen von GOOS (*1) oder einem anderen TDD Buch ist hier kritisch wichtig. Es sind die Tests, die bei der eigentlichen Codegeneriert das Modell hart auf der Spur halten und verhindern, daß es vom Pfad abweicht. (*1) Growing Object Oriented Software guided by Tests, https://growing-object-oriented-software.com/