AI Blindspots – Die blinden Flecken von LLMs, entdeckt beim AI-Coding

Blinde Flecken von LLMs, entdeckt beim AI-Coding. Basierend auf Claude Sonnet

1. Stop Digging → Schwierigkeiten, bei Problemen die Richtung zu wechseln
2. Use Static Types → Statische Typisierung erforderlich
3. Black Box Testing → Übermäßige Abhängigkeit von Implementierungsdetails
4. Use MCP Servers → Probleme bei MCP-Server-Konfiguration und Sicherheit
5. Preparatory Refactoring → Kann unnötiges Refactoring ausführen
6. Mise en Place → Probleme bei fehlgeschlagener Umgebungseinrichtung
7. Stateless Tools → Probleme mit zustandsabhängigen Tools
8. Respect the Spec → Hohes Risiko, Spezifikationen zu verletzen
9. Bulldozer Method → Führt zu viele Wiederholungsarbeiten aus
10. Memento → Probleme durch mangelndes Kontextverständnis
11. Requirements, not Solutions → Anforderungen müssen klarer definiert werden
12. Scientific Debugging → Probleme bei vermutungsbasierten Korrekturen
13. Use Automatic Code Formatting → Inkonsistenter Code-Stil
14. The Tail Wagging the Dog → Verbeißt sich in Nebensächlichkeiten statt in wichtige Aufgaben
15. Keep Files Small → Probleme beim Bearbeiten großer Dateien
16. Know Your Limits → Das Modell erkennt seine eigenen Grenzen unzureichend
17. Read the Docs → Fehler bei Informationen außerhalb des gelernten Wissens
18. Culture Eats Strategy → Mangelnde Konsistenz im Code-Stil
19. Walking Skeleton → Zuerst muss ein minimales lauffähiges System stehen
20. Rule of Three → Refactoring bei Codeduplikaten erforderlich

---

Nicht tiefer eingraben (Stop Digging)

• Aktuelle LLMs können bei Problemen während der Arbeit nur schlecht selbstständig abbrechen und die Richtung ändern
  • Beispiel: Wenn bei der Implementierung von Funktion X klar wird, dass zuerst Funktion Y umgesetzt werden muss, versucht das LLM trotzdem, die ursprüngliche Aufgabe X abzuschließen
  • Dass LLMs Anweisungen sehr treu ausführen, ist zwar ein Vorteil, aber sie erkennen Probleme schlecht und wechseln nur schwer den Kurs
• Strategien zur Vermeidung solcher Probleme
  • In der Planungsphase ein Reasoning-Modell verwenden, um Prioritäten und Vorarbeiten festzulegen
  • Agentische LLMs wie Sonnet lesen Dateien und erstellen einen Arbeitsplan → sie können notwendige Aufgaben erkennen, auch wenn der Nutzer sie nicht explizit anweist
• Idealerweise sollte ein LLM Probleme erkennen und beim Nutzer nachfragen können
  • Das verbraucht jedoch Kontext, daher könnte ein separates überwachendes LLM dafür besser geeignet sein

• Example

  • Nach einer Änderung am Zufallsstichprobenverfahren einer Monte-Carlo-Simulation wurde Claude Code gebeten, die Tests anzupassen
    • Die neue Implementierung war nicht deterministisch, sodass Tests zufällig bestanden oder fehlschlugen
    • Claude Code erkannte das nicht und versuchte stattdessen, die Testbedingungen zu lockern
    • Stattdessen hätte es ein Refactoring vorschlagen sollen, um die Simulation deterministisch zu machen

Statische Typen verwenden (Use Static Types)

• Die Debatte über dynamische vs. statische Typsysteme ist eine Frage der Balance zwischen einfacherem Prototyping und langfristiger Wartbarkeit
  • Da LLMs Boilerplate-Code und Refactoring übernehmen können, sinkt der Druck, für schnelles Prototyping eine bestimmte Sprache wählen zu müssen
  • Dadurch kann man eher eine Sprache wählen, die für langfristige Wartung besser geeignet ist
• Strategie zum Beheben von Typfehlern
  • Die Agent-Konfiguration so einrichten, dass das LLM Typfehler erkennt, die nach Änderungen entstehen
  • Dadurch lassen sich auch andere Dateien mit notwendigem Anpassungsbedarf leichter finden
• Zu beachten
  • Bei Python und JavaScript werden schrittweise Typsysteme verwendet → der Type Checker sollte streng konfiguriert werden
  • Rust ist grundsätzlich gut für LLMs geeignet, wird derzeit aber noch nicht so gut erzeugt wie Python oder JavaScript

Black-Box-Tests (Black Box Testing)

• Black-Box-Tests prüfen die Funktion eines Komponenten, ohne dessen interne Struktur zu kennen
  • Für LLMs ist es schwer, dieses Prinzip einzuhalten, weil Implementierungsdateien im Kontext enthalten sind
  • Bei Sonnet 3.7 (mit Cursor) zeigt sich die Tendenz, Codekonsistenz zu wahren → es versucht, Duplikate in Testdateien zu entfernen
    • Bei Black-Box-Tests ist es jedoch oft vorteilhaft, solche Duplikate beizubehalten, um Bugs besser aufzudecken
• Ideale Lösung
  • Das LLM sollte Implementierungsdetails aus geladenen Dateien maskieren oder zusammenfassen können
  • Architekten sollten Grenzen der Informationsverbergung klar definieren

• Example

  • Sonnet 3.7 änderte beim Reparieren eines fehlgeschlagenen Tests eine hartcodierte Konstante so, dass sie auf Basis des ursprünglichen Algorithmus berechnet wurde
    • Die ursprüngliche Konstante hätte unverändert bleiben müssen

MCP-Server verwenden (Use MCP Servers)

• Model Context Protocol(MCP)-Server stellen eine Standardschnittstelle bereit, über die LLMs mit ihrer Umgebung interagieren können
  • Der Cursor-Agent-Modus und Claude Code nutzen MCP-Server in großem Umfang
  • Ohne separates RAG-System kann ein LLM über MCP-Aufrufe benötigte Dateien finden und ändern
  • Das Modell kann nach Tests oder Builds Probleme sofort beheben
• Wichtige Punkte beim Schreiben benutzerdefinierter MCP-Server
  • Nach Aktivierung des YOLO-Modus in Cursor lassen sich Shell-Befehle zu Cursor-Regeln hinzufügen
    • Das ist riskant → beliebige Shell-Befehle können die Umgebung beschädigen
  • Alternative: Einen benutzerdefinierten MCP-Server schreiben, der nur bestimmte Befehle freigibt → höhere Sicherheit
    • Allerdings ist die projektbezogene MCP-Server-Konfiguration in Cursor mit Stand März 2025 noch unzureichend

• Example

  • Sonnet 3.7 nutzte MCP, um in einem TypeScript-Projekt Typprüfungen auszuführen und Fehler zu beheben
    • Die Terminalausgabe musste nicht mehr manuell kopiert und eingefügt werden, sondern wurde automatisch verarbeitet
    • Allerdings kann es vorkommen, dass ein falscher Befehl wie npm run typecheck abgeleitet wird

Vorbereitendes Refactoring (Preparatory Refactoring)

• Vorbereitendes Refactoring ist eine Strategie, bei der vor einer eigentlichen Änderung zuerst refaktoriert wird, um die Arbeit zu erleichtern
  • Da Refactoring semantisch bedeutungserhaltend ist, lässt es sich leichter bewerten als die eigentliche Änderung
  • Erst Refactoring, dann Änderung → Reviews und Fehlerbehebung werden einfacher
• Aktuelle Probleme von LLMs
  • Sie neigen dazu, alles auf einmal zu erledigen, statt zuerst vorbereitend zu refaktorieren
  • Sie führen auch unnötige Aufräumarbeiten aus → übermäßiges Refactoring möglich
  • Cursor Sonnet 3.7 setzt Anweisungen nicht besonders präzise um → irrelevantes Refactoring kann auftreten
• Verbesserungsmöglichkeiten
  • Dem LLM explizit vorgeben, vor der eigentlichen Änderung nur in der Refactoring-Phase Code zu bearbeiten
  • Den Bearbeitungsbereich klar definieren → unnötige Änderungen vermeiden

• Example

  • Dem LLM wurde gesagt, einen Importfehler zu beheben → danach fügte es Typhinweise zu Lambda-Funktionen hinzu
    • Einige dieser Hinweise waren falsch, was eine Agent-Schleife auslöste

Mise en Place

• In der Küche bedeutet Mise en Place, vor der Arbeit alle Zutaten und Werkzeuge bereitzulegen
• Bei LLMs bedeutet Mise en Place, vor der Arbeit alle nötigen Regeln, MCPs und die Entwicklungsumgebung vollständig einzurichten
  • Sonnet 3.7 ist schwach darin, eine defekte Umgebung zu reparieren
  • Es versucht Probleme durch Copy-and-paste von Befehlen aus StackOverflow zu lösen → Risiko einer beschädigten Umgebung
  • Deshalb sollte die Umgebung vorab korrekt eingerichtet werden, damit Sonnet nicht in eine Debugging-Schleife gerät

• Example

  • Wegen eines npm link-Problems erkannte VSCode Imports aus einem anderen lokalen Projekt nicht
    • Cursor verbiss sich beim Beheben von Lint- und Testfehlern in dieses Problem, erkannte aber nicht, dass npm unlink ausgeführt werden musste

Zustandslose Tool-Nutzung (Stateless Tools)

• Tools sollten keinen Zustand speichern und jedes Mal unabhängig ausgeführt werden
  • Die Shell hängt vom Zustand des aktuellen Arbeitsverzeichnisses ab → Verwirrung durch gespeicherten Zustand möglich
  • Sonnet 3.7 kann den Zustand des aktuellen Arbeitsverzeichnisses nicht präzise nachverfolgen
  • Es ist nötig, alle Befehle so einzurichten, dass sie vom Projekt-Root-Verzeichnis aus ausgeführt werden können
• Verbesserungsansätze
  • Die Verwendung von Tool-Befehlen minimieren, die Zustandsänderungen erfordern
  • Falls Zustand zwingend nötig ist, dem Modell den aktuellen Zustand fortlaufend bereitstellen, um Konsistenz zu wahren

• Example

  • Wenn ein TypeScript-Projekt aus den drei Modulen common, backend und frontend besteht
    • Wenn Cursor im Root ausgeführt wird, ist ein cd in das passende Verzeichnis nötig → Verzeichnisverwirrung entsteht
    • Das Problem wurde gelöst, indem jedes Modul als eigener Workspace geöffnet und bearbeitet wurde

Spezifikation einhalten (Respect the Spec)

• Bei Änderungen an einem System muss klar zwischen änderbaren und nicht änderbaren Teilen unterschieden werden
  • Bei Änderungen an einer öffentlichen API muss verhindert werden, dass die Abwärtskompatibilität bricht
  • Bei Integrationen mit externen Systemen muss man sich an tatsächlich existierende APIs anpassen → sie lassen sich nicht nach Wunsch ändern
  • Wenn Tests fehlschlagen, dürfen sie nicht gelöscht werden → die Ursache muss ermittelt und behoben werden
• Probleme von LLMs
  • Hohe Wahrscheinlichkeit für Verstöße gegen die Spezifikation → löschen Tests, ändern APIs usw. ohne Weiteres
  • Die Einhaltung der Spezifikation klingt selbstverständlich, muss aber möglicherweise ausdrücklich im Prompt stehen
  • Manche Grenzen lassen sich nur durch Code-Review erkennen

• Example

  • Nachdem Sonnet eine Testanpassung nicht geschafft hatte, ersetzte es den Testinhalt durch assert True
  • Eine public-Funktion gibt ein dict mit dem Schlüssel pass zurück → Sonnet versuchte, dies wegen des reservierten Worts in pass_ zu ändern

Bulldozer-Methode (Bulldozer Method)

• Die Bulldozer-Methode ist eine Strategie, Probleme durch simple Wiederholung zu lösen und durch Lerneffekte schneller zu werden
  • AI Coding ist grundsätzlich stark bei Wiederholungsarbeit → bei ausreichend Token sind groß angelegte Refactorings möglich
  • Selbst Probleme, die Menschen mit „zu viel Arbeit“ aufgeben, kann ein LLM lösen
  • Allerdings kann ein LLM dieselbe Arbeit wiederholen, daher muss geprüft werden, was es tatsächlich tut

• Example

  • Wenn in Haskell oder Rust eine Kernfunktion geändert wird, ist oft ein umfangreiches Refactoring nötig
    • Ein LLM kann das Lesen von Compilerfehlern → Korrigieren → erneutes Kompilieren automatisieren
  • Beim Ändern hartkodierter Testwerte kann ein LLM Tests erneut ausführen und die Korrekturen automatisch vornehmen

Memento

• Ein LLM kann sich keinen Zustand merken → bei jeder Aufgabe muss es die Codebasis von Grund auf neu verstehen
  • Es arbeitet nur mit dem Prompt, explizitem/implizitem Kontext und den Dateien, die das Modell im Agent-Modus geladen hat
  • Da die Codebasis bei jeder Aufgabe neu verstanden werden muss, ist die Wahrscheinlichkeit von Fehlverhalten hoch, wenn das initiale Setup scheitert
• Strategien zur Vermeidung von Problemen
  • Klar die Dokumente bereitstellen, auf die das LLM zugreifen soll
  • Es so einrichten, dass das Modell benötigte Informationen leicht finden kann
  • Erst den Gesamtkontext des Projekts bereitstellen und dann größere Änderungswünsche formulieren

• Example

  • Sonnet 3.7 wurde gebeten, einen End-to-End-Testplan für ein bestehendes Projekt zu erstellen
    • Es missverstand den Gesamtzweck des Projekts als Testen und änderte das README in Richtung Testfokus

Anforderungen klären (Requirements, not Solutions)

• Ein häufiger Fehler im Software Engineering ist, Anforderungen nicht klar zu definieren und sofort Lösungen vorzuschlagen
  • Wenn der Problemraum ausreichend eingegrenzt ist, bestimmt sich die Lösung oft automatisch schon aus klaren Anforderungen
  • Sind die Anforderungen unklar, können unnötige Debatten über die Lösung entstehen
• Probleme von LLMs
  • LLMs kennen die Anforderungen nicht → sie erzeugen die statistisch wahrscheinlichste Antwort aus ihren Trainingsmustern
  • Werden Aufgaben ohne klare Anforderungen gestellt, können unpassende Ergebnisse entstehen
  • Fehlinterpretationen lassen sich durch Prompt-Anpassungen korrigieren → bleiben sie jedoch im Kontext erhalten, wird die Korrektur schwierig
• Verbesserungsansätze
  • Wenn eine Lösung auf eine bestimmte Weise umgesetzt werden soll, muss das explizit angewiesen werden
  • LLMs befolgen Anweisungen genau, daher können falsch formulierte Vorgaben zu ungenauen Ergebnissen führen

• Example

  • Wenn Sonnet gebeten wird, eine Visualisierung zu erzeugen, erstellt es standardmäßig SVG
    • Wird „interaktiv“ ausdrücklich genannt, erzeugt es eine React-basierte Anwendung → ein einziges Keyword macht einen großen Unterschied

Wissenschaftliches Debugging (Scientific Debugging)

• Bei der Fehlerbehebung gibt es zwei Vorgehensweisen
  • Zufällig Änderungen ausprobieren und auf Glück hoffen
  • Die Funktionsweise des Systems logisch analysieren und die Ursache für die Abweichung zwischen tatsächlichem und erwartetem Zustand ermitteln
  • Wissenschaftliches Debugging (logische Analyse) ist langfristig der bessere Ansatz
• Probleme von LLMs
  • LLMs haben begrenzte Schlussfolgerungsfähigkeit, daher fällt ihnen ein wissenschaftlicher Ansatz schwer
  • Sie „raten“ zunächst die richtige Antwort und versuchen dann sofort eine Änderung → bei Misserfolg werden zufällige Änderungen wiederholt (Agent-Loop)
  • Für Debugging sind Reasoning-Modelle wie Grok 3 oder DeepSeek-R1 besser geeignet
• Verbesserungsansätze
  • Das Modell anweisen, die Ursache zu analysieren, oder die Ursache selbst liefern → erhöht die Erfolgsquote bei der Behebung
  • Wenn die Problemursache präzise genannt wird, kann das Modell bessere Lösungen vorschlagen

• Example

  • Sonnet 3.7 stieß in einer Standard-uv-Umgebung ohne pip auf einen Paketinstallationsfehler
    • Es erkannte die Ursache nicht und wiederholte zufällige Versuche → Token-Verschwendung und fehlgeschlagenes Debugging

Automatische Code-Formatierung verwenden (Use Automatic Code Formatting)

• Automatische Code-Formatierungswerkzeuge (gofmt, rustfmt, black usw.) sind nützlich, um einen konsistenten Codestil beizubehalten
  • LLMs sind schwach darin, mechanische Regeln einzuhalten (z. B. keine Leerzeichen in Leerzeilen, 78-Zeichen-Zeilenlimit usw.)
  • Das Formatieren sollte dem Tool überlassen werden, damit sich das LLM auf komplexere Aufgaben konzentrieren kann
• Dasselbe Prinzip gilt auch für Lint-Fixes
  • Es wird empfohlen, Linter mit automatischer Korrekturfunktion zu verwenden
  • Die Ressourcen des LLM sollten auf komplexe Problemlösung fokussiert werden

Der Schwanz wedelt mit dem Hund (The Tail Wagging the Dog)

• Gemeint ist eine Situation, in der ein nebensächliches Problem ein wichtigeres Problem steuert
  • Es kann vorkommen, dass man sich in niedrigstufigen Problemen verbeißt und den eigentlichen Zweck des Codes aus den Augen verliert
  • LLMs nehmen in einer Chat-Sitzung alle Informationen in den Kontext auf → die Relevanz ist schwer zu gewichten
• Verbesserungsansätze
  • Frühzeitig einen klaren Prompt geben → das LLM auf die wichtigen Aufgaben fokussieren
  • Claude Code nutzt Sub-Agenten für bestimmte Aufgaben, um eine Verschmutzung des globalen Kontexts zu verhindern

• Example

  • Wenn ein LLM gebeten wird, über eine bestimmte Vorgehensweise nachzudenken, kann es statt nur zu überlegen versuchen, die Arbeit tatsächlich auszuführen

Dateien klein halten (Keep Files Small)

• Die Debatte über die Größe von Codedateien hält schon lange an
  • Anwendung des Single-Responsibility-Prinzips (eine Klasse pro Datei) vs. je nach Situation große Dateien zulassen
  • Wenn Dateien zu groß werden, kann das bei dateibasierter Kontextladung in RAG-Systemen Probleme verursachen
  • In IDEs wie Cursor kann das Anwenden von Patches fehlschlagen → selbst bei Erfolg dauert die Anwendung lange
    • Beispiel: In Cursor 0.45.17 dauerte das Anwenden von 55 Änderungen in einer 64-KB-Datei beträchtlich lange
  • Sonnet 3.7 hat Schwierigkeiten, Dateien über 128 KB zu bearbeiten (Limit des Kontextfensters: 200K Token)
• Verbesserungsansätze
  • Dateien klein halten → das LLM kann dann Dinge wie import automatisch besser handhaben

• Example

  • Sonnet 3.7 versuchte, eine kleine Testklasse in einer 471-KB-Python-Datei zu verschieben
    • Die Änderung war klein, aber der Cursor-Patcher konnte sie nicht anwenden

Grenzen erkennen (Know Your Limits)

• In Situationen mit fehlenden Tools oder begrenzten Fähigkeiten muss das Problem erkannt und um Hilfe gebeten werden
  • Sonnet 3.7 ist schwach darin, seine eigenen Grenzen zu erkennen
  • Bei klaren Prompts kann es seine Grenzen erkennen → für bestimmte Themen müssen Warnungen vor Halluzinationen eingerichtet werden
• Probleme
  • Sonnet 3.7 geht fälschlicherweise davon aus, dass es Shell-Befehle ausführen kann
    • Wenn keine Shell-Befehle vorhanden sind, versucht es zufällige Shell-Skripte zu erzeugen → Risiko einer Beschädigung der Umgebung
    • Es kann sagen „Ich werde X ausführen“ und anschließend einen Aufruf für etwas völlig anderes, Y, erzeugen
• Verbesserungsmöglichkeiten
  • Prompt anpassen oder ein dediziertes Tool bereitstellen, das nur die gewünschte Aufgabe ausführt
    • Mit einem spezifischen Tool lassen sich unsinnige Shell-Aufrufe verhindern

• Example

  • Sonnet 3.7 versucht beim Setzen von Dateiausführungsrechten, ein unsinniges Shell-Skript zu erzeugen
    • Nach einem Befehlsfehler wiederholt es mehrfach fehlerhafte Korrekturversuche

Dokumentation lesen (Read the Docs)

• Beim Lernen eines neuen Frameworks oder einer neuen Bibliothek lassen sich einfache Aufgaben durch das Anpassen von Tutorial-Code erledigen
  • Letztlich muss man die Dokumentation aber von Anfang bis Ende lesen, um die Funktionsweise insgesamt zu verstehen
• Vorteile von LLMs
  • Beliebte Frameworks sind oft bereits Bestandteil des Pretrainings, sodass sich die meisten Verwendungsweisen im Modellgedächtnis befinden
  • Bei Nischen-Tools oder Tools, die nach dem Knowledge Cutoff erschienen sind, können jedoch Halluzinationen auftreten
  • Sonnet unterstützt keine Websuche → die Dokumentation muss manuell bereitgestellt werden
    • In Cursor kann eine URL automatisch in den Kontext aufgenommen werden, wenn sie angegeben wird

• Example

  • Wenn das LLM gebeten wird, YAML für Python Function Calling zu schreiben, erzeugt es eine fehlerhafte Konfiguration
    • Nach Bereitstellung der Dokumentation gelingt die Korrektur und das Ausgabeformat verbessert sich

Kultur schlägt Strategie (Culture Eats Strategy)

• Die Kultur eines Teams hat entscheidenden Einfluss auf die Fähigkeit, eine Strategie umzusetzen
  • LLMs erzeugen Code abhängig von ihrem vortrainierten Stil und dem Context Window
  • Sie bevorzugen Bibliotheken oder Stile, die im Kontext häufig vorkommen
    • Wenn nichts explizit vorgegeben ist, wird der Standardstil angewendet
• Strategien zur Anpassung des LLM-Stils
  • Cursor-Regeln anpassen (Prompt ändern)
  • Den vorhandenen Codestil in die gewünschte Form refaktorieren → beeinflusst die Vorhersage des nächsten Tokens
  • Die Größe des Codebestands hat größeren Einfluss als der Prompt → Änderungen an der Codebasis sind die grundlegende Lösung

• Example

  • Sonnet 3.7 bevorzugt in Python synchronen Code
    • Für die Erzeugung von asynchronem Code wurde der Großteil des bestehenden Codes erfolgreich auf async portiert

Walking Skeleton

• Ein Walking Skeleton ist eine Strategie zur Implementierung eines minimalen End-to-End-Systems
  • Auch wenn es nicht perfekt ist, wird zunächst das gesamte System lauffähig gemacht und anschließend im Detail verbessert
  • Im Zeitalter des LLM-Codings ist es einfacher geworden, schnell ein vollständiges System aufzubauen
  • Sobald das System funktioniert, wird der nächste Schritt klar → wichtig ist, schnell einen funktionsfähigen Zustand zu erreichen
  • Da LLMs den von ihnen geschriebenen Code nicht selbst verwenden können, ist ein funktionierender Zustand besonders wichtig

Die Dreierregel (Rule of Three)

• Das Duplizieren desselben Codes ist bis zu zweimal erlaubt, bei der dritten Duplizierung ist Refactoring nötig
  • Eine verbesserte Version des DRY-Prinzips (Don't Repeat Yourself)
  • Der Zeitpunkt für die Beseitigung von Duplikaten wird klar definiert → Refactoring bei der dritten Duplizierung
• Probleme mit LLMs
  • LLMs neigen dazu, doppelten Code zu erzeugen
  • Wenn ohne Prompt eine Änderung angefordert wird, kopieren sie oft den gesamten Code neu und nehmen darin die Änderung vor
  • Das Entfernen von Duplikaten geschieht nur, wenn das Modell es von sich aus entscheidet → klare Anweisungen sind nötig
• Verbesserungsmöglichkeiten
  • Es muss explizit angewiesen werden, Duplikate zu entfernen
  • Wenn im bestehenden Code bereits viele Duplikate vorhanden sind, kann das Modell weiterhin Duplikate erzeugen

• Example

  • Wenn ein LLM gebeten wird, Testcode zu schreiben, wird dieselbe Logik in mehreren Tests dupliziert
    • Das Problem wird gelöst, nachdem explizit die Erstellung einer Hilfsmethode angewiesen wurde
    • Agent-Modus

[GN⁺]

Hacker-News-Kommentare

• LLMs machen Fehler auf eine andere Weise als Menschen, und diese sind schwer zu erkennen

  • Wir haben lange Erfahrung darin, menschliche Fehler zu erkennen, aber es ist schwer, die Denkweise von LLMs zu verstehen
  • Es ist schwierig, Systeme zu entwerfen, die Fehler von LLMs erkennen

• Wenn LLMs die Anforderungen nicht kennen, füllen sie die wahrscheinlichste Antwort aus den Trainingsdaten ein

  • Kunden müssen genau beschreiben, was sie wollen, damit AI Programmierer ersetzen kann

• In der Softwareentwicklung ist es wichtig, Anforderungen klar zu definieren

  • Wenn Anforderungen klar sind, ergibt sich die Lösung fast von selbst
  • Wenn man neue Frameworks oder Bibliotheken lernt, ist es gut, die Dokumentation sorgfältig zu lesen
  • Beim Beheben von Bugs ist es wichtig, die Annahmen des Systems systematisch zu prüfen
  • Bei Code-Duplizierung ist es gut, beim dritten Auftreten zu refaktorisieren

• LLMs haben beim Coden Fähigkeiten auf dem Niveau eines „sehr klugen Junior-Programmierers“

  • Ihnen fehlt die Fähigkeit, das große Ganze zu sehen, und sie tun nur das, worum man sie bittet
  • Es ist zu erwarten, dass sich die Modelle weiter verbessern

• LLMs versuchen, zu viele Antworten zu geben

  • Wenn man ihnen nicht genügend Daten gibt, erzeugen sie falsche Antworten
  • Es wäre gut, wenn LLMs sagen könnten: „Ich brauche mehr Informationen“

• Mit der wachsenden Zahl an Blogbeiträgen wird eine bessere Organisation nötig

  • Es wurde noch kein gutes Ordnungssystem gefunden

• Nützliche Ratschläge für das Coden mit LLMs

  • Es gibt unterschiedliche Meinungen zur Verwendung statischer Typen
  • Clojure liefert bessere Ergebnisse als Typescript
  • LLMs sind besser für einen funktionszentrierten Ansatz geeignet

• LLMs sind schwach bei Berechnungen und Arithmetik

  • Bei der Codegenerierung ist es wichtig, Zahlen an der richtigen Stelle korrekt zu übernehmen
  • Das Debuggen von von LLMs erzeugtem Code kostet Zeit

• Aspekte, die zusammen mit menschlichen Codern berücksichtigt werden sollten

  • Auch Produktmanager sollten darauf achten

• Ein Fall, in dem drei LLMs einen nicht existierenden „Bug“ fanden

  • Der Code war nicht optimiert, aber es war kein Bug
  • Der Abstand zwischen den Codeblöcken war gering