Die „kurze Leine“-Methode für KI-Coding, die Fable schlägt

• Wer KI-Coding-Agenten in sicherheitskritischer Software einsetzen will, braucht statt autonomer Ausführung eine Short-Leash-Methode, bei der Entwickler Änderungen kontinuierlich kontrollieren
• Der „Vibe“-Ansatz, bei dem mehrere Agenten parallel Code schreiben und prüfen, kann das Verständnis der Codebasis schwächen und dazu führen, dass Probleme erst entdeckt werden, wenn die KI bereits off the rails ist
• Der Kernprozess führt von Planung, Zerlegung in Schritte und Diff-Prüfung in Permission-Prompts über häufiges Ablehnen und Eingreifen bis zu Commits pro Teilaufgabe und einem abschließenden Review
• Bei PR-Reviews sollten KI und Menschen gemeinsam eingesetzt werden, um Fehler zu reduzieren: KI findet häufige Fehler schnell, Menschen beurteilen übergeordnete Probleme und die Richtung
• PRs, an deren Erstellung KI beteiligt war, sollten vom Einreichenden Zeile für Zeile selbst geprüft werden; zudem sollte in der PR-Beschreibung unter AI Disclosure das verwendete Modell genannt werden, um Vertrauen zu schaffen

---

Voraussetzungen für den Einsatz von KI-Coding-Agenten

• Diese Methode basiert auf Erfahrungen mit dem Einsatz von KI-Agenten zur Entwicklung hochwertiger Software in sicherheitskritischen Systemen
• Zielgruppe sind nicht unerfahrene Entwickler, die KI als Gegner des Lernens betrachten sollten, sondern professionelle Entwickler, die in ihrem Fachgebiet besser sind als „frontier AI models“
• Ziel ist es, KI als Werkzeug zur Leistungssteigerung zu nutzen, ohne die Qualität der Software zu opfern
• Der Erfahrungsbereich umfasst das Ausloten der Grenzen von KI-Agenten, die Entwicklung eines eigenen KI-Review-Tools und die Pflege eines Custom Fork des KI-Coding-Agenten Crush

Wo der „Vibe“-Ansatz ins Wanken gerät

• In Sitzungen mit KI-Agenten können häufig zwei Probleme auftreten
  • Man merkt zu spät, dass die ursprüngliche Idee schlecht war und es einen besseren Ansatz gibt
  • Der Agent gerät in eine unerwünschte Richtung und ist off the rails
• Wenn mehrere parallele Agenten und Orchestratoren gleichzeitig arbeiten und der Entwickler aus dem Coding-Prozess herausfällt, wird es schwierig, ein eigenes Verständnis der Codebasis aufzubauen
• In Situationen, in denen Qualität keine Rolle spielt, kann diese Vorgehensweise akzeptabel sein; wenn Qualität wichtig ist, braucht es jedoch einen anderen Ansatz
• Code, den Fable 5 geschrieben oder geprüft hat, kann zwar funktionieren, aber ineffizient und unschön sein
• In Nischenbereichen, für die das Modell weniger Trainingsdaten hat, können solche Probleme häufiger auftreten
• Entgegen dem Marketing bestimmter CEOs können Modelle aus dieser Sicht nicht über ihre Trainingsdaten hinausdenken

Wie die Short-Leash-Methode funktioniert

• Die Short-Leash-Methode ist nicht für beliebige Nutzer gedacht, sondern auf professionelle Softwareentwickler zugeschnitten
• Ihr Vorteil ist, dass sie Ergebnisse liefern kann, die Fable schlagen, ohne ein frontier model zu verwenden
• Vor der Arbeit werden in einer Planungsphase die Aufgabe untersucht und ein Plan erstellt
  • Große Aufgaben werden mit Tools wie tasks skill in Schritte zerlegt und ihr Fortschritt verfolgt
  • Dieser Teil hat Gemeinsamkeiten mit verschiedenen Formen von „vibe engineering“
• Danach besteht der Kern darin, die KI durchgehend an der kurzen Leine zu halten
  • Es wird kein „YOLO“-Modus und kein „dangerously skip permissions“ verwendet
  • Man lässt die KI nicht allein arbeiten, während der Nutzer spielt
  • Man verwendet einen Coding-Agenten, der im Permission-Prompt das Diff der geplanten Änderungen zeigt
  • Der Entwickler analysiert die von der KI vorgeschlagenen Änderungen tatsächlich
  • Über das Diff im Permission-Prompt hält man das Verständnis der Codebasis aktuell und behält die KI unter Kontrolle
  • Wenn die KI etwas Unerwünschtes tun will, wird die Berechtigung verweigert
  • Bei Bedarf greift man häufig ein, damit die KI nicht die Richtung verliert
• Nach jeder Teilaufgabe wird ein Commit erstellt, um zu verhindern, dass die KI frühere Arbeit beschädigt oder löscht
  • Das kann tatsächlich passieren; ein solcher Fall wurde bei Opus beobachtet
• Im letzten Schritt wird ein Review durchgeführt

KI-Reviews ersetzen keine menschlichen Reviews

• PRs, die von Menschen und KI gemeinsam geprüft wurden, können mehr Fehler vermeiden als PRs, die nur von Menschen oder nur von KI geprüft wurden
• KI kann wie ein Linter behandelt werden
  • Sie findet häufige Fehler schnell
  • Menschen beurteilen übergeordnete Probleme und ob eine Richtungsänderung nötig ist
• Es wird empfohlen, jeden PR durch ein KI-Review laufen zu lassen
• KI-Reviews benötigen ausreichend Kontext
  • Issue
  • PR-Beschreibung
  • Codebasis
  • Änderungen
• Für Reviews wird empfohlen, das neueste verfügbare Modell zu verwenden

AI Disclosure und Verantwortung des Einreichenden

• Wenn KI beim Erstellen eines PRs verwendet wurde, sollte in der PR-Beschreibung im Abschnitt AI Disclosure das genaue verwendete Modell offengelegt werden
• Diese Offenlegung dient mehreren Zwecken
  • Sie informiert Maintainer darüber, dass KI verwendet wurde
  • Wenn ein schwaches Modell verwendet wurde, können sie ein besseres Modell vorschlagen
  • Sie signalisiert, dass nicht versucht wird, KI heimlich einzuschleusen
• Ein PR, bei dem KI eingesetzt wurde, muss unbedingt vom „Autor“ des PRs selbst geprüft werden
• KI-gestützte PRs ähneln in der Praxis eher PRs einer KI, die menschliche Hilfe erhalten hat; deshalb muss der Einreichende verstehen, was er einreicht
• Der Einreichende sollte den eigenen PR wie den PR einer anderen Person betrachten und ihn selbst line-by-line prüfen
• Nach Abschluss des eigenen Reviews kann der Einreichende seine Zustimmung bestätigen und die Maintainer um Prüfung bitten
• Dieser Prozess dient dazu, dass der Einreichende ein Verständnis der Codebasis aufbaut und zeigt

Wie okTurtles die Methode anwendet

• okTurtles verwendet KI nach dieser Methode
• Die offizielle Richtlinie ist in der AI Usage Policy festgehalten
• Der Artikel selbst wurde von einem Menschen geschrieben und enthält eine AI Disclosure, dass vor der Veröffentlichung nur eine KI-gestützte Rechtschreibprüfung durchgeführt wurde

[GN⁺]

Meinungen auf Hacker News

• Dieser „kurze Leine“-Ansatz wirkt eher wie eine Krücke als wie ein Hilfswerkzeug und scheint ein Zeichen dafür zu sein, dass man der KI das Problem zu Beginn nicht ausreichend erklärt hat oder die Ausgabe nicht geprüft und iteriert hat.
  Ein starkes Modell wie Fable in der Implementierungsphase an die Hand zu nehmen und mitzuziehen, ist Zeitverschwendung und eine Verschwendung von Fable. Je stärker das Modell, desto subtilere Designdiskussionen sind möglich, und es schreibt deutlich besseren Code als früher. Der Prozess, Design und Implementierung zu besprechen, bei merkwürdig wirkenden Stellen nachzufragen und die KI-Antworten tatsächlich zu lesen, hilft selbst dabei, bessere Lösungen zu finden.
  Früher wollte ich eine Lösung mit einem Greedy-Algorithmus bauen, und in der Diskussion mit Opus bekam ich den Vorschlag, das Problem mit einer bestehenden MILP-Bibliothek exakt zu lösen. Ich hatte noch nie von MILP gehört, aber die finale Implementierung wurde besser und einfacher, als wenn ich sie allein gemacht hätte.

  • Es heißt, mit starken Modellen seien subtilere Diskussionen möglich, aber als ich Claude fragte, warum es eine kleine Änderung vorgenommen hatte, die ich nicht verstand, antwortete es auf Basis des Codepfads, es habe „von ersten Prinzipien ausgehend geschlossen“.
    Das funktionierte aber nicht, und als ich es bat, diesen Schritt der Herleitung aus ersten Prinzipien zu erklären, antwortete es, dass es sich das in Wirklichkeit einfach ausgedacht hatte. Deshalb fällt es mir schwer, an diese subtilen Diskussionen mit dem Modell zu glauben.
  • Ich stimme weitgehend zu.
    Wenn man genug in die Planungsphase investiert hat und die bestehende Architektur und die Konventionen des Projekts solide sind, braucht man in der Implementierungsphase möglicherweise nicht so viel Aufsicht, wie hier beschrieben.
    Dass „die ursprüngliche Idee dumm war und man entdecken kann, dass es einen besseren Weg gibt“, stellt man normalerweise auf hoher Ebene in der Planungs- und Architekturphase fest.
    Auch das Problem, dass ein Agent in eine unerwünschte Richtung „entgleist“, ist nicht mehr so schlimm wie früher, und für Änderungen mit Auswirkungen sollte es zumindest eine minimale Testabdeckung geben. Dieser Test kann auch nur das implementierte Verhalten „festnageln“. Die abschließende Review-Diskussion ist eine gute Gelegenheit, über das hinaus zu prüfen, was ein Review- oder adversarial Review-Agent gefunden hat.
  • Ich bin etwas verwirrt, welchem Teil genau du widersprichst. KI-Antworten zu lesen und Code zu prüfen, wirkt letztlich wie derselbe Ansatz.
    Das MILP-Beispiel wäre nichts, was dieser Ansatz verhindert hätte; es wäre in der Planungsphase sichtbar geworden.
    Am Ende sind die Details entscheidend, und wie man den Startprompt für die Aufgabe formuliert, hat Einfluss. Trotzdem sind das Prüfen der Ausgabe, die Beteiligung an dem, was das Modell tut, und das Nachhaken, warum es etwas so bauen will, zwingend notwendig.
  • Der Artikel fühlt sich an, als würde er die KI micromanagen. Wenn man sie wie einen Junior-Mitarbeiter betrachtet, kann man sie durch Micromanagement dazu bringen, genau das zu tun, was man will, und zwar auf die gewünschte Weise.
    Aber dann kommen die Ideen dieses Mitarbeiters nicht auf den Tisch, und Beiträge, die langfristig dem gesamten Team nützen könnten, verschwinden ebenfalls.
  • Ich nutze es auf diese Weise.
    Es sorgt dafür, dass ich alles verstehe, was erzeugt wird, und weiterhin Arbeitswissen über die Codebase behalte. Auch Kurswechsel lassen sich leicht veranlassen.

• Ich habe das bei einem Nebenprojekt zwei Wochen lang so gemacht, hatte am Ende aber kein mentales Modell der Codebase.
  Ich bin dadurch noch stärker überzeugt, dass es keinen Weg gibt, dieses Modell aufzubauen, ohne es selbst zu bauen.

  • Leider hatte ich dasselbe Problem schon vor KI.
    Wegen der Vergessenskurve hält mein mentales Modell nicht annähernd so lange wie die ursprüngliche Phase, in der ich es aufgebaut habe. Wie ich es wieder aufbaue, habe ich noch nicht herausgefunden.
  • Wie würde ein Manager eines großen Projekts so ein Modell aufbauen? Also in einer Situation, in der man berufsbedingt das ganze Projekt verstehen muss, aber nicht wirklich viel Code schreiben oder reviewen muss.
  • Man kann das Modell bitten, den Code zu erklären.
  • Ich weiß nicht recht. Ich halte es für möglich, aber man muss sich bewusst in die Teile vertiefen, die man nicht versteht, und das ist die Richtschnur.
    Allerdings stimme ich zu, dass man dabei nicht so gut die „Fähigkeit, es selbst bauen zu können“ aufbaut wie beim direkten Schreiben.
    Zum Beispiel weiß ich, welche Änderung nötig ist, um einen bestimmten Effekt zu erzielen, und wenn ich die Änderung tatsächlich vornehme, kommt das erwartete Ergebnis heraus; daran sehe ich, dass mein mentales Modell funktioniert. Aber wenn ich etwas Ähnliches von Grund auf selbst bauen sollte, glaube ich nicht, dass ich es könnte. Der Ansatz fühlt sich an, als läge er außerhalb meiner Reichweite; schwer zu erklären.
  • Code-Reviews funktionieren für mich gut.

• Ich dachte, alle, die wirklich programmieren können, nutzen KI bei wichtigen Dingen genau so.
  Lag ich falsch? Lassen heutzutage alle einfach den YOLO-Modus laufen?

  • Ja. Ich habe ein Notebook, das mir egal ist, bereitgestellt und lasse Claude darin nach Belieben in WSL herumwerkeln.
    Das ist der Spaß an funemployment. Wenn ich wieder anfange zu arbeiten, dürfte das eine ziemlich interessante Veränderung werden.
    Im Moment ist es simpel: Ich lasse es laufen, trinke ein Bier und richte nach etwa einer Stunde wieder grobe Kritik und Selbstprüfung/Closed-Loop-Feedback ein, bevor ich es erneut frei laufen lasse.
  • Meinst du damit, man solle den „YOLO-Modus“, also „Berechtigungen gefährlich überspringen“, nicht verwenden?
    Ich frage mich, wie man Claude anders als mit bypass-permissions nutzen soll. Ich habe lange die Liste der Tools gepflegt, die Claude verwenden darf, aber am Ende kam ich immer wieder zurück und sah, dass es versucht hatte, die Ausgabe eines Tools in ein anderes zu pipen, und angehalten hatte, weil das nicht ausdrücklich erlaubt war. Es ging nur um etwas wie grep, und trotzdem hielt es an, was nervig war.
    Mit bypass-permissions „funktioniert es einfach“. Natürlich nutze ich es nur zur Analyse bestehender Codes und für Änderungsvorschläge; und wenn etwas kaputtgeht, ist das eben der Grund, warum es Versionsverwaltung gibt.

• Ich stimme dem Autor weitgehend zu. Vor allem möchte ich ergänzen: Glaube nichts, was ein LLM tut oder sagt.
  Heute habe ich Claude gebeten, das Verhalten von drei Komponenten zu vereinheitlichen, und ich habe es fünfmal machen lassen. Jedes Mal gab es am Ende immer noch Teile, die nicht passten, und Claude fand einen Weg, das zu rationalisieren.
  Wenn ich nachfragte, antwortete es „Das ist meine Verantwortung“ oder „Ich dachte, das sei eine bewusste Entscheidung“, aber es fragte nie zuerst, was zu tun sei, oder benannte das Problem. Also: kurze Leine halten, den Denkprozess beobachten und Unsinn sofort korrigieren. Das gilt heute für Sonnet 5; morgen kann es besser oder schlechter sein. Eine Formulierung, die heute bei Claude funktioniert, kann morgen andere Ergebnisse liefern.

• Das Problem bei Artikeln der Art „Wie man X mit AI macht“ ist, dass jede Situation völlig anders ist. Zum Beispiel ist der Weg bei der Aufgabe, ein Symfony-Projekt von 3.1 auf 8.1 zu aktualisieren, klar vorgegeben.
  Man folgt den für jede Major-Version geschriebenen Migrationsleitfäden und testet alle Routen, Authentifizierungs-Flows usw. Diese Tests kann man auch selbst auswählen; manche können 200 zurückgeben, andere 302.
  Optional kann man zuerst ein Sicherheitsnetz schreiben, um manuelle Tests zu reduzieren, und zum Beispiel eine PHPStan-Baseline setzen.
  Wenn die Routen Ende-zu-Ende funktional wie beabsichtigt funktionieren, ist man fertig. Dafür kann man auch Snapshot-Tests verwenden.
  In solchen Fällen muss man die AI nicht beobachten. Am Ende kann man den Code reviewen, aber da man zwischendurch keine manuellen Freigaben braucht, schalte ich die Sicherheitsfunktionen ab.

  • Das ist weniger ein Problem von „Wie man X mit AI macht“ als vielmehr eine Frage, wie man Internet-Content aufnimmt.
    Die meisten schreiben aus einer bestimmten Perspektive, aber die tatsächlichen Perspektiven sind breit gefächert, und was in einer Situation funktioniert, funktioniert in einer anderen nicht. Software Engineering läuft letztlich weitgehend darauf hinaus, herauszufinden, was man wo und wann anwendet, und den Rest zu ignorieren.
    Viele Firmenblog-Artikel lassen einen glauben, es gäbe eine Silver Bullet, die in allen Fällen funktioniert, aber das ist normalerweise nicht wahr.
    Am Ende ist es, wie es im Software Engineering schon immer war, eher „Manches funktioniert in manchen Situationen“; es geht weniger um richtig oder falsch, sondern darum, dass die praktische Anwendung je nach Kontext unterschiedlich ist, und das ist normal.
  • Hast du rector ausprobiert?

• AI ist etwa auf dem Niveau eines Junior- bis Mid-Level-Engineers. Wenn man sie so behandelt, bekommt man die Vorteile von Vibe Coding und strengem Engineering, ohne all diese Paranoia.
  Ich habe Claude von Anfang an in einer isolierten VM im YOLO-Modus laufen lassen. Das ist so, als würde man einem Engineer seinen eigenen Laptop geben. Claude bringt ein Feature bis zu einem PR-fähigen Punkt, und ich reviewe dann wie bei einem anderen Engineer das Diff, bringe es in die passende Form und mache weiter.
  Unerfahrene Engineers machen dieselben Fehler. Ich habe auch schon rm -rf gesehen, wenn auch nicht im Root-Verzeichnis. Wenn ich jemanden mit verweigerten Berechtigungen mikromanagen müsste, würde ich wahrscheinlich durchdrehen.

  • Dieser Sichtweise stimme ich stark zu, und genau deshalb verstehe ich diesen Artikel noch weniger. Ist der PR nicht bereits das Gate? Mir ist egal, was der Agent innerhalb des Arbeitsbereichs macht, solange der Beitrag über das Git-Repository gegatet wird und die Entwicklung keinen merkwürdigen Produktionszugriff braucht.
    Der Analogie zum Junior-/Mid-Level-Engineer stimme ich ebenfalls zu, aber mit einer großen Einschränkung: AI ist wie ein Junior-Engineer, der nicht weiß, wie man lernt.
    Es fühlt sich an, als würde man mit der Hauptfigur aus Memento arbeiten. Jeden Tag, wenn das LLM zur Arbeit kommt, hat es nichts aus der bisherigen Arbeit gelernt, und jeder Tag ist der erste Tag.
    Natürlich kann man ihm wie der Hauptfigur aus Memento helfen, indem man überall im Arbeitsbereich Post-its und Hinweise verteilt. Mit Mühe kommt man etwas näher an das heran, was man „Lernen“ nennen würde, und das ist buchstäblich die wichtigste Eigenschaft jedes Softwareentwicklers im Team.
    Aber es ist nicht einfach, und die Tools sind noch unzureichend. Das Beste, was ich bisher ausprobiert habe, war eher ein „zweites Gehirn“ mit Tools wie Obsidian. Traurigerweise ist ein zweites Gehirn meiner Ansicht nach kein Ersatz für das erste. Ehrlich gesagt: Ein Engineer, der wie ein AI-Agent nicht lernen und wachsen kann, wäre in jedem Unternehmen, in dem ich gearbeitet habe, nach dem ersten Monat entlassen worden.
    Trotzdem bin ich ziemlich optimistisch, dass die großen AI-Anbieter oder jemand anderes diesen Bereich in Zukunft verbessern werden. Wenn gute Memory mit einem gut designten Denksystem kombiniert wird, das Erinnerungen kontextgerecht besser einspeist, und wenn man tatsächliches Lernen ohne Aufsicht erfassen kann, wirkt das nicht wie eine unmögliche Aufgabe.
    Ich lese solche Texte in der Hoffnung, dass jemand dieses Problem bereits gelöst hat und ich es nur verspätet bemerken muss; im Moment ist es aber nur so, dass meine Fähigkeit, Agenten zu entwerfen, ein wenig besser geworden ist als am Anfang.
  • Meine Erfahrung ist ähnlich. Ich sehe es eher als einen sehr klugen und schnellen Praktikanten. Man sieht, dass daraus etwas Großes werden kann, und in vieler Hinsicht ist es mir schon deutlich überlegen, aber es muss immer noch mit erfahrener Hand gelenkt werden.
    Meine Faustregel ist: Spezielle Prozesse, die man für AI baut, müssen auch für Menschen sinnvoll sein; wenn nicht, sind sie wertlos. Gute Kommandozeilentools, automatische Zusammenfassungen langer Befehlsausgaben, Markdown-Dokumentation und Workflows sind auch für Menschen nützlich.
    Um Fehler und Missbrauch zu verhindern, sollte man Sandboxing und bereichsbeschränkte Berechtigungen verwenden, nicht Micromanagement.
    Was ich herausfinden möchte, ist ein guter Pair-Programming-Workflow mit AI-Agenten. Man kann einem leistungsstarken Modell große Aufgaben geben, und das funktioniert gut. Man kann auch ein Low-Level-Modell als IDE-Assistent verwenden, und auch das funktioniert gut. Aber beides sind getrennte Workflows.
    Wirklich nützlich wäre eine Arbeitsweise, bei der man mit einem leistungsstarken Modell zusammenarbeitet und sich die Tastatur hin und her reicht. Allerdings sollte es nicht im vollständigen YOLO-Modus auf meiner Maschine laufen. Genau das ist der Unterschied zwischen Menschen und LLMs. Sie sind so schnell, dass es schwer ist, ihnen die Tastatur wieder zu entreißen, wenn sie vom Kurs abkommen.
  • Wenn man Claude einen echten Laptop gibt, kann es auch Linux-Bluetooth-Audio-Probleme beheben ;)
  • Welche VM/Provisionierung verwendest du?
  • Die Aussage „AI ist ein Junior- bis Mid-Level-Engineer“ ist inzwischen nicht mehr wahr, und es hilft nicht, sich das einzureden.
    Niemand weiß genau, was AI ist, aber sie ist kein Junior- oder Mid-Level-Engineer. Sie ist eher ein Nuclear Staff Engineer, der in einer Bretterbude lebt, keinen Domänenkontext hat und alle 5 Stunden ohne Erinnerung aufwacht.

• Ein LLM ist immer noch ein Prädiktor für das nächste Token. Dass es auch bei vageren Anweisungen die richtigen Schritte findet, heißt nicht, dass es intelligent ist. Es heißt, dass du dieselbe Sprache sprichst wie der Harness, der zum Trainieren des Modells verwendet wurde.
  Und das hat Grenzen. Wenn du auf dem Niveau von Proofs of Concept oder einfachen Apps bleibst, merkst du vielleicht nicht, wie begrenzt die aktuellen Modelle noch sind. Dort sollte man Aufgaben zerlegen und nicht einem Token-Prädiktor vertrauen, der plausibel klingende Schritte aufzählt.
  Irgendwo muss es zwingend eine Human Loop geben. Wenn man anfängt, Berechtigungen zu überspringen, ist der Best Case ein Volltreffer, wahrscheinlicher sind aber zweitbeste Lösungen und verschwendete Tokens. Wirklich beängstigend ist, wenn das Modell Anweisungen ignoriert, etwas Dummes tut und dir den Tag ruiniert.
  Das ist scharf wie eine CNC-Maschine. Nicht nutzlos, aber potenziell gefährlich. Wenn du nicht parallel einparken kannst, solltest du besser nicht versuchen, mit einer Monster-Maschine Holz zu fräsen oder einen Ferrari in einer engen Wohngegend abzustellen.

  • Vorhersage des nächsten Tokens ist kein Algorithmus, sondern ein Interface. Der Prozess, „das nächste Token vorherzusagen“, kann beliebig komplex oder einfach sein, und die Fähigkeit, eine gegebene Aufgabe auszuführen, kann ebenfalls beliebig hoch oder niedrig sein.
    Zu sagen, ein LLM könne etwas tun oder nicht tun, weil es ein „Token-Prädiktor“ sei, ist ein Kategorienfehler. Das Interface ist keine harte Grenze.
  • Bei „das ist keine Intelligenz“ weiß ich nicht, wie du Intelligenz definierst.
    Ich frage mich, wie eine Definition möglich sein soll, die Sprachmodelle ausschließt und Menschen einschließt, ohne als Axiom vorab festzulegen, dass LLMs keine Intelligenz haben.
  • Dann bist du auch nur jemand, der das nächste Wort sagt.
  • LLMs als „Prädiktoren für das nächste Token“ zu bezeichnen, ist völlig reduktionistisch und unredlich. Technisch stimmt es, aber für dich gilt dasselbe.
    Meist ist damit gemeint: „Sie sagen nur das nächste Token der Trainingsdaten, also des Internets, voraus.“ Für Rohmodelle mag das stimmen. Aber Modelle durchlaufen Post-Training, also passt selbst diese Beschreibung nicht mehr.
    „Das ist keine Intelligenz“ ist nicht nützlich und meiner Meinung nach falsch. Wen kümmert es, ob es deiner Definition von Intelligenz entspricht. Sie leisten weiterhin Beeindruckendes, und auch deutlich Beeindruckenderes, als du andeutest.
  • Ab welchem Maßstab würdest du es intelligent nennen?

• Der Originalbeitrag wirkt, als stecke er noch im Jahr 2025 fest.
  Er sagt: „Man merkt es erst, wenn die AI mehrfach entgleist und die Software tatsächlich benutzt“, aber inzwischen kann diese AI die Software selbst benutzen, Bugs finden und beheben sowie neue Features vorantreiben.
  Es kommt vor, dass Agenten Dinge anfangen, die man nicht will, aber deutlich seltener als früher, und das Argument für vollständig autonome Agenten wird nicht schwächer, sondern stärker.
  Auch die Aussage „Es ist menschlich unmöglich, dass ein Mensch die Codebase versteht“ wirkt veraltet. Ich denke, wir bewegen uns in eine Richtung, in der Menschen die Codebase nicht mehr verstehen müssen und die AI die Führung übernimmt.

  • AI-Unternehmen haben einen Anreiz, dieses rücksichtslose slopmaxxing voranzutreiben. Das Endergebnis ist, dass dein Business vollständig von ihnen abhängt und der gesamte Produktwert von ihnen kommt.
    Viele springen darauf auf, aber ich halte es für einen dummen Trend.
  • Genau, etwas zu verstehen ist einfach so 2025.
  • Für nicht-kritische Software wie Entertainment oder Medien mag das stimmen.
    Für Systeme mit hohen Sicherheitsrisiken stimmt es aber absolut nicht. In Bereichen wie Banken, Luftfahrt und Verteidigung wird AI sicher beitragen, aber nicht unabhängig von menschlichem Engineering-Verständnis agieren können.
  • Wer ein ausreichend gutes Gespür für effektive Programmierung und Architektur hat, würde der Aussage nicht zustimmen, dass AI Software selbst benutzen, Bugs finden und Features bauen kann.
    Die Kurzleinen-Methode ist ein Weg, gute Ergebnisse zu gewährleisten, wenn man außerhalb der Trainingsdaten arbeitet. Ich denke, für jeden auch nur etwas überdurchschnittlichen Programmierer ist das die einzige Methode, um mit LLMs schnelle und qualitativ gute Entwicklung sicherzustellen.
    Die Behauptung, Menschen müssten die Codebase nicht mehr verstehen, scheint aus Unkenntnis der Programmierwelt zu kommen, in der AI noch katastrophal unbeholfen ist. Ich sehe immer wieder, dass sie in Sprachen mit manueller Speicherverwaltung die Speicherbehandlung vermasselt. Es ist nicht so einfach, sie nur in eine Valgrind-Schleife zu stecken.
  • Ich habe nicht das Gefühl, dass das Argument für vollständig autonome Agenten stärker wird. Das ist mir vor ein paar Wochen mit Claude Code + Opus 4.8 passiert. Die Aufgabe war nicht besonders kompliziert: vier neue API-Endpunkte und Events, die per WebSocket zum Client gestreamt werden.
    Ich habe API-Definitionen, Request-/Response-Modelle, Datenbankschema und den gesamten Ablauf in mehreren Iterationen verfeinert und viele Widersprüche beseitigt sowie Dokumentation selbst angepasst. Opus ist immer wieder entgleist, und das endgültige Dokument hatte mehr als 500 Zeilen.
    Auch bei den API-Integrationstests musste ich mehrfach hin und her. Die AI konnte die Tests nicht direkt aus der Dokumentation erstellen, also habe ich zuerst Platzhalter mit Given-When-Then-Kommentaren erstellt, sie manuell geprüft und korrigiert und erst in einer zweiten Iteration die Tests implementieren lassen. Nach dem Review gab es viele Fehler zu korrigieren.
    Für die Implementierungsphase stellte ich API-Dokumentation, funktionierende Tests, einen Hook zum Blockieren von Änderungen, über sechs „Best-Practice“-Skills, „Rubber Duck“- und „Code-Vereinfachungs“-Agenten sowie Skripte zum Prüfen von Tests, Linter- und Kompilierfehlern bereit. Nach Planung, Ausführung, Review und mehreren Korrekturrunden war das Feature implementiert, und alle Tests liefen durch.
    Im Code-Review fand ich im Schnitt ein Problem pro 20 Codezeilen. Selbst ohne Code-Style gab es Dinge wie die Verwendung eines In-Memory-Semaphores in einem Kubernetes-Service, acht DB-Aufrufe zum Aktualisieren desselben Datensatzes innerhalb einer einzigen Anfrage, Updates Spalte für Spalte, Read-Modify-Save ohne Transaktion sowie Fehler in Business-Logik, Recovery und Autorisierung.
    Das Ergebnis war fast eine Arbeitswoche, über 100 Dollar Token-Kosten und nur der Gedanke: „War dieser Aufwand das wert?“ Ich habe ein Team aus zwei Entwicklern, und als ich gerade den PR eines der beiden reviewt habe, waren 80 % davon Slop.

• Ich habe einen ähnlichen Ansatz ausprobiert, aber für mich hat er nicht gut funktioniert. Es gab kaum oder gar keinen Geschwindigkeitsgewinn. Um Produktivität zu gewinnen, braucht man meiner Meinung nach in einer Sandbox ein gewisses Maß an YOLO-Modus.
  Das Ziel sollte sein, dem Modell so viel Arbeit wie möglich auszulagern und zugleich den Aufwand zu minimieren, der nötig ist, um das Ergebnis zu verstehen und zu reviewen.
  Zum Beispiel kann man dem Modell Aufgaben geben wie die Ursache eines Bugs zu finden, einen Proof of Concept für X zu bauen, etwas schrittweise zu optimieren oder ein gut definiertes Refactoring mit Anleitung durchzuführen.
  Was Leute meinen, wenn sie von Loops sprechen, ist sehr ähnlich: maximieren, was das Modell tut, und minimieren, was ich tun muss, um es zu kontrollieren.

• Der Artikel hatte kaum Substanz

  • Er folgt nur der gerade angesagten Phrase
    Letztes Jahr hieß es: „KI ist nur ein stochastischer Papagei“
    Dieses Jahr heißt es: „KI kann zwar Code schreiben, aber Menschen müssen ihn immer noch reviewen!“ Natürlich nutzt man auch für dieses Review KI
    Wenn noch ein Jahr vergeht, wird das Narrativ lauten: „Code-Reviews kann nur KI machen, und auch die Reviews der KI kann nur KI reviewen. Menschen müssen nur noch die abschließende Einschätzung der KI lesen, um eine sinnvolle Aufsicht aufrechtzuerhalten“
    Die Torpfosten werden ständig verschoben, aber die Überzeugung bewegt sich nie