AI-Coding
(geohot.github.io)- KI fürs Programmieren hat eine ähnliche Rollenstruktur wie bestehende Compiler
- Englische Prompts sind als Programmiersprache unpräzise und ineffizient
- Der Produktivitätsgewinn durch KI wird in der Praxis tendenziell übertrieben oder falsch wahrgenommen
- KI-Tools verändern den Entwicklungsprozess, aber die wirkliche Innovation könnte aus besseren Sprachen und Tools entstehen
- Die Einführung von LLMs bedeutet keinen Ersatz für Entwickler, sondern spiegelt eher die Grenzen der heutigen Entwicklungsumgebung wider
Ähnlichkeiten zwischen KI und Compilern
- Der Autor habe mit zunehmendem Alter aufgegeben, andere überzeugen zu wollen
- Es wird betont, dass viele Menschen sich nicht für die Wahrheit interessieren, sondern nur Überzeugungen folgen, die ihnen nützen
- Es wird Kritik an jenen geäußert, die behaupten: „Perception is reality“
- Es wird darauf hingewiesen, dass die in autonomes Fahren investierten Milliarden Dollar durch falsche Überzeugungen verschwendet wurden
- Die Vorstellung, dass KI Code schreiben könne, sei ähnlich wie die Sichtweise, Compiler würden programmieren
KI-Coding als compilerähnliches Modell
- Es wird erklärt, dass das optimale Modell für Programmier-KI der Compiler sei
- Nutzer geben einen Prompt (Code) ein und erhalten als Ergebnis eine kompilierte Ausgabe
- Der Unterschied liegt darin, dass der Prompt auf Englisch eingegeben wird, doch Englisch hat viele Nachteile wie mangelnde Klarheit und fehlende Spezifikation
- Bei neuen oder komplexen Aufgaben nimmt am Ende die Ausführlichkeit des Prompts zu
- Die Ausgabe der KI ist nicht deterministisch, und Änderungen an einem Teil des Prompts können das Gesamtergebnis beeinflussen
Kritische Sicht auf KI-Coding
- Dass KI-Coding positiv erscheint, liege an der Schwäche heutiger Tools, Sprachen und Bibliotheken
- Durch „KI“-Technologien seien bessere Suche, Optimierung und Werkzeuge zur Mustererkennung möglich geworden
- Tatsächlich programmiert weiterhin der Entwickler selbst; nur die Sprache, in der Code geschrieben wird, habe sich geändert
- Wenn ein Unternehmen LLMs einsetzen kann, um Entwickler zu ersetzen, bedeutet das, dass Codebasis und Einstellungsstandards des Unternehmens sehr niedrig sind
- KI kann wie Compiler oder Tabellenkalkulationen schrittweise einen Teil der Arbeit übernehmen
KI ist ein Werkzeug, langfristig braucht es bessere Sprachen und Bibliotheken
- Es wird betont, dass eine instrumentelle Sichtweise auf KI viel Nachdenken und Vorsicht erfordert
- Durch Investitionen in falsche Erwartungen oder Illusionen werden Milliarden Dollar verschwendet
- Erwähnt wird die Überreaktion des Marktes auf falsche Produktivitäts-Tools wie „vibe coding“
- Es gebe die Illusion, KI erhöhe die Produktivität tatsächlich um 20 %, doch es wird eine Studie (Paper) zitiert, nach der sie in Wirklichkeit um 19 % verlangsamt
- Echte Fortschritte könnten aus Innovationen bei Programmiersprachen, Compilern und Bibliotheken entstehen
1 Kommentare
Hacker-News-Kommentare
Ich bin fast 50 und schreibe seit Ende der 90er beruflich Code. Ich habe Projekte sofort im Kopf und weiß genau, was ich bauen will. Ich verdiene auch ziemlich gut. Oberflächlich betrachtet wirke ich wohl wie der typische AI-Skeptiker, aber das bin ich nicht. Ich kann zwar alles bauen, aber die ganzen Basisarbeiten öden mich oft an. Deshalb gefällt mir an AI wirklich, dass ich die langweiligen Teile schnell hinter mich bringen und mich auf die Kernarbeit konzentrieren kann, die mir Spaß macht. AI-Entwicklung ist ein bisschen so, als würde man einem Entwickler irgendwo zwischen Junior- und Mid-Level mit ein paar Sätzen die Idee erklären und ihn dann eine Stunde Arbeit erledigen lassen. Dass echte Juniors dadurch womöglich nicht mehr wachsen können und der zukünftige Pool an Senior-Entwicklern schrumpft, ist allerdings ein ernstes Problem — aber das ist eine separate Frage
Ich habe gesagt, dass ich mit AI die langweiligen Teile im Schnellverfahren erledige, aber unter erfahrenen Senior-Entwicklern gibt es auch Leute, die AI eher ablehnen, weil sie die harten Teile fürchten. Viele Entwickler finden psychologische Sicherheit gerade in den langweiligen und einfachen Abschnitten; mit AI kann die Arbeit dagegen zu einer ununterbrochenen Abfolge schwieriger Aufgaben werden. Wer zwar viele Jahre Erfahrung, aber wenig tatsächliches Können hat, brennt schnell aus, wenn er nur noch ein anspruchsvolles Thema nach dem anderen bekommt. Unternehmen führen AI ein und wollen vor allem alles beschleunigen, übersehen dabei aber, dass Menschen kognitive Erholungsphasen brauchen. Wenn nur noch anstrengende Arbeit übrig bleibt, ist das nicht gut für Menschen. Entwickler hingegen, die repetitive und einfache Aufgaben satt haben, können mit AI regelrecht wiederbelebt werden. Letztlich braucht es einen individuellen Ansatz
Ich bin auch etwas jünger als du, denke aber fast genau gleich — vielleicht sogar noch stärker. Mir macht es inzwischen weniger Spaß, Code zur Umsetzung interessanter Ideen zu schreiben, als Ideen zu entwickeln und zu experimentieren. Deshalb war Programmieren für mich eher etwas, das ich tun musste, nicht das, was ich im Kern tun wollte. Wenn ich meine Ideen umsetzen wollte, musste ich eben Code schreiben. AI ist als Brainstorming-Partner hervorragend. Wenn man sie bittet, nicht zu schmeicheln, weist sie einen sehr ehrlich darauf hin, wenn man overengineert. Auch beim Debugging ist sie wirklich gut. Ich erkläre also dem Computer in Sprache die Architektur und die Vorgehensweise, mache Brainstorming, erstelle eine Spezifikation und lasse dann die AI implementieren. Wenn mein Denken falsch war, iteriere ich mit der AI einfach schnell weiter. Die Iterationen sind so schnell, dass Fehler kaum noch schlimm sind. Bei falschen Designs habe ich früher oft einfach damit gelebt, weil ein Umbau der gesamten Codebasis zu aufwendig gewesen wäre, aber dank Agentic-Coding-Tools sind selbst Änderungen an der ganzen Codebasis kein Problem mehr. Auch in neue technische Bereiche, in denen ich kein Experte war, konnte ich dank AI effektiv einsteigen und schnell Kompetenz aufbauen. Ehrlich gesagt bin ich gerade so glücklich wie nie zuvor in meinem Leben als Programmierer. Die Tools werden jede Woche besser, manchmal sogar mehrmals pro Woche
Das deckt sich vollständig mit meiner Erfahrung. Ich habe eine ähnliche Berufserfahrung. Ich nutze AI sowohl für private Projekte als auch bei der Arbeit sehr aktiv. Erstens dient AI als deutlich unvoreingenommenerer Sparringspartner für Ideen. Die schnellen Feedback-Schleifen und die Validierung des eingeschlagenen Wegs fühlen sich wirklich essenziell an. Zweitens spart sie Tipparbeit und Zeit. Die „Basisarbeit“ erledigt sie in einem Rutsch zu mindestens 80 % perfekt. Es ist keine 100-%-Fertigstellung, aber die eingesparte Zeit ist viel größer, also ist es absolut ein Gewinn. Ich habe mir angewöhnt, beim Einsatz von AI immer Guardrails zu setzen, Anweisungen möglichst konkret und detailliert zu formulieren und die Ergebnisse immer selbst zu prüfen
Ich habe etwa zehn Jahre weniger Erfahrung, stehe aber ähnlich da. Trotzdem kann ich das nicht gut nachvollziehen. Sobald ein Teil langweilig zu werden droht, wird das Automatisieren oder Generalisieren selbst so schwierig und herausfordernd, dass es in der Praxis fast nie wirklich langweilige Arbeit gibt. Oft bin ich mit dem eigenen Tippen sogar schneller. Gerade in den nicht trivialen Teilen kommen mir beim direkten Schreiben des Codes bessere Strukturen oder Automatisierungsideen. Deshalb gibt es kaum Code, den ich wirklich abgeben möchte. Und ich glaube, dass ich nur deshalb so denke, weil ich lange in derselben Firma war. Wenn ich ständig neue Codearbeit machen müsste, würde ich vielleicht anders denken
Ich bin auch in meinen 50ern, code seit den 90ern und habe genug Geld verdient, um mehr als dreimal davon leben zu können. In 30 Jahren Berufserfahrung hatten die besten Entwickler immer eine gemeinsame Eigenschaft: „perfekte Faulheit“. Das klingt vielleicht seltsam, aber das Einzige, was die wirklich großartigen Engineers gemeinsam hatten, war Faulheit. Es ist fast erstaunlich, wie direkt Faulheit in Produktivität umschlägt. Der Grund ist, dass sie jede wiederholte Arbeit konsequent automatisieren. Ich habe die eiserne Regel gelernt: Wenn man etwas zweimal macht, braucht man beim dritten Mal zwingend Automatisierung. Mit dem Aufkommen von AI hat sich das Niveau der Automatisierung völlig verändert. Jetzt lässt sich sogar Arbeit automatisieren, die früher unmöglich war. Ich entdecke ständig neue Einsatzmöglichkeiten für AI, und nicht nur ich, auch meine faulen Kollegen nutzen sie unglaublich gut. Inzwischen kann ich mir Arbeit ohne AI gar nicht mehr vorstellen. Nicht weil sie „Magie“ wäre, sondern weil sie als fauler Mensch wie ich alle Aufgaben übernimmt, die sich irgendwie automatisieren lassen
Ich halte das für ein extremes Beispiel des AI-bezogenen Gruppendenkens, das man auf Hacker News oft sieht. Geohot gehört vielleicht zu den besten 0,001 % der Entwickler, aber die 99,999 % der Entwickler, die er nicht versteht, machen weiterhin viel grundlegendere Arbeit. Das ist das Expertenparadox. Wenn alle auf Expertenniveau wären, wären sie keine Experten. Ich habe viele Entwickler gesehen, die sich wie AI verhalten. Sie können nicht einmal ihre eigene Codebasis erklären oder konsistent pflegen. Das ist ungefähr so, als würde ein Luft- und Raumfahrtingenieur jemanden auslachen, der Überraschungsspielzeug für Kinder herstellt, weil er nichts über Strömungssimulation weiß
Es überrascht mich, dass du HN für AI-negativ hältst. Wenn ich mir Kommentare und populäre Beiträge anschaue, wirkt HN auf mich insgesamt sehr technologieoptimistisch
Es wirkt auch ziemlich inkonsistent, dass jemand, der ein Unternehmen für autonomes Fahren gegründet hat, so eine Position vertritt. Wenn AI-Modelle angeblich keinen Code schreiben können, wie sollen sie dann Autofahren ersetzen — eine noch viel schwierigere Aufgabe?
Genau dieser Punkt wird am Anfang des Artikels bereits erklärt. Die Aussage ist, dass vieles nur deshalb funktioniert, weil allgemeine Programmier-Workflows so verbreitet sind; wenn man etwas wirklich Neues machen will, muss man es auf einem Detaillierungsgrad beschreiben, der fast dem einer Programmiersprache entspricht
Ich arbeite in der Luft- und Raumfahrt, und die Engineers hier sind auch nicht unbedingt besser. Man muss sich darüber aber nicht zu viele Sorgen machen. In Unternehmen werden solche Leute auf Positionen versetzt, auf denen sie keinen Schaden anrichten, und meistens landen sie im Management
Ich weiß nicht, ob Geohot wirklich zu den besten 0,001 % der Entwickler gehört. „Das optimale Modell für Programming AI ist der Compiler. Man gibt einen Prompt (= Code) hinein, und er gibt kompilierten Code aus. Statt wie in den meisten IDEs mit Feedback und Interaktivität zu arbeiten, ist Prompt-Anpassung → Neukompilierung besser.“ Ich bezweifle, dass das wirklich stimmt
Einer der Kernpunkte der Debatte ist, dass man die „Art des Programmierens“ etwas genauer definieren muss. So wie es wenig sinnvoll ist, bei Robotern einfach nur zu fragen „Sind Roboter gut oder schlecht beim Bauen von Dingen?“, kommt man auch hier nur weiter, wenn man zuerst fragt: „Wofür genau?“
Ich sehe mehrere Probleme mit diesem Beitrag. Erstens die Behauptung „AI-Coding ist ein Compiler“. Ein Compiler transformiert eine Sprache deterministisch gemäß einer Spezifikation, während LLM-Coding-Tools unter Constraints (Tests/Typen/Linter/CI usw.) iterativ Code suchen, erzeugen und verändern — also eher Programmsynthesizer sind. In der Praxis lösen sie sogar große Open-Source-Issues wie bei SWE-bench Verified end-to-end. Zweitens die Behauptung „Programmiersprachen sind Englisch“. In Wirklichkeit besteht die Arbeit aus Code, Tests, Spezifikationen, APIs, JSON-Schemata, Diffs, IDE-Tools usw.; Englisch ist nur der Klebstoff dazwischen. Der Autor greift sich gezielt die schwächste Schnittstelle heraus und attackiert genau diese. Drittens die Behauptung, Nichtdeterminismus sei das Problem. In der Realität gibt es viele probabilistische Elemente wie Fuzzing oder SAT/SMT, aber die endgültige Determiniertheit und Korrektheit kommen aus externen Spezifikationen wie Tests, Typsystemen oder CI. Und die Vorstellung, LLMs seien nur deshalb populär, weil Sprachen oder Bibliotheken schlecht seien, ist eine falsche Dichotomie. Selbst wenn Sprachen wie Rust oder TypeScript besser werden, helfen LLMs weiterhin bei API-Suche, Repo-Tracing, repetitivem Code, Migrationen, Testschreiben und Refactoring. Schließlich wird als Alternative nur vorgeschlagen, „bessere Sprachen oder Compiler zu bauen“, obwohl moderne Teams bereits großen Nutzen aus der Kombination mit AI ziehen. Deshalb ist es viel realistischer, AI-Coding und LLMs nicht als „magischen englischen Compiler, den man per Prompt steuert“ zu behandeln, sondern als eine Art „Junior-Pair-Programmierer“, der anhand meiner eigenen Constraints (Typen, Tests, CI usw.) unterstützt
(Autor selbst) Dem stimme ich zu. Wenn ich den Blogpost so geschrieben hätte, wäre er vermutlich nicht populär geworden. Die Beschreibung „LLM-Coding-Tools sind suchbasierte Programmsynthesizer“ kommt meiner Ansicht nach der Definition eines Compilers tatsächlich ziemlich nahe. Dass die meisten Compiler nicht genug suchen und stattdessen stark auf Heuristiken setzen, liegt aus meiner Sicht nur daran, dass ihnen die Laufzeitintegration fehlt. Es stimmt, dass es in Engineering-Tools viele nichtdeterministische Komponenten gibt, aber bei einem SAT-Solver ändert eingeführte Zufälligkeit zum Beispiel nur die Laufzeit bis zur Lösung, nicht die Korrektheit des Ergebnisses. Ein Fuzzer dient dem Testen und erwartet seinem Wesen nach keine Perfektion. Ich habe noch nie einen Fuzzer gesehen, der direkt in Produktion eingesetzt wurde. Der Aussage „Determinismus kommt aus externen Tests oder Spezifikationen“ stimme ich vollständig zu. Mein Traum ist eine Sprache, in der man nicht den Implementierungsweg, sondern nur das Verhalten als Spezifikation beschreibt. So etwas wie eine Verallgemeinerung des Schedule-Konzepts von Halide. Der Computer findet dann selbst die Implementierung. Ich glaube, dass AI solche Werkzeuge liefern kann. Das muss nicht zwingend ein LLM sein, aber eine strenge Spezifikation ist auf jeden Fall nötig. Das ist letztlich selbst wieder Programmierung. Aus dieser Perspektive lehne ich es ab, AI als „magischen englischen Compiler“ zu sehen. Wenn man die Stärken und Grenzen des Tools kennt und es als Arbeitsunterstützung einsetzt, ist das ein wirklich guter Workflow
Ausgezeichnete Antwort. Stimme voll zu
Dass so ein fehlerhafter Beitrag geschrieben wurde, überrascht nicht. Der Autor ist George Hotz, also Geohot
Ich nutze sowohl Openpilot als auch claude code häufig. Ich betrachte beide fast auf derselben Ebene. Openpilot fährt in einfachen Situationen wie auf Autobahnen über Stunden wirklich gut. claude code erledigt intuitive Refactors, Boilerplate, Scaffolding, Git-Bisects und andere repetitive Aufgaben sogar ohne weitere Eingaben von mir. Aber keines von beiden ersetzt am Ende den „Fahrer“. claude code ist so etwas wie Level-2-autonomes Fahren für das Programmieren
Die METR-Studie wurde wegen ihres Titels extrem populär. Vermutlich haben nur wenige sie wirklich komplett gelesen — sie war ziemlich lang. In den Daten zeigt sich aber, dass nur bei einer einzigen Person mit sehr viel Cursor- oder AI-Erfahrung eine Geschwindigkeitssteigerung von 50 % beobachtet wurde. Das deutet darauf hin, dass die Ergebnisse erst deutlich werden, wenn man sich eingearbeitet hat. Gleichzeitig sind die statistischen Schwankungen bei so kleinen Stichproben groß. Später wurde zudem korrigiert, dass der Geschwindigkeitsunterschied bei einer anderen Person falsch erfasst worden war, was den Aussagewert der Resultate zusätzlich fragwürdig erscheinen lässt. Die in der Studie gemessenen Ineffizienzen könnten durch bessere LLMs, parallele Agenten und ähnliche Weiterentwicklungen durchaus behoben werden. Verwendet wurde damals noch Technik aus der Ära von Claude 3.7, also vor Claude Code. Und selbst das subjektive Gefühl, 20 % weniger gearbeitet zu haben, ist ein echter Wert. Wenn Arbeit Spaß macht, vergeht die Zeit schnell
Das Problem ist auch, dass AI-Labs AI bisher viel zu stark überverkauft haben. Überall hieß es: „AI denkt wirklich, sie macht nicht bloß Pattern Matching.“ Ich baue und nutze AI-Tools selbst, und aus meiner Sicht ist es viel nützlicher, sie einfach als pattern-matching-basierten „Nächster-Token-Vorhersager“ zu behandeln. Wenn man zu viele unnötige Informationen in den Kontext kippt, scheitert die AI oft an der Verallgemeinerung. Das entspricht letztlich genau Pattern Matching und Nächster-Token-Vorhersage. Ich denke durchaus, dass „AI-Technologie heute zu sehr guten Tools beitragen kann“, aber das ist ein Ergebnis massiver Suche/Optimierung und der Wiederverwendung vorhandener Muster. Wenn ich Claude code zum Beispiel bitte, eine einfache CRUD-API zu schreiben, kommt sie in einer Minute zurück und spart mir eine Stunde Zeit. Wenn ich nach einem Algorithmus frage, der schon hunderttausendfach implementiert wurde, liefert sie schnell korrekten Code. Wenn man AI innerhalb des eigenen Fachgebiets einsetzt, funktioniert sie wirklich gut. Außerhalb davon sind die Ergebnisse eher mäßig
Das ist eine Frage von Abstufungen der Intelligenz. Es geht nicht um Wissen, sondern um fundamentale Unterschiede im Denkvermögen. Wir unterschätzen oft, wie viel kognitive Anstrengung bestimmte Aufgaben wirklich kosten. Aber manchmal zeigt AI auch Verhalten, das deutlich „nachdenklicher“ wirkt, als man erwartet hätte. Dann fühlt es sich tatsächlich wie Magie an
CRUD oder Boilerplate lassen sich zum Teil auch mit klassischen Tools lösen. Aber es gibt viele Dinge, die nur mit AI möglich sind. Wenn ich zum Beispiel Trace-Level-Logs im Rahmen eines Tests analysieren muss, kostet es enorm viel Zeit, Hunderte Zeilen selbst durchzugehen. Wenn ich stattdessen der AI sage: „Führe den Test aus und finde die Ursache“, bekomme ich oft ein ausreichend brauchbares Ergebnis. Inzwischen ist das fast immer mein erster Schritt
Ich denke, in deiner Sicht steckt ein Stück Wahrheit. Aber die Geschäftswelt hat eine enorme Sehnsucht nach „Neuordnung“. Riesige Geldmengen wollen in kurzer Zeit hohe Renditen, und Fondsmanager verlieren ihren Job, wenn sie Trends verpassen. Für CIOs oder CEOs gilt dasselbe. Der Wettlauf um AI-Einführung ist wie ein nukleares Wettrüsten praktisch nicht mehr aufzuhalten. Im Kern ist das für niemanden wirklich gut. Aber weil alle anderen aufspringen, kann man selbst auch kaum außen vor bleiben. Menschen waren auch schon vor dem Auto glücklich genug. Doch mit dem Auto wurden Städte umgebaut, die Abstände zwischen Gebäuden größer und Pendeln zur Normalität. AI verändert auf ähnliche Weise den Kontext, in dem wir arbeiten. Jetzt entsteht die Erwartung, dass alle AI nutzen müssen, und irgendwann fühlt es sich wie eine Grundvoraussetzung an. Allgemeiner gilt ohnehin: Von den Produkten, die Wissenschaft und Technik hervorgebracht haben, war fast nichts ein echtes menschliches „Grundbedürfnis“. Technologie schafft das Problem und verkauft dann die Lösung dazu. Das Problem existierte vorher gar nicht; erst nachdem die Lösung da ist, wird es als Problem empfunden. Das ist eine zentrale Triebkraft von Business
Viele Meinungsbeiträge zu AI-Coding scheinen aus der Perspektive sehr erfahrener Software-Engineers zu stammen, gewissermaßen aus dem „Ivory Tower“. (Auch die betreffende Studie untersuchte nur „16 erfahrene Open-Source-Entwickler“.) Für Nicht-Profis sind diese Tools jedoch enorm wertvoll. Ich habe selbst etwas Programmiererfahrung, bin aber kein Profi — ich bin bildender Künstler. Früher hätten mich manche Dinge Tage gekostet, heute schaffe ich sie an einem halben Nachmittag. Ich habe vor zwei Monaten meinen Job gekündigt, um mich auf Game Development zu konzentrieren; mein Budget ist nicht üppig, aber Claude und ChatGPT behalte ich auf jeden Fall. Und wenn ich nachts um eins im Bett eine Idee aufschreibe, sie direkt an Codex übergebe und morgens aufwache, um sie auszuprobieren, fühlt sich das wirklich magisch an. Früher habe ich oft gezögert anzufangen, weil ich Sorge hatte: „Ist das wirklich der beste Weg?“ Jetzt ist Refactoring so leicht, dass diese Sorge weitgehend verschwunden ist. Der Nutzen liegt also nicht nur im eigentlichen Schreiben von Code, sondern auch darin, die psychologische Hürde zu senken. Ich verstehe natürlich, dass sich ein Großteil der Kritik in Wahrheit gegen das übertriebene Marketing dieser Tools und gegen die Erzählung richtet, „jetzt werden alle Engineers entlassen“
Ich bin 72 und habe 40 Jahre als Entwickler gearbeitet. So tief fokussieren wie früher kann ich mich nicht mehr, aber dank AI baue ich immer noch Dinge. Ich entwerfe die Spezifikation des Projekts, und der Agent übernimmt Implementierung und sogar Tests. Inzwischen programmiere ich nur noch zum Vergnügen