Coding mit LLMs (Sommer 2025)
(antirez.com)- Update zum Einsatz von LLMs durch den Redis-Entwickler antirez
- Hochmoderne LLMs wie Gemini 2.5 PRO und Claude Opus 4 verstärken die Fähigkeiten von Entwicklerinnen und Entwicklern
- Mit LLMs lassen sich Arbeitsabläufe auf vielfältige Weise effizienter gestalten, etwa durch Bug-Beseitigung, das Testen von Ideen und die Erweiterung von Wissen
- Auch in fachfremden Bereichen oder bei neuen Technologien ist es möglich, diese mit Hilfe von LLMs leicht zu erschließen
- Für die Gesamtqualität und Wartbarkeit des Codes ist jedoch die Zusammenarbeit von „Mensch + LLM“ entscheidend
- Um LLMs optimal zu nutzen, sind ausreichender Kontext und klare Kommunikationsfähigkeit wichtig
Veränderungen in der Entwicklung mit LLMs und die wichtigsten Punkte
Hochmoderne LLMs wie Gemini 2.5 PRO und Claude Opus 4 erweitern die Fähigkeiten von Softwareentwicklern durch ihr enormes Verständnisvermögen und ihre Fähigkeit, große Codebasen zu verarbeiten.
- Wer Probleme klar beschreiben kann und an iterative Kommunikation gewöhnt ist, kann
- Bugs bereits vor dem Release beseitigen (z. B. im Fall der Implementierung von Redis Vector Sets, bei der Gemini/Claude durch Code-Review sofort Bugs entfernten)
- schnell testen, ob Ideen funktionieren, dabei experimentellen Code schreiben und die Performance bewerten
- Pair-Design auf Basis von Erfahrung und Intuition betreiben, wobei sich das umfangreiche Fachwissen des LLM mit menschlicher Intuition verbindet
- bei klaren Anweisungen an das LLM Teile der Implementierung zügig abschließen
- sich auch in unbekannten Bereichen (z. B. 68000-Assemblercode für den Amiga) schnell technisch einarbeiten
Im früheren Beitrag „LLMs und Programmierung Anfang 2024“ wurde die Nützlichkeit von LLMs bereits erwähnt, doch in den letzten 1,5 Jahren haben sich LLMs sprunghaft weiterentwickelt.
Für die bestmögliche Nutzung von LLMs brauchen sowohl Menschen als auch LLMs bestimmte Fähigkeiten und Gewohnheiten, und die zugrunde liegenden Prinzipien sind entscheidend.
Zurückhaltung bei Vibe Coding und Prinzipien der Zusammenarbeit zwischen Mensch und LLM
Aktuell sind LLMs hervorragend als Fähigkeitsverstärker für Entwickler geeignet, haben aber noch nicht das Niveau erreicht, auf dem sie autonom sämtliche Aufgaben allein erledigen können.
- Bei einmaligen kleinen Projekten wie Tests oder kleinen Utilities kann ein LLM das Design allein übernehmen
- Bei großen oder untypischen Projekten führt der alleinige Einsatz eines LLMs jedoch mit hoher Wahrscheinlichkeit zu Problemen wie Komplexität, unnötigem Code und strukturellen Schwächen
- Die Zusammenarbeit von LLM und Mensch bringt die größten Produktivitätsgewinne, setzt aber effektive Kommunikation und Erfahrung im Umgang mit LLMs voraus
- Komplexe Aufgaben sollten nicht allein an ein LLM delegiert werden; stattdessen ist eine Strategie nötig, bei der Menschen jederzeit aktiv in den Prozess eingreifen
Warum ausreichend Kontext für LLMs so wichtig ist
Damit ein LLM die Richtung einer Entwicklung oder Fehlerbehebung richtig versteht, ist die Bereitstellung umfangreicher Kontextinformationen unverzichtbar.
- Idealerweise stellt man Papers, die Ziel-Codebasis (möglichst vollständig) und die Absicht der Arbeit bereit
- Dazu gehören zentrale Informationen wie Implementierungsziel, unerwünschte oder fragile Ansätze, realisierbare Kernideen, Ziele, Invarianten und Codestil
- Wenn ein LLM beispielsweise mit einer neuen Technologie arbeitet, die es nicht kennt (z. B. Redis Vector Sets), kann es durch die Einbeziehung der README-Dokumentation in den Kontext sofort Antworten auf Expertenniveau liefern
Auswahl und Nutzung von LLMs
Das bekannteste LLM liefert nicht zwangsläufig die besten Ergebnisse.
- Für das Coding sind Gemini 2.5 PRO und Claude Opus 4 besonders effizient
- Gemini 2.5 PRO ist hervorragend bei der Erkennung komplexer Bugs und der Problemlösung
- Claude Opus 4 ist stark beim Schreiben neuen Codes und bietet zudem eine gute User Experience
- Wer beide Modelle abwechselnd nutzt, gewinnt bei komplexen Designs ein tieferes Verständnis
- Wenn man nur eines wählen würde, wäre Gemini 2.5 PRO die Empfehlung
- Bedingungen, die bei der Nutzung von LLMs eingehalten werden sollten
- Code-Agents oder in IDEs integrierte Agents sollten vermieden werden
- Das LLM sollte den gesamten Kontext (Code, Dokumentation usw.) direkt sehen können, um die bestmöglichen Antworten zu liefern
- Funktionen, die nur Teile des Kontexts zeigen, etwa RAG (wissensbasierte Extraktion), führen zu Leistungseinbußen
- Menschen sollten den Code in jedem Schritt manuell kopieren/einfügen und den Ablauf selbst nachverfolgen
Fazit – Kontrolle zu behalten ist entscheidend
Das Auftauchen von Agents, die Code eigenständig schreiben, ist nicht mehr fern, aber zum jetzigen Zeitpunkt liefert die vom Menschen geführte Zusammenarbeit mit LLMs den präzisesten Code.
- Die Rolle des Menschen, zu entscheiden, was und wie etwas getan wird, bleibt zentral
- Mit LLMs kann man über die Grenzen des eigenen bisherigen Wissens hinaus neue Technologien oder Konzepte lernen und daran wachsen
- Wer den Code direkt kontrolliert, kann die Konsistenz von Design und Implementierung wahren und zugleich die Unsicherheit durch Fehler von LLMs minimieren
- Es ist auch eine kluge Strategie, die Leistungsentwicklung von Agents regelmäßig zu überprüfen
- Wer den Einsatz von LLMs in dieser Phase meidet, könnte den Anschluss an den Wandel verlieren; daher ist jetzt ein ausgewogener Umgang besonders wichtig
1 Kommentare
Hacker-News-Kommentare
Ich finde es bedauerlich, dass proprietäre LLM-Modelle wie Gemini 2.5 PRO oder Claude Opus 4 zur Norm werden. Die Weiterentwicklung von LLMs und ihre Stärke als Werkzeug sehe ich sehr positiv, aber ich kann schwer nachvollziehen, warum Entwickler – egal ob prominent oder unbekannt – es offenbar akzeptabel finden, fürs Programmieren dauerhaft von kostenpflichtigen Diensten Dritter abhängig zu sein. Früher konnte man auch nur mit Open Source und kostenlosen Tools programmieren. Ich mache mir Sorgen, dass es in ein paar Jahren genauso unpraktisch sein wird, ohne ein kostenpflichtiges LLM zu arbeiten, wie heute ohne IDE oder vim zu programmieren. Auch das Argument, dass 200 Dollar im Monat doch nichts seien, löst das grundlegende Problem nicht.
Die Open-Modelle, die man derzeit lokal betreiben kann, reichen qualitativ nicht aus, und vor allem sind die Betriebskosten viel höher. Sobald sich ein Modell auf Claude-4-Niveau wirtschaftlich auf einem privaten Rechner ausführen lässt, werden es viele Leute ausprobieren. Im Moment laufen Modelle wie Kimi K2 zwar auf zwei Mac Studios mit 512 GB, aber allein die Hardware kostet rund 20.000 Dollar.
Das Abo-Modell vermittelt anfangs den Eindruck eines außergewöhnlich guten Preis-Leistungs-Verhältnisses. Mit der Zeit steigen aber die Preise, die Qualität sinkt, und am Ende ist man an den Dienst gebunden – wie in der Black-Mirror-Folge "Common People".
Ich persönlich glaube nicht, dass eine Zukunft wahrscheinlich ist, in der alle Entwickler zwangsläufig von kostenpflichtigen LLMs abhängig sind. Langfristig werden die Leute erkennen, dass schon die bloße Massenproduktion von Code ein Problem ist. Code ist technische Schuld, und wenn sich instabiler oder langsamer Code ansammelt, wächst auch diese Schuld. AI wird nicht verschwinden, aber wenn der Hype etwas abklingt, wird das Verständnis dafür wachsen, wo und wie man sie einsetzen sollte. Außerdem ist fraglich, was passiert, wenn das Investment austrocknet. OpenAI und Anthropic sind nicht profitabel und brauchen fortlaufend Kapital, um den aktuellen Zustand aufrechtzuerhalten. Falls die Evolution der LLMs ungefähr auf dem heutigen Stand stehenbleibt und das die Grenze ist, wird auch das Investment nachlassen. Dann könnten die Nutzungskosten steigen oder die Dienste ganz verschwinden.
Realistisch betrachtet ist das kein großes Problem. Wenn es keinen echten Produktivitätsgewinn gibt, gibt es keinen Grund, auf Dauer von teuren und unfreundlichen Diensten abhängig zu bleiben. Auch Open-Modelle entwickeln sich stetig weiter; wenn der Abstand zu ihnen nicht groß ist, muss man solche Dienste nicht weiter nutzen. Falls sich LLMs hingegen weiter steil verbessern, sind wir mit der bisherigen Arbeitsweise ohnehin nicht mehr konkurrenzfähig und müssen in andere Bereiche wechseln. Unterm Strich glaube ich daher nicht, dass man sich allzu viele Sorgen machen muss. Außerdem habe ich das Gefühl, dass die Bewertung der großen Modellfirmen massiv überhöht ist.
Ich möchte der Aussage widersprechen, dass man mit Open Source und kostenlosen Tools programmieren könne: JetBrains ist älter als viele der Kollegen hier, und auch MS mit Visual Basic/C++/Studio hat die Windows-Entwicklung einfacher gemacht – alles kostenpflichtig.
Ich stimme dem Ausdruck "PhD-level knowledge" nicht zu. In einem PhD-Programm geht es nicht primär darum, vorhandenes Wissen aufzunehmen, sondern zu lernen, wie man Forschung betreibt. Das ist ein Punkt, der in AI-Debatten oft missverstanden wird; deshalb wird auch die Formulierung „Wissen auf Doktoratsniveau“ unscharf.
Zusätzlich dazu, dass ein PhD ein Prozess des Forschenslernens ist, ist die Fähigkeit, Fragen zu stellen, zentral. LLMs sind eher wie „faule Arbeiter mit viel Wissen“; sie stellen sich nicht selbst Fragen und erkunden keine Hypothesen. Ein praktisches Beispiel: Ich ließ Claude Code (Max Pro) Test-Assertions auskommentieren, und dabei entstand ein Bug auf Basis einer falschen Annahme im ursprünglichen Plan. Erst als ich direkt anwies, den Plan neu zu schreiben, fand es den Grund und korrigierte ihn. Konkret lag es etwa daran, dass ein ORM-Objekt Null-Werte hatte, weil nach dem Commit kein Refresh erfolgt war, und weil etwas, das in einer anderen DB-Session geladen worden war, nach dem Ende der Session weiterverwendet wurde.
Stimme zu: Wissen auf Expertenniveau ist da, aber Dinge, die Menschen gut können, beherrschen LLMs in gleichem Maße nicht. Zum Beispiel kann ein LLM manchmal in einem Zug ein bemerkenswertes Programm von Anfang bis Ende schreiben, hat aber Schwierigkeiten mit iterativer Verbesserung.
Selbst wenn man versteht, dass ein PhD mehr ist als Wissen, ist es ein enormer Wert, leichteren Zugriff auf dieses Wissen zu haben. In einer früheren Firma stellte ich sehr spezielle Fragen, die sonst nur PhDs beantworten konnten – grob so etwas wie „Was passiert, wenn man an der Grenzfläche zweier Materialien in einer bestimmten Richtung Spannung anlegt?“ – und das LLM lieferte überraschend brauchbare Antworten.
Mit einem PhD kümmert man sich am Ende nicht stärker um das Fach selbst; entscheidend ist, dass man gelernt hat, wie man Forschung betreibt.
Ich denke, jede Diskussion über LLM-basiertes Programmieren muss zwingend das Anwendungsgebiet und die verwendete Programmiersprache nennen. Diese beiden Variablen haben weit mehr Einfluss als die konkrete Art, wie man LLMs nutzt. Wenn jemand LLM-Coding liebt oder hasst, sollte man zuerst fragen, welche Art von Problemen die Person gelöst hat, und dann selbst versuchen, genau diese Probleme mit AI zu lösen. Sonst landet man immer nur bei fruchtlosen Aussagen wie „Du hast es falsch benutzt“ oder „Ich habe es probiert, aber es taugte nichts“.
Ausgehend von meiner Erfahrung, nach einigen Monaten intensiver Arbeit mit agentic coding, kann ich allem im Beitrag zustimmen. Die modernsten LLMs sind derzeit am einfachsten sinnvoll zu nutzen, aber ich erwarte, dass Open-Modelle bald aufholen. Man kann sich von LLMs neue Methoden empfehlen lassen oder bekannte Ansätze vorschlagen lassen. Manchmal neigen LLMs dazu, Dinge unnötig zu verkomplizieren; dann muss man das früh erkennen oder Refactoring verlangen. Mit jedem neuen Modell verändert sich die Lage ohnehin wieder. Nicht für jede Aufgabe braucht man zwingend das modernste Modell. Für einfache Features oder Bugfixes ist Copilot oft schon ein ganz guter Startpunkt. Ich hoffe, alle haben Spaß daran, inmitten dieses Wandels verschiedenste Dinge auszuprobieren und dabei zu lernen.
Ich habe Claude’s GitHub Action bei etwa 10 bis 20 Issues für Implementierung und PR-Review ausprobiert und stimme zu, dass es im wahrsten Sinne Hit or Miss ist und eher als unterstützendes Werkzeug als für blinde Automatisierung taugt. Kleine Änderungen und kleinere Features oder Refactorings mit guten Tests funktionieren fast automatisch erfolgreich. Wenn ich es als Action laufen lasse, kann ich mich in der Zeit um andere Dinge kümmern – das ist ein klarer Vorteil, und noch bequemer wird es, wenn Claude auch gleich die Issues schreibt. Aber ab mittlerer Größe entstehen oft Ergebnisse, die plausibel aussehen, in Wirklichkeit aber nicht funktionieren. Das mag teilweise meine Schuld wegen unzureichender Testabdeckung sein, aber es passiert definitiv häufig. Auch wenn ich Issues detaillierter schreibe oder verschiedene Prompts ausprobiere, sind die Resultate enttäuschend. Bei großen Aufgaben ist es ganz klar schwierig. Die PR-Review-Funktion ist für kleine bis mittlere Aufgaben brauchbar, produziert aber auch viele nutzlose Rückmeldungen. Insgesamt glaube ich, dass LLMs noch weit davon entfernt sind, selbstständig zu programmieren. Am effizientesten ist es für kleine Aufgaben, nur das Issue schreiben zu lassen und zu warten, bis der PR kommt. Bei den meisten Aufgaben mittlerer Größe muss ich Claude hauptsächlich Richtung geben und muss fast nicht mehr selbst coden; dadurch steigt meine Produktivität eindeutig. Gemini habe ich auch ausprobiert, aber wenn man es einfach machen lässt, gerät der Code auf unvorhersehbare Weise ins Schlingern. Intern nutzen wir Copilot ebenfalls für PR-Reviews, aber der Effekt ist gering. Bei sehr großen Codebasen könnte Gemini vielleicht nützlicher sein.
Im Unterschied zum OP habe ich mich einen Monat lang intensiv in dieses Gebiet eingegraben, und dabei zeigten Gemini 2.5 PRO und Opus 4 bessere Ergebnisse bei abstrakten Diskussionen wie Architekturfragen. Die eigentliche Implementierung einzelner Codeabschnitte dann an Sonnet zu übergeben, war effizienter. 2.5 PRO und Opus kreisen oft um die richtige Antwort herum und korrigieren sich wiederholt selbst, während Sonnet direkter zum Ergebnis kommt – dafür aber ausreichend detaillierte Anweisungen braucht.
Das klingt absolut plausibel. Tatsächlich sind Sonnet/Opus 4 in den besten Fällen zwar leistungsfähiger, aber in mancher Hinsicht bei Konsistenz oder Alignment manchen Versionen von Sonnet 3.5v2 (auch 3.6 genannt) oder sogar 3.7 unterlegen. Außerdem sind Modelle komplexe Objekte, sodass je nach Domäne ein „schwächer“ wirkendes Modell besser funktionieren kann. Und interaktive Umgebungen und agentenorientierte Umgebungen verwenden unterschiedliche Reinforcement-Learning-Methoden, sodass sich die Modellleistung je nach Nutzungsweise verändert.
Auch interne Statistikdaten bestätigen, dass Opus und Gemini 2.5 Pro in realistischen Umgebungen schlechter abschneiden als Sonnet 4 verwandter Statistik-Link
Ich habe sehr ähnliche Erfahrungen gemacht: Gemini 2.5 Pro nutze ich in AI Studio, um große Designideen zu überprüfen und zu verfeinern, und wenn ich die Anforderungen dann in Claude Code übernehme, codet es meist sauber. Kürzlich habe ich auch Gemini CLI ausprobiert, aber gegenüber Claude Code ist die Coding-Fähigkeit deutlich schwächer. Es produziert viele Syntaxfehler, kommt aus Schleifen nicht heraus, und die Ergebnisse sind so ausschweifend und schnell, dass man kaum folgen kann. Claude Code dagegen ist auch beim Debugging hervorragend. Für Probleme auf der „Big Picture“-Ebene ist DeepSeek R1 ebenfalls einen Versuch wert – sehr langsam, aber mit hoher Trefferquote.
Ein realistisches Beispiel dafür, dass AI/LLMs mitunter extrem ineffizienten Code schreiben, wird hier geteilt verwandter Blog-Link
Ich habe die Erfahrung gemacht, dass der Code deutlich besser wird, wenn man das LLM zunächst nur bittet, die gewünschte Aufgabe zu erklären, und dann mit eigenem Feedback einige Iterationen durchläuft. Es ist effektiv, zuerst den detaillierten Plan bestätigen zu lassen und erst danach weiterzumachen.
Meiner Erfahrung nach kann man im Frontend repetitive, einfache und leicht validierbare Aufgaben ruhig dem vibe coding überlassen. Im Alltag nutze ich LLMs aber eher als Sparringspartner, der meinen Code reviewt und verschiedene Alternativen bewertet. Selbst wenn Vorschläge unsinnig sind oder logische Schwächen haben, hilft mir das, keine offensichtlichen Dinge zu übersehen. Außerdem korrigiert es meine Tendenz, bei komplex verschachtelten Problemen zu schnell zu viel ausprobieren zu wollen.
Ich verstehe nicht genau, was der OP mit seiner Arbeitsweise meint. Soll man etwa Redis-C-Dateien manuell in das Web-Chatfenster von Gemini Pro einfügen?