Wie Oxide LLMs einsetzt

 (rfd.shared.oxide.computer)
4 Punkte von GN⁺ 2025-12-08 | 1 Kommentare | Auf WhatsApp teilen
  • Large Language Models (LLM) verändern die Arbeitsweise grundlegend, und Oxide hat klar definiert, wie sie innerhalb der Organisation eingesetzt werden sollen
    • Oxide ist ein On-Demand-Computing-Infrastruktur-Startup, das integrierte Hardware- und Softwarelösungen für On-Premises-Datacenter entwickelt
  • Oxide stellt als Leitprinzip die Balance zwischen Verantwortung, Gründlichkeit, Empathie, Teamwork und Dringlichkeit für die Nutzung von LLMs dar
  • Beim Dokumentenverständnis/-zusammenfassen, Code-Review und Debugging sind LLMs nützlich, beim Schreiben von Texten oder Code sind jedoch menschliches Urteil und Verantwortung erforderlich
  • Für von LLMs erzeugte Ergebnisse muss immer ein Prozess mit menschlicher Prüfung und Verantwortungsübernahme erhalten bleiben
  • Oxide fördert den Einsatz von LLMs, setzt ihn jedoch auf die Voraussetzung von Verantwortung für Produkt, Kunden und Kollegen

Werte für den Einsatz von LLMs

  • Oxide bewertet den Einsatz von LLMs anhand der Kernwerte der Organisation
    • Verantwortung (Responsibility): LLM ist lediglich ein Werkzeug, und die Verantwortung für Ergebnisse liegt vollständig beim Menschen
    • Gründlichkeit (Rigor): Bei sorgfältiger Nutzung kann das Denken geschärft werden, bei Nachlässigkeit sinkt die Qualität des Denkens
    • Empathie (Empathy): Sowohl Empfänger als auch Autoren von Sprache sind Menschen, daher muss menschliche Kommunikation erhalten bleiben
    • Teamwork (Teamwork): Der Einsatz von LLM darf das Vertrauen zwischen Kollegen nicht untergraben und das Offenlegen der Nutzung darf nicht wie Verantwortungsabschiebung wirken
    • Dringlichkeit (Urgency): Auch wenn die Geschwindigkeit erhöht werden kann, dürfen andere Werte nicht geopfert werden

LLMs als Leser

  • LLMs sind besonders stark in Dokumenten-Zusammenfassung und Frage-Antwort, und sie können große Mengen an Material schnell erfassen
  • Datenschutz muss jedoch gewährleistet werden, und es muss sichergestellt werden, dass hochgeladene Dokumente nicht für das Training des Modells verwendet werden
  • Als Hilfsmittel zur Dokumenten-Verständnisunterstützung sind sie sinnvoll, können jedoch nicht die direkte Lektüre ersetzen

LLMs als Editoren

  • Sehr effektiv für die Verbesserung von Struktur und Stil in fertiggestellten Dokumenten, insbesondere in späteren Phasen
  • LLMs haben jedoch die Tendenz, übermäßig positiv zu reagieren, sodass kritische Analyse fehlen kann
  • Beim Einsatz in der Entwurfsphase besteht das Risiko, die eigene Stimme des Autors zu verlieren

LLMs als Autoren

  • Texte, die von LLMs erzeugt werden, sind häufig floskelhaft oder tragen deutliche Spuren automatischer Erzeugung
  • Automatisch erzeugte Inhalte können die Echtheit des Denkens und das Vertrauen der Leser untergraben
  • Leser gehen üblicherweise davon aus, dass der Autor den Inhalt versteht; LLM-Inhalte brechen diese Annahme
  • Oxide geht davon aus, dass alle Mitglieder über Schreibfähigkeit verfügen und nutzt LLMs nicht als primären Schreiber
  • Sie können jedoch eingeschränkt als Hilfsmittel zur Ideenfindung oder Unterstützung genutzt werden

LLMs als Code Reviewer

  • LLMs sind bei der Erkennung bestimmter Code-Probleme hilfreich, können jedoch kein menschliches Review ersetzen
  • Da Vorschläge unlogisch sein oder den Kontext verfehlen können, sollten sie nur als ergänzendes Werkzeug genutzt werden

LLMs als Debugger

  • LLMs können als eine Art 'Rubber-Duck' dienen, das Debugging-Ideen anregt
  • Die eigentliche Problemlösungskapazität ist begrenzt, aber sie sind nützlich als Impuls für neue Herangehensweisen

LLMs als Programmierer

  • LLMs haben eine sehr starke Code-Generierungsfähigkeit und eignen sich für experimentelles und unterstützendes Coden
  • Je näher der Code dem Produktcode kommt, desto wichtiger werden Validierung und Verantwortungsübernahme
  • Code, der von LLMs erstellt wurde, muss vom Autor selbst geprüft werden (Self-Review), und vor einem Kollegium-Review ist eine Überprüfung zwingend erforderlich
  • Im Rahmen eines Code-Reviews ist es verboten, mit vollständiger Neukompilation zu reagieren, da ein wiederholtes Review unmöglich wird
  • Auch bei der Code-Generierung müssen Verantwortung, Gründlichkeit, Empathie und Teamwork gewahrt werden

Betrieb und Richtlinien

  • Die technischen Details und internen Leitlinien zur LLM-Nutzung sind in einem internen Dokument auf GitHub festgehalten
  • Oxide empfiehlt den Einsatz von LLMs, macht jedoch verantwortungsvolle Nutzung zur Voraussetzung
    • Verantwortungssinn für Produktqualität, Kundenvertrauen und Zusammenarbeit unter Kollegen steht an erster Stelle

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-12-08
Hacker-News-Kommentare

  • Bryans Text zeigt eine ausgewogene und realistische Perspektive
    Ich denke, dass im RFD entsprechende Inhalte fehlen, weil Oxide keine Junior Engineers einstellt
    Bryan ist ein Engineer, der seit über 30 Jahren mit schwieriger Software und Hardware arbeitet, und hat Erfahrung damit, ein „wirklich schwieriges Programm (OS)“ fertigzustellen
    Seine Art, mit LLMs umzugehen, unterscheidet sich stark von der eines Junior Engineers im Jahr 2025
    Heutige Juniors haben wahrscheinlich kaum jemals ohne die Hilfe von LLMs programmiert

    • Früher gab es bei uns in der Firma Zeiten, in denen man monatelang nur Modelle für die Dateninjektion gebaut hat
      Das war so langweilig, dass es schon schwerfiel, überhaupt zur Arbeit zu gehen, aber heute könnte man das mit einem LLM wahrscheinlich in ein paar Minuten erledigen
      Wenn ich heute daran denke, wirkt die damals investierte Zeit fast verrückt
    • Ich erinnere mich an meinen ersten Webdesign-Kurs, in dem der Lehrer ein ganzes Semester lang mit Notepad die „grundlegenden Prinzipien“ von HTML, CSS und JS vermittelt hat
      Erst danach hat er Dreamweaver eingeführt, und die Produktivität stieg um das Zehnfache
    • Die Spannung zwischen „Handwerklichkeit vs. Pragmatismus“ bei LLMs ist interessant
      In Bereichen mit klaren Ergebnissen wie der Sicherheitsforschung sind LLMs hervorragend, aber bei Problemen, die feine Urteile erfordern, sind sie schwach
      Ideal ist es daher, die wiederholbaren und systematischen Teile dem LLM zu überlassen und die urteilsabhängigen Teile Menschen
    • Ich programmiere seit über 20 Jahren und hatte eine unsichtbare Abneigung dagegen, LLMs zu benutzen
      Inzwischen habe ich aber akzeptiert, dass das „eine neue Art des Programmierens“ ist, und als ich das erkannt habe, fühlte ich mich sogar irgendwie jünger
    • Ich musste lachen, dass direkt nach der Formulierung „Leute, die Spuren von LLMs erkennen“ ein em dash (—) auftauchte
      Es nervt mich ein wenig, dass man heute schon wegen eines em dash für AI-generierten Text gehalten wird

  • Beim Lesen von Oxides RFD habe ich meistens zustimmend genickt, aber dem Teil, dass „LLMs von Anfang an guten Code schreiben“, stimme ich nicht zu
    LLMs sind gut darin, das „Blank-Page-Syndrom“ zu lösen, aber ich denke, dass produktionsreifer Code weit von diesem Ergebnis entfernt ist
    Das könnte auch eine „Illusion des Fortschritts“ sein

    • Schreiben ist persönlicher Ausdruck, Code dagegen ein Werkzeug zur Problemlösung
      LLMs lernen „gute Lösungen“, die oft in Datensätzen vorkommen, und sind deshalb stark bei der Problemlösung
      Menschlicher Ausdruck lebt dagegen wesentlich von Vielfalt, sodass durchschnittlicher Ausdruck schnell langweilig wird
      Am Ende könnten LLMs die Fähigkeit einschränken, ungelöste Probleme zu lösen
      Ich denke, die geringe Codequalität liegt an den Grenzen des context window
    • Abgedroschene Texte sind schlecht, aber abgedroschener Code ist eher gut
    • Die Erwiderung „Probier einfach ein anderes Modell“ fühlt sich inzwischen an wie das „No True Scotsman“ der LLM-Welt
      Generierung auf Funktionsebene ist okay, aber wenn man ihr ein ganzes Feature überlässt, werden Struktur und Interfaces chaotisch
      Mit Schreiben verglichen ist es am ehesten so, als gäbe man nur den ersten und letzten Satz eines Absatzes vor und lässt den Rest auffüllen
    • Das ist ähnlich wie bei Nachrichten aus Bereichen, in denen wir uns auskennen: Dort erkennen wir Fehler leicht, während wir sie in unbekannten Feldern einfach glauben
      Programmierer können Codequalität beurteilen, bei Texten ist das oft nicht so
    • Die Qualität von LLMs hängt vom Modell ab
      Viele haben einen schlechten Eindruck, weil sie ältere oder billigere Modelle benutzt haben

  • Ich habe Zweifel an der Behauptung, „LLMs erkennen von LLMs geschriebenen Text gut“
    Ich frage mich, ob das durch Daten belegt ist

    • Bryan von Oxide erklärt das selbst
      Ihr Einstellungsprozess sei stark schreibzentriert, daher habe die Zahl der mit LLMs verfassten Bewerbungen zuletzt stark zugenommen
      In RFD 0003 und auf der Karriereseite werde zwar davor gewarnt, trotzdem komme es weiter vor
      Im Podcast-Episode werden ebenfalls entsprechende Fälle behandelt
      LLMs würden zwar nicht jeden AI-Text erkennen, seien aber als Hilfswerkzeug zur Erkennung verdächtiger Fälle nützlich
    • Als Methode zur Erkennung von LLM-Text wird die Idee vorgeschlagen, die Hälfte eines Textes in ein LLM einzugeben, den Rest vorhersagen zu lassen und dann die n-Token-Wahrscheinlichkeiten zu vergleichen
      Ausprobiert habe ich das nicht, aber es ist ein interessanter Ansatz
    • Je nachdem, wie stark ein LLM eingegriffen hat (kompletter Text, Zusammenfassung, Korrektur usw.), ist Erkennung schwierig
      Deshalb halte ich mit dem aktuellen Stand der Technik eine perfekte Erkennung für unmöglich

  • Bei der Nutzung von LLM-Code liegt die Verantwortung beim Engineer
    Code, den man nicht selbst geprüft hat, kann kein Review-Kandidat sein
    Mein Ablauf ist folgender:

    1. Relevanten Code eingeben → 2) Ziel erklären → 3) Entwurf prüfen → 4) Code generieren → 5) testen und korrigieren → 6) den gesamten Code gründlich lesen und manuell überarbeiten
      Der letzte Schritt ist am schwierigsten, und emotional will man ihn am liebsten überspringen
      Diese Vorgehensweise reduziert repetitive Arbeit und erhält zugleich Denken auf Architekturebene
      Aber LLMs sind nichtdeterministisch und damit anders als vorhersehbare Werkzeuge wie Compiler
    • In der Praxis nimmt Schritt 6 den größten Teil der Gesamtzeit ein
      Wenn der Code nicht richtig funktioniert, sind noch mehr Korrekturen nötig
      Deshalb bin ich nicht sicher, ob LLMs wirklich Zeit sparen
    • Vor Schritt 4 könnte man zusätzlich zuerst Testcode erzeugen lassen, ihn zunächst scheitern lassen und dann zum Bestehen bringen
    • Statt manueller Änderungen könnte man das LLM alle Änderungen führen lassen, damit innerhalb der Sitzung Wissenskonsistenz erhalten bleibt
    • Dabei hat man aber das Gefühl, dass Selbstachtung und Besitzgefühl des Engineers leiden
      Es fällt emotional schwer, sich in das Feintuning von maschinell erzeugtem Code hineinzuhängen

  • Ich finde es seltsam, dass die mögliche Urheberrechtsverletzung durch LLM-generierten Code nicht erwähnt wurde
    GitHub-Code könnte wortwörtlich kopiert werden, und das ist für ein Open-Source-Unternehmen ein wichtiges Thema

    • Wenn LLM-Ergebnisse nicht urheberrechtlich geschützt sind, wird der rechtliche Status von Code unter Copyleft-Lizenzen unklar
      Für Urheberrecht braucht es einen hinreichenden menschlichen Beitrag, aber wo diese Grenze liegt, ist unklar
    • Ich frage mich, ob solche Fragen jemals vor Gericht behandelt wurden
    • Ich bin unsicher, ob aktuelle LLMs solche Probleme noch immer verursachen oder ob sie das sogar häufiger tun als Menschen

  • Das Dokument ist gut aufgebaut, aber der Teil, dass „es unproblematisch ist, LLMs als Lesehilfe zu verwenden“, wirkt widersprüchlich
    Wenn das Ergebnis perfekt wäre, gäbe es keinen Unterschied zum Original; wenn es nicht perfekt ist, besteht das Risiko von Fehllektüren
    Ich sehe oft, dass LLMs Dokumente nicht wirklich lesen, sondern nur aus dem Inhaltsverzeichnis Schlüsse ziehen
    Es besteht die Gefahr, dass zwischen Inhalt und Leser eine Übersetzungsschicht entsteht

    • Ich denke, im RFD ging es nicht um „Lesen“, sondern um soziale Erwartungen an das „Schreiben“
    • Wenn man drei technische Bücher vergleichen lässt und ein falsches Ergebnis bekommt, ist das ein Fehler bei der Tool-Nutzung
      Man muss den vollständigen Text direkt in das context window geben
      Allerdings könnten drei ganze Bücher den Rahmen dessen sprengen, was ein LLM leisten kann

  • Ich stimme der Aussage zu, dass „von LLMs geschriebener Text sogar die Echtheit des Denkens beschädigt“
    Von Menschen direkt geschriebene Texte haben Wert, aber von LLMs geschriebene Texte wirken wie verwässerte Kopien, denen Wert entzogen wurde
    Die Bemerkung, man würde lieber den Prompt lesen, fand ich besonders eindrücklich

    • Menschliche Kunst drückt das Innere einer Person aus, während LLMs Produkte des kollektiven Durchschnitts sind
      Interessante und originelle Gedanken liegen an Punkten, die vom Durchschnitt abweichen
      Ich kann verstehen, wenn Nicht-Muttersprachler LLMs verwenden, um ihre Gedanken besser auszudrücken, etwa bei Übersetzungen,
      aber der Empfänger beginnt sich dann zu fragen, ob dieser Ausdruck wirklich die Gedanken der Person selbst sind
    • Das erinnert mich an Naurs „Programming as Theory Building“
      Kommentare sind der Versuch, theoretischen Kontext auszudrücken, der nicht im Code enthalten ist
      LLMs können keine solche „Theorie“ haben und deshalb auch keine wirklich wertvollen Kommentare erzeugen
    • Ich mag den typischen „AI-Schreibstil“ von LLMs nicht, aber viele Menschen merken ihn gar nicht
      Zum Beispiel wirkten die meisten Beiträge auf /r/SaaS auf mich so, als wären sie von LLMs geschrieben,
      aber durch emotionales Storytelling erzeugen sie trotzdem gute Reaktionen beim Publikum
      Ich selbst nutze LLMs auch für Dokumentation oder zum Schreiben von Benchmarks
      Auch Nicht-Muttersprachlern helfen sie beim Verfassen technischer Dokumentation, aber die Qualität schwankt stark
      Am Ende werden LLMs für informationsorientiertes Schreiben immer nützlicher
    • Den Gedanken „Ich würde lieber den Prompt lesen“ habe ich auch oft bei Nachrichtenüberschriften
      Mich interessiert nicht nur was geschrieben wurde, sondern warum
    • LLMs sagen durchschnittliche Sätze gut voraus, aber kreative Sätze fast gar nicht
      Deshalb tröstet mich der Gedanke, dass meine Ideen vielleicht nicht originell sind, statistisch aber immerhin selten

  • Ich denke, Texte, die mit LLMs geschrieben wurden, sind nicht lesenswert
    Es gefällt mir, dass Oxide den klaren Grundsatz aufgestellt hat, LLMs nicht für nicht-codebezogene Ergebnisse zu verwenden
    Dasselbe gilt auch für Code-Reviews: Generierter Code muss zuerst vom Autor selbst geprüft werden
    Ob diese Kultur in der Praxis wirklich bestehen bleibt, muss sich zeigen, aber die Richtung ist klug

  • Die Wahrnehmung, dass LLMs mit gestohlenen Daten trainiert wurden, ist stark verbreitet,
    und ich denke, man hätte diese öffentliche Wahrnehmung berücksichtigen sollen
    Ob als ethisches Problem oder als Markenrisiko: Im Moment ist das eindeutig ein wichtiger Faktor

    • Ich sehe dieses Dokument nicht als öffentliche Botschaft, sondern als internes technisches Dokument
      Sein Ziel ist weniger eine ethische Position als vielmehr technische Leitlinien
    • Ich glaube, der im Text erwähnte „Vertrauenszusammenbruch“ behandelt genau dieses Problem mit anderen Worten
      Von LLMs geschriebene Texte verlieren Authentizität, und beim Leser entsteht der Eindruck, sogar der Gedanke selbst sei automatisiert worden
      Am Ende kann das gegenseitiges Vertrauen beschädigen

  • Die Aussage „Schreiben ist größere intellektuelle Arbeit als Lesen“ fand ich interessant
    Bei Code fühlt es sich für mich aber eher umgekehrt an

    • Schlechter Text ist nutzlos, aber schlechter Code kann immerhin laufen und ein Jira-Ticket schließen
      Deshalb gibt es sehr viel mehr schlechten Code
      Gut geschriebener Code hat dagegen hohen Lernwert und braucht wie gute Texte Einsicht
    • Es wird Kernighans Gesetz zitiert
      „Debugging ist doppelt so schwer wie das Schreiben von Code.
      Wenn du also beim Schreiben so klug wie möglich vorgehst, wird Debugging unmöglich.“
      laws-of-software.com-Link