Elektrine lite

← Feed

@isotopp@infosec.exchange

Post #4119599

2026-07-26 19:46 UTC

Produziert ein LLM schlechten Code? Das kommt darauf an, als was man sich selbst sieht, wie man es fragt und was man denn erwartet. Man kann ein LLM schlau fragen, https://blog.koehntopp.info/2026/06/05/llm-driven-development/ Was man hier macht sind drei wirkmächtige Dinge mit dem LLM zu kombinieren: Wir verwenden einen Coding Harness, der dem LLM Zugriff auf ein Dateisystem gibt. Das fügt dem Kurzzeitgedächnis "Kontext" das Langzeitgedächnis "Dateien" hinzu.Wir verwenden das Konzept der Progressive Discovery, das es dem Modell erlaubt, sich selbst seinen Kontext aus den Dateien anzureichern, indem wir Indexdateien bereitstellen, die das Modell verwenden kann, um zu entscheiden, welche Dateien es einliest.Wir verwenden das Konzept des Refinements, um von der vagen Idee "Ich will etwas, das x macht" zu einer strukturierten Beschreibung von x zu kommen (den User Stories), und dann mit dieser zu einer schrittweisen Implementierungsvorschrift, den Tickets. Das Modell implementiert dann nicht dem vagen Wunsch, sondern arbeitet konkrete Tickets nach einer bestimmten Methode – TDD – ab. Vom Prozeß her bin ich ein Product Owner mit einem Team von Null Menschen. Meine Arbeit ist die eines Product Owners. Wie ein Product Owner bekomme ich Code, der jedesmal anders aussieht, wenn ich ein Team frage, dasselbe Problem zu lösen. Wie ein Product Owner bekomme ich Code, den ich erst einmal nicht verstehe und den ich, wenn mich das interessierte, erst einmal erforschen muß. Tu ich das, bekomme ich von einem aktuellen LLM Code, der nicht so aussieht, wie ich ihn geschrieben hätte, aber der passing ist, also für Code in der Zielsprache gut genug aussieht.

Replies (5)

  • @isotopp@infosec.exchange 2026-07-26 19:50

    Ja, aber Kris, wieso ist dann der ganze gevibecodete Kram so Scheiße? Wir haben hier ein neues Werkzeug. Wie bei jedem Werkzeug braucht es Handwerk, also eine Liste von Verfahrensweisen – werkzeugspezfisch – die uns Kontrolle über den Output geben. Handwerk beherrschen heißt, das Werkzeug so zu verwenden, daß man den Output kontrolliert und die Form des Ergebnisses gezielt beeinflussen kann. Wenn man einen Harness fragt "Implementiere mir $DING", dann ist das Ergebis komplett unkontrolliert. Wenn man einen Harness fragt, verfeinere mit doch mal die idee von $DING, die User Stories durchsieht und editiert, den Harness fragt "Ok, auf dieser Grundlage, und TDD, wie kriegen wir $DING implementiert" und dann die Tickets durchsieht und dann dem Harness die Implementierung kleiner umsetzbarer Tickets schrittweise beauftragt, der hat vermutlich eine Menge mehr Kontrolle über das Resultat. Das ist der Prozeß eines PO, und man hat dann vermutlich so viel Kontrolle über das Resultat wie ein PO.

    Open ##4119643

  • @hzulla@infosec.exchange 2026-07-26 20:09

    @isotopp@infosec.exchange mMn kannst Du eine generative KI nur dann wirklich sinnvoll nutzen, wenn Du als Anwender bereits Experte auf dem Thema bist, für das die generative KI für Dich Output produziert. Generative KI wird aber aktiv als Werkzeug vermarktet mit dem Versprechen, dass Du ohne vorherige eigene Expertise Aufgaben erfüllen kannst. A PhD in your pocket. Bzw dass Du keine Experten mehr einstellen musst, weil ungelernte Mitarbeiter diese Arbeit jetzt erledigen können. Dieses Versprechen hat die Mehrheit der Öffentlichkeit auch so geglaubt, wenn ich mir die Art ansehe, wie vom Lehrer über die Teamleitung bis hin zum CEO jetzt generative KI einsetzen. Das ist das Problem, das ich hier sehe. Nicht, dass generative KI jetzt "da ist" und "nicht wieder weg" geht. Sondern dass ein sehr sehr großer Teil ihrer Anwender fest daran glaubt, dass deren Ergebnisse gut genug sind für das, wo sie Chatbots einsetzen.

    Open ##4120003

  • @jwalzer@infosec.exchange 2026-07-26 21:34

    @isotopp@infosec.exchange @mastoreaderio@mastodon.social unroll

    Open ##4121507

  • @WooShell@chaosfurs.social 2026-07-27 08:10

    @isotopp@infosec.exchange ach, einfach "don't make mistakes! don't hallucinate!" ins Manifest mit reinschreiben, und schon wird alles gut. Oder halt die Aufgabe nicht an ein glorifiziertes Autocomplete sondern an einen Menschen mit echtem Wissen und Verstand abgeben.

    Open ##4132247

  • @cdonat@hostsharing.coop 2026-07-26 19:57

    @isotopp@infosec.exchange Nach meiner Erfahrung kann ein LLM guten Code erzeugen, tut das aber nicht konsistent. Ich mach das so: 1. Ich diskutiere Architektur und Design mit dem LLM 2. Damit lasse ich das LLM dann Code erzeugen, den ich Reviewe, bevor ich ihn übernehme. 3. Wenn der Code schlecht ist, dann Gibt es konkrete Kritik und wir machen bei 2. weiter, bist es passt. 1/2

    Open ##4323927