Warum Coding trotz LLMs nicht gelöst ist
Coding Is Not Solved – Alex Ewerlöf Notes
Alex Ewerlöf argumentiert, dass die Behauptung, Coding sei gelöst, auf einem Missverständnis von Softwareentwicklung beruht. Er zeigt, dass LLMs zwar Code generieren können, aber bei Logik und großen Kontexten scheitern. Die eigentlichen Kosten entstehen durch Wartung, Zuverlässigkeit und Sicherheit – nicht durch die Erstellung. Besonders in sicherheitskritischen Bereichen wie Gesundheitswesen oder Finanzen ist Verantwortlichkeit entscheidend, die AI nicht übernehmen kann.
Menschen, die behaupten, „LLMs können anständigen Code schreiben“, verstehen nicht, wie Code funktioniert.
- efficax
Den Code zu lesen bedeutet nicht, den Code zu verstehen. Eine Lektion, die mir die Erfahrung in der Softwareentwicklung erteilt hat: Ich habe den Code nie verstanden. Man denkt, er funktioniert auf eine bestimmte Weise, bis man herausfindet, dass er es nicht tut.
Was LLMs möglich machen, ist, dass ich sagen kann: Finde alle Arten heraus, wie dieses Ding funktioniert. Analysiere die verschiedenen Weisen, wie wir diese Software ausführen können, baue einen Fuzzer, baue Property-Tests und führe diese Software in jedem möglichen Szenario aus. Protokolliere vollständige Traces. Protokolliere alle Ausgaben. Analysiere nun jedes Szenario auf Bugs. Das kann man nicht von Hand machen.
Wenn wir uns darauf einlassen, wenn wir Ressourcen dafür bereitstellen und die Zeit dafür aufwenden (und wir könnten das einfach tun, indem wir sagen: Es wird halb so lange dauern wie früher!), dann kann Software, die von LLMs in den Bereichen Gesundheitswesen, Finanzen, Automobil, Verteidigung, Kraftwerke, Luftfahrt und Fertigung gebaut wird, mit LLMs ZUVERLÄSSIGER und besser gemacht werden ... ohne jemals eine einzige Zeile Code zu lesen. Die LLMs sind übrigens sehr gut in Logik.
Wie auch immer, das alles liest sich wie von jemandem, der LLMs nicht tatsächlich zum Bauen von Software einsetzt oder sie eine Weile nicht ausprobiert hat. Ich fühlte 2025 genauso. Ich habe Hunderttausende Zeilen schwierigen Code geschrieben. Du, die Person, die das hier liest, hast wahrscheinlich mit Software interagiert, die ich geschrieben habe. Eine Zeit lang hättest du bei jeder Debitkartentransaktion in den Vereinigten Staaten damit interagiert, zum Beispiel. Ich verstehe Code und lege Wert auf Qualität, und deshalb bin ich bei LLMs für Code voll dabei.
- askonomm
Was ich festgestellt habe, ist, dass KI es faulen und inkompetenten Entwicklern ermöglicht, noch fauler und noch inkompetenter zu sein. Das hat dann zur Folge, dass die Produktqualität schneller leidet. Aufgrund der schieren Menge an Code, die jetzt herausgehauen wird, ist Code-Review, eine Sache, die früher einigermaßen verhindert hat, dass faule und inkompetente Entwickler schrecklichen Code abliefern, praktisch tot, da kein Mensch solche Mengen an Code realistisch noch überprüfen kann. Manche Unternehmen setzen KI ein, um Code zu überprüfen, was, nun ja ... du lässt KI Code machen, KI Code überprüfen ... Ich hoffe, du erkennst die Dummheit hier, wenn du überhaupt deterministische Ergebnisse erwartest.
Ich schätze, die Zeit wird zeigen, ob sich der Verbraucher an die niedrigere Produktqualität anpasst, sodass Unternehmen die Existenz fauler und inkompetenter Entwickler rechtfertigen können, oder ob der Verbraucher zurückschlägt und Unternehmen gezwungen sind, die Qualität ihrer Entwickler zu erhöhen.
Anmerkung: Ich nutze KI jeden Tag, und es ist durchaus möglich, damit hochwertige Software zu erstellen, solange man nicht faul und inkompetent ist.
- temp00345
Ich lese solche Artikel mehr oder weniger jeden Tag.
Dieser Artikel wäre vor 1 Jahr zu 100 % korrekt gewesen, vor 9 Monaten zu 75 %, vor 3 Monaten zu 50 %, und jetzt ist er wahrscheinlich zu 25 % korrekt, wenn nicht weniger.
Ich verstehe total, woher das kommt. Auch ich tue mich schwer damit zu akzeptieren, dass meine über 30 Jahre Programmiererfahrung schnell obsolet werden. Ich verliere deswegen Schlaf, es ist hart.
Aber gib den neuesten Modellen (Opus 5.5 / Astra 6, Stand heute) einfach noch eine Chance.
Schau, wozu sie fähig sind, und lies den Code, den sie produzieren.
Irgendein Problembereich, Low-Level-C++ oder High-Level-TypeScript oder Clojure oder eine seltsame Kombination davon ...
Sei nicht schüchtern, gib ihnen eine große Aufgabe, lass sie eine ganze App bauen, UI und alles ...
Vergleiche nun die Ausgabe mit Opus 4 oder gpt-5 von vor 1 Jahr – als sie nicht mal eine einzelne Funktion zusammenbekamen, ohne dass sie seltsam und fehlerhaft war.
Genau das ist mein Problem, nicht dass die Modelle schon sehr gut sind, sondern wie schnell sie so gut geworden sind.
Wenn Coding also noch nicht gelöst ist, wird es sehr bald so weit sein.
- thesumofall
Ich glaube, der Autor unterschätzt, wie langweilig und einfach 90 % der Unternehmenssoftware sind. Der Teil, der keine Flugzeuge und Kraftwerke antreibt. So viel davon stammt aus One-Nightern, schlecht gemanagten Subunternehmern und Anforderungen, die von Anfang an von schlechter Qualität sind (weil sie von Leuten geschrieben werden, die ganz andere Tagesjobs haben). Und weißt du was? Das meiste davon läuft 24/7 ohne einen Fehler. LLMs geben uns einfach mehr davon. Und vielleicht ist es sogar besser
- brainless
Ich programmiere seit etwa 30 Jahren (einschließlich Schulzeit). Beruflich seit 18 Jahren.
Kann mir jemand sagen, warum wir 40 oder mehr Programmiersprachen haben, mit etwa 10 populären? Dann etwa 20 Frameworks in jeder davon. Und füge nochmal 200 populäre Bibliotheken für jede Sprache hinzu? Diese Matrix ergibt keinen Sinn, bis man erkennt – es sind Vorlieben bis zum Schluss.
Die meisten von uns Ingenieuren haben ihr eigenes mentales Modell vom Programmieren gebaut. Wir haben alle recht. Aber die Nutzer interessiert das nicht. LLMs sind da, um Code nach Bedarf immer näher an die Hardware zu bringen. Sie können sich hinsetzen und aus jeder Spezifikation einen Graphen erstellen, einen AST verwenden, den sie entwickeln, und ihn auf der CPU ausführen, wenn es sein muss. Sie werden es tun. Keine Menge unserer Diskussionen wird das aufhalten.
Programmierung wird neu erfunden werden. Ich glaube nicht, dass die aktuellen Arten, Software zu schreiben, überhaupt noch eine Rolle spielen werden.
- hibikir
> Du kannst auch nicht für das verantwortlich sein, was du nicht kontrollieren kannst. Dieses Verständnis ist der Schlüssel, um über Systemverhalten zu räsonieren und es zu beheben, wenn die KI unweigerlich versagt.
Das ist keine gute Prämisse. Überall im Recht findest du Menschen, die für das verantwortlich gemacht werden, was sie nicht kontrollieren und irgendwie besitzen. Lass einen Hund los, der ein Kind verletzt, oder halte ihn einfach in einer Umgebung, aus der er entkommen kann, und schau, was passiert.
Es gibt so etwas wie unvorhersehbare Situationen, in denen man möglicherweise nicht verantwortlich gemacht wird, da ein Problem weit jenseits vernünftiger Richtlinien auftreten könnte.
Also kann man natürlich für das haftbar gemacht werden, was eine KI tut, die man angeblich nicht ganz kontrollieren kann, oder für den KI-geschriebenen Code, den man ausliefert. Behandle es wie das Freilassen eines Wolfsrudels oder den Verkauf eines unsicheren Spielzeugs, das Kinder verstümmeln kann. Es gibt überall Präzedenzfälle.
- thefilmore
Von den Autoren von „Coding is solved“: Heute stieß ein Kollege, der Claude Code ausführen wollte, auf ein Problem, bei dem es stattdessen das Bun-Hilfemenü anzeigt [1]. Zuvor hat sich Claude Code mehrmals selbst deinstalliert, als ich es benutzte. [2]
- hakunin
Diejenigen, die behaupten, LLM-generierte Software sei gut genug:
Haben seit Ewigkeiten keinen Code mehr geschrieben
Können nicht erkennen, ob ihr Code im übertragenen Sinne 6 Finger hätte!
Haben eine niedrige Messlatte dafür, was gut aussieht
Kümmern sich nicht um Qualität oder NFRs
Haben Schwierigkeiten, eine S-Kurve zu verstehen
Es gibt Ausnahmen wie antirez, aber ich denke, das gilt für viele laute Optimisten da draußen.
- lordnacho
Meine Gedanken dazu:
- Coding im Kleinen ist gelöst. Ich habe einen aktuellen Zustand, ich möchte ihn ändern, und ich weiß, wie ich ihn ändern möchte. Z. B. ich habe aus irgendeinem Grund einen blockierenden TCP-Handler, und ich möchte ihn asynchron machen. Ich kann entweder daran herumbasteln oder einfach das LLM die Änderungen für mich machen lassen.
- Coding im größeren Sinne ist niemals gelöst. Man braucht Urteilsvermögen, um zu entscheiden, was man herstellen möchte. Egal, was man baut, es gibt Entscheidungen zu treffen (Für wen/was ist es?) und diese Entscheidungen ändern sich mit der Zeit. LLMs können einige Standardentscheidungen für dich treffen, und wenn du damit zufrieden bist, bekommst du den Standard (großartig für POCs). Allerdings merkst du vielleicht nicht einmal, was es für dich entschieden hat. Ab einer gewissen Größenordnung wirst du viel Zeit damit verbringen, diese Entscheidungen durchzugehen. Aber was wir jetzt haben, ist, dass die Reibung beim Ändern der Entscheidungen deutlich geringer ist. Man kann jetzt viele Dinge testen, die früher sehr zeitaufwendig waren.
- Der Punkt, dass LLMs probabilistisch sind, ist nicht so wichtig, wie er dargestellt wird. Wenn ich einen Junior-Entwickler bitte, etwas zu programmieren, weiß ich auch nicht, was er machen wird. Zum Teufel, du kannst sicher sein, dass du etwas lösen kannst, und doch weißt du selbst nicht, wie die Lösung aussehen wird. Vielleicht stellt sich heraus, dass die Bibliothek, die du verwenden wolltest, doch nicht geeignet ist. Du weißt nicht, was du am Ende verwenden wirst, aber du weißt, dass etwas das Problem lösen wird. Es kann mehr als eine Lösung für ein Problem geben, und es ist nicht immer wichtig, welche man findet.
- Ich tue STILL […]
- josephmtummon
Beim Lesen des Artikels stimmte ich dem Autor definitiv zu, aber ich ertappte mich auch dabei, den Gegenargumenten in den Kommentaren zuzustimmen.
Was ich persönlich an KI-Coding-Praktiken widersprüchlich finde, ist, dass ich völlig zustimme, dass KI unglaublich beeindruckend darin ist, selbst komplizierte Aufgaben zu erledigen, und ich kann zumindest sagen, dass sie viel, viel besser darin ist, Code zu schreiben, als ich es bin.
Mein Problem damit ist, dass sie dir jedes Mal eine „faule“ Option bietet, die nicht dasselbe Maß an Denken erfordert. Ich verstehe, dass das völlig an mir als Entwickler liegt, und die einfache Lösung ist, dass ich sicherstellen muss, dass ich mir Zeit nehme, zu lernen und zu verstehen, was genau das LLM produziert. Ich versuche das und habe separate Skills eingerichtet, um sicherzustellen, dass ich mein Verständnis unterwegs aufbaue.
Unabhängig davon, wenn ich mich heute hinsetze und etwas ohne LLM implementiere, dauert es viel länger, aber sobald ich drin bin, finde ich einen Flow-Zustand, den ich beim Hin und Her des Lesens von LLM-Ausgaben nie bekomme. Wenn ich dann fertig bin, habe ich, auch wenn meine Lösung nicht perfekt ist, so viel mehr gelernt und mein eigener Kontext zum Problem ist so viel besser, sodass ich dann meist mit einem LLM reviewen kann. Das hinterlässt normalerweise eine bessere Implementierung und, was wichtiger ist, eine, hinter der ich stehen kann.
Ich denke, für einen neueren Entwickler wie mich (~2 Jahre Erfahrung), da ich nicht jahrelange Problemlösungserfahrung aufgebaut habe, wenn ich mir nicht täglich Zeit freischaufle, die KI-Tools wegzulegen und meine Problemlösung zu verbessern, werde ich […]