AI verlangt nicht weniger, sondern mehr Engineering-Disziplin
(charitydotwtf.substack.com)- Dass die Qualität von KI-generiertem Code gestiegen ist, ist kein Signal, Code Reviews aufzugeben, sondern verlangt in einer Umgebung, in der Code billig und schnell neu erzeugt werden kann, eine noch stärkere Validierungs- und Betriebsdisziplin
- Seit Opus 4.5 Ende 2025 kann KI zumindest bei gängigen Mustern Code erzeugen, der eher an einen Software Engineer auf mittlerem Niveau heranreicht – und das schneller und günstiger; agentic harnesses, Tool-Nutzung, Function Calling und MCP stützen diesen Übergang
- Da die Kosten der Codeproduktion nahezu gegen 0 gehen, sind Codezeilen nicht länger ein wertvolles Gut, das bewahrt werden muss, sondern eher ein neu erzeugbarer Cache, der das aktuelle Verständnis materialisiert
- So wie immutable infrastructure dazu geführt hat, laufende Server nicht zu reparieren, sondern zu ersetzen, wird im KI-Zeitalter bei Anwendungscode nicht die Änderung selbst wichtiger, sondern Verhaltensvalidierung, Characterization Tests, Capture/Replay, Traffic Splitting und Observability
- Nichtdeterministische Systeme verlangen Engineering-Disziplin wie Traces, Production Evals und schnelle Feedback-Loops, statt sich darauf zu verlassen, dass Menschen als Qualitäts-Gate durchhalten; KI hebt nicht auf, dass Software weiterhin Fachleute und Disziplin braucht
Die 2025 umgekehrte Ökonomie der Codeproduktion
- Während des größten Teils von 2025 war die Ansicht vernünftig und Mainstream, dass KI-generierter Code „slop“ sei und wohl auch bleiben werde
- Seit Opus 4.5 im November 2025 kann KI zumindest bei gängigen Mustern Code erzeugen, dessen Qualität der eines Software Engineers auf mittlerem Niveau ähnelt – deutlich schneller und günstiger
- Opus 4.5 ist weniger eine einzelne Ursache als vielmehr ein Tipping Point
- Ein agentic harness ist eine Code-Struktur, die ein LLM zusammen mit Tools in eine Schleife setzt
- Solche Harnesses wurden Mitte 2025 in realistischer Form nutzbar, mit Vorzeichen, die bis Ende 2024 zurückreichen
- Tool Use, Function Calling und MCP haben sich im Laufe des Jahres 2025 aufgebaut und zum Jahresende in allgemeiner Nutzbarkeit gemündet
- Beim ersten Wandel mochte Skepsis im Sinne von „Ich glaube es, wenn ich es sehe“ noch akzeptabel sein, aber wenn sich Wandel erneut mit derselben Geschwindigkeit zeigt, ist diese Haltung schwerer aufrechtzuerhalten
Code wird vom wertvollen Gut zum neu erzeugbaren Artefakt
- Die zentrale Veränderung im Jahr 2025 war die Umkehr der Ökonomie der Codeproduktion
- Code zu erzeugen war zuvor schwierig, langwierig und teuer, und wurde nun faktisch sofort möglich und billig
- Codezeilen verschieben sich vom Objekt, das man wiederverwendet und pflegt, hin zu etwas, das man verwerfen und neu erstellen kann
- Es gibt auch die Sichtweise, dass das eigentliche Produkt eines Software-Engineering-Teams ein geteiltes Verständnis ist
- Dieses Verständnis ist wie ein Cache in den Köpfen der Menschen gespeichert und wird mit GitHub-Commits und Production-Deployments auf die Festplatte geschrieben
- Aber menschliche Erinnerung vergisst leicht, stumpft bei Wiederholung ab und übersieht kleine Details
- Das mentale Modell driftet ständig von der Welt weg, der Nutzer tatsächlich begegnen
- Aus SRE-Sicht liegt das eigentliche Produkt eines guten Software-Teams in Production
- „Only prod is prod“
- Production sollte nicht als Ort nach der Entwicklung betrachtet werden, sondern als eine Phase der Entwicklung
Die Ähnlichkeit zwischen Phoenix Architecture und immutable infrastructure
- Honeycomb gab im August 2025 ein AI Mandate aus und kam als Devtools-Unternehmen zu dem Schluss, dass es sich mit den schwierigen Problemen der neuesten Technologie befassen muss
- Chad Fowlers Phoenix Architectures verbindet das Zeitalter von KI-Code mit immutable infrastructure
- Chad Fowler prägte 2013 den Begriff „immutable infrastructure“
- Relocating Rigor ist ein Text, den Martin Fowler in einer Thoughtworks-Meetup-Zusammenfassung erwähnte
- Der Kern von The Death and Rebirth of Programming ist das Prinzip, Laufendes nicht zu reparieren, sondern zu ersetzen
- immutable infrastructure, stateless services, containers, blue-green deployments und infrastructure as code teilen alle dieselbe Annahme
- KI erweitert diese Annahme von Infrastruktur auf Anwendungscode
- Wenn die Kosten des Neuschreibens sinken, werden Änderungen am Ort riskanter, Mutation sammelt Entropie an, und Replacement setzt sie zurück
- The Deletion Test fordert dazu auf, sich vorzustellen, die gesamte Implementierung zu löschen
- Wenn das Löschen Angst macht, liegt das weniger am Code selbst als daran, dass man das nötige Verhalten, unzulässige Fehler, stets einzuhaltende Invarianten oder die Kriterien zur Beurteilung der Korrektheit einer neuen Version nicht kennt
- Dass man auch nicht weiß, welcher gefixte Bug einen vergessenen Edge Case abdeckt, ist dasselbe Problem
- Das ist kein Code-Problem, sondern ein Evaluationsproblem
- Wenn Code der einzige Ort ist, an dem Wissen lebt, wird Code wertvoll
- Früher war die Arbeit, Code zu erzeugen, der Flaschenhals, deshalb war es vernünftig, Code wie ein dauerhaftes Asset zu behandeln
- Wenn Regeneration leicht wird, funktioniert Code eher als materialisierte Sicht auf Verständnis, die aktuell nützlich ist, aber weggeworfen werden kann, wenn sie veraltet
Code sollte sich so regenerieren lassen wie Server
- Der Wechsel von handgepflegten Server-Pets zu immutable-infrastructure-Cattle hinterließ die Lehre, dass Mutability ein Feind des Verständnisses ist
- Wenn man laufende Artefakte direkt im Betrieb repariert, entsteht Drift
- Drift macht Systeme schwer wartbar
- Honeycomb tötet jeden Dienstag per Cron den ältesten Kafka-Knoten
- Dadurch kann das Team sicher sein, dass Bootstrapping- und Balancing-Prozesse wiederholbar sind
- Daten sind regenerierbar; die wichtigen Zusagen liegen woanders
- Wenn sich Code nicht auf dieselbe Weise regenerieren lässt, ist das ein Signal, dass man ihn nicht gut genug versteht
- Man weiß nicht, welche Zusagen gemacht wurden
- Man weiß nicht, welche Abhängigkeiten brechen werden
- Meist findet man es erst heraus, indem man Dinge kaputt macht
- Langsame und schmerzhafte Migrations, Rewrites, der Austausch von Legacy-Code und strangler fig sind Beispiele dafür, dass Codezeilen zu viel Verantwortung tragen mussten
- Im Code waren Entwicklerabsicht, Nutzererwartung, implizites und explizites Verhalten sowie Spuren vergangener Bugs zusammengebunden
Nicht nur Codezeilen sind Gegenstand von Reviews
- Weil die Kosten für Wartung und Änderung von Codezeilen hoch waren, konnten sich andere Artefakte nicht ausreichend entwickeln
- Es fehlten Artefakte, um zu verstehen und zu diskutieren, wie sich Architektur verändert
- Oft ließ sich die Architektur selbst nur vage aus dem Code ableiten
- Die ideale Richtung wäre eher, Architekturdiagramme zu diskutieren und zu vereinbaren und dann den Code aus dieser Änderung neu zu erzeugen
- Man kann nicht einfach annehmen, dass KI allen Code anhand von Spezifikationen erzeugt und menschliches Verständnis umgeht
- Das gesamte Potenzial hängt davon ab, was eine spec ist oder sein kann
- Wer schmerzhafte Datenbank-Migrations erlebt hat, sollte wissen, wie schwer es ist, Nutzererwartungen in eine reproduzierbare und automatisierbare Form zu extrahieren und zu formalisieren
- Die Tools sind noch nicht da, aber die zugehörigen Ideen existieren bereits
- Dazu zählen Behavioral Tests, Characterization Tests, Capture/Replay und Traffic Splitter aus Operations und QA
- Diese Techniken beobachten und kodieren eher, was tatsächlich geschieht, als festzulegen, was richtig sein sollte
- Dazu gehört auch Observability im guten Sinn
Menschen taugen nicht als Qualitäts-Gate für Validierung
- Nichtdeterministischer Code in Production zwingt dazu, Dinge zu tun, die man schon früher hätte tun sollen
- Trace-Instrumentierung
- Tests und Evals in Production
- Die Behandlung von Production nicht als etwas nach der Entwicklung, sondern als Entwicklungsphase
- Das menschliche Gehirn ist nicht gut für Validierung geeignet
- Bei der fortlaufenden Prüfung repetitiver, kleiner Unterschiede ist es Maschinen unterlegen
- Wenn man die Rolle des Menschen auf die Fähigkeit als Qualitäts-Gate reduziert, wird Softwarequalität fragil
- Menschen können bei Kreativität, Inspiration und logischen Sprüngen noch lange eine Rolle spielen, aber sie als Instanz zu sehen, die Maschinen in der Validierung schlägt, ist schwierig
Die Schlussfolgerung im KI-Zeitalter ist die Rückkehr der Disziplin
- Dass der KI-Diskurs der vergangenen zwei Jahre für viele Engineers fremd und beängstigend wirkte, lag daran, dass manche Stimmen so klangen, als sei Software kein Engineering-Problem mehr
- „SaaS is dead“
- „Making AI great at coding was the strategy that unlocks everything else“
- Adam Jacob wurde als jemand betrachtet, der große Veränderungen bei Software-Jobs erwartet
- Wenn 2025 das Jahr des vibe coding war, wirkt 2026 wie eine Rückkehr zur Disziplin
- Weil KI Codezeilen auf dem Niveau eines Software Engineers auf mittlerem Niveau erzeugen kann, hat sich die Bandbreite möglicher Zukünfte auf instabile Weise erweitert
- Wissen in den Köpfen bleibt für KI unzugänglich, bis es im System kodiert ist
- Sehr wenige Software-Teams arbeiten mit schnellen, kurzen Feedback-Loops
- Der Anteil wird mit etwa 5 %, sicher unter 10 %, angegeben
- KI-Tools können diesen Arbeitsstil näher bringen als zuvor
- Dass allein KI ohne Engineering-Disziplin in naher Zukunft enorme Renditen erzeugt, ist kein großes Risiko, um das man sich sorgen müsste
- Viele Teams werden es versuchen, aber was Wert hat, wird nicht durch Disposability, sondern durch Durability getragen
- Nutzer wollen nicht, dass sich Buttons und Menüs bei jedem täglichen Login in Slack subtil verändern
- Sie wollen auch nicht, dass Finanztransaktionen nur in den meisten Fällen abgeschlossen werden
- Determinism verschwindet nicht
- KI ist keine Magie, und Software bleibt Engineering
- Technologie braucht Technologen
- In Zukunft müssen nicht nur Codezeilen überprüft werden, sondern ein breiteres Spektrum anderer Engineering-Artefakte
1 Kommentare
Hacker-News-Kommentare
Es ist inzwischen viel schwieriger zu unterscheiden, wer das System versteht und AI effektiv einsetzt und wer einfach nur LLM-Copy-paste verteilt, ohne irgendetwas zu verstehen.
Vor 2025 fielen Leute mit geringer Leistung oder solche, die sich nur durchschleppten, noch vergleichsweise auf, weil ihr Beitrag gering war, aber jetzt produziert jeder Engineer plausibel aussehende PRs, Code-Reviews, technische Designdokumente usw. in Massen.
Ein großer Faktor ist auch, dass die C-Ebene starken Druck ausübt, AI maximal zu nutzen, und aus Sicht jedes einzelnen Engineers ist es außerdem eine spieltheoretische Reaktion, möglichst viel zu produzieren.
Wir versinken völlig in plausibel aussehenden Dokumenten und Code und greifen dann wieder zu AI, um diese Menge überhaupt verarbeiten zu können.
Der Nachhall dieser Phase wird wohl eine eigentümliche Form von technischer Schuld sein, die sich besonders durch ihr Ausmaß bemerkbar macht.
LLMs mögen es, viel zu erzeugen und irgendetwas hinzuzufügen, aber wirklich fähige Engineers erzielen mit weniger Code und weniger beweglichen Teilen mehr Business-Ergebnisse.
Ich höre oft: „Ich möchte AI einsetzen, um den Prozess zu automatisieren, aber die Prozessdokumentation ist unvollständig, also hoffe ich, dass AI hilft.“
Selbst wenn man erklärt, dass man nicht aus dem Nichts Ergebnisse erzeugen kann, laufen alle AI-Diskussionen am Ende wieder in dieselbe Richtung.
Sogar die Lösung, die Dokumente für diese AI-Automatisierung zu erstellen, soll dann wieder AI sein — es wirkt wie ein Ouroboros, bei dem AI Dokumente erstellt, AI sie zusammenfasst und AI sie erklärt.
Mit Code wird genau dasselbe passieren: AI erzeugt Tausende Zeilen, und anschließend erklärt AI sie wieder.
Heute ist es dank LLMs viel zu leicht, allein aufgrund des Umfangs der Beiträge fleißig zu wirken.
Der Unterschied besteht jetzt darin, dass eine inkompetente Person buchstäblich um mehrere Größenordnungen mehr Output erzeugen kann als ein vorsichtiger, erfahrener Engineer.
PRs sind kein perfektes Gate, aber eines der wenigen Gates, die wir derzeit überhaupt haben, und es ist ziemlich klar, wer sich Mühe gibt und wer nicht.
Die Algorithmusfragen im Interview haben doch sicher alle herausgefiltert, die nur so tun, als hätten sie Systemwissen — oder nicht?
Ich stimme der Aussage zu: „Das ist kein Code-Problem, sondern ein Bewertungsproblem“ und „Code wird dann wertvoll, wenn Wissen nur im Code selbst lebt“.
Den ganzen Tag von AI geschriebenen Code zu lesen ist qualvoll und eine schreckliche Art, das Gehirn genau in den Momenten zu zermürben, in denen ein Mensch am kompetentesten sein müsste.
Beim manuellen Programmieren gibt es eine produktive und befriedigende Feedback-Schleife: Code lesen, schreiben, kompilieren oder ausführen und ihn so lange korrigieren, bis er tut, was man will.
AI-Code nimmt einem nicht nur die Hälfte davon ab, auch der letzte „Klick“-Moment ist weniger bewegend. Man kann sich nicht sicher sein, ob man sich auf dem Weg dorthin nicht irgendwo ein wenig selbst betrogen hat.
AI-generierten Code als einziges dauerhaftes Artefakt des Programmierens zu behandeln, ist eine Sackgasse für die Branche.
Was Charity als interessanten Arbeitsbereich zeigt und richtigerweise wegwirft, sind Architekturdiagramme und Spezifikationen.
Mein Verdacht ist, dass es eher um Prompts, Markdown-Pläne und Steuerungsanweisungen geht, die Menschen direkt selbst schreiben.
Wir müssen uns auf das konzentrieren, was wir als Menschen unmittelbar selbst erzeugt haben, denn das bildet die Grundlage für die Kernschleife „Ist AI meinen Anweisungen gefolgt?“ und schafft auch in Code-Reviews mehr Hebelwirkung.
Wenn man beim PR angekommen ist, hat man Claude vermutlich schon genug Input gegeben, um den Code erneut erzeugen zu können, aber der derzeitige Branchenstandard ist, die ganze Session wegzuwerfen und nur den Code auszuliefern. Das ist verkehrt herum.
Große Codeblöcke lassen sich von Menschen faktisch nicht reviewen, aber sobald LLMs beteiligt sind, scheinen viele das zu vergessen.
Jeden Tag kommt ein riesiger Haufen Code zur Review, und das ist wirklich zermürbend.
Trotzdem fühlt sich AI besser an, weil sie wenigstens dazu neigt, Regeln zu befolgen, wenn man sie aufschreibt.
Viele Offshore-Entwickler wiederholen dieselben Fehler jeden Tag aufs Neue.
Offenbar muss unser Unternehmen bessere Offshore-Entwickler einstellen.
Früher habe ich einen Teil meines mentalen Modells des Systems durch das Codieren selbst aufgebaut, heute entsteht er eher durch Code-Review.
Es wird schwieriger, die Details des Systems zu verstehen und im Gedächtnis zu behalten, was nicht überrascht, wenn man bedenkt, dass Informationen, die man selbst „erzeugt“ hat, besser im Gedächtnis bleiben als Informationen, die man nur gelesen hat.
Ich übertrage gerade Erkenntnisse aus der Pädagogik auf die Ausweitung von Code-Reviews, und wenn dir das etwas sagt, würde ich gern darüber sprechen.
Als Behelf könnte man Claude vielleicht eine Sitzungszusammenfassung als Teil einer Commit-Message schreiben lassen, aber ich wüsste gern, ob es dafür strukturiertere Werkzeuge auf höherer Ebene gibt.
Wenn man überprüfbaren Code möchte, der zu einem gut entworfenen Plan passt, muss man im Grunde Pseudocode schreiben und AI ihn übersetzen lassen.
Dann fragt man sich ohnehin, warum man AI überhaupt den Code schreiben lässt.
Ich persönlich finde es spannender, selbst zu planen, zu schreiben und zu debuggen. Genau das war schließlich der Teil, durch den ich Programmieren überhaupt lieben gelernt habe.
Ich denke in letzter Zeit wirklich oft darüber nach
Ein großer Teil meiner Intuition zur Softwareentwicklung basiert auf 25 Jahren Erfahrung damit, „wie lange es dauert, bestimmten Code zu schreiben“
Wenn ich überlege, ob ich eine Prüfung für einen Edge Case hinzufügen soll, der nicht gleich alles kaputtmacht, aber etwas unschön werden könnte, wenn jemand darauf tritt, dann überspringe ich das vielleicht, wenn dafür ein paar Stunden mehr Code nötig sind
Aber wenn es nur ein Prompt ist, warum sollte ich es dann nicht tun?
Um ein neues Feature leichter verständlich zu machen, wäre ein dedizierter API-Explorer schön, aber früher hätte sich die Investition wohl nicht rechtfertigen lassen
Wenn es mit Codex aber nur 10 Minuten dauert, sieht die Sache anders aus, und genau so war es auch: https://tools.simonwillison.net/datasette-extras-explorer#ur... auch in den Release Notes verlinkt https://docs.datasette.io/en/latest/changelog.html#extra-sup...
In größerem Maßstab gibt es Projekte, die ich früher gar nicht erst in Betracht gezogen hätte. Eine benutzerdefinierte Bibliothek zum Parsen von SQLite-
SELECT-Abfragen zu brauchen war zwar real, aber nicht wichtig genug, um mehr als eine Woche darauf zu verwendenJetzt ist das aber machbar: https://github.com/simonw/sqlite-ast
Wenn man sagt, dass es wertvoll ist, schneller mehr Codezeilen produzieren zu können, werden manche Leute sehr wütend und schauen darauf herab
Natürlich ist es dumm, Output in „Codezeilen“ zu messen
Aber die Zahl validierter Codezeilen, die Wert liefern, zu messen, ist nicht dumm, und jetzt können wir das schneller tun
Google ist wertvoll, weil es Daten absaugt und damit Werbeumsätze erzeugt und weil seine Ausgaben im Verhältnis zu den Einnahmen gering sind
Und all diese „Wetten“? Lustig, und was ist daraus geworden?
Ingenieurskunst um der Ingenieurskunst willen hat für die Wirtschaft keinen Wert, ist also bedeutungslos
Die kalte Wahrheit, die niemand hören will, ist: In einer gegebenen Wirtschaft zu einem bestimmten Zeitpunkt kann nur eine begrenzte Menge existieren, und nur das, was wertvoll und wirtschaftlich tragfähig ist, überlebt
Vielen ist das egal, aber manchen eben nicht
Der Beitrag hat mir gefallen, und da viele andere Kommentare offenbar anderer Meinung sind, schreibe ich mal auf, wie ich das sehe.
Wenn ich in einer neuen Codebasis möglichst schnell zu jemandem werden will, der sinnvoll beitragen kann, gehe ich zuerst direkt zu von Menschen geschriebener Dokumentation.
Ich schaue nach, welches Problem dieses System ursprünglich lösen sollte, was das ursprüngliche Design war, was die größten Probleme sind und wer es heute benutzt.
Wenn man das weiß, kann man vermuten, warum es so gebaut wurde, und das Lesen des Codes wird sehr viel einfacher.
Auch dieser Blogpost war populär: https://blog.gpkb.org/posts/just-send-me-the-prompt/
Charity scheint ein sehr altes Problem zu sehen und zu erwarten, dass neue Technik zu einer neuen Lösung führen wird.
Vermutlich würde sie nicht sagen, dass die aktuelle Tool-Generation das Ende der Geschichte von AI-Softwareentwicklung ist.
Es geht auch nicht darum, einfach ein Designdokument bei Claude code abzuladen und dann zu verschwinden. Auch Designdokumente sind nicht vollständig; beim Onboarding muss man mit Menschen sprechen und auch alte Tickets sowie Postmortems lesen.
In der Produktion machen wir heute Infrastructure as Code, weil wir es hassen, wenn schwer nachvollziehbar ist, warum die Infrastruktur in ihrem aktuellen Zustand ist.
Bei Codebasen ist der Grundzustand ebenfalls, dass schwer nachzuvollziehen ist, warum sie in ihrem aktuellen Zustand sind, und das ist ein Problem, das schon vor „Programming as Theory Building“ beobachtet wurde.
Deshalb scheint die Erwartung zu sein, dass sich die Softwareentwicklung ähnlich wie die Infrastruktur in Richtung von Tools bewegen wird, die klarer machen, „warum der Code seinen aktuellen Zustand hat“.
Wenn man in eine neue Codebasis kommt, ist es natürlich richtig, zuerst mit Menschen und menschlich geschriebener Dokumentation zu beginnen, aber in vielen Engineering-Teams gibt es so etwas überhaupt nicht.
Entscheidungen werden im Kopf eines einzelnen Engineers oder in nicht gespeicherten Chats getroffen, und die Spezifikation bestand aus ein paar Notizen in einem Ticket, das beim Aufräumen gelöscht wurde oder beim Wechsel des Tracking-Tools verlorenging.
Es gibt keine Karte der Codebasis oder der Features, keine ADRs, und die Observability ist minimal.
Am Ende bleibt nur der Code, also muss man den Code lesen, um herauszufinden, was passiert, und den Engineer fragen, der zuletzt in dem Bereich committed hat, ob er sich noch erinnert, warum es so gemacht wurde.
Wenn jemand etwas ändert, geht dann mitunter auf der völlig anderen Seite der Codebasis etwas kaputt, das man für völlig unabhängig gehalten hatte.
Es stimmt zwar, dass AI mehr Disziplin erfordert, aber theoretisch ist diese Disziplin sehr viel leichter zu lernen, als ein guter Engineer zu werden.
Um vor 20 Jahren guten, skalierbaren C-Code zu schreiben, musste man entweder ein Genie sein oder sich der Technik wirklich verschreiben.
Man musste unzählige Tools wie ASan, LSan, UBSan, TSan und GDB in- und auswendig kennen, und wenn man auch noch DWARF-Dateien direkt lesen musste, war es noch viel schlimmer.
Das in kurzer Zeit wirklich zu meistern, war praktisch unrealistisch, und gleichzeitig musste man noch Systemdesign lernen, was fast eine orthogonale, eigene Fähigkeit ist.
Heute reicht es, die Gefahren der verwendeten Sprache und des Frameworks zu kennen, dem LLM zu sagen, dass es darauf testen soll, die Infrastruktur zu haben, um zu prüfen, ob ausreichend getestet wurde, und dann die tatsächlichen Tests und die Implementierung zu lesen.
Rust zu lesen und zu verstehen ist sehr viel einfacher, als die magisch wirkenden Fehler zu debuggen, die bei der Rust-Entwicklung auftauchen.
Zu erkennen, dass ein bestimmtes Szenario einen Loom-Test braucht, und ein Tool zu bauen, das feststellt, ob er wirklich geschrieben wurde, ist ebenfalls einfach.
Selbst wenn man weiter C oder Zig verwendet, ist es sehr viel leichter zu wissen, wann man welches Tool einsetzen muss und das zu erkennen, als jedes Tool einzeln zu meistern.
SQL zu lesen ist nicht schwer, und fast die Hälfte aller Menschen im Business kann das auch. Python ist nur ein klein wenig schwieriger, und selbst Rust kann man mit einem 50-seitigen Leseguide verstehen — ein sehr kleiner Preis im Vergleich zu den Kosten von zehn Jahren Trial-and-Error.
Der Weg von „LLMs funktionieren auf unbekannte Weise“ über „also braucht man mehr Disziplin“ zu „also ist alles in Ordnung“ ist für mich nicht klar.
Ich stimme zwar zu, dass alles in Ordnung ist, aber ich halte diesen Gedankengang nicht für einen klaren Pfad dorthin.
Wer den Willen hat, Dinge wirklich zum Laufen zu bringen, und sich ein wenig Zeit nimmt zu verstehen, was sie scheitern lässt, kann mit LLMs enorm viel erreichen.
LLMs werden die Situation eher noch sehr viel komplexer machen, weil sie die Kosten dafür, komplexe Dinge zu bauen, fast auf null senken.
Engineering hatte schon immer mit Disziplin und damit zu tun, Dinge zum Funktionieren zu bringen, aber früher brauchte man einen ganzen Satz an Vorwissen, um überhaupt wertvoll zu sein.
Das meiste davon ist jetzt verschwunden, und alles ist viel leichter geworden als früher.
Disziplin ist weiterhin nötig, aber verglichen mit zehn Jahren im Feuer ist Disziplin billig.
Ich habe gerade eine Woche damit verbracht, diesen ungefähr 200 Zeilen langen PR zu prüfen: https://github.com/ncruces/wasm2go/pull/37
Er wurde von einem erfahrenen Nutzer eingereicht, und vermutlich hat er auch ein führendes LLM dazu befragt.
Trotzdem fühlte sich etwas daran falsch an. Ich habe es nicht verstanden und hatte nicht vor, es zu mergen, ohne es zu verstehen.
Ich hatte auch den Verdacht, dass es auf eine Weise falsch war, die später Probleme verursachen würde.
Also habe ich es auf vier Arten geprüft: verstehen und verbessern, es mit einem besseren Algorithmus machen, das Problem upstream beheben und so vermeiden oder es von Grund auf neu so schreiben, dass es zu meinem Kopf passt.
Ich erwartete, dass die Antwort die zweite oder dritte Variante sein würde, aber die zweite war zwar die richtige Antwort, hätte jedoch bedeutet, das Projekt von Grund auf neu zu machen, und bei der dritten hatte ich wirklich gehofft, dass sie funktioniert, aber das tat sie nicht.
Am Ende wurde es eine Mischung aus der ersten und der vierten, und ich bin noch nicht völlig sicher, aber jetzt verstehe ich immerhin das Problem und die Lösung.
Natürlich halte ich meinen Ansatz für besser.
Trotzdem habe ich auf beiden Seiten die Kommentare entfernt und das LLM das Review machen lassen.
Das LLM antwortete, der ursprüngliche PR sei offensichtlich besser, und als ich erklärte, warum das nicht so ist, antwortete es, dass ich recht hätte.
Wenn ich es mit Kommentaren versuche, sagen die LLMs, meines sei besser. Das liegt daran, dass ich das eigentliche Problem gefunden habe.
Aber ich weiß nicht, ob sie sagen, meines sei besser, weil ich sie dazu gelenkt habe, das zu sagen.
Beim Lesen hatte ich den Eindruck, dass das Sprichwort „Alle Modelle sind falsch“ vergessen wurde
Das ist auch ein häufiger Fehler von Leuten, die „realistische“ „Simulations“-RPGs mögen
Wenn man etwas umfassend genug modelliert, wird das Modell einfach zum Gegenstand selbst
Um ein Ortsmodell zu erstellen, das alle Details eines realen Ortes enthält, bräuchte man ein Modell im Maßstab 1:1, und das wäre letztlich nur eine Kopie dieses Ortes
Ein Prompt für ein Modell, der genug Planung enthält, um 100 % der Systemfunktionalität zuverlässig nachzubilden, ist wahrscheinlich der Source Code dieses Systems selbst
Ich habe mich oft gefragt, ob ein großer Teil von IT und Programmierung nicht einfach nur daraus besteht, gut verstandene Bausteine zusammenzusetzen
Vor 8 Jahren habe ich darüber nachgedacht, warum man LLVM nicht durch ein viel einfacheres System ersetzen und handgemachte Optimierungen nicht durch einen einfachen KI-„Optimierer“ austauschen kann
Ich dachte, man müsse nur ein Training darauf machen, einfachen Compiler-Code in „optimierten“ Code umzuwandeln, aber der damalige Konsens war, dass KI-Systeme kaum zuverlässig genug korrekten Code erzeugen können, um brauchbar zu sein
Wenn KI nicht einmal solchen Low-Level-Code ersetzen kann, dann müssten High-Level-Probleme doch offensichtlich noch viel weiter entfernt sein
Trotzdem setzen die Leute KI bei High-Level-Problemen ein
Meine Hypothese ist, dass ein großer Teil moderner digitaler Technik einfach Plug-and-Play ist
Ich erinnere mich daran, dass auf HN vor 2023 alle die Verringerung der Codezeilen als das stärkste Senior-Merkmal gefeiert haben
Es ist nur so, dass die Strömung zu stark ist, um gegen die Flut von LLM-Codezeilen anzuschwimmen und das Rennen zu gewinnen
Und ich stimme auch nicht der Annahme des Artikels zu, dass LLMs guten Code schreiben können
Sie schreiben funktionierenden Code, aber er sieht aus, als hätte ihn ein Demogorgon geschrieben, und wenn man ihn ansieht, wird einem etwas übel
Er ist schlecht, aber auf eine Weise schlecht, wie ein Mensch ihn niemals schreiben würde
Es ist ein anderes Unbehagen als beim Lesen von Spaghetti-Code eines Juniors, eher eine Art Ekel, als würden irgendwo tief im Bauch Eier von Cthulhu schlüpfen
Ich erinnere mich an einen Senior in einer früheren Firma, der vom Eintritt bis zur Beförderung zum Manager nur Code entfernt hat
Dieser Artikel hat mir keinen Spaß gemacht zu lesen
Die einzelnen Sätze und Absätze waren in Ordnung, aber als Ganzes wirkte er zerstreut und, wenn ich so sagen darf, bedeutungslos
Es waren wirklich viele Worte, aber tatsächlich wurde sehr wenig gesagt
Zum Beispiel ist die Formulierung, dass sich 2025 die Ökonomie der Codeproduktion umgekehrt habe, nicht präzise
Früher war der Herstellungsprozess eher streng additiv wie 3D-Druck, jetzt ist es eher so, dass er um einen subtraktiven Prozess wie CNC-Fräsen ergänzt wurde
Die geforderte „Form“ hat sich kaum verändert, und wenn man auf bestimmte Toleranzen achtet, hat sich auch der menschliche Aufwand nicht verändert
Man muss Produkte immer noch in dem Maß wertschätzen, wiederverwenden, pflegen und kuratieren, das der Markt verlangt
Ich stimme auch der Aussage nicht zu, dass „Codezeilen kein ideales Artefakt zum Reviewen sind“
Was bedeutet hier überhaupt „ideal“?
Als ich jung war, galt bei jeder Prüfung die Regel „Zeige den Lösungsweg“
Der Grund war, dass man nicht nur das morgen erscheinende Produkt verbessern wollte, sondern auch die mentalen Modelle und Denkprozesse der nächsten Generation
Der Sprachstil war wirklich schwer zu verfolgen, und auch der Kern des Textes sprang nicht ins Auge
Wenn ich solche Texte sehe, werde ich noch skeptischer gegenüber der Behauptung, Software-Engineering-Jobs würden verschwinden
Die Arbeit eines Software Engineers im Jahr 2026 ist anders als 2020 und erst recht anders als 1990; warum sollte ich also dieser falschen Dichotomie glauben, dass die Arbeit 2026 entweder unverändert bleibt oder vollständig verschwindet?
Als ich vor sehr langer Zeit bei Google gearbeitet habe, war die Vorstellung, allen Code zu reviewen, für mich neu
Davor war es bei MS so, dass Code auf CDs gebrannt und in Kartons gepackt wurde, sodass das meiste bis zu einem risikoreichen Zeitpunkt am Ende des Projekts kaum reviewt wurde
Zwischen 2000 und 2004 hat sich die Art, wie Software Engineers ihre Zeit verbringen, drastisch verändert, und ich denke, es wurde besser, weil das gemeinsame Verständnis zunahm und Zusammenarbeit gefördert wurde
Wenn KI Code schreibt und Menschen mehr Zeit mit Reviews verbringen, muss das nicht nur schlecht sein
Wenn KI-Code aber gut genug wird, wird man gründliche Reviews als optional ansehen
Dann wird die Arbeit von Software Engineers sehr anders aussehen, und sie werden weder viel Code schreiben noch viel Zeit mit Reviews verbringen
IDEs könnten wie der Dodo verschwinden
Der Schwerpunkt könnte sich auf Zielvorgaben und das Aufsetzen von Tests verlagern, damit KI-Coding-Teams nicht vom Kurs abkommen
Software Engineers, die gut wissen, wohin ein Projekt steuert, könnten mehr Zeit für Architektur aufwenden, weil man nicht möchte, dass die KI Dinge ständig neu schreibt, wenn sich das Ziel vernünftig ändert
Man könnte auch mehr Zeit für Exploration aufwenden: etwas auf eine Weise bauen, dann auf eine andere und dann noch auf eine dritte, danach vergleichen und aus verschiedenen Ansätzen neue Ideen erzeugen
Ich habe keine besseren Vorhersagen als andere, aber ich widerspreche entschieden der Ansicht, dass die Rolle verschwindet, und befürworte, dass sie sich weiterentwickelt, wie schon oft zuvor. Nur war es vielleicht noch nie so schnell wie jetzt
Ich halte die Aussage „Wir behandelten Code als etwas Dauerhaftes, weil die Arbeit zur Produktion von Code der Engpass war“ für falsch
Code wurde als dauerhaft betrachtet, weil er als Single Source of Truth galt
Computer führen keine Dokumentation aus, sondern Code
Wenn ein Anforderungsdokument dem Code widerspricht, ging man standardmäßig davon aus, dass das Anforderungsdokument falsch ist
Man kann Code nicht von der Spezifikation trennen. Der Code ist die Spezifikation