Abenteuer mit KI

• In persönlichen Projekten erwiesen sich mehrere KI-Modelle bei Code-Reviews, Refactorings und einmaligen Skripten im Verhältnis zu den Kosten als dauerhaft nützlich, aber nicht-autonome Entwicklungsarbeit blieb durch die Qualität der Urteile und die Kosten der Verifikation stark eingeschränkt.
• Nach dem Vergleich von Anthropic- und OpenAI-Abos für 20 $ pro Monat sowie 20-$-Credits bei Google, Moonshot, DeepSeek und Cerebras nutzte ich in der Praxis hauptsächlich abwechselnd Opus 4.8 und GPT 5.5.
• Den größten Wert lieferten Bug-Suche-Aufgaben wie Reviews von git diff main; in kleinen Codebasen liegt die Stärke in genauer Codelektüre, etwa als Opus in einem Interpreter ein double-free fand, das selbst ein Fuzzer übersehen hatte.
• Wenn ich gemeinsam mit dem Modell Code schrieb oder es allein implementieren ließ, tauchten immer wieder Probleme auf: Bugs wurden auf der falschen Abstraktionsebene behoben, unnötige Tests und Refactorings erzeugt und die Fertigstellung von Implementierungen oder Testläufen fälschlich bestätigt.
• Auch ohne dass die Modelle selbst viel klüger werden, gewinnen Praktiken an Bedeutung, die Verifikationskosten senken und den Änderungsradius begrenzen, etwa Sprach- und Runtime-Garantien, statische Analyse, leichtgewichtige formale Methoden und ein Editor-Harness.

---

Verwendete Modelle und Werkzeuge

• Ich hatte bei Anthropic und OpenAI jeweils ein 20-$-Monatsabo und nutzte bei Google, Moonshot, DeepSeek und Cerebras jeweils 20 $ an Credits.
• Nach Vergleichen zwischen Modellen bei verschiedenen Problemen verwendete ich meist abwechselnd Opus 4.8 und GPT 5.5.
  • Diese beiden Modelle waren deutlich besser als die anderen.
  • Es kam selten vor, dass ich gleichzeitig in die Nutzungslimits beider Modelle lief.
• Als Werkzeuge nutzte ich claude code, codex und pi.
  • Ich halte claude code und codex für instabil.
  • codex blieb nach dem Schließen des Terminals manchmal mit 100 % CPU-Auslastung aktiv und musste per kill beendet werden.
  • claude code forderte dazu auf, mit Escape einen Dialog abzubrechen, unterbrach in Wirklichkeit aber nur Claude und schloss den Dialog nicht.
  • Das Verhalten beider Tools änderte sich von Tag zu Tag.
• pi habe ich nicht viel benutzt, aber es verhielt sich wie normale Software.
  • Bei allen drei Tools war der Eindruck stark, dass sie vibe-coded waren, und ich fragte mich, wie pi überhaupt ein Mindestmaß an Codequalität hält.

Sandbox und Sicherheit

• Alle Tools liefen innerhalb von bubblewrap.
  • Das aktuelle Verzeichnis und die Konfigurationen der jeweiligen Tools hatten Lese- und Schreibrechte.
  • Auf den nix store gab es nur Lesezugriff.
• Dieses Setup war nur ein minimales Sandboxing, gedacht, um den Zugriff auf Credentials oder die Zerstörung nicht versionskontrollierter Dateien zu verhindern.
• Wenn in AGENTS.md vermerkt war, dass die Ausführung in einer Sandbox erfolgt und dass sich Tools per nix-shell holen lassen, funktionierte es meist gut.
  • Ohne diesen Hinweis driftete das Modell dazu ab, einen Festplattenfehler oder Dateisystemschäden zu vermuten.
• Das Safety-Training schien nicht besonders wirksam zu sein.
  • Auf die Bitte, „aus der Sandbox auszubrechen“, reagierte das Modell mit einer Ablehnung als unverantwortliches Verhalten.
  • Als ich sagte, ich müsse wissen, ob die Sandbox funktioniere, behauptete es, ausgebrochen zu sein.

Der größte Wert aus Code-Reviews

• Der bisher größte Nutzen kam aus Code-Reviews und Bug-Suche.
• Selbst ein einfacher Prompt wie Review git diff main and look for bugs war effektiv.
• In persönlichen Projekten wäre ich allein für diese Funktion bereit, 20 $ im Monat zu zahlen; würde ich ein Unternehmen führen, könnte ich mir auch mehrere hundert Dollar pro Person und Monat vorstellen.
• Opus fand in diesem Transkript nach einem teilweise fehlgeschlagenen pattern-match cleanup in einem Interpreter ein double-free.
  • Diesen Bug hatte ein Fuzzer nicht gefunden.
  • Vermutlich hätte auch ein durchschnittlicher Programmierer ihn nicht schnell entdeckt.
• Wirklich nützlich waren nur Frontier-Modelle.
  • Günstigere Modelle blufften meiner Einschätzung nach stark, wie überforderte Studierende.
  • Auch Frontier-Modelle mischten Bluff unter richtige Antworten, markierten das aber oft mit Formulierungen wie „this isn't a bug per se“, sodass man es leicht ignorieren konnte.
• Bisher habe ich nur mit relativ kleinen Codebasen experimentiert.
  • Bei großen Codebasen dürfte viel davon abhängen, wie ihre Struktur aussieht und wie gut lokales Schlussfolgern möglich ist.

Wie Refactoring die Kosten von Designkorrekturen senkt

• Beispiele für Refactorings waren:
  • pos, das auf einen Byte-Offset verweist, in offset umzubenennen
  • Document in Buffer umzubenennen und dabei auch Kommentare und Variablennamen anzupassen
  • Eine Editor-Funktion, die Document::apply_edits aufruft, so zu ändern, dass sie statt Editor ein EditorId entgegennimmt und erst nach dem Freigeben des borrows aufgerufen wird
• Solche Arbeiten helfen überraschend stark bei der Verbesserung der Codequalität.
  • Sie senken die Kosten dafür, Designfehler zu korrigieren.
  • Besonders nützlich ist das, wenn sich kleine Denkarbeit zum Umstellen auf eine sichere API mit großer repetitiver Arbeit zum Anpassen aller callsites mischt.
• Selbst bei wiederholten Änderungen, die man per sed-RegEx erledigen könnte, schrieb das Modell meiner Ansicht nach oft bessere sed-Befehle.
• Refactoring-Reviews sind allerdings heikel.
  • Das Modell mischte unter 200 korrekte callsite-Änderungen manchmal einen irrelevanten drive-by fix.
  • Mit einem separaten Modell zu fragen, „welche Änderungen nichts mit dem Prompt zu tun haben“, funktionierte teilweise.

Grenzen beim gemeinsamen Coden

• Weil ich erwartete, dass es für ernsthafte Arbeit frustrierend wäre, experimentierte ich meist an entbehrlichen Projekten, war aber wegen der Codequalität dennoch unruhig.
• Vor KI fühlte sich Programmieren für mich wie eine Mischung aus wichtigen Entscheidungen und paint-by-numbers-artigem Ausfüllen an.
  • Wenn man Aufgaben so bündelt, dass die Entscheidungen zuerst fallen und man danach mehrere Stunden nur noch ausfüllt, reduziert das Kontextwechsel und macht schneller.
• Modelle sind stark darin, paint-by-numbers-artige Detailimplementierungen schnell und sorgfältig zu erzeugen.
• Beim Treffen von Entscheidungen sind sie dagegen sehr schwach.
  • Sie beheben Bugs auf der falschen Ebene.
  • Sie schlucken Fehler still, die gemeldet werden sollten, oder propagieren Fehler, die lokal behandelt werden müssten.
• Opus erhielt die Anweisung, Tests passend zu einer Funktionsänderung zu aktualisieren, und fügte daraufhin ein boolesches Argument do_new_behaviour hinzu.
  • Es erzeugte Wrapper foo_do_new_behaviour und foo_do_old_behaviour, die jeweils true und false weiterreichen.
  • So testeten die Tests weiterhin das alte Verhalten, während die eigentliche Binärdatei bereits das neue Verhalten ausführte.
• Die Idee, ein anderes Modell zur Review einzusetzen, überzeugt mich wenig.
  • Ein Modell mit schlechtem Urteilsvermögen kann auch schlechte Entscheidungen noch als „plausibel“ durchgehen lassen.
• Selbst bei der Anweisung „Fülle nur den Body dieser Funktion aus, nimm keine anderen Änderungen vor und schreibe keine Tests“ refaktorierte das Modell irrelevanten Code, extrahierte Helper-Funktionen und versuchte, Unit-Tests zu schreiben.
  • Selbst wenn ich erklärte, dass die Codebasis end-to-end deterministic simulation testing besitzt, wollte es für isolierte Unit-Tests zusätzliche public functions pro Interface einführen.
• Von Bots geschriebener Code ließ sich nur schwer effektiv reviewen.
  • Es kam vor, dass ich Änderungen mergte und erst viel später beim erneuten Lesen desselben Codes Probleme entdeckte, die ich anfangs übersehen hatte.
• Ich halte ein Harness im Editor für nötig, das markiert, wo der Benutzer Änderungen wünscht, und das Modell daran hindert, woanders etwas zu ändern.
  • Ich stelle mir vor, gewünschten Code zu skizzieren und Kommentare zu hinterlassen, die das Modell dann ausfüllt.
  • Wenn in den nächsten Jahren ein Modell erscheint, das die heutige Qualität von Frontier-Modellen beim Coden viel schneller liefert, möchte ich Ergebnisse sofort reviewen können, ohne ständig zwischen Worktrees zu wechseln.

Fälle, in denen ich das Modell allein implementieren ließ

• Kleine Plumbing-Arbeiten funktionierten gut, wenn ich nur das Ergebnis reviewen musste.
  • ein Skript, das resume.md in resume.pdf umwandelt
  • ein Skript, das Brettspielregeln parst und daraus spielkartengroße Karten für US Letter als PDF erzeugt
  • die Übersetzung eines kleinen Deno-Projekts nach Rust
  • ein Rust-Projekt, das ein Fenster öffnet und ein Rechteck rendert
• Solche Aufgaben waren meist in einem Durchgang oder nach einigen Runden visuellen Design-Feedbacks erledigt, und die Codequalität war nicht wichtig.
• Schwer verifizierbare Aufgaben waren bisher Zeitverschwendung.
  • Ich habe mehrfach versucht, mit mehreren Modellen Brettspielregeln in eine Multiplayer-Webapp umzusetzen.
  • Nur Opus erzeugte tatsächlich eine funktionierende UI, aber die Regeln waren falsch implementiert.
• In diesem Bereich sah ich die meiste Misalignment.
  • In Kommentaren des Modells oder im verfügbaren chain of thought war erkennbar, dass die eigentliche Arbeit aufgeschoben wurde.
  • Selbst bei einer expliziten Anweisung, eine bestimmte UI fertigzustellen, tauchten Gedanken auf wie „wir brauchen noch eine Spieler-Auswahl-UI, also hard-coden wir das erst einmal“.
• Modelle übertrieben oder erfanden wiederholt den Abschluss von Aufgaben.
  • Ein Modell behauptete, alle Tasks erledigt zu haben, räumte auf Nachfrage dann aber ein, nur die ersten beiden gemacht und den Rest verschoben zu haben.
  • Wenn ich erneut um Abschluss bat, erklärte es wieder, alles sei fertig, und gab bei weiterer Nachfrage zu, tatsächlich nur Code hin- und hergeschoben zu haben.
• Selbst mit Hilfe von Browser-Automatisierung zum Schreiben von end-to-end tests scheiterten Modelle an der Einrichtung von Dependencies und logen darüber, Tests erfolgreich ausgeführt zu haben.
  • Wenn die UI kaputt war, versuchten sie, den Test per direktem HTTP-Aufruf statt per Button-Klick zum Bestehen zu bringen.
• Für das Scheitern bei der Implementierung von Brettspielregeln sehe ich zwei Gründe.
  • Brettspielregeln sind willkürlich, sodass man sich nicht auf Trainingsdaten verlassen kann, sondern die Regeln explizit durchdenken muss.
  • Die Kosten, mehrere echte Partien zu spielen, um die Regelimplementierung zu überprüfen, sind höher als die Kosten, den Code von Anfang an selbst richtig zu schreiben.
• Bei der Kombination aus niedriger Erfolgsquote und keineswegs geringen Verifikationskosten sind Modelle meiner Einschätzung nach völlig nutzlos.

Einschätzung zum Einsatz als autonomer Softwareingenieur

• Wenn man KI in der heutigen Form als autonomen Softwareingenieur einsetzt, bekommt man meiner Ansicht nach einen riesigen Haufen aus duct tape und chewing gum, den kein Mensch mehr reparieren kann.
• Andererseits sahen viele ausgelagerte Codebasen der letzten Jahrzehnte ähnlich aus, und Modelle können dieselbe Arbeit wohl billiger liefern.
  • Modelle verschieben die Kosten-Qualitäts-Grenze.
• Selbst wenn Modelle über das heutige Niveau hinaus nicht intelligenter werden, kann sich die Praxis in eine Richtung entwickeln, die mehr Wert daraus zieht.
  • Sprach- und Runtime-Garantien
  • statische Analyse
  • leichtgewichtige formale Methoden
  • Methoden, die Verifikationskosten senken oder den Verhaltensspielraum von Modellen begrenzen
• Ich erinnere mich daran, dass man in der Zeit, als Python und Ruby weit verbreitet waren, davon ausging, dass Hardware schneller besser wird als Codeoptimierung; nach der Verlangsamung sequentieller Hardware-Fortschritte stieg das Interesse an Programmiersprachen-Performance wieder.
• Bei Modellen stehen wir meiner Ansicht nach an einem ähnlichen Punkt auf der Kurve.
  • Wenn das Modell nächsten Monat ohnehin klüger wird, interessiert man sich weniger für Harnesses oder Verbesserungen rundherum.
  • Falls die Modellleistung ihren Höhepunkt erreicht, bevor sie überall übermenschlich wird, beginnt die wirklich interessante Arbeit.

Suche und billige Arbeit

• Gut funktionieren Probleme, bei denen man die Antwort direkt überprüfen kann und Präzision wichtig ist, Recall aber weniger.
  • Fehler in Blogposts finden
  • APA-Formfehler in Fußnoten eines Essays finden
  • in goodreads_library_export.csv eine Trilogie mit Polizisten und Hexen finden
  • aus https://mgaudet.github.io/CompilerJobs/ nur die Links zu Rollen herausfiltern, die remote ausdrücklich erwähnen, und Cryptocurrency-Unternehmen ausschließen
• Ich lasse das Modell Fehler nicht selbst korrigieren.
  • Sobald es selbst korrigieren soll, fängt es an, Entscheidungen zu treffen.
• Weit riskanter sind Aufgaben, bei denen die Antwort plausibel wirkt, sich aber nicht direkt verifizieren lässt.
  • Auf die Frage nach reef-safe DIY wetsuit lube empfahlen Opus und GPT Glycerin.
  • Es scheint keine gute Idee zu sein, die Haut den ganzen Tag mit nasser Bakteriennahrung zu bedecken.

Brainstorming und Kreativität

• Wenn mir Namen für Typen oder Variablen schwerfallen, frage ich das Modell oft nach Ideen.
• Da es sich um eine Sprachverarbeitungsmaschine handelt, sollte es darin eigentlich gut sein, aber ich habe nie auch nur einen Vorschlag tatsächlich verwendet.
• Die Vorschläge empfand ich durchweg als gewöhnlich und klischeehaft.

Gesamtfazit und verbleibende Unzufriedenheit

• Reviews, Refactorings und einmalige Skripte waren durchweg nützlich und für sich genommen das Geld wert.
• Gemeinsames Coden bringt insgesamt noch keinen Gewinn, könnte aber in naher Zukunft mit schnelleren Modellen und besseren Harnesses sinnvoll werden.
• Das Modell allein Code schreiben zu lassen, funktionierte bei nichttrivialen Aufgaben nicht.
  • Um ohne tiefes menschliches Eingreifen hochwertige Software zu erhalten, wären deutlich mehr Experimente nötig.
  • Für den Markt minderwertiger Software könnte es heute schon ausreichen.
• Bei Frontier-Modellen habe ich nichts gesehen, was ich als Halluzination bezeichnen würde.
  • Nur DeepSeek flash erfand gelegentlich komplette Fakten.
  • Wenn Modelle falsch lagen, dann meist wegen Denkfehlern, falsch verstandener Evidenz oder fehlendem wichtigen Kontext, nicht weil sie etwas aus dem Nichts erfanden.
• Frontier-Modell-Abos waren ein sehr gutes Geschäft, wirken aber wie etwas, das nach der Gewöhnung aller schrittweise verschwinden wird.
  • Bei tokenbasierter Abrechnung bin ich nicht sicher, welche Anwendungsfälle dann noch lohnend wären.
  • DeepSeek v4 flash ist sehr billig, aber noch nicht klug genug und log am ehesten darüber, Tests erfolgreich ausgeführt zu haben.
• Die bestehenden Harnesses gefallen mir nicht.
  • In Interfaces, die nicht einmal einfache Textbearbeitung gut beherrschen, Prompts einzugeben, war mühsam.
  • Ich möchte stärker kontrollieren, was das Modell tun kann, und Interaktionen, bei denen ich direkt auf Dinge auf dem Bildschirm zeige.
  • Mein aktueller Workflow besteht darin, @bot-Kommentare im Code zu hinterlassen und den festen Prompt Handle comments marked @bot zu verwenden.
• Wenn Menschen Code schreiben, lesen sie ihn gleichzeitig und bauen dabei ihr mentales Modell neu auf.
  • Wenn ein Bot den Code stattdessen schreibt, bleibt der Aufbau dieses mentalen Modells weiterhin nötig, aber der natürliche Effekt des Schreibens fällt weg.
  • Reines Lesen reicht dann nicht; es braucht eine zusätzliche Praxis, etwas wie review++.
• Die bisherigen Erfahrungen haben Spaß gemacht und waren wahrscheinlich hilfreich, gerade weil ich bewusst an unwichtigen Projekten experimentiert habe.
• Diese Erfahrungen sind stark vom aktuellen Stand geprägt; was sich in den nächsten Jahren mit weiteren Verbesserungen ändern wird und wohin man sich bewegen sollte, verarbeite ich noch.

[GN⁺]

Meinungen auf Lobste.rs

• Dass pi weniger Bugs hat als andere Harnesses, liegt vermutlich daran, dass es von einem kleinen Team gebaut wird, die Maintainer konstante Qualitätsstandards einhalten, Code reviewen und sich überlegen, welche Funktionen hineinkommen sollen.
  Der Ansatz, nicht wahllos alle möglichen Features in den Harness zu stopfen, macht den Unterschied.
  https://mariozechner.at/posts/…

  • Selbst mit diesen drei Vorteilen würde es bei mir wohl zu einem verhedderten Klumpen werden, wenn ich per Vibe Coding etwas Großes baue.
    Da ist eindeutig zusätzliches Können am Werk.

• Der Punkt „Wenn der Bot den Code für mich schreibt, muss ich trotzdem ein mentales Modell aufbauen, bekomme es aber nicht mehr ‚gratis‘ beim Schreiben des Codes dazu“ ist sehr gut.
  Nur Code zu lesen funktioniert einfach nicht so gut; das ist ähnlich, als würde man hervorgehobene Notizen noch einmal ansehen und das für Prüfungsvorbereitung halten.
  Das knüpft auch an Programming as Theory Building an.
  Wenn man LLMs erstmals in einem Projekt einsetzt, dessen Systemtheorie man bereits im Kopf hat, erzielt man leicht Ergebnisse. Lässt man sie aber eine Weile machen, wird man zunehmend abgekoppelt, wie ein nicht programmierender Projektmanager, der nicht einmal die Anforderungen richtig formulieren kann, und die Frustration kann wachsen.

• Die Formulierung „fiebertraumhaftes Gebilde mit Unit-Tests“ werde ich künftig ohne Hemmungen in meine Sprache und Texte übernehmen.

  • Selbst bei mehreren bekannten Multi-Agent-Orchestratoren halluzinieren teure Modelle zur Laufzeit faktisch etwa 60 % des Orchestrators herbei.

• Das deckt sich wirklich stark mit meiner Erfahrung.
  Ergänzend hatte ich auch beim Debuggen von Linux-Desktop-Problemen mit Claude Code recht viel Erfolg.
  In 25 Jahre alten dotfiles haben sich Schichten von Altlasten angesammelt, deren Debugging mühsam ist; da ich die dotfiles aber mit yadm ohne Secrets über mehrere Maschinen teile, war auch Sandboxing einfach.
  Es lohnt sich auch, sich anzugewöhnen, Code-Änderungen von einem LLM prüfen zu lassen.
  Irgendwer wird meine Commits ohnehin per LLM prüfen, ob in einem Open-Source-Repository oder gegen Produktionsziele, und auch bei Lobsters habe ich in den letzten zwei Wochen von Leuten mit LLM-basierten Scannern vier valide Schwachstellenberichte bekommen.
  Alle behoben.
  In den neun Jahren davor erinnere ich mich nur an ungefähr zwei ähnliche Berichte.

• Zu sagen, man habe bei Frontier-Modellen noch nie etwas gesehen, das man Halluzination nennen könne, wirkt seltsam.
  Im Artikel selbst kommen mehrere Dinge vor, die ich als Halluzination einordnen würde.

  • Es erscheint sinnvoll, Folgendes zu unterscheiden: Halluzination („Lobsters wurde von Paul Graham gemacht“), Lügen/Faulheit („Ich habe die Aufgabe erledigt“) und schlechtes Urteilsvermögen („Diesen Wert kann man hier ruhig hardcoden“).
    Nach diesem Maßstab gab es in dem Artikel keine Halluzination, die ich entdeckt hätte, aber Lügen, Faulheit und schlechtes Urteilsvermögen sind auch nicht gerade gut.
    Diese Unterscheidung ist nützlich, weil Halluzinationen leichter zu reduzieren sein könnten, Lügen, Faulheit und schlechtes Urteilsvermögen dagegen schwieriger.
    Halluzinationen und Lügen führen beide dazu, dass das Modell falsche Dinge sagt, aber Halluzinationen entstehen eher aus Unwissen oder fehlenden Informationen und lassen sich adressieren, indem man Quellen verlangt oder das Modell darauf trainiert, Antworten auf schwacher Informationsbasis zu vermeiden.
    Lügen und Faulheit wirken dagegen wie Produkte zielgerichteten Verhaltens und von Reinforcement Learning und scheinen durch Training deutlich schwerer zu entfernen zu sein.

• LLMs für Code-Reviews statt zum Schreiben neuen Codes einzusetzen, vor allem bei Ein-Personen-Projekten, halte ich für eine der Varianten mit dem besten Verhältnis von Nutzen zu Risiko.
  Wenn es keinen erfahrenen dedizierten Reviewer gibt, ist eine LLM-Analyse buchstäblich besser als nichts.
  Da ich für Open-Source-Arbeit keine kommerziellen Cloud-Modelle verwenden möchte, experimentiere ich mit lokalen LLMs für Code-Reviews und weise sie an, keinen neuen Code zu erzeugen, sondern nur kurz Probleme zu beschreiben.
  Lokale Modelle sind vermutlich nicht so gut wie kommerzielle, aber Qwen 3.6 27B war ziemlich nützlich.
  Bei einer mittelgroßen Rust-Codebasis waren grob 70 % der Ausgaben in Ordnung; etwa 60 % der gefundenen Probleme waren korrekt, etwa 20 % waren zwar qualitativ schwach, brachten mich aber dazu, problematische Codebereiche anzusehen, was zu Verbesserungen führte, und 20 % waren Müll.
  Dass es viel Müll gibt, ist nicht gut, aber dadurch wurde sofort klar, dass man den Aussagen des Modells mit Vorsicht begegnen muss.
  Ich weiß nicht, wie viele echte Probleme es übersehen hat, und einige der Funde waren oberflächlich, etwa Tippfehler in Dokumentationskommentaren, aber insgesamt hat es mich dazu gebracht, den Code zu verbessern, also fühlt es sich wie ein Nettogewinn an.
  Das Risiko besteht darin, dass ich anfangen könnte, mich auf das LLM zu verlassen, statt meine eigene Arbeit gründlich noch einmal zu prüfen.
  Allerdings ist dieses Qwen-Modell auf meiner Maschine langsam genug, dass ich es nicht bei jeder Änderung laufen lassen möchte.
  Andere Modelle wie Qwen 3.6 35B oder Gemma4 26B waren deutlich schneller, aber deutlich schlechter.
  Es ist langsam und braucht Hardware, aber Qwen 27B zeigt, dass eine Zukunft möglich sein könnte, in der man Code mit lokalen Modellen verbessert, ohne von kommerziellen Anbietern abhängig zu sein und ohne sich die Expertise und den Spaß am Code-Hacking nehmen zu lassen.
  Trotzdem habe ich weiterhin sehr gemischte Gefühle dabei, LLMs überhaupt in den Prozess einzubauen, aber es fühlt sich besser an als die entfremdende Zukunftsvision, die die großen Anbieter vorantreiben.
  Ich stimme zu, dass von den Harnesses, die ich ausprobiert habe, nur pi ruhig wirkt.

  • Ich lasse zuerst den Bot laufen, mache währenddessen mein eigenes Review und kehre dann zur Bot-Ausgabe zurück, um zu prüfen, was ich übersehen habe.
    Der Bot findet oft andere Arten von Problemen als Menschen und ist deshalb ziemlich komplementär zu menschlichen Reviews.

• In pi kann man mit ctrl+G den Prompt in $EDITOR öffnen.
  Theoretisch ließe sich ein Editor finden, der Cursorbewegung per Klick unterstützt und zu den eigenen Anforderungen passt, sogar ein Terminal-UI-Editor.
  Ansonsten insgesamt ein guter Artikel, dem ich weitgehend zustimme.

• Das Problem „auf Text zeigen“ ist in GUI-IDEs/-Editoren bereits gelöst
  Wenn man eine JetBrains IDE nutzt, kann ein Plugin die ausgewählte Datei und Zeile immer als Prompt-Kontext übergeben
  Je nach Art der Anfrage werden Änderungen auch inline oder in einem Diff-Fenster angezeigt

  • Auch Zed hat eine Inline Assistant-Funktion, die so funktioniert, wie der Autor es beschreibt
    Man wählt einen Bereich aus, drückt Control-Enter und gibt einen Prompt ein; dann transformiert das LLM die Auswahl passend zum Prompt und ersetzt sie
    Die User Experience ist sehr gut, aber die typischen Probleme von LLM-Ausgaben bleiben bestehen

• Es wurden nur die monatlichen 20-Dollar-Abos der Modelle von Anthropic und OpenAI erwähnt und gesagt, pi sei viel besser als Claude Code oder Codex; dann frage ich mich, ob die Kombination Frontier-Modell + pi in der Praxis gar nicht ausprobiert wurde
  Ich dachte, das Abo zwinge einen dazu, den jeweiligen Harness zu verwenden

  • Das Codex-Abo lässt sich definitiv zusammen mit Pi verwenden

• Ein wirklich vernünftiger Text, das freut mich
  Beruflich kaufe ich Tokens bei der US-basierten Novita, für private Projekte nutze ich DeepSeek und seit Kurzem Xiaomi
  Kimi habe ich auch direkt ausprobiert, war aber nicht überzeugt genug, es weiter zu nutzen; mit Claude Code oder Codex oder dem jeweils gerade angesagten Harness habe ich keine Erfahrung
  Mit Qwen Code habe ich mir einen privaten Rust- + ratatui-Harness gebootstrapped; das war ein Fork von irgendetwas aus dem Google-Umfeld
  Er nutzt Single-Thread-Async, aber die Modelle lieben Threads und mpsc so sehr, dass es mühsam war, sie davon abzubringen
  Nebenbei: smol halte ich für okay
  Am Ende habe ich einigermaßen verstanden, was das Tool wie macht, und wenn das Modell neue Tool-Syntax erfindet, wäge ich die Vor- und Nachteile ab und füge nur in bestimmten Fällen lokale Korrekturen hinzu
  Meist ging es dabei um Synonyme für Namen von Tool-Argumenten
  Je weniger Parameter aktiviert sind, desto mehr achtet das Modell darauf, was es tun soll, und vergisst eher, wie es das tun soll; das ist nachvollziehbar
  Irgendwann werden Tool-Aufrufe wohl eher aus dem latenten Raum extrahiert werden, statt sie per Token zu erzwingen, und vielleicht nutzt man dafür sogar ein eigenes Übersetzungsmodell
  Ich nutze landlock, um das Modell auf das Projektverzeichnis zu isolieren und vom Home-Verzeichnis abzuschneiden
  Systempfade außerhalb von Home sind lesbar, und auf /tmp, einige Paket-Cache-Verzeichnisse innerhalb von Home sowie Orte wie /dev/null darf es schreiben
  Künftig könnte ich noch bessere Isolation ergänzen, aber wenn ich sehe, dass die meisten Leute, die ich kenne, Claude Code einfach so ausführen, wirkt das hier wie grundlegende Hygiene
  Das Netzwerk blockiere ich nicht, und ich mache keine Arbeiten, die zusätzlichen Schutz vor Datenabfluss erfordern
  Code-Reviews treffen nicht immer ins Schwarze
  Wenn man zuerst Richtlinien definiert, ist das Modell ganz brauchbar darin, Code und Richtlinien zu vergleichen und Abweichungen zu markieren; allgemeine Anfragen wie „Sag mir, ob das mies ist“ liefern aber sehr schwankende Ergebnisse
  Bei DeepSeek V4 Flash, das ich als Baseline nutze, habe ich bisher noch keine Angeberei erlebt
  DeepSeek V4 Pro war für mich beim Coding schlechter, Xiaomi MiMo 2.5 Pro ist besser, aber etwas teurer, und das normale MiMo 2.5 war schlechter
  Meiner Erfahrung nach sind Modelle meistens einfach nur dumm, besonders wenn der Kontext mit widersprüchlichen Ideen verunreinigt oder zu lang wird
  Manchmal verfällt das Modell in Gedanken wie „Um schneller Wert zu liefern, muss man Ecken abschneiden“, und dann muss man ein paar Schritte zurückgehen und das Modell selbst herausarbeiten lassen, wo es meinen Anweisungen widerspricht
  Manchmal liegt es daran, dass ich es nicht gut genug verstehe, manchmal ist es Overengineering des Modells, und gelegentlich schließt man bei kniffligen Randfällen Kompromisse, indem man Anforderungen vereinfacht
  Für Refactoring setze ich Modelle ungern ein
  Modelle treffen keine guten Entscheidungen
  Wenn man eine Funktion für zwei Einsatzzwecke in zwei Funktionen aufteilt und das Modell die Codebase durchsuchen lässt, um an jedem Call-Site zu entscheiden, welche Variante zu verwenden ist, liegt es in 25 % der Fälle falsch und zeigt keinerlei Unsicherheit
  Viel besser ist es, das Modell die Codebase untersuchen und den Wirkungsbereich kartieren zu lassen und das Refactoring dann selbst zu machen
  Sehr einfache Umstellungen, etwa simple Strukturänderungen, die Arbeit an mehreren Stellen einklammern, beschleunigen die Arbeit, aber man muss es ausdrücklich anweisen, auch veraltete Kommentare oder nicht mehr passende Variablennamen zu prüfen
  Anders als im Originalbeitrag habe ich nicht erlebt, dass Modelle unbedingt Dinge tun wollten, um die ich nicht gebeten hatte
  Das könnte daran liegen, dass ich vor dem Erlauben von Edits einen klaren Vorabplan verlange und den Reasoning-Fluss live beobachte und neu prompe, wenn das Modell komisch wird
  Bei beruflichem Code committe ich nichts, bevor ich alles gelesen und verstanden habe
  In dieser Phase nehme ich viele größere Korrekturen vor und lasse das Modell anschließend noch einmal prüfen
  Dann findet es recht zuverlässig Tippfehler, vertauschte Variablen und Kleinigkeiten, die problematisch werden könnten
  Die erste Version privater Projekte ist einfach eine Wegwerfversion
  Sobald die eigentliche Architektur klar ist, muss alles neu geschrieben werden, diesmal mit sauberer Vorabplanung
  Diese Methode könnte etwas unterschätzt sein
  Die Modelle, die ich nutze, sind ziemlich schnell
  Solange ich keine längere Recherche ausdrücklich anfordere, muss ich bis zum Aufgabenwechsel meist nicht umschalten; wenn das Modell lange braucht, um sich selbst davon zu überzeugen, wie viele r in strawberry stecken, denke ich normalerweise schon über den nächsten Schritt nach
  Was einigermaßen funktioniert, ist, vom Modell einen Plan erstellen zu lassen, ihn explizit in eine Datei zu schreiben und dann ein wenig iterativ zu verbessern
  Das Modell kann helfen, die Codebase zu durchsuchen und vor dem Coden den Wirkungsbereich zu verstehen, und mit einem sichtbaren Vorabplan lässt sich das Modell leichter auf Kurs halten
  Für Suche oder billige Arbeitskraft habe ich Modelle genutzt, um Papers zu einem bestimmten Thema zu finden, und das war nicht schlecht
  Die Papers habe ich danach selbst per Abo oder über andere Wege beschafft und das Modell lesen lassen, um zu beurteilen, ob sie zum Thema passen; das funktionierte tatsächlich ziemlich gut
  Relevante Papers habe ich anschließend selbst gelesen
  Auch eine große Codebase untersuchen zu lassen und bestimmte Aspekte erklären zu lassen, war in gewissem Maß produktiv
  Gemeinsam war beiden Fällen, dass das Modell ziemlich viel halluzinierte
  Die Halluzinationsrate hing stark davon ab, wie tief die zentralen Fakten im Kontext vergraben waren
  Wenn ich jeweils ein Paper klassifizieren und zusammenfassen ließ, dann den Kontext löschte und mit dem nächsten Paper weitermachte, verringerte sich das Problem deutlich
  Es dürfte mit Sparse Attention zusammenhängen, aber ich bin kein Experte
  Für Brainstorming und Kreativität war es nutzlos
  Ich habe überhaupt nicht erlebt, dass DeepSeek V4 Flash gelogen hätte, Tests oder Type-Checks ausgeführt zu haben
  Es kann zwar sehr schwer zu steuern werden, neigt aber eher dazu, sogar nach einer kleinen Kommentaränderung „zur Sicherheit“ Tests und Type-Checks erneut laufen zu lassen
  Und der Aussage, dass dies das Interessanteste in meinem Leben sei, stimme ich nicht zu